Comment by x3haloed | Hacker News Reader

Comment by x3haloed | Hacker News Reader

Parent Full thread

In my experience, Matrix and Riot are great. I love the protocol and concepts around it, and Riot was much higher quality than I expected it would be. Since trying it out for a while a few months ago, I have since abandoned it, however, because operating my own Synapse server was just too much work.

Specific pain points were:

- setting up SSL - getting Let’s Encrypt certs onto a server without a web server was a pain, and keeping them up to date was even worse. I would love to see ACMEv2 support integrated into Synapse for painless SSL setup.

- TURN server - if you want to use voice chat, you need to set up a separate TURN server, which has its own set of challenges. Again, I would love to see a solution integrated into Synapse.

- Video chat - Even with a TURN server in place, video chat requires a separate plugin to work. Jitsi is recommended, I believe. Yet again, I want this integrated into Synapse and Riot.

- Federation - Federation is part of what makes the Matrix protocol so great, but it was a huge pain to configure in Synapse. I spent hours to get it working, and it still had quirks about matrix.mydomain.tld vs mydomain.tld. I would like to see this simplified.

Probably the thing I was happiest about is that a ton of administrative settings are easy to work with in the Riot web client.

Keep it up, guys! I hope Matrix takes over the world, and I hope to come back some day.

Sorry to hear that :( There are two things we've tried to do to fix it:

1) Running Synapse really isn't that hard if you follow best practices... but I think we've done a bad job of communicating those best practices; instead Synapse's INSTALL.md lays out tonnes of different options and expects folks to pick their poison. I tried to fix this a few weeks ago by sitting down and recorded a dorky video to try to steer folks through best practices for setting up Synapse + certbot + Jitsi: https://matrix.org/blog/2020/04/06/running-your-own-secure-c.... (I need to extend it to coturn, but again, coturn should be straightforward. I don't think we should be baking TURN into Synapse though!). You could also shove everything in Docker and forget about it.

2) Peer-to-peer Matrix will let you get up and running without even needing a server. This is progressing alarmingly rapidly at the moment - https://p2p.riot.im is a version of Riot/Web which installs a homeserver (Dendrite) in your browser as a WASM service worker. It's alpha, but it mostly works pretty well, and is hopefully the shape of things to come - to let people have autonomy over their comms without ever needing to understand SSL, TURN, etc.

Thanks for the reply! I understand not wanting to re-implement entire servers within Synapse. Maybe an installer util would go a long way towards making setup more manageable. A step to automatically download and configure coturn, for example, could be very helpful.

I also understand that making things too turn-key (no pun intended) can be extremely difficult to do well and can also impede advanced configuration. But there is somewhat of an incongruity between the Matrix philosophy of keeping private servers vs. the expertise required to actually get that done.

P2P sounds really cool! I’ll try it out.

I’m getting the following error when using the P2P instructions. Is this likely an from an outage?

https://photos.app.goo.gl/myGNh77ukXWgqaVX9

https://p2p.riot.im is a webapp and runs in browser.

For the SSL part , I have been looking at Caddy as it seems to have pretty simple reverse proxy over SSL setup.

Reverse proxy with Caddy to get mindless automatic TLS is incredibly easier than any other setup for something you want to just work. I wish more projects supported reverse proxy setups better.

Synapse is a beast. I am looking forward to a more compact server to become viable. Matrix is working on Dendrite (https://github.com/matrix-org/dendrite) and there is Conduit (https://conduit.rs) as well.

Dendrite is rapidly approaching the point where it could be considered beta rather than alpha. However, it doesn't have any of the richness of Synapse yet, and it'll be a while before it can be used as a Synapse replacement. Meanwhile, Synapse keeps shrinking and is getting a lot of performance love - so personally I'd give keep giving Synapse a go for now. It's a smaller cuter beast these days :)

I've just tried it again a week ago (last time was ~2 years ago).

While there's definitely lots of improvement, it's still painfully slow and eats lots (like, 40% of 1 core) of CPU time. Took me a two attempts and a couple minutes (!) to join a relatively crowded room at #synapse:matrix.org on a freshly installed Synapse. I get it that there are over 12k people in there, but I haven't seen any other platforms having similar issues.

And this just doesn't feel right, design-wise. It could take a long while loading user pictures, presence states, ancient chat history and extra fluff. But seeing the most recent messages* and having an impression of joining the room should be nearly instantaneous.

Still a huge improvement over what it used to be. I remember waiting for no less than 10 minutes in a similar scenario, and it used to consume nearly 100% of CPU available.

*) For some reason, previews never worked for me. Despite being able to join, when just trying to peek I always get either the never-ending "loading" spinner or "this room can't be previewed" message.

So the problem is that if you join a room with lots of different servers, your server has to go handshake with each one to check its signing key in order to verify the events the server has emitted. #synapse:matrix.org is almost by definition one of the worst rooms for this, given most people in there are joining from their own server.

Solving this is an interesting challenge - one option could be to opportunistically trust events. Another could be to opportunistically fetch server signing keys. A better one would be to implement MSC1228, which switches all our IDs for public keys, which should make verification much easier and less burdensome.

In terms of peeking rooms over federation - sadly this still isn't implemented yet. https://github.com/matrix-org/matrix-doc/blob/matthew/msc244... is the proposal to fix that however.

Ah, so the server that hosts the room is not fully authoritative and messages from participants are all signed by their respective server owners?

This makes sense. Thank you for explaining!

Yup, precisely. In Matrix, rooms are not hosted by any single server - instead, they're replicated over all participating servers, much like git. But you need to check the provenance of the original messages to stop spoofing, hence needing to go check signatures the first time you interact with messages from a given server. Once you're joined, things should be fast however.

Food for your UI folks' thought:

Basically it sounds like you can download the messages relatively quickly from any old server, but the first-time process of verifying takes awhile. Maybe there's a way to show that visually, so you can get the messages up on screen earlier, even if the content isn't trusted yet?

It also seems like there might be gains from prioritizing connections with servers whose members chatted more recently.

Thanks for sharing! I’ll give them a look. As an aside, another protocol I would really love to see a simple implementation for is LDAP. Through my research, it seems that every LDAP controller server out there is just monstrous. I would love a cross-platform, turn-key solution that provides just the basics: user management, authentication, and replication. There has to be a better way to manage identities across internal networks.

Oh, and there is construct as well, not to be forgotten (C++ homeserver). It federates, and works with most clients, though it lacks a few features (link previews, a couple others). I've interacted with a few of its users over federation, though I haven't tried it myself.

Compared to synapse's resource use, it seems completely anemic (I've read that the lead developer makes it run on a 800 MHz pentium, though that could have been a joke).

https://github.com/matrix-construct/construct

https://matrix.org/docs/projects/server/construct

Reply on news.ycombinator.com