Federation Guide

Early development. This is a high-level overview of how federation works in flebop. Detailed technical documentation will be published once the project reaches a useable state.

What is Federation?

Flebop is a fully federated platform. Each node is a fully independent instance with its own users, servers, and database. Nodes communicate with each other over a signed REST API, allowing users on one node to browse and participate in servers hosted on another.

There is no central authority and no central authentication point. No single node controls the network. Each node operator has full ownership of their data and their users.

Independent Nodes

Each node runs its own instance with its own database. Nodes can operate entirely standalone or connect to the wider federation.

Auto-Enrollment

New nodes join the federation by pointing at any existing node. No pre-shared secret required — trust is established entirely through public key cryptography.

Signed Events

Every message and request between nodes is cryptographically signed with the sender's private key and verified on receipt. Tamper-evident by design.

Cross-Node Identity

Users are identified across the federation by a global ID in the format username@nodeurl. No account duplication needed.

How It Works

Each node generates an ECDSA P-256 keypair on setup. The private key never leaves the node. The public key is published at a well-known endpoint (/.well-known/flebop-node) so any other node can discover it without prior coordination.

When a new node wants to join the federation, it fetches the seed node's public key, then sends a signed registration request. Every subsequent message between nodes is signed with the sender's private key and verified against the stored public key — no shared secrets, no symmetric API keys.

┌──────────────────────────────────────────┐ │ Node A (existing) │ │ │ │ Public key at /.well-known/flebop-node │ └────────────────────┬─────────────────────┘ │ Node C fetches A's public key Sends signed registration (self-verifiable) A returns its public key │ ┌────────────────────┴─────────────────────┐ │ Node C (new) │ │ │ │ Stores A's public key │ │ All future events signed + verified │ └──────────────────────────────────────────┘

Once connected, users can:

Browse servers hosted on any node in the federation
Join servers on remote nodes and participate as if they were local
Send and receive messages across nodes in real time
Send end-to-end encrypted direct messages to users on any node

Server owners control whether their server is visible to the federation. Private servers stay local to their node.

Security

Federation is built on asymmetric cryptography with no central trust anchor:

Node keypairs — each node generates a long-lived ECDSA P-256 keypair. The private key stays on the node. The public key is shared during registration.
Signed events — every inter-node request includes a signature over the payload and a timestamp. Receiving nodes verify the signature before processing anything. Tampered or replayed requests are rejected.
Replay prevention — each signed event includes a timestamp. Events older than 5 minutes are rejected, preventing replay attacks.
Permissions — remote users go through the same permission system as local users. Server owners retain full control over who can do what.

Remote users can read and send messages in servers they've joined. They cannot create servers, upload files, or manage settings on nodes they don't belong to.