Hacker News new | past | comments | ask | show | jobs | submit login

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.


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


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.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: