Last updated: 2026-06-10

                                        ____                      _   ___
  __ _ _ __ ___   __      _____    _ __|___ \ _ __     _   _  ___| |_/ _ \
 / _` | '__/ _ \  \ \ /\ / / _ \  | '_ \ __) | '_ \   | | | |/ _ \ __\// /
| (_| | | |  __/   \ V  V /  __/  | |_) / __/| |_) |  | |_| |  __/ |_  \/
 \__,_|_|  \___|    \_/\_/ \___|  | .__/_____| .__/    \__, |\___|\__| ()``
                                  |_|        |_|       |___/

Not yet, but as of 2026 we’re making progress again.

2026 update

P2P Matrix work has resumed at Element as of July 2026 thanks to funding from the Dutch Government.

We’ll update this site properly once we get a chance, but current status is:

• We’ve put together a dedicated lightweight embedded homeserver in Rust called Neutrino: https://github.com/element-hq/neutrino
  • It is not intended for standalone use, and is not yet secure for use in untrusted networks (e.g. it does not sign/check event signatures yet)
  • It only implements the very latest experimental room versions needed for P2P
  • The intention is to share its Rust code with the Synapse and Synapse Pro in future (rather than being a divergent evolutionary branch like Dendrite was, which meant halving efforts rather than converging efforts).
  • See the README for more caveats and details.
• Element X Android has a new P2P fork which embeds Neutrino: https://github.com/element-hq/element-x-android-neutrino
  • A quick and dirty armv8 APK build can be found here
• We’re not planning to build an overlay network. Instead, Neutrino currently uses Iroh for connecting over BLE and is designed for smaller meshes, in future using the normal Matrix network to backhaul between local meshes.

For more info, see the slides from DWebCamp 2026: P2P Matrix - A New Hope.

2020-2023 details below:

Check out the Introducing P2P Matrix and Introducing Pinecone blog posts for why we are doing this.

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.

Track the progress of P2P Matrix and join us at #p2p:matrix.org.

Dendrite

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%
• Embeddability:
  • ✅ Embeddable database (SQLite3)
  • ✅ WASM
  • ✅ Android
  • ✅ iOS
• Performance:
  • ✅ 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)

Pinecone

We need a production-ready overlay network for P2P traffic. Testing pinecone is done primarily using the simulator which allows for faster iteration times on protocol changes.

• 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

Matrix

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.com or 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.

Pinecone Releases

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

History

be58e8d - (2026-07-10) fix links again

2f931c8 - (2026-07-10) bump last updated date

29a4e57 - (2026-07-10) fix more links

a1a1c67 - (2026-07-10) fix links

8a01b4f - (2026-07-10) unbitrot the website CI

eec6bd8 - (2026-07-10) A new hope!

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