4 ms·

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,

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.

Arathorn 6y ago
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/msc2444/proposals/2444-peeking-over-federation-peek-api.md https://github.com/matrix-org/matrix-doc/blob/matthew/msc244... is the proposal to fix that however.
- drdaeman 6y ago
  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!
  - Arathorn 6y ago
    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.
    - smichel17 6y ago
      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.

Arathorn 6y ago

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/msc2444/proposals/2444-peeking-over-federation-peek-api.md https://github.com/matrix-org/matrix-doc/blob/matthew/msc244... is the proposal to fix that however.

drdaeman 6y ago
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!
- Arathorn 6y ago
  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.
  - smichel17 6y ago
    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.