Introduction
Current status: protocol specifications (draft). Runtimes are planned deliverables — not yet available.
Vision
We believe the next generation of the Internet should be built on open, interoperable, and sovereign infrastructure rather than centralized cloud platforms.
We envision a world where distributed applications run across independently operated runtimes owned by their participants — resilient when individual nodes fail, free from mandatory dependence on a single vendor cloud, and as simple to build and operate as traditional software.
In that future, computing power on personal devices and community-scale nodes carries everyday workloads; personal and community micro datacenters provide backup and continuity; and openness, interoperability, resilience, and digital sovereignty are the default properties of the platform layer — not optional extras bolted onto closed SaaS stacks.
Mission
Our mission is to create the universal open runtime platform for distributed applications independent of centralized infrastructure.
Faberio will provide a standardized runtime, an open protocol, and a developer ecosystem that enable applications to execute seamlessly across heterogeneous infrastructure — from participants' personal devices (smartphones, tablets, laptops, personal computers) to always-on servers run by users or independent operators.
By standardizing the execution environment rather than the underlying infrastructure, Faberio is designed to keep applications portable, interoperable, resilient, and independent of centralized platforms.
Concrete product categories — federated community hub, local civic platform, resilient emergency collaboration, and other business applications among them — are widely delivered today as vertical SaaS: one vendor controls application, data, and hosting. Faberio is designed to enable the same categories on a network of nodes that may include participants' personal devices and always-on servers run by users or independent operators, so communities and organizations are not locked into a rented, centralized stack. See Application Examples — Alternatives to Vertical SaaS.
Platform goals
Faberio is designed for:
- Data decoupling — Application logic is separated from data custody. State replicates across personal devices and always-on servers inside an information space; it is not trapped in a vendor's proprietary backend. Operators and users can back up, export, and migrate nodes and spaces without vendor permission — see Node Discovery — Export, backup, and migration.
- Service portability — The Faberio Protocol and Runtime let the same application category run on heterogeneous nodes. A node may be a participant's smartphone, tablet, laptop, or personal computer, or an always-on server on rented cloud infrastructure or hardware operated by a user or independent operator. A dedicated server is not required for every participant. Operators can deploy, migrate, or combine hosting models without losing interoperability or rewriting distributed plumbing.
- No tracking or exploitation — The platform is self-hosted infrastructure, not a surveillance or ad product. The reference Runtime will not include mandatory vendor telemetry, behavioral profiling, or extraction of user content for third-party monetisation. See Threat Model — No tracking or exploitation.
See Application Examples — Service portability and data decoupling for how these goals apply to distributed application alternatives to vertical SaaS.
How the reference Runtime is sequenced and why Laravel is first: Implementation Roadmap — Delivery sequence.
Sustainability and Threat Model describe long-term maintenance, expansion phase, and high-level security assumptions.
Related Work compares Faberio to CouchDB/PouchDB, Automerge, Solid, ATProto, and Yjs.
Platform Layers
Faberio consists of four fundamental layers.
The platform consists of:
-
Applications — implement business logic; run inside the Runtime or externally.
-
Faberio Runtimes — independent implementations that host applications and provide platform services on each node:
- Node identity — cryptographic identity for nodes and users
- Node discovery — finding peers within an information space
- Secure connectivity between nodes — P2P links, NAT traversal, and relay
- Distributed database — replicated structured application data
- Distributed file storage — replicated files and attachments
- Access control — policies over data replicated between nodes
Multiple Runtime implementations MAY exist for different host classes; all interoperate through the same protocol. See Implementation Roadmap for the reference Runtime path.
-
Faberio Protocol — the standardized communication layer between Runtimes and the Network; enables interoperability between independent Runtime implementations.
-
Network — provides communication over the Internet, LAN, VPN, or mesh networks.
Applications inside a Runtime access data through the Faberio SDK. External applications use the HTTP API or native access (native database client or filesystem). All paths pass through data access control before reaching the database or file storage. Authorization is enforced on the source Runtime — the node serving or sending the data — not only on the client. See Data Access Control — Source-Side Authorization. Each Runtime maintains its own replicated state. Nodes may be personal devices or always-on servers; all participate in the same information space when connected through the protocol.
Core Principles
Runtime-managed Applications
Applications MAY execute inside the Faberio Runtime or operate externally and interact with the Runtime through its APIs.
When hosted inside the Runtime, applications use language-specific Faberio SDKs. When running externally, applications access the distributed database and file storage through the Runtime's HTTP API. Applications MAY also use native access — native database clients for change-stream engines, or native filesystem operations for local filesystem backends.
In all cases, the Runtime manages replication, synchronization, and coordination. Applications do not use Messaging or RPC directly.
| Integration | Application location | Database / file storage access |
|---|---|---|
| In-runtime SDK | Inside the Runtime | Faberio SDK |
| HTTP API | Outside the Runtime | Runtime HTTP API |
| Native access | Inside or outside the Runtime | Native database client or filesystem operations |
Developers focus on business logic while the Runtime handles distributed infrastructure regardless of how the application is deployed.
Replication-first
Replication is a core capability of the platform rather than an application concern.
Instead of relying on centralized databases, Faberio is designed around replicated application state.
The Runtime continuously synchronizes data across participating nodes using standardized replication services defined by the Faberio Protocol.
Local-first
Applications execute locally whenever possible and synchronize only when necessary.
This reduces latency, improves privacy, enables offline operation, and minimizes dependence on network connectivity.
Platform Services
Building distributed applications typically requires every team to solve the same infrastructure problems: identifying nodes, discovering peers, establishing connectivity, securing communication, storing and replicating data, and enforcing access policies.
The Faberio Runtime provides these capabilities as shared platform services. Applications access them through the Faberio SDK, the Runtime HTTP API, or native access — native database clients for change-stream engines, or native filesystem operations for local filesystem backends. The Runtime handles coordination across participating nodes.
Platform services include:
- Identity Model — cryptographic identity for nodes and users, public key registry per information space
- Node Discovery — peer discovery within information spaces
- Node Connectivity — P2P connectivity, NAT traversal, operator/federated/user STUN/TURN configuration, relay limits
- Replication
- Distributed application state
- Distributed Database — SDK, HTTP API, or native access
- Distributed File Storage — SDK, HTTP API, or native access
- Data Access Control
Messaging and RPC are runtime-internal protocols used to implement replication. Applications do not interact with them directly — they access replicated state through the database and file storage APIs, regardless of whether the application runs inside or outside the Runtime.
By centralizing distributed infrastructure in the Runtime, Faberio reduces application complexity and ensures consistent, interoperable behavior across independently operated nodes.
Protocol Compatibility
Independent Runtime implementations communicate through the open Faberio Protocol.
Applications written using different language-specific SDKs interoperate because every Runtime follows the same protocol specification.
The protocol - not a specific Runtime implementation - is the interoperability layer of the ecosystem.
Distributed Information Spaces
Runtimes that trust one another connect to form a network. Through secure communication and replication, connected runtimes build distributed information spaces in which users register with cryptographic key pairs, authenticate via signatures, and access shared data.
Participating nodes may include participants' personal devices — smartphones, tablets, laptops, and personal computers — and always-on servers operated by users or independent operators. The same information space can combine both; no single hosting model is mandatory.
Each information space emerges from the trust relationships between participating runtimes rather than from centralized infrastructure. Users operate from one or more devices simultaneously, while their identity is established by a single public key registered in the space.
A single node may participate in multiple networks simultaneously. Each network represents a separate trust boundary and information space. The node maintains independent trust relationships, replicated data, and access policies for each network it joins.
Information spaces operate independently from one another. Data, peers, access policies, and replication in one space do not affect other spaces — even when they share the same physical node.
Applications running on a node do not have access to all information spaces by default. Access must be explicitly configured for each application. An application may be granted access to one or more spaces, or to none — depending on operator configuration.
Distributed by Design
Every Faberio application is designed to operate as a distributed system.
Application state can be replicated across multiple nodes while execution remains decentralized.
Resilient by Architecture
Resilience is achieved through replicated state, peer-to-peer communication, and autonomous Runtime instances.
Applications continue operating despite node failures, infrastructure outages, or temporary network partitions.
Runtime Architecture
Replication Model
Faberio separates application logic from data replication.
Applications never synchronize data directly.
Instead, the Runtime replicates application state between participating nodes.
When a node has been offline for an extended period, it cannot rely on individual change notifications — messages sent while the node was unreachable are not retained. In this case, the node requests a full state copy from a peer instead of synchronizing change by change. See Distributed Database — Synchronization on Reconnect.
Future: flexible full synchronization — lazy loading, paginated snapshots, and metadata-first replication (headers without full payload, with on-demand content fetch) — MAY be implemented later. See Distributed Database and Distributed File Storage.
Distributed File Storage
The Faberio Runtime is designed to provide distributed file storage as a built-in platform service.
Applications will store and retrieve files through a standardized storage API without implementing replication, distribution, or access control themselves. The Runtime will manage file placement, replication, and synchronization across participating nodes.
Files remain accessible locally through local-first caching, enabling low-latency access and offline operation. When nodes reconnect, the Runtime synchronizes file state automatically.
This approach allows applications to work with files as naturally as with local storage while benefiting from distributed resilience and data ownership.
Distributed Database
The Faberio Runtime is designed to provide distributed database capabilities as a built-in platform service.
Applications will access structured data through a standardized database API without managing replication, consistency, or node coordination themselves. The Runtime will handle data synchronization across participating nodes independently of the underlying storage engine.
Applications may use embedded databases, SQL databases, document stores, or key-value engines while the Runtime provides replication and synchronization transparently.
Data will remain available locally through local-first execution, enabling low-latency queries and offline operation. When connectivity is restored, the Runtime will synchronize database state automatically.
Development Model
Applications will be developed using language-specific Faberio SDKs or will interact with the Runtime as external applications via the HTTP API or native access.
Each SDK will expose the same programming model while delegating distributed infrastructure to the Runtime. External applications access the distributed database and file storage through the Runtime's HTTP API, or through native access — native database clients for change-stream engines, or native filesystem operations for local filesystem backends.
Licensing
Faberio is an open ecosystem where interoperability does not depend on proprietary software. Platform deliverables use recognised open licenses; application authors retain freedom to choose their own terms.
By layer
| Layer | License | What it covers |
|---|---|---|
| Protocol specifications | Creative Commons Attribution 4.0 (CC BY 4.0) | Spec documents in Specs, protocol text, and technical documentation that defines intended runtime behaviour |
| Reference Runtime, SDK, and demo software | Apache License 2.0 | Reference Runtime and SDK, Federated Community Hub demo, NixOS module, container definitions, CI configuration, and related source code. |
| Applications | Author's choice | Business logic built on Faberio — proprietary, open source, or commercial |
The reference Runtime, SDK, and demonstration application will be released under Apache-2.0 once developed. Protocol specifications and this documentation site are published under CC BY 4.0 (or will be marked accordingly at publication).
Why these licenses
- CC BY 4.0 for specifications — standard for open documentation; allows anyone to implement, translate, and republish the protocol text with attribution.
- Apache-2.0 for software — OSI-approved, widely used in open infrastructure projects; includes an express patent grant; permissive enough for independent Runtime implementations and for proprietary in-runtime applications using the SDK (unlike strong network copyleft licenses that would conflict with optional closed-source apps).
Applications and proprietary code
Applications are not required to be open source. Developers may ship in-runtime or external applications under commercial or other licenses. Apache-2.0 applies to Faberio platform code — not to application code that merely uses the SDK or HTTP API.
Independent Runtime implementations in other languages are encouraged; they need not use Apache-2.0 if they are clean-room implementations of the open protocol specification.
When the reference implementation is complete, all software artefacts will be published in full under Apache-2.0, with specifications and operator documentation under CC BY 4.0.
Contact
- Website: https://faberio.dev
- GitHub: github.com/faberio-platform/faberio-docs
- Email: info@faberio.dev
Shared terminology: Glossary. Navigation: How to read these docs. How to contribute: Contributing.