Why SynckHub Uses Managed Federation

Status: This page describes the selected architecture for customer-operated self-hosting. SynckHub Free Self-Hosting enrollment and local authentication are under implementation. Until they ship, follow the current deployment documentation and release notes for supported behavior.

SynckHub is designed as a managed federation: Common provides one trusted coordination point, while each customer-operated installation remains authoritative for its authentication, permissions, repositories, and private data.

This is a deliberate middle ground. It gives customers meaningful control of their infrastructure and data without making every installation solve global identity, discovery, reputation, abuse handling, billing, and federation routing independently.

The model in one sentence

Common coordinates the network; customer installations authenticate their users and control their data; the Federation ClearingHouse carries only data that an installation explicitly chooses to federate.

The three parts

Common: the coordination plane

Common maintains the shared information that must be consistent across the SynckHub network:

stable global user identities
registered installations and their public routes
which users belong to an installation
free and paid entitlements
federation admission and routing
network-level suspension and abuse response

Common is intentionally not the customer installation’s login authority. For customer-operated self-hosting, it does not hold local password hashes or issue local user sessions.

Customer installations: the data planes

Each customer-operated installation controls:

local password hashes and login sessions
local roles and repository permissions
repositories, blobs, backups, and private data
its private cryptographic keys
whether local data is exported into federation

A Common account or administrator credential is not accepted by the customer installation as a local login credential. SynckHub does not require a vendor reverse tunnel, vendor SSH key, hidden support account, or remote command channel.

Federation ClearingHouse: exchange between installations

The ClearingHouse coordinates approved federation traffic between installations. It receives only the content carried by an explicit, locally authorized federation operation.

Common decides whether an installation is registered and admitted to the managed network. The customer installation decides whether its users may send local data into that network.

SynckHub Free Self-Hosting

SynckHub Free Self-Hosting is the normal customer-operated self-hosted product under a free entitlement, not a separate product edition.

The free entitlement allows up to five active human users per installation, including the owner. All five users may collaborate. Pending invitations, disabled users, and service identities do not consume active-human seats.

Moving to a paid self-hosting plan changes the entitlement and available limits or features. It does not move the customer’s data, replace local authentication, or convert the installation into a SynckHub-managed deployment.

The DNS and email analogy

Email is decentralized, but it still relies on coordinated shared infrastructure. The Domain Name System is a distributed hierarchy with one authoritative root. Domain owners operate their own authoritative zones, while the root delegates responsibility for the global namespace. Email servers then use DNS MX records to discover where mail for a domain should be delivered.

Common plays a comparable role for SynckHub installations:

Internet email	SynckHub managed federation
The DNS root coordinates the global namespace	Common coordinates global users and installation identities
Domain DNS delegates authority to independent operators	Common registers customer-operated installations
MX records locate a domain’s mail servers	Federation routes locate an installation’s approved endpoint
Mail servers store mail and authenticate their own users	SynckHub installations store data and authenticate their own users
SMTP transfers messages between servers	SynckHub federation transfers explicitly shared application data

The analogy has limits. DNS primarily publishes delegations and routing information. Common also applies product policy: entitlements, installation membership, federation admission, and abuse response. Common is therefore closer to an application-level combination of a naming root, identity registry, trust authority, and network operations desk.

Why not copy email exactly?

Email proves that an open network of independent servers can survive for decades. It also exposes the costs of having no organization responsible for the network as a whole:

spam and sender reputation are fragmented
identity and account recovery differ by provider
abuse complaints cross organizations with inconsistent results
server compatibility and policy vary
ordinary operators must understand delivery, reputation, and security details

Those costs are acceptable for a universal Internet protocol. They are a poor default for a collaboration product that should behave consistently for a small company running its own server.

SynckHub keeps the useful part of the email model—independent servers controlling their users and data—while centralizing the global coordination that benefits from one accountable operator.

How this differs from fully decentralized federation

Systems such as Matrix and ActivityPub normally let each server create its own identities and federate directly with other servers. This provides greater independence from any one vendor, but it also distributes discovery, trust, compatibility, moderation, and abuse handling across the network.

SynckHub makes a different trade-off:

Property	Email, Matrix, or ActivityPub-style federation	SynckHub managed federation
Global coordination	Primarily protocol, DNS, and independent operators	Common is the trusted coordination plane
User identity	Usually belongs to a domain or home server	Common provides a stable global identity
Local authentication	Controlled by each provider or server	Controlled by each customer installation
Private data	Controlled by each provider or server	Controlled by each customer installation
Federation admission	Each server chooses peers and policy	Common provides network-wide admission and routing
Abuse response	Distributed across independent administrators	SynckHub can coordinate a network-wide response
Vendor independence	Higher	Lower while Common is required
Product consistency	Varies by implementation and operator	One coordinated SynckHub product contract

This is not the most decentralized architecture possible. It is the smallest architecture that provides customer control of authentication and data while preserving a coherent, supportable federation.

Benefits

Customer control where it matters

Customer credentials, sessions, permissions, repositories, and private data remain on customer-controlled infrastructure. Common cannot use one of its human or administrative credentials to log in to a customer-operated installation.

One global identity

The same person can be recognized consistently across installations without creating unrelated network identities for every server. Membership is separate from authentication: Common can record that a person belongs to an installation, but that person must still create and use a separate local password there.

Accountable federation

SynckHub can provide consistent admission rules, routing, reputation, and abuse response. Customers have one organization to contact when federation fails or another participant behaves maliciously.

Simpler self-hosting

An operator runs the customer data plane, not an entire global identity and reputation network. Common handles the shared registry and coordination work.

Predictable upgrades

Changing from free to paid self-hosting changes an entitlement. It does not require reinstalling SynckHub, migrating repositories, or handing authentication authority to SynckHub.

Trade-offs and limitations

Common is a dependency

Common is required for new installation enrollment, shared identity verification, entitlement updates, and federation coordination. SynckHub managed federation is therefore not vendor-independent in the same way as email.

Common can deny network services

Common can suspend an installation or refuse new federation operations. This is necessary for entitlement and abuse enforcement, but it means Common is a real authority rather than a passive directory.

Federation has two authorities

Common authorizes a registered installation and its route. The customer installation separately signs the exact request with its own private key. Once the ClearingHouse has pinned that public key, it requires both proofs. Common can deny federation, but Common alone cannot impersonate the pinned customer participant.

The ClearingHouse operator remains trusted because explicitly federated payloads are readable in ClearingHouse storage. This design does not claim end-to-end encryption from that operator.

This is not an open alternative network

The design does not currently promise that another organization can operate an interchangeable Common service or that federation will continue unchanged if Common permanently disappears. Customers seeking a completely vendor-independent or censorship-resistant network need a different trade-off.

What happens when Common is unavailable?

The intended failure boundary is explicit.

Existing users on a customer-operated installation should continue to:

sign in and refresh local sessions
read and write repositories
use locally available product features
administer local data within their existing authority

Operations requiring new global coordination may pause:

enrolling a new installation
verifying and activating a new global identity
refreshing a paid entitlement
selecting a new federation route

Local changes to existing members can complete against the installation’s authority and synchronize with Common later.

An outage of the coordination plane should degrade coordination, not turn off the customer’s data plane.

Managed deployments are different

SynckHub-operated SaaS and SynckHub-managed dedicated deployments are managed end to end. Common authentication and audited SynckHub support access may be part of those services because SynckHub is responsible for operating their data planes.

Customer-operated installations have a different trust boundary. Free or paid, they retain local authentication and do not gain a SynckHub access path merely by changing entitlement.

Why we chose this model

The design follows four priorities:

Customers must control access to their own infrastructure and private data.
Self-hosting should not require operating a global trust, routing, and abuse network.
Federation needs an accountable organization that can resolve operational and abuse problems.
The first implementation should be small enough to build, secure, and operate correctly.

Fully centralized SaaS would be simpler but would not provide the desired self-hosting boundary. Fully decentralized federation would provide greater independence but introduce substantial identity, trust, moderation, compatibility, and distributed-state complexity.

Managed federation is the practical middle: globally coordinated, locally controlled.