Implementing an e2ee messenger would be way easier if it wouldn’t have to support federation. And you know what? If the clients support proper multi-server setups (like Mattermost and most IRC clients), I am totally fine with that.

@merlin in conclusion, Signal Protocol over IRC

@merlin I would like to hear your reasoning for this, I have some intuition that wants to say it's probably true but at the same time server-side message propagation is roughly an independent layer from E2EE?

@RunxiYu the issue seems to be that with federated e2ee you need to have all interacting servers on a version of your server software that is similar enough to not have breaking changes, and the same feature set overall. Especially when different server implementations interact. Furthermore the added complexity of implementing federated e2ee seems to make it hard to develop new Server implementations (this seems to heavily depend on the protocol though, XMPP has no problem with a variety of server software)

@merlin i think those are huge challenges to federated protocols in general and not necessarily related to e2ee... just that all modern federated chat protocols try to do e2ee in some sense or another so we kinda associate them?

@RunxiYu @merlin Not every modern federated chat protocol tries to do E2EE. ActivityPub is newer than Matrix and makes no attempt to do E2EE. Problems with E2EE compatibility between different implementations are mostly to do with the client software, not the server software, since E2EE does not usually require any support from the server. Not supporting federation does not help with this.