Boson Network A decentralized network where your identity is a key, not an account.

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

Three things Boson does not have.

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.

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.

No certificate authority

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.

No password database

Authentication is a CBOR Web Token - Ed25519-signed, validated against your DHT public key. There are no stored credentials to breach.

Read the architecture overview

Why Boson

Specific properties, not adjectives.

Your identity is a key pair

Ed25519, self-generated. No username, no email address, no account recovery - because there is no account.

No certificate authority

A self-signed certificate, bound to the node identity, is enough. Clients pin the service peer ID instead of trusting a root store.

No passwords to breach

Ed25519-signed CBOR Web Tokens replace the credential database entirely.

Permissionless

A key pair and a reachable UDP port is the entire joining procedure. No registration, no authority that approves nodes.

Federated, not centralized

Super nodes federate peer to peer through signed proposals. There is no hub to join and no directory to be listed in.

Open

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

Two layers, three kinds of node.

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.

Layer 2

Application services

Run on super nodes and announce themselves into the DHT, so clients can find them without hard-coded addresses.

  • Active Proxy Encrypted TCP
  • Messaging MQTTS
  • Ion Store HTTPS
  • Web Gateway HTTPS
Layer 1

Boson DHT

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

Node types

Super NodeRegular NodeLight Node
DHT participationFull (UDP)Full (UDP)None - via Web Gateway
Hosts layer-2 servicesYesNoNo
Needs a public IPYesNoNo
Typical deploymentServer infrastructureDesktop / mobile appBrowser app
Node types in detail

What you can build

Four services, shipping today.

All four layer-2 services ship in the current distribution and have been generally available since 3.1.0.

Active Proxy

Encrypted TCP

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.

Documentation

Messaging

MQTTS

Federated, 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.

Documentation

Ion Store

HTTPS

Content-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.

Documentation

Web Gateway

HTTPS

Exposes 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.

Documentation

Hold your identity

Boson Identity

The app that holds your Boson key on your phone, and uses it to approve everything that acts in your name.

Three Boson Identity screens: the home screen with the profile and home node, the security summary with key backup and passphrase, and the device list with its apps and passkeys.
The Boson Identity home screen: the profile, the public profile card switch, and the home node with its plan.

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 GitHub

Approve what acts in your name

A 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.

Lose the phone, not the identity

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.

Run your node from it

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

Photon

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
Four Photon screens fanned out: the chat list, the contact list, friend requests, and the settings screen with its Boson ID.
The Photon chat list, showing direct conversations and a group, each with the time and the unread count.

Also built on the same primitives

Self-sovereign identity

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.

Self-hosted services behind NAT

Expose a home server or a device to the internet through Active Proxy, without touching your router.

Federation

Federated like email. Except your identity is not owned by your provider.

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 works

Operators

Run a super node.

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.

Public nodes

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

Get Boson.

Latest release 3.2.0 2026-10-16

Generally available since 3.1.0, August 2026.

PlatformArchitectureFormats
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.

Community

Build with us.

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.