No central registry
You generate an Ed25519 key pair. The public key is your identity, written as a Base58 string or a did:boson: W3C DID. Nobody grants it and nobody can revoke it.
Boson is a peer-to-peer network built on a hardened Kademlia DHT. Every node and every user is identified by an Ed25519 public key - no usernames, no central registry, no certificate authorities. Run a node, publish a service, or build an application on it. No permission required.
Not a blockchain. No proof of work, no ledger, no token - just Kademlia routing and Ed25519 signatures.
What is Boson
Most networked systems assume a central authority that everything else trusts - a server, a certificate authority, a user registry. Each one is a single point of failure and a chokepoint for censorship, surveillance, and lock-in. Boson removes all three.
You generate an Ed25519 key pair. The public key is your identity, written as a Base58 string or a did:boson: W3C DID. Nobody grants it and nobody can revoke it.
A node can serve TLS with a certificate from a public authority, or with a self-signed one bound to its own Ed25519 identity. Clients pin the service peer ID either way, so a compromised CA cannot impersonate a Boson service.
Authentication is a CBOR Web Token - Ed25519-signed, validated against your DHT public key. There are no stored credentials to breach.
Why Boson
Ed25519, self-generated. No username, no email address, no account recovery - because there is no account.
A self-signed certificate, bound to the node identity, is enough. Clients pin the service peer ID instead of trusting a root store.
Ed25519-signed CBOR Web Tokens replace the credential database entirely.
A key pair and a reachable UDP port is the entire joining procedure. No registration, no authority that approves nodes.
Super nodes federate peer to peer through signed proposals. There is no hub to join and no directory to be listed in.
The DHT core, the protocols, and every client SDK are MIT licensed and developed in the open. The layer-2 services and the super node stack will follow.
How it works
Services announce themselves down into the DHT. Clients look them up through it. That relationship is the whole design - no hard-coded addresses, no DNS, no service registry to operate.
Run on super nodes and announce themselves into the DHT, so clients can find them without hard-coded addresses.
Kademlia DHT over UDP. Carries node routing, mutable and immutable values, and peer announcements. The discovery and signalling layer for everything above it.
Ed25519 identity - nodes, values and peers - UDP 39001
| Super Node | Regular Node | Light Node | |
|---|---|---|---|
| DHT participation | Full (UDP) | Full (UDP) | None - via Web Gateway |
| Hosts layer-2 services | Yes | No | No |
| Needs a public IP | Yes | No | No |
| Typical deployment | Server infrastructure | Desktop / mobile app | Browser app |
What you can build
All four layer-2 services ship in the current distribution and have been generally available since 3.1.0.
NAT traversal. A service on a private network opens an outbound encrypted tunnel to a super node, which allocates a public TCP port and forwards inbound connections back through it. No port forwarding, no static IP, no VPN - and the public endpoint is announced to the DHT so clients find it automatically.
DocumentationFederated, end-to-end encrypted messaging with offline delivery and multi-device support. The client encrypts before transmission; the server routes ciphertext it cannot read. Users on different super nodes reach each other over DHT peer lookups.
DocumentationContent-addressed binary object storage with TTLs, per-user quotas, and cross-node federation. Requests for objects held elsewhere are proxied to peer nodes and cached. No storage bucket, no cloud account, no third party holding your data.
DocumentationExposes the DHT as an authenticated REST API, so browsers and HTTP-only clients participate as light nodes without running a DHT node or speaking UDP.
DocumentationHold your identity
The app that holds your Boson key on your phone, and uses it to approve everything that acts in your name.
The key is generated on the device and sealed by the operating system's key store; every use asks for your fingerprint, your face or the screen lock. It leaves the phone only when you send it - as a backup you make, sealed to a new device you approve, or when you move your identity to another phone. Your home node hosts your account and its services, and never sees it.
Source on GitHub, MIT licensed. Android today, with iOS to follow.
Boson Identity on GitHubA new device joining your account, a web page signing in, a node making you an administrator. You scan the code it shows and confirm the number beside it, so an approval can only come from something in front of you. The key itself reaches a new device only when that device asks for one, sealed so that nothing in between can read it.
Back the key up as a file, a QR code or rows you can write down, and type part of it back before you rely on it. Moving to a new phone is one scan and a code. A forgotten passphrase resets with a recovery code, a passkey or a linked account - never with the key alone, and no operator can reissue a key for you.
If you run a super node, the same app administers it: users, plans, federation and the blacklist. Administration runs in a short session your key issues and that ends when you leave it, so an unlocked phone is not a standing key to the node.
Built on Boson
An end-to-end encrypted, federated messenger for Android, and the reference application for the Boson stack.
No Photon account, no phone number, no central address book. Your identity is an Ed25519 key pair generated on the device, and the private key never leaves the phone. Pick any super node as your home node; messages reach users on every other node.
Source on GitHub. MIT licensed.
Photon on GitHub
Every node ID is simultaneously a W3C DID. Publish a signed Card into the DHT as a mutable value and anyone holding the DID can resolve it - no registrar, no blockchain, no identity provider.
Expose a home server or a device to the internet through Active Proxy, without touching your router.
Federation
Anyone can run a super node, and you pick one as your home node much as you pick a mail provider. Federation is peer-driven: two operators exchange signed proposals and agree to share service registrations. There is no federation hub to join, no directory to be listed in, and no central operator who can de-list you.
Unlike email, changing home nodes does not change who you are. Your identity is discovered through the DHT, not through DNS or a provider database.
How federation worksOperators
Super nodes are the persistent infrastructure of the network: they host the layer-2 services, queue messages for offline devices, and relay traffic for peers behind NAT.
Anyone can run a super node. Run one privately, for yourself and your own devices, or open it up and host a community - the network makes no distinction between the two.
A small node is undemanding. A modest server with a public IP address - one core and a gigabyte of memory is enough to start - will comfortably carry a private node or a small community. What you need beyond that grows with the people using it.
Boson has no official server. These are public nodes anyone can use - one run by the project, one by the community - and you can run your own.
Download
Generally available since 3.1.0, August 2026.
| Platform | Architecture | Formats |
|---|---|---|
| macOS | Apple Silicon | ZIP |
| Linux | x86_64, aarch64 | ZIP, DEB (super node), DEB (bootstrap) |
| Windows | x86_64 | ZIP |
| Any | Portable, brings no Java runtime | ZIP |
The bootstrap package is a lightweight DHT-only node, for seed and discovery nodes without any layer-2 services.
Every release carries a SHA256SUMS file signed with the project release key, and the super node installer checks it before anything is installed.
Developers
The documentation is the technical source of truth - protocols, APIs, wire formats, and the full configuration reference.
Community
Boson is developed in the open, and the project runs on what people contribute to it. Issues, discussions, and pull requests are all welcome - code and documentation alike.