Skip to main content

Related Work

note

Current status: positioning document for architecture discussions. Faberio is specification-stage; compared projects are existing software or protocols.

Faberio sits at the intersection of local-first sync, operator-governed trust, and heterogeneous hosting — personal devices alongside always-on servers. Several mature projects address parts of that problem space. None combines administrator-gated information spaces, background replication as a platform service, and a reference validation path in the way the current scope defines.

Comparison overview​

Project / familyPrimary modelSync / stateHostingvs Faberio
CouchDB / PouchDBDocument DB + replicationApp-configured replication filtersSelf-host per databaseFaberio moves replication, identity, and DAC into the Runtime
Automerge / CRDT librariesIn-app CRDT documentsPeer sync in application codeAny hostFaberio applies CRDT merge in the Runtime — apps use record/file APIs, not embedded CRDT libraries
SolidPods + linked dataPer-pod storage; app-specificPod providersFaberio is information-space infrastructure with admin-gated membership
ActivityPub / FediverseFederated social productsActivity streams between instancesSelf-hosted instances (Mastodon, Lemmy, …)Faberio is Runtime infrastructure below the product — complementary, not a Mastodon replacement
ATProto (Bluesky)PDS + lexicon + relayAccount-centric federationHosted PDSFaberio is category-neutral Runtime, not a PDS or lexicon stack
Yjs / CRDT editorsReal-time co-editingCRDT over WebSocket/WebRTCApp-dependentPossible future app pattern; not the reference MVP deliverable

CouchDB and PouchDB​

CouchDB and PouchDB pioneered local-first replication with HTTP sync and conflict handling. Applications define what replicates via filters and design documents.

Faberio borrows the local-first replication goal but moves sync, identity, and access control into the Runtime. Applications use SDK/API against replicated state; they do not configure Couch-style replication filters per app. The reference MVP implements node-level database replication for the Community Hub path first — not a general CouchDB-compatible engine.

Automerge and CRDT-centric stacks​

Automerge and similar libraries expose CRDT documents as the application data model. Sync is peer-to-peer at the document level; applications embed the CRDT library directly.

Faberio applies CRDT merge at the Runtime layer for replicated records and file metadata. Applications use the database and file storage APIs; the Replication engine detects concurrent updates and merges replicas using declared CRDT types (see Distributed Database — CRDT merge). Real-time co-editing (Yjs-style) remains a possible application-level pattern on top of the platform.

Solid​

Solid separates data into pods controlled by users, with apps accessing linked data via standard protocols.

Faberio uses information spaces — operator-governed networks of nodes with administrator approval for nodes and users. Data portability and cryptographic identity are shared themes; trust model and protocol differ.

ActivityPub and the Fediverse​

The Fediverse — Mastodon, Lemmy, PeerTube, Pixelfed, Misskey, and similar software — gives communities federated, self-hosted application instances. Operators run a finished product; users join an instance; instances exchange data through an application-level federation protocol, most often ActivityPub.

ActivityPub fits social scenarios well: posts, comments, follows, notifications, and reach across the wider Fediverse. Clients talk to a home server; federation extends visibility between instances.

Faberio addresses a different layer: distributed runtime infrastructure for applications whose state is local-first, replicates across operator nodes and user devices, and stays within an administrator-gated information space. It is not an ActivityPub server and not a drop-in alternative to Mastodon or Lemmy.

LayerFediverse stack (typical)Faberio
ProductMastodon, Lemmy, PeerTube, …Custom Community Hub, Civic Platform, Emergency Collaboration, other business apps, … built on the Runtime
Application protocolActivityPub and app-specific APIsFaberio Protocol between Runtimes
Data modelInstance database (often PostgreSQL)Replicated database and file storage on each node
Offline / local-firstServer-centric; clients are views on the instanceLocal replica on devices; background sync between nodes
Trust boundaryInstance membership and moderationInformation space with explicit node and user approval
Best fitAdopt a mature federated product and join the wider FediverseBuild a custom app with operator-owned, replicated state

ActivityPub is not Faberio's replication core. Arbitrary record replication, offline reconciliation, CRDT merge, and business-process sync need a Runtime-level protocol — see Distributed Database. The long-term model is Faberio Protocol first, with a future ActivityPub adapter that could publish selected content to the Fediverse or interact with users on compatible platforms — without constraining what the Runtime replicates internally. That adapter is not in the current scope.

An operator may run both stacks: Mastodon or Lemmy for public federated reach, and a Faberio-based Community Hub for device-local history and administrator-gated membership in a dedicated information space. Faberio is complementary to the Fediverse ecosystem, not a competitor.

ATProto (Bluesky)​

ATProto defines Personal Data Servers, lexicons, and relay-based federation for social applications.

Faberio is category-neutral infrastructure: the reference implementation validates a Federated Community Hub on a general Runtime, not a PDS or lexicon implementation. Data portability and cryptographic identity are shared themes; protocol and scope differ.

What Faberio adds​

Across related work, Faberio's scoped contribution is:

  1. Runtime-first platform — replication, identity, and access control as platform services, not per-app wiring.
  2. Administrator-gated information spaces — explicit node and user approval before shared data access.
  3. NixOS-deployable server Runtime — reproducible self-hosting for operator nodes.
  4. Honest MVP scope — reference milestones deliver validation for Community Hub on node-level DB replication first; full file storage, user-level replication, native access, and ActivityPub adapters follow the protocol spec in later work.

Further reading​