Joining big rooms is still slow because you currently have to check the keys of every server in the room before you know whether to trust the events in that room; we're fixing this with MSC1228 (using keys as identifiers so you don't have to separately check the keys).
Once you're in, though, performance has improved 2-3x over the last year, and there's easily 10-100x more improvements to be made one way or another. We're also about to add active/active clustering in Synapse at last, which should make bigger servers zippy.
In terms of receiving traffic after you've torn down the server; this is equivalent to getting people trying to talk SMTP to you on port 25 years after you've taken down your MTA. You can mitigate it by explicitly leaving all the rooms on your server before you tear it down, though; i've just filed a bug at https://github.com/matrix-org/synapse/issues/7551 to track maintaining a script to do so.
I love the idea of using public keys as identifiers, but to be honest the current proposal does NOT give me a warm fuzzy feeling inside.
First, you’re having the server generate keys for the users. This is at best a “code smell” —- even if it works for your particular security goals, it sure feels weird. Zoom recently got absolutely blasted (and rightly so) for doing something similar. Why not have the user generate their own keypair, and then the server can sign the public half, essentially giving you a cert.
Second, there’s a lot of places where you have a layer of indirection between old @user:domain id’s and the new public keys. As an attacker, I would see every one of those places as extra attack surface where I might be able to exploit some confusion.
I hope this doesn’t come off as excessively negative. Matrix is awesome and you’re all doing a great job tackling some huge problems.
Yup, that's the right link, but I think you've misunderstood the intention of MSC1228.
The user identity keys are not used for encryption, let alone end-to-end encryption. These are of course only ever created on clients, and never leave the clients.
Instead, this is just a proposal for how to determine what servers are allowed to host a given identity. The proposal also predates E2E - nowadays we might also sign the keys with your E2EE keys to lock the chain of trust to the client.
I get why the whole indirection from @foo:bar.com through to new public keys might also feel weird, but in practice we have that indirection today - as you resolve (say) an email address to a matrix ID. It's basically making the old matrix IDs equivalent to today's 3rd party IDs (email or phone number or whatever).
So yup, understood that it smells funny, but I think the concerns aren't entirely well-founded here. That said, the proposal is ~2 years old, and we'll be dusting it off and sorting it out in the coming months in order to support P2P and speed up room joins, and that might be the point where we tie it into E2EE keys (or not).
Once you're in, though, performance has improved 2-3x over the last year, and there's easily 10-100x more improvements to be made one way or another. We're also about to add active/active clustering in Synapse at last, which should make bigger servers zippy.
In terms of receiving traffic after you've torn down the server; this is equivalent to getting people trying to talk SMTP to you on port 25 years after you've taken down your MTA. You can mitigate it by explicitly leaving all the rooms on your server before you tear it down, though; i've just filed a bug at https://github.com/matrix-org/synapse/issues/7551 to track maintaining a script to do so.
Sorry you've had a crap time so far though :(