Protocol Specifications
Maturity: All Faberio protocol documents on this site are draft specifications. They define intended runtime behavior but are not yet validated by a reference implementation. Expect revisions during Phase 2 (reference Runtime) and Phase 3 (multi-node validation).
Current status: Runtimes are planned deliverables — not yet available.
These documents define the Faberio Protocol — the open, implementation-neutral contract for independently operated runtimes. They describe how nodes and users are expected to behave once a compatible Runtime exists; they are not documentation for a shipped product.
License: Protocol specifications and this documentation are published under Creative Commons Attribution 4.0 (CC BY 4.0). Reference Runtime and SDK source code will use Apache License 2.0. See Introduction — Licensing.
The reference Laravel Runtime (server, PC, laptop), NixOS module, and Community Hub demo described in the Implementation Roadmap will implement and validate these specifications. A Flutter Runtime for mobile devices is planned separately (Phase 4).
For positioning relative to other sync and self-hosting projects, see Related Work.
Maturity
| Document | Maturity | Notes |
|---|---|---|
| Object Identifier | Draft | Foundational — read first |
| Identity Model | Draft | Nodes, users, groups, devices, keys |
| Node Discovery | Draft | Information spaces, membership |
| Node Connectivity | Draft | P2P transport, NAT traversal, STUN/TURN policy |
| Distributed Database | Draft | Application-facing replicated data |
| Distributed File Storage | Draft | Application-facing replicated files |
| Data Access Control | Draft | Policies, approval, replication modes |
| Messaging | Draft | Runtime-internal only |
| RPC | Draft | Runtime-internal only |
Draft means the specification is published for review and implementation planning, but no conforming Runtime has completed full validation yet.
Reference MVP coverage
The specifications describe the full platform target. The Implementation Roadmap — Reference implementation milestones defines what the first Laravel reference Runtime (Phase 2–3) is expected to implement and validate. Use this table to see which spec areas are in scope for that MVP versus deferred work.
| Spec area | Full protocol (draft spec) | Reference MVP (Phase 2–3) |
|---|---|---|
| Object Identifier | UUIDv7 for all stored objects | M1 — UUIDv7 for all stored objects |
| Identity Model | Nodes, users, groups, devices, Ed25519 keys | M1–M2 nodes and users; M3 Community Hub flows; groups optional |
| Node Discovery | Information spaces, membership, admin approval, export/migration | M1 information spaces and membership; M2 admin approval for server nodes |
| Node Connectivity | P2P, NAT, STUN/TURN policy, degraded mode | M1–M2 simplified peer connectivity between server nodes |
| Distributed Database | Full replication model, CRDT merge, flexible sync (planned §9.4), export/backup | M1 MongoDB local engine; M2 node-level replication; M3 Community Hub tables; CRDT on concurrent updates; peer snapshot recovery |
| Distributed File Storage | Full file replication, CRDT content merge, export/backup | M1 local engine; M2 node-level replication; M3 Community Hub attachments |
| Data Access Control | Policies, source-side auth, user- and node-level replication modes | M2 platform policies; M3 Community Hub paths; node-level replication auth |
| Messaging | Change notifications, sync requests, conflict signals | M2 DB + FS replication transport; M3 Community Hub workloads |
| RPC | fetch, snapshot, compare, verify, resolve | M2 DB + FS replication RPCs (fetch, snapshot, compare as needed for node-level sync) |
Deferred capabilities remain normative in the draft specs for Phase 4 and later hardening. Gaps found during reference implementation feed back into spec updates.
Reading order
Read in this sequence — later documents assume concepts from earlier ones:
- Object Identifier — UUIDv7 for all stored objects
- Identity Model — cryptographic identity for nodes and users
- Node Discovery — information spaces, membership, approval
- Node Connectivity — P2P transport and NAT traversal
- Distributed Database — replicated structured data
- Distributed File Storage — replicated files
- Data Access Control — policies, approval gates, replication modes
- Messaging — runtime-internal (not for applications)
- RPC — runtime-internal (not for applications)
Steps 8–9 describe runtime-internal protocols used to implement replication. Application developers normally start with steps 1–7 and the Introduction.