____ _ ___ __ _ _ __ ___ __ _____ _ __|___ \ _ __ _ _ ___| |_/ _ \ / _` | '__/ _ \ \ \ /\ / / _ \ | '_ \ __) | '_ \ | | | |/ _ \ __\// / | (_| | | | __/ \ 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 430932f)
- ✅ Client-Server API: 93% (583/626), aim: >90%
- ✅ Server-Server API: 100% (114/114), 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)
- 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
- 🚧 Scales to meet global demand
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.
- ✅ Initial design & implementation in Dendrite
- ✅ Integrated into p2p demo apps
- 🚧 Robust to differing levels of use (many user rooms, encrypted rooms, different scenarios of varying offline-ness, etc.)
- 🚧 Improve event authentication rules when the majority of nodes in the room are unreachable.
- 🚧 Change the protocol to utilize a Power DAG, and ensure that the Power 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 Power 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.
v0.11.0 - Protocol broadcasts
v0.10.0 - Hybrid routing
v0.9.0 - Soft-state v2
v0.8.0 - QUIC Traffic
v0.7.0 - Traffic queues
v0.6.0 - Protocol Setup ACKs
v0.5.0 - Cryptographically signed protocol frames
v0.4.0 - Complete refactor
v0.3.0 - Hard-state v2
v0.2.0 - Hard-state v1
v0.1.0 - Soft-state v1
b77f2cc - (2023-07-06) Fix link to “Introducing P2P Matrix”
ef185e0 - (2023-05-01) Update federation section to reflect new Power DAG approach
9d6d5a8 - (2023-03-13) Update matrix protocol section to WIP
48b27f8 - (2023-01-23) Update progress on store & forward capability
9810cc5 - (2023-01-20) Reached 100% server-server sytest coverage!
d250309 - (2023-01-03) Bump synapse client-server parity
cb6ebdc - (2022-12-09) Add reference to pinecone simulator
fc19b51 - (2022-12-08) Update last updated date
e08469d - (2022-12-08) Add pinecone release tracking to page
6f7cecf - (2022-12-05) Update synapse parity numbers & latest dendrite commit
249b9e5 - (2022-11-15) Update synapse parity numbers
6503f12 - (2022-10-31) Change to github actions for site generation
92e23a2 - (2022-10-31) Mark s&f as in progress
01cfc28 - (2022-10-31) Update CS api metrics
20c640a - (2022-10-24) Remove AS API stats since they don’t matter