Application Examples
Current status: protocol specifications (draft). Runtimes are planned deliverables — not yet available.
Faberio is designed to enable a wide range of distributed applications whose state is shared across a trusted network of nodes. That network may include participants' personal devices — smartphones, tablets, laptops, and personal computers — and always-on servers run by users or independent operators.
This page describes the target architecture for representative application categories — and how they benefit from Faberio's local-first, replication-first design. Current validation scope and Runtime delivery: Implementation Roadmap.
Alternatives to Vertical SaaS
Many everyday software categories are delivered as vertical SaaS — a single vendor bundles the application, the data store, hosting, identity, and governance into one closed stack. Users and organizations adopt the product, but the provider retains operational control, data custody, and the ability to change terms, pricing, or availability.
Faberio targets the same application categories with a different ownership model: applications run on a network of nodes — personal devices and/or always-on servers operated by users or independent operators — with data replicating within a trust-boundary information space, without mandatory dependence on one cloud vendor.
Community platforms and business applications as vertical SaaS
Community platforms and business applications are often delivered as vertical SaaS: one vendor hosts the application and the datastore for universities, NGOs, cooperatives, municipalities, and companies. The product surface is familiar; the infrastructure model is not.
In countries where centralized collaboration platforms are blocked or restricted, communities cannot depend on a single foreign SaaS operator. A Faberio application runs on operator-controlled nodes — without one mandatory central service whose domain or API a blocklist can disable in a single step. Participants keep coordination, documents, and operational data within their information space, under policies set by their own administrators rather than an external platform vendor. Network-level blocking remains an operational risk for any hosting model; Faberio removes the single-vendor choke point that makes centralized products easy to cut off. In practice, the platform makes it feasible to build craft applications — products shaped for a specific organization, language, or governance model instead of a one-size-fits-all global SaaS product.
On Faberio, each node stores only the data that access control permits on that node — not the entire organization or company dataset. That scoped replica is usually modest in size, so keeping it on a smartphone, tablet, or laptop is practical: local search, offline reading, and a responsive UI without fetching every record from a remote server on each interaction.
How long data stays on a personal device depends on information space settings as well as available storage. Administrators define retention policies for the space; the Runtime may trim older local copies when disk space runs out. In a small, low-traffic space — for example a hub for one university department or a local association, or a branch office with a modest workload — the volume exchanged over time is periodic and modest, so the same subset can remain on devices for a long time without pressure to evict it. Users who need longer or fuller archives can run a Faberio node on their own server with larger disk capacity; that always-on node holds a more complete replica and keeps history available even after a phone or laptop has dropped older local copies.
Each organization runs its own node, and nodes MAY federate with partners — for example university ↔ laboratory, city ↔ civic organization, fund ↔ partners, or headquarters ↔ branch — without surrendering custody to a shared SaaS backend.
For small organizations, Faberio offers a way to use computing power already on participants' personal devices — smartphones, tablets, and laptops — to run applications and automate day-to-day processes locally, without treating a rented datacenter as the primary execution layer. An optional 24/7 server acts as backup storage and a replication anchor that speeds up how updates spread across the group — not as a central automation hub that every action must round-trip through. That topology lowers datacenter and SaaS hosting spend while keeping data under operator control.
| Category | Vertical SaaS model | Faberio model |
|---|---|---|
| Federated Community Hub | Membership, events, documents, tasks, polls, and calendars live on provider servers. Governance, export, and retention are controlled by the vendor. Cross-organization collaboration usually means separate tenants or shared cloud accounts. | A Federated Community Hub on Faberio stores participants, events, working groups, documents, tasks, polls, calendar, and a local contact directory on operator nodes and user devices. Each organization owns its node; nodes can interact through federation while data custody stays with participants. |
| Local Civic Platform | Civic initiatives, hearings, local news, and resource maps sit in a centralized municipal or vendor SaaS. Neighbouring communities rarely share data without a shared cloud account. | Each community runs its own server; initiatives, volunteer groups, hearings, news, voting, documents, and resource maps stay local, with optional federation to peer communities. |
| Resilient Emergency Collaboration | Coordination tools require continuous cloud connectivity; outages halt shared situational awareness. | Organizations work autonomously on local replicas; when connectivity returns, messages, tasks, maps, contacts, resources, and event logs synchronise automatically. |
| Business application | Operational records, documents, and workflows run on vendor servers. Staff lose access when offline or when the provider changes terms. Integrations and export are limited by the provider's API and licensing. | A business application on Faberio replicates records across employee devices and company nodes — local-first operation in offices and field locations, with optional always-on nodes for continuous sync and data under operator governance. |
The functional experience can match what users expect from community and business products — membership directories, events, shared documents, tasks, and calendars — while the operational and data boundary shifts from vendor cloud to participants who run the Faberio Runtime.
What changes for operators and users
| Vertical SaaS | Faberio application on owned infrastructure |
|---|---|
| Data custody with the vendor | Data replicated across your devices and nodes |
| Per-seat or usage-based SaaS pricing | Infrastructure cost under operator control |
| Terms, export, and shutdown at vendor discretion | Governance by information space administrators |
| Optional federation bolted on later | Interoperability by protocol from the start |
| Application tied to one provider's backend | Same app category, portable across NixOS, containers, and nodes |
Faberio does not replace the need to build or adopt a specific product in any category. It replaces the need to rent a vertically integrated stack for that category: the Runtime supplies replication, identity, access control, and discovery; developers implement the product logic; operators deploy nodes where they choose.
See Federated Community Hub, Local Civic Platform, Resilient Emergency Collaboration, and Other business applications below. Which categories are validated first is defined in the Implementation Roadmap.
Service portability and data decoupling
Faberio is designed so operators can separate application logic from data custody and avoid tracking or exploitation by platform vendors. Three platform goals map directly to distributed application deployments on Faberio:
| Platform goal | Vertical SaaS problem | Faberio response |
|---|---|---|
| Data decoupling | Membership records, documents, customer records, and operational data are bound to the provider's datastore — export and custody are limited. | Application state lives on personal devices and always-on servers within an information space. The application is a service layer; data ownership stays with participants, governed by cryptographic identity and access control. Operators can back up, export, and migrate nodes and spaces in open formats. |
| Service portability | Switching providers means losing history, contacts, or federation hooks. | The same application category runs on any Faberio node — a participant's smartphone, tablet, laptop, or personal computer, or an always-on server on rented infrastructure or hardware run by a user or independent operator. Nodes connect through the Faberio Protocol; operators can relocate, replicate, or add hosting without rewriting the product or surrendering data to a new vendor. |
| No tracking / exploitation | Hosted SaaS monetises attention, profiles, and metadata; users cannot opt out of vendor analytics. | Faberio is operator-owned infrastructure — no mandatory platform telemetry, ad profiling, or sale of participant data. Operators control their nodes; optional local metrics only. See Threat Model — No tracking or exploitation. |
The diagrams at the top of this section contrast vertical SaaS coupling with Faberio's decoupled, portable model.
See Federated Community Hub, Local Civic Platform, Resilient Emergency Collaboration, and Other business applications for how those categories are intended to work on Faberio. Validation scope and Runtime delivery: Implementation Roadmap. Broader comparison to sync and hosting projects: Related Work.
Client-installed Applications
The sections below describe the target device-local model. Validation of server-side nodes and the demonstration application is covered in the Implementation Roadmap.
Faberio applications are installed and executed on user devices. Each device runs a Faberio Runtime that hosts the application and maintains a local copy of relevant data. Runtimes for different host classes interoperate through the Faberio Protocol — see Implementation Roadmap — Multi-platform Runtimes.
Once device-local Runtimes are available, users interact with applications locally. The Runtime synchronizes state in the background when nodes are connected. Applications remain responsive because data is available on the local replica without waiting for a remote server on every operation.
Server-optional Architecture
Personal-device networks and optional always-on servers describe the full platform once device Runtimes and user-device replication exist. Validation sequencing: Implementation Roadmap.
Faberio applications do not require a dedicated server to function in the long-term target model. A network of personal devices — smartphones, tablets, laptops, and personal computers — can form a complete information space on its own. Always-on servers run by users or independent operators are optional peers that improve availability; they are not mandatory for every participant.
| Mode | Description |
|---|---|
| Personal devices | Nodes run on participants' smartphones, tablets, laptops, and personal computers. The network operates while enough devices are online to maintain connectivity and replication. |
| With always-on servers | One or more nodes run continuously (24/7) on stable infrastructure — a home server, on-premise hardware, a VPS, or a data center — operated by a user or an independent operator. These nodes act as always-available peers alongside personal devices. |
Both modes are valid. The difference is operational resilience, not functional capability.
Decentralized Server Placement
Using a dedicated server does not mean deploying to a centralized cloud or forming a hub-and-spoke network controlled by a single provider.
A 24/7 node is an equal peer in the information space — the same as a smartphone, tablet, laptop, or personal computer, except it stays online continuously. It can run anywhere the operator or user chooses:
| Location | Examples |
|---|---|
| On-premise | A server at the company office, a home NAS, or hardware on the user's premises |
| User-owned infrastructure | A VPS or dedicated machine rented and operated by the organization or community |
| Third-party data center | A hosting provider in any region — not necessarily the same provider or region as other nodes |
| Multiple locations | Several always-on nodes in different cities, countries, or datacenters |
There is no requirement that all server nodes share a cloud platform, a geographic region, or a single operator. A company may run an on-premise server at headquarters while a remote office hosts its own node. A community or university may operate servers in different countries. Each node participates in the same replication protocol as every other peer.
Because every node — whether a personal device or an always-on server — uses the same Faberio Protocol and holds replicated state, the network remains distributed by architecture. Adding always-on servers improves availability and stability; it does not centralize control, data ownership, or infrastructure dependency.
The network topology is determined by trust relationships between participating nodes, not by a single cloud provider or a mandatory central server.
Why a 24/7 Server Improves Stability
When all nodes are intermittent — smartphones offline, laptops sleeping, tablets switching networks — the system depends on whichever devices happen to be online at a given moment. This works, but introduces practical limitations:
- Peer availability — offline devices cannot participate in replication or relay connectivity for other peers.
- Data freshness — nodes that reconnect after extended offline periods must perform full state synchronization rather than incremental updates.
- Discovery and connectivity — NAT traversal and peer discovery are more reliable when at least one node maintains a stable, reachable address.
A dedicated node running 24/7 on stable infrastructure substantially improves system stability:
- Acts as a persistent replication anchor — always available to receive and distribute state changes.
- Provides a stable rendezvous point for peer discovery and NAT traversal.
- Ensures continuous availability of shared data even when most user devices are offline.
- Reduces synchronization latency — changes propagate through the always-on node immediately rather than waiting for the next device to come online.
The server is not a single point of failure in the traditional sense. It is one peer among many. If a dedicated server goes offline, user devices continue operating locally and re-synchronize when connectivity is restored. Other always-on nodes — whether at another office, in a home lab, or in a different datacenter — continue serving the network. Adding a 24/7 node improves reliability; it does not create mandatory dependency on centralized infrastructure.
Faberio Capabilities Used
Developers implement domain logic; the Runtime supplies these platform services for every application category:
- Distributed Database — structured application records
- Distributed File Storage — documents and attachments
- Data Access Control — policies over replicated data, including organization and federation boundaries
- Identity Model — authentication and administrator approval
- Node Connectivity — peer links between devices and organization nodes
- Node Discovery — finding peers within an information space
Server-optional vs. Server-backed
Every category can run on personal devices only or with optional always-on organization / community / company nodes. Details: Server-optional Architecture.
| Aspect | Personal devices only | With always-on server |
|---|---|---|
| Offline operation | Full local access on each device | Full local access on each device |
| Cross-device sync | Syncs when peers are online | Continuous background sync via the always-on node |
| Shared state for offline members | Limited to currently reachable peers | Server holds authoritative replica until devices reconnect |
| Onboarding / full state copy | Requires an online peer | Server provides an immediate full state copy |
| Files and attachments | P2P when author and recipient are online | Server caches files for later retrieval |
| Cross-org or multi-site federation | Requires reachable peer devices | Always-on nodes provide stable federation endpoints |
Application categories
| Application | Roadmap status | Notes |
|---|---|---|
| Federated Community Hub | Reference validation | Participants, events, working groups, documents, tasks, polls, calendar, local contacts; org-owned nodes with federation — see Implementation Roadmap |
| Local Civic Platform | Future | Local communities — initiatives, volunteers, hearings, news, voting, documents, resource map; per-community servers with federation |
| Resilient Emergency Collaboration | Future | Autonomous operation under unstable networks; messages, tasks, map, contacts, resources, event logs; local-first resilience |
| Other business applications | Future | Operator-owned business software — local-first records, offline field use, optional always-on company nodes |
The sections below describe the target architecture for each category once the reference Runtime is available. All categories use the same Faberio Runtime capabilities and the same server-optional vs. server-backed deployment pattern.
Federated Community Hub
The Federated Community Hub is the reference validation application category. Demo scope: Implementation Roadmap.
A Federated Community Hub is an application for communities, associations, universities, civic organizations, cooperatives, or small municipalities. It unifies everyday coordination in one product:
| Capability | Role in the hub |
|---|---|
| Participants | Membership and roles within the organization |
| Events | Meetings, public gatherings, and internal activities |
| Working groups | Teams, committees, and project circles |
| Documents | Shared files and collaborative document records |
| Tasks | Assignments and progress within groups |
| Polls | Decision-making and feedback |
| Calendar | Shared schedule across the organization |
| Local contact directory | Organization-scoped contacts, not a global social graph |
| User communication | Optional — hubs MAY integrate Matrix (or similar) for direct and group messaging; chat is not Faberio application state |
As vertical SaaS, community platforms route membership, documents, and calendars through vendor-controlled backends: history, moderation, and policy enforcement depend on the provider's cloud, and self-hosting the complete product is typically not an option.
On Faberio, a Federated Community Hub replaces that rented stack with replicated state on user devices and operator nodes — the same coordination category, without mandatory dependence on a third-party SaaS operator. Organizations can ship a craft hub tailored to their members rather than renting a generic global product.
User messaging: Faberio does not implement a messenger protocol. A hub MAY link membership and contacts to Matrix identities so participants can message one another on a Matrix homeserver (or federated Matrix network). Coordination data (events, documents, tasks, polls, calendar) stays on the Faberio information space; conversation traffic stays on Matrix when that integration is used.
Each organization runs its own node. Nodes MAY interact through federation so partner organizations exchange selected state without merging into one tenant. Typical federation patterns:
| Pairing | Example |
|---|---|
| University ↔ laboratory | Shared events, working groups, and documents between campus and research lab nodes |
| City ↔ civic organization | Coordinated calendars and participant directories across municipal and NGO hubs |
| Fund ↔ partners | Joint tasks, polls, and document spaces between a foundation and grant partners |
Where centralized collaboration tools are blocked or unavailable, a community-operated deployment can sustain internal coordination on infrastructure the society controls.
The bullets below describe the full Community Hub architecture on user devices and optional server nodes.
- User devices — hub clients run on smartphones, tablets, laptops, and personal computers. Participants, events, tasks, and documents relevant to the user are stored locally, enabling offline reading and updates.
- Organization node — each community, association, university, cooperative, or municipality operates its own always-on (or intermittently available) node that holds the organization's hub state and sets membership and access policy.
- Federation between nodes — partner organizations connect their hubs through the Faberio Protocol so selected working groups, events, or documents can cross organizational boundaries without a shared SaaS tenant.
- User messaging — hubs MAY integrate a Matrix homeserver (or federated Matrix network) alongside the hub for participant communication; Faberio does not replicate chat history as Community Hub records.
- Dedicated server (recommended) — a 24/7 node improves availability for offline members, anchors replication, and keeps calendar and document state reachable when personal devices are offline.
Local Civic Platform
Not part of the reference validation path. Documented here as a target application category for local communities.
A Local Civic Platform serves local communities: neighbourhoods, municipalities, and civic initiatives that need shared coordination without a single commercial SaaS tenant.
| Capability | Role in the platform |
|---|---|
| Initiatives | Local projects and campaigns residents can join or follow |
| Volunteer groups | Organising people around tasks and shifts |
| Public hearings | Scheduling, agendas, and records of civic consultations |
| Local news | Community announcements and updates scoped to the locality |
| Voting | Polls and decision-making for local matters |
| Shared documents | Agendas, minutes, proposals, and attachments |
| Resource map | Places, assets, and services available in the community |
As vertical SaaS, civic tools often centralise initiatives, maps, and voting in a vendor cloud — availability and export depend on that provider. On Faberio, each community runs its own server (node) and keeps data within its information space. Communities MAY federate with neighbouring towns, partner NGOs, or regional hubs to share selected initiatives, news, or map layers without merging into one platform account.
- Community server — each locality operates its own always-on (or intermittently available) Faberio node that holds initiatives, hearings, documents, and the resource map.
- Resident devices — phones and laptops keep a local replica of relevant civic data for offline reading and participation when connectivity is poor.
- Federation — peer community nodes exchange selected state (for example shared regional news or joint volunteer efforts) through the Faberio Protocol.
Resilient Emergency Collaboration
Not part of the reference validation path. Documented here as a target application category that stresses local-first operation and fault tolerance.
Resilient Emergency Collaboration covers scenarios where internet connectivity is unstable or intermittent — disaster response, field operations, or crisis coordination across agencies. Organizations work autonomously on local replicas; when a link reappears, data synchronises automatically through background replication.
| Capability | Role in the scenario |
|---|---|
| Messages | Coordination notes and status updates among responders |
| Tasks | Assignments that continue offline and reconcile later |
| Map | Shared situational picture — locations, zones, hazards |
| Contacts | Reachable people and roles within the response network |
| Resources | Inventory of supplies, vehicles, and capacity |
| Event logs | Chronological incident journal for accountability and handoff |
Centralized SaaS collaboration fails when the cloud path is down. On Faberio, each participating organization keeps a local-first replica on devices and optional field or HQ nodes. Connectivity is opportunistic: the Runtime reconciles messages, tasks, map updates, resources, and event logs when peers reconnect — demonstrating local-first UX and resilience under partition.
- Autonomous operation — responders read and write against the local replica while disconnected; no round-trip to a remote cloud is required for core flows.
- Opportunistic sync — when connectivity returns (direct P2P, field relay, or restored WAN), background replication merges updates across organization nodes.
- Organization nodes — each agency or team may run its own node; federation shares selected tasks, map layers, and logs with partners without a single mandatory central server.
Other business applications
Not part of the reference validation path. Documented here as a target application category for organizations that want operator-owned business software.
Other business applications cover the everyday operational software organizations run for internal processes — structured records, documents, workflows, and reporting. As vertical SaaS, conventional products centralize that state in a vendor cloud: connectivity, export, and long-term custody depend on the provider.
On Faberio, a business application runs on employee devices and company nodes within a shared information space. Local replicas keep work usable offline or in branches with intermittent connectivity; optional always-on nodes improve sync across sites and time zones. Developers implement domain logic for their organization; the Runtime supplies replication, identity, access control, and discovery.
- Employee devices — staff run the business client on phones and laptops. Records needed for day-to-day work are available locally for offline operation in offices, warehouses, retail locations, or areas with poor connectivity.
- Office and branch nodes — desktop workstations and on-premise servers participate in replication, providing fast local access for back-office operations.
- Dedicated server (recommended) — a 24/7 node on company premises, at a branch office, or on operator-owned infrastructure maintains continuous replication, supports onboarding with a full state copy, and keeps shared data current when field devices are offline.
Common Patterns
Across Federated Community Hub, Local Civic Platform, Resilient Emergency Collaboration, and other business applications, several architectural patterns recur:
Local-first User Experience
Applications read and write data locally. Users experience low latency and full functionality regardless of network conditions. Synchronization happens transparently in the background.
Replication over Messaging
Applications do not implement their own sync logic. The Runtime replicates database and file storage state across nodes. See Distributed Database and Distributed File Storage.
Trust-boundary Information Spaces
Each application operates within an information space — a network of nodes that trust one another. Access policies, replicated data, and user identities are scoped to the space. See Introduction — Distributed Information Spaces.
Progressive Enhancement with Infrastructure
Applications may start with personal devices only and add always-on server nodes — run by users or independent operators — as operational requirements grow. The same application code and protocol work in both configurations — only the set of participating nodes changes.
This progression is a deployment pattern, not the platform Implementation Roadmap Phase 1–4.
Summary
Faberio supports diverse application categories — from community coordination hubs to business systems — with a common architectural foundation.
Representative categories:
- Federated Community Hub as an alternative to vertical SaaS community platforms — participants, events, working groups, documents, tasks, polls, calendar, and local contacts on operator-owned nodes, with federation between organizations
- Local Civic Platform — initiatives, volunteer groups, public hearings, local news, voting, shared documents, and resource maps; each community runs its own server and may federate with others
- Resilient Emergency Collaboration — autonomous local-first operation under unstable networks; messages, tasks, map, contacts, resources, and event logs reconcile when connectivity returns
- Other business applications — operator-owned operational software on company nodes and employee devices
- Applications on user devices and optional always-on servers
- Data replicates through built-in platform services
- A server is optional — device-only networks can be fully functional once device Runtimes ship
- A 24/7 dedicated server improves stability, sync speed, and availability — on-premise, user-owned, or any datacenter without centralization
Validation scope and Runtime delivery: Implementation Roadmap.
Developers implement business logic through the Faberio SDK. The Runtime handles distributed infrastructure — replication, discovery, connectivity, and access control — regardless of deployment topology.