Specs
Specs
The Bonafide protocol specification and domain vocabularies.
The Bonafide specification is public and still a draft. Current version: v0.1.
What v0.1 means. The pre-1.0 number is deliberate. It signals that the spec hasn't yet taken public, external input, and that breaking changes are still possible. We expect to release 1.0 once the spec has gone through at least one full cycle of the change process with real outside participation. That's a milestone, not a date.
Reading the spec
| Chapter | What it covers |
|---|---|
| 00 Overview | Terminology and the two-layer model. |
| 01 Messaging | The message envelope, deduplication, and how messages are routed to handlers. |
| 02 Connections | The connection handshake, key exchange, and the router's role. |
| 03 Cross-Domain | Extending one connection across multiple apps and domains. |
| 04 Access Control | Which content a connection may receive, and the subscription mechanism that enforces it. |
| 05 Content Model | The contract content types follow, and how a domain declares its own. |
| 06 Propagation | Hop-limited resharing, and how update and delete ordering is resolved. |
| 07 Security | Cryptography, the threat model, and trust boundaries, including one known gap. |
| 08 Versioning & Governance | How the spec is versioned, how changes are made, and who stewards it. |
| 09 Identity & Credentials | The local credential a person uses to reach their own database. |
| Appendix: Worked Examples | A connection handshake and a cross-domain subscription traced against concrete example data. Non-normative. |
Domain vocabularies
| Domain | Status |
|---|---|
Pools (bonafide.pools) |
Draft v0.1. Versioned separately from the base spec. |
Messaging (bonafide.messaging) |
Not yet published. |
Reference implementation
A reference implementation exists today: a Bonafide agent library and a router service. It powers Pools. The specification repository defines the protocol that implementation follows, and doesn't contain the implementation itself.
Not in v0.1
Two things aren't specified yet. One is per-field schema subsets, meaning negotiating a reduced content shape for each connection. The other is moving an account between independently operated hosts. Both are known future directions.
Contributing
Anyone can open an issue or pull request. A proposal should name the chapter and section, describe a concrete scenario where two compliant implementations would disagree or a reader can't tell what's required, and say what, if anything, in the spec already touches on it. This keeps the process useful without being flooded by low-effort or generated submissions. How a proposal was drafted doesn't matter, but showing that you've worked with the spec does. Open an issue →