Traditionally Matrix decentralises communication by replicating conversation history over a mesh of servers, so that no single server has ownership of a given conversation. Meanwhile, users connect to their given homeserver from clients via plain HTTPS + DNS. This has the significant disadvantage that for a user to have full control and ownership over their communication, they need to run their own server - which comes with a cost, and requires you to be a proficient sysadmin. In order to fully democratise communication and eliminate a compulsory dependency on a homeserver, we've started seriously working on making Matrix run as a P2P protocol by compiling homeservers to run clientside and using P2P transports such as libp2p - while seamlessly supporting all existing Matrix clients (e.g. Riot.im), bots and bridges with negligible changes. This work includes:

• Compiling Matrix homeservers (e.g. Dendrite) to efficiently run clientside
• Layering HTTPS over P2P transports such as libp2p (e.g. https://github.com/matrix-org/libp2p-proxy)
• Switching Matrix identifiers from @user:domain tuples to be Curve25519 public keys (MSC1228)
• Decentralising accounts so they can be hosted concurrently on multiple nodes (e.g. a mix of server-side and client-side homeservers)
• Experimenting with node discovery from DNS to DHTs and other mechanisms (e.g. gossip mechanisms)
• Experimenting with smarter bandwidth-efficient routing algorithms than full-mesh (e.g. combinations of spanning trees, overlapping spanning trees, gossip mechanisms)
• Making Matrix's low-bandwidth CoAP transport production grade
• Experimenting with metadata-protecting relay mechanisms rather than using full homeservers for server-side relaying.

In this talk we'll show off our progress so far, and lay out the path forwards over the coming year as we go from proof-of-concept to the live Matrix network.