815 karma · joined April 21, 2020
I don't mean to be snarky, it's just frustrating to be told that it's common sense that this wouldn't be the case, when it's come as a huge surprise to everyone I've mentioned it to.
That said, I love Matrix, big supporter of the project and of the team, etc etc. Just, there's a lot of work still to do!
document.getElementById
like I should have and everything worked fine. Like others in this thread, I recommend not relying on this behavior.For hosting, I believe the flagship host is Element Matrix Services [2]. It's made by the same organization that leads development (it is all FOSS) of Element and the reference server Synapse.
You can also self-host. Synapse is pretty slow and memory-hungry (it's written in Python), but for a small group it still fits pretty comfortably on a $5 DigitalOcean VPS. That's what I'm doing. It took less than an afternoon to set up (`apt install synapse` and then setting some config, mainly—there are a bunch of good guides online) and has been happily running ever since. Matrix is federated, so as long as you set up federation properly, you can seamlessly message anyone on any federated Matrix server. (Federation is opt-in.)
There's also Dendrite and Conduit, Matrix servers written in Go and Rust respectively, which are much leaner and faster. Both are still in beta and missing some features, but are definitely usable.
If you want to mess around with bots, I've had a lot of fun with both the Matrix Rust SDK [3] and JavaScript bot SDK [4]. Both are quite easy to get started with, and as of a few months ago both support E2EE pretty painlessly too (not totally pain-free though lol), which is cool.
Overall, the ecosystem is still maturing imo, but I've been using self-hosted Synapse and Element "in production"—it's me and my girlfriend's primary method of communication—for over a year now with only some minor UX hiccups (mostly issues decrypting E2EE messages in Element). I definitely encourage giving it a shot as long as you're willing to tolerate a few remaining growing pains.
[1]: https://element.io/get-started
[2]: https://element.io/matrix-services
<div onclick="aJavascriptFunction().then(r => setTimeout(anotherJavascriptFunction, 10000)">Do some stuff</div>
but if you don't know ahead of time whether or not it's async (or don't want to have to care, like hyperscript allows), then you'd need <div onclick="(async () => { await aJavascriptFunction(); setTimeout(anotherJavascriptFunction, 10000) })()">Do some stuff</div>But in reality, good regulation is good, and bad regulation is bad.
It sounds silly written out because it's a tautology, but if more people internalized it we could have much more productive conversations. Instead of going back and forth on whether regulation is good or bad, we should try to figure out which regulations are good and which are bad, and then try to get rid of the bad ones and pass more of the good ones.
Edit: actually, I think this would make a good submission. Looks like it hasn't been posted since 2017.
[0]: https://www.theatlantic.com/technology/archive/2017/04/the-t...
Looks like it's 500k calls per month per Apple Developer Program account, so essentially $99/yr. Not totally unreasonable pricing, although I wish I could buy it a la carte. It's a bit out of my price range for hobby projects. If I ever start developing apps for my family members (who mostly have iPhones at this point) though this will be a nice freebie to come with that. Ah well.
Edit: my bad for skimming too fast, I'm glad there's a REST API, that's unexpected and cool!
Also, in Chrome, if and only if you have the dev tools open, right clicking the reload button will give you a menu with the options "Normal Reload", "Hard Reload", and "Empty Cache and Hard Reload". The third option will ensure that requests initiated by JS or that otherwise weren't part of the page load also won't be served from cache.
Not quite really—I do enjoy my work and my time at my job, and I would sacrifice some compensation to work at a more interesting/meaningful/fun company. I don't price the enjoyment of 50% of my waking hours at zero, of course. But my primary purpose in working a job is making money, and I don't think that's anything to be ashamed about. I want to buy a house one day.
how to go about doing that is the meat of the article, and is worth reading if that sounds like something you would want to do.
This latter point matters a lot to me since the disk in question is a Raspberry Pi's SD card, which I've heard have a tendency to wear out quickly, so I wanted to avoid writing to it unnecessarily. And yeah, this system is fragile, not actually ACID, etc etc… but I'm the only one who relies on it (it's not even accessible on the public internet, only over my Wireguard VPN), so it doesn't matter if it breaks!
I will probably rewrite this service later, backed by either SQLite or Postgres, but writing it this way saved me a fair bit of thinking and lines of code, which was great for getting it off the ground and usable to me in like two hours.
That said, I love the idea this architecture. Might use it for whatever next dumb little web service I cook up! I love how this simplifies a lot of dev/deployment ops, perfect for a side project.