Federation
Overview
Federation connects independently operated UnoLock nodes, so people can keep their own home service while exchanging private messages, sending files and working in Shared Spaces with Safes on other nodes. There is no central directory and no single operator in the middle.
Each node is a home service for the Safes created on it. Your browser talks only to your home node. The node finds other nodes and carries encrypted content between them. Encryption and authority stay with the client.
How It Works
- Peer discovery without a central directory: Nodes learn about one another through a distributed lookup network. Seed peers introduce a node to the federation, and after discovering other reachable peers, lookup can continue without the original seed.
- Tor between nodes: Federation traffic between nodes travels over Tor onion services.
- HTTPS for you: Your browser connects to your home node over HTTPS. The node handles peer discovery and transport.
- Receive Addresses: A Receive Address is fixed to its node's onion service, and the receiving client can stay offline while the node and the address remain active. See Receive Addresses and Messaging Across Nodes.
- Shared Spaces across nodes: People on different nodes can share encrypted notes and files in the same Space. See Shared Spaces Across Nodes.
Security Implications
- Encrypted before it leaves: The browser encrypts content before it leaves your device, so nodes only carry sealed data.
- Client-held authority: The client signs application messages and remote archive operations, verifies message signatures after decryption, and signs the exact node route authorized for each Receive Address.
- Peers never decrypt: Federation peers carry encrypted content and opaque routes. The federation layer does not decrypt application messages.
- Route pins: Verified route pins prevent later lookup records from silently redirecting a Receive Address to another node.
- Metadata: Nodes still process operational metadata such as sizes, timing and routing. See Security Model.
Use Cases
- Families on different nodes: Each household runs its own node and still shares a Space for important documents.
- Teams across organisations: Each organisation keeps its own node and exchanges messages and files with the other.
- Independent operators: Anyone can run a node and join the federation, with no central sign-up.
Why It Matters
Choosing where your Safe lives should not cut you off from anyone. Federation lets you keep your data on a node you trust while still working with people who chose a different node. The federation is built to outlast any one company: operators can build and run the open-source node independently and configure their own bootstrap peers.
FAQs
Do I need to be online to receive a message?
No. The receiving client can stay offline while the node and the Receive Address remain active.
Can other nodes read my messages or files?
No. Content is encrypted in the browser before it leaves your device, and federation peers carry encrypted content and opaque routes only.
What happens to the federation if TechSologic shuts down?
Operators can build and run the AGPL node independently and configure their own bootstrap peers. Continued operation depends on participating operators and reachable peers, not on TechSologic staying in business. It does not automatically recover data from a service that has shut down.
Why does federation use Tor?
Traffic between nodes travels over Tor onion services. Each node also runs a non-exit Tor relay by default, which you can configure or disable. See Tor and the Relay.
Integration with Other Features
- Self-Hosted: Federation connects self-hosted UnoLock Federated Nodes. See Self-Hosted.
- Vault Messaging: Messages and files travel between nodes through Receive Addresses. See Vault Messaging.
- Shared Spaces: Collaborate in a Space with Safes on other nodes. See Shared Spaces.