Make e2ee less reliant on the server

Although e2ee means that a server cannot read encrypted messages, a malicious server could still block encryption outright. In #construct:zemos.net, @ jason:zemos.net writes:

> If e2ee requires server involvement, it's going to be impossible to maintain encryption in hostile nation-states and environments like, for example, China
> It's too easy for someone like China to remove or mandate the removal of server support for e2ee
> Since servers are large and don't move, they're easy targets for national authorities
> Clients OTOH may be journalists, and may have more control over their device, etc.
> However if clients cannot use e2ee because it's been disabled by the server, it's a rather pointless endeavour
> and matrix becomes useless in an environment where encryption is paramount
> and this is not exactly a niche environment. china has a billion f***ton of users
(in a mark-to-market sense)
> so all i'm saying here ixnay on the server-support-ay

There are various issues that would need addressing, as there are many ways in which e2ee can be blocked, but reducing the number of e2ee-specific endpoints would be a start.

Currently, the server is involved in:

- storing and distributing device keys and one-time keys (the public parts)
- processing to-device messages for distributing megolm keys (to-device messages are generally not used except for in e2ee)
- notifications of device changes
- online key backups
- processing cross-signing keys (the public parts)

Some things that could be done are:

- moving some things to more generic mechanisms such as account-data or profiles-as-rooms
- moving some things completely off the server, such as onto a separate server that the user controls (e.g. for key backups), or something more p2p such as a DHT.

This may involve performing more processing on the client-side as some of the e2ee endpoints involve the server doing some work. For example, key backups involve the server choosing the "best" key when multiple keys for the same session are uploaded, and with cross-signing, the server ensures that the self-signing and user-signing keys are properly signed by the master key.

Start by reviewing the issue's list of server responsibilities for end-to-end encryption, including device keys, to-device messages, key backups, device-change notifications, and cross-signing. Compare the proposed generic, user-controlled, and peer-to-peer alternatives, then define which server dependencies should change and how clients would handle the affected processing.

Written by the indexing model from the issue text.