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

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).