p2panda: building local-first applications that survive a bad connection

Broadcast-only, and why that is the whole premise

p2panda aims to provide everything you need to build modern, privacy-respecting and secure local-first applications, and the design decision that shapes everything else is stated plainly: p2panda is broadcast-only at its heart.

That means any data sent is not addressed to one recipient but broadcast, and every node that can hear it receives it. The consequence the project draws is that this makes any data not only offline-first but also compatible with post-internet communication infrastructure, such as shortwave, packet radio, Bluetooth Low Energy, LoRa or simply a USB stick.

That is a strong claim and it is the interesting part of the project. A protocol that assumes a reliable, addressed, bidirectional transport cannot run over a LoRa link or a shortwave radio, because those give you a sender, a receiver and no guarantee of delivery, ordering or delivery at all. A broadcast protocol with CRDT-based merge semantics can, because a message that arrives late or twice still converges.

So the transport-agnosticism is not a feature bolted on. It is the reason the data model is shaped the way it is. The stated goal is that collaboration, encryption and access control work even when operating over unstable or ephemeral connections, and the project says it is actively working alongside researchers to design and implement resilient solutions for that.

The other stated design choice is the modular approach. Projects pick what they need and integrate it with minimal friction, and the project connects that to a wider, interoperable peer-to-peer ecosystem which outlives framework lock-in.

Eleven crates, and the boundaries between them are the design

The crate list is where the architecture is visible, and each entry has a clear job.

p2panda is the out-of-the-box API for application developers, and it is where the project documentation sends you first. p2panda-net is data-type-agnostic p2p networking, discovery, gossip and local-first sync. p2panda-discovery is the confidential topic and node discovery protocol. p2panda-sync is local-first sync for append-only logs and traits to build your own.

Then the storage and transfer pieces. p2panda-blobs is for efficiently sending, receiving and storing very large files, which is a separate concern from the sync protocol because a large blob should not be merged by a CRDT. p2panda-store is the interfaces and implementations to store p2panda data types in databases, memory or file systems, so the storage backend is pluggable. p2panda-stream is a collection of various methods to process your p2panda data streams before they reach your application.

And the three that are about trust rather than transport. p2panda-spaces is data encryption for multi-device groups. p2panda-encryption is decentralised data and message encryption for groups with post-compromise security and optional forward secrecy. p2panda-auth is decentralised group management with fine-grained, per-member permissions.

The key line about interoperability sits at the top of that list. Many of the Rust crates operate over raw bytes and are fully compatible with your own data types and any CRDT. So the sync and encryption layers do not impose a document model on you. You can bring your own types, or your own CRDT, and the framework handles the transport and the trust.

Underneath, the project uses existing libraries and well-established standards, naming iroh, BLAKE3, Ed25519, CBOR, TLS and QUIC, chosen as long as they give the radical offline-first guarantee needed.

Getting started, and the three ways in

There are three entry points, and they correspond to three levels of commitment.

The fastest path is the high-level p2panda API, whose documentation is on docs.rs. That is the crate to reach for if you are building an application and want working sync, encryption and permissions without designing the protocol.

For more low-level hacking, the project documentation points at the list of libraries, and each of the eleven crates is published on crates.io individually, so you can depend on p2panda-core alone if that is all you need.

The third route is other languages. There is experimental support for bindings of the high-level API into alternative programming languages and flavours: p2panda-gobject provides an introspectable GLib and GObject API for various languages, and p2panda-ffi provides Node.js, Python and Go support via UniFFI. The word experimental is doing real work there, and the GLib and GObject route is the one that opens the door to a language ecosystem that is not Rust.

The repository is a Cargo workspace with resolver 2 and thirteen members, the eleven published crates plus a fuzz directory. Each crate is versioned together at 0.7.1, which is the current release, and the workspace pins the shared dependencies centrally: blake3 for hashing, serde and serde_bytes for serialisation, hex, tokio with default features off, tokio-stream, tokio-util, futures-channel, futures-util, futures-test, rand and rand_chacha, pin-project, thiserror, tracing and tracing-subscriber, mock_instant, static_assertions and test-log.

The dependency choices say something about the design. tokio with default features disabled, futures-channel and futures-util, pin-project and static_assertions are the marks of an async library that is careful about its runtime footprint and its feature flags. serde_bytes is there because the crates operate over raw bytes, and hex is there because the protocols are byte-oriented rather than string-oriented.

Trust is three crates: encryption, spaces and permissions

The security side of p2panda is where the project is most specific, and it is worth separating the three concerns because they answer different questions.

p2panda-encryption is the cryptographic core: decentralised data and message encryption for groups with post-compromise security and optional forward secrecy. The direction of those two properties is what makes this more than ordinary group encryption. Forward secrecy is the familiar one, meaning past messages stay unreadable if a group key is later compromised. Post-compromise security is the other, and it means the system recovers from a key compromise rather than requiring every member to be trusted again. On a network with unstable or ephemeral connections, where a peer might be offline for weeks and a session key might be sitting in memory somewhere the whole time, that property is doing real work.

p2panda-spaces is the multi-device layer on top: data encryption for multi-device groups. A group of people is not the same as a group of devices, and a phone that joins a space has to encrypt to the other devices of the same person without being able to read that person's other spaces. That separation is what the crate is for.

p2panda-auth is the group management layer: decentralised group management with fine-grained, per-member permissions. The topic list on the repository includes access-control, group-encryption, crdt, local-first, offline-first, p2p and stream-processing, and the auth crate is where the access-control part lives. Per-member permissions in a decentralised group means the authorisation data is itself replicated and reconciled, which is a substantially harder problem than a server checking a role column.

The combination is the point. Encryption without a membership model leaves you unable to revoke anyone, and a membership model without encryption leaves the group list readable by the whole broadcast domain. Putting them together in a protocol that assumes a lossy network is what the project is building.

Sync, storage and blobs are separate problems

The remaining crates split along a boundary that is easy to miss and expensive to get wrong, which is the difference between merging data, moving data and storing data.

p2panda-sync handles local-first sync for append-only logs. Append-only is the constraint that makes CRDT merging tractable: if the only operation is append, then two replicas that have seen different subsets of appends can be merged by taking the union, and the merge is commutative, associative and idempotent, so a message that arrives three times or in the wrong order changes nothing. The sync crate is where the traits to build your own live on top of that.

p2panda-store is the persistence layer: interfaces and implementations to store p2panda data types in databases, memory or file systems. It is deliberately behind an interface, so the same protocol code runs against a database in production and memory in a test.

p2panda-blobs is the exception to the append-only model, and the separation is the point: it is for efficiently sending, receiving and storing very large files. A large file is not something you want to merge with a CRDT. You want to send it once, store it once, and have every replica refer to it. So blobs get their own crate with their own transfer logic, and the data model references them by hash.

p2panda-stream then sits in front of the whole thing, described as a collection of various methods to process your p2panda data streams before they reach your application. That is the hook for filtering, batching or transforming incoming data before your application code sees it, which keeps the protocol layer and the application layer separate.

p2panda-net provides the transport: data-type-agnostic p2p networking, discovery, gossip and local-first sync, and the discovery crate handles confidential topic and node discovery, which is the part that lets two nodes find each other without a directory server announcing who they are.

Where p2panda is the wrong tool

The first limit is stated at the top of the readme in a construction warning, and it should be the first thing you read. The library is under active development and the APIs are not yet considered stable for production use. Core data types and user-facing APIs may still undergo breaking changes. Stability guarantees will improve with the release of v1.0.0.

That matters more here than it would for most libraries, because the crate is a protocol. If your application and your peers both run p2panda, a breaking change in the wire format is not a compile error in your code, it is a node that cannot talk to a node. The version history supports the warning: v0.6.1 from 2026-05-22, v0.7.0 from 2026-07-07 and v0.7.1 from 2026-08-21, with the last push on 2026-10-20. The line is moving and the numbers are not yet a promise.

The second limit is that p2panda assumes peers are peers. A broadcast-only protocol with CRDT merge and per-member permissions is the right shape for an application where each participant holds their own copy of the data and nobody is the server. It is the wrong shape for an application with a central authority, a user account model, or a place where a moderator can centrally delete something, because those are questions a broadcast protocol answers differently and less efficiently.

The third is the operational cost of the security model. Group keys that rotate, membership changes that have to reconcile across replicas that may be offline, and permissions enforced without a server all add moving parts. The project is working alongside researchers on resilient designs for exactly this, which tells you the problem is not solved.

The fourth is the language story. The bindings are described as experimental, and the GLib and GObject route plus UniFFI is not the same as having a first-class Python or Node SDK. A team that wants to write the application in Python is going to be reading the Rust source as well as the generated bindings.

The fifth is the licence, and here the project documentation and the recorded licence field disagree in a way worth noting. The project documentation states the project is licensed under either of Apache License, Version 2.0 or the MIT license at your option, with contributions dual licensed the same way and without additional terms. The licence is recorded as unknown, and the licences live in a LICENSES/ directory with the Apache-2.0 and MIT texts named individually. A dual Apache-2.0 or MIT grant is one of the most permissive arrangements available, so this is a documentation detail rather than a legal obstacle, but a team with a policy check should read the two files in LICENSES/ rather than rely on the metadata field.

The funding note is worth a line too. The project has received funding from the European Union's Horizon 2020 research and innovation programme through the NGI-POINTER project under grant agreement No 871528, NGI-ASSURE No 957073, NGI0-ENTRUST No 101069594 and NGI0-COMMONS No 101135429. This is research-funded infrastructure, which is a reasonable explanation for the pre-1.0 status and a reasonable signal about the timeline to stability.

Editorial conclusion

p2panda is worth evaluating for a team building a local-first application that has to keep working over an unstable or ephemeral connection, because the broadcast-only design and the CRDT-based sync are the parts that are hard to retrofit, and because the crate split lets you take only the pieces you need rather than adopting a framework. It is the wrong choice if you need a stable API today, and the wrong choice if you are writing a client-server application where a central server is acceptable. Before you build on it, check the three things the project states plainly: that it is under active development with APIs not yet considered stable for production use and that core data types and user-facing APIs may still undergo breaking changes until v1.0.0; that the crates operate over raw bytes and are compatible with your own data types and any CRDT, so you can replace the sync layer but you write the mapping; and that the high-level entry point is the p2panda crate on docs.rs, with the lower-level crates there for when you need to go underneath it.

Frequently asked questions

Official sources

1. Issues
2. p2panda/p2panda on GitHub
3. README
4. Releases