____ _ ___ __ _ _ __ ___ __ _____ _ __|___ \ _ __ _ _ ___| |_/ _ \ / _` | '__/ _ \ \ \ /\ / / _ \ | '_ \ __) | '_ \ | | | |/ _ \ __\// / | (_| | | | __/ \ V V / __/ | |_) / __/| |_) | | |_| | __/ |_ \/ \__,_|_| \___| \_/\_/ \___| | .__/_____| .__/ \__, |\___|\__| () |_| |_| |___/
Our aims are to:
- Bootstrap a permanent public P2P Matrix network
- Link it to the existing Matrix network to benefit from the existing content & users and make it actually usable.
We need a fully-featured production-ready homeserver which can be embedded into a range of clients, from mobile devices to web browsers.
- Synapse parity: (as of 05607d6)
- 🚧 Client-Server API: 86%, aim: >90%
- 🚧 Server-Server API: 93%, aim: 100%
- ✅ Embeddable database (SQLite3)
- ✅ WASM
- ✅ Android
- ✅ iOS
- ❌ Ensure memory usage of embedded instances is bounded e.g cache sizes.
- ❌ Ensure CPU usage of embedded instances is bounded e.g # spawned goroutines.
- Stability and Maintenance:
- 🚧 Test coverage >=80% for code used in embedded instances: 72.4% (as of 05607d6, sytest coverage only, excludes Complement and unit tests)
- 🚧 Active and timely (<7d) triage over main issue tracker.
- 🚧 dendrite.matrix.org metrics are healthy (Sentry, Prometheus)
We need a production-ready overlay network for P2P traffic.
- Experiment with existing P2P network stacks for use with Matrix:
- ✅ libp2p
- ✅ yggdrasil
- Create a custom P2P network stack which works for Matrix:
- ✅ Source-routed yggdrasil
- ✅ SNEK for improved routing
- ✅ Simulator to debug and stress-test the network
- Works on a range of transports:
- ✅ Public internet
- ✅ LANs
- ✅ Bluetooth LE
- Resilience to adversarial attacks:
- 🚧 Sybil attacks
- 🚧 Eclipse attacks
- 🚧 Keyspace collision attacks
- 🚧 Churn attacks
- 🚧 Root hijacking attacks
- 🚧 Malicious packet drop attacks
- ✅ Good (>80% median) packet arrival performance in Mobility tests
- Mobility is defined as 50 randomly placed nodes in a 1x1km square, each randomly moving 0-20m every 10s
- Mobility testing is performed for 360 iterations of node movement
- Packet arrival performance is measured using pings between a subset of randomly selected nodes at least 2 hops apart at each mobility step
We need to improve the Federation protocol to work with servers which frequently go offline and may have 1000s of servers (p2p nodes) in each room.
- ❌ Implement comprehensive Store-and-Forward event routing capabilities in Matrix to allow nodes to talk to each other even if they aren’t online at the same time. Matrix currently has limited support for this via backfilling events.
- 🚧 Improve event authentication rules when the majority of nodes in the room are unreachable.
- Change the protocol to include a State/Auth DAG in addition to a normal Room DAG, and ensure that the Auth DAG is shared with all servers in the room. This allows servers to authenticate any incoming event without needing to make additional API calls.
- Change the protocol to eagerly connect to servers to ensure we rapidly synchronise Auth DAGs, rather than waiting until the user sends a message.
- ❌ Improve semantic delivery of old events to clients to ensure that when old nodes come online clients don’t see lots of old messages.
- ❌ Support delivery of push notifications to P2P devices
- ❌ Extension: Improve delivery of media uploads (content ID based?)
- ❌ Extension: implement a better federation routing algorithm than full-mesh routing. This allows users to talk in very large rooms without O(n) scaling on the number of nodes in the room.
Bridging between P2P and Normal Matrix
We need a way to bootstrap the system with content and users. We can use the existing Matrix ecosystem to do this.
- ❌ A server which can bridge traffic between P2P and normal matrix e.g
@ed25519-key:server-name.comor a bridge.
- ❌ First-class support for P2P gateways in Matrix (e.g MSC for it) so any compatible room can use P2P rather than relying on a bridging server.
Antigoals at this point
- Account portability or multihomed accounts are out of scope. As a first cut, each P2P node will be its own user account (to avoid the initial release getting blocked on solving account portability)
- Avoid temptation to redesign all of Matrix; instead, do the minimal changes required to achieve the above goals.
- Avoid premature optimisation for metadata privacy. As long as we don’t design it out, we can ratchet up our metadata privacy at the federation level (e.g. by adding in per-room user IDs, sealed sender, mixnets etc) in subsequent phases.