> For the complete documentation index, see [llms.txt](https://docs.bosonnetwork.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bosonnetwork.io/resources/roadmap.md). # Roadmap & Status This page describes what is implemented and available today, and what is planned or in progress. Where the status is uncertain or not yet publicly committed, items are marked accordingly. {% hint style="success" %} **Boson is generally available.** [3.1.0](/resources/changelog.md) (2026-08-23) was the first GA release, concluding the Community Technical Preview series that ran through 3.0.x. The current stable release is **3.2.0**. {% endhint %} *** ## What is implemented today ### Layer 1 - Boson DHT (KadNode) * Hardened Kademlia DHT over UDP (default port 39001) * Ed25519 cryptographic node identity - no central registry, no username registration * Signed mutable values and unsigned immutable values in the DHT * Full RPC protocol: `PING`, `FIND_NODE`, `FIND_VALUE`, `STORE_VALUE`, `FIND_PEER`, `ANNOUNCE_PEER`, and since 3.2.0 `SUBSCRIBE` with `NOTIFY_VALUE` and `NOTIFY_PEER` * [Subscriptions](/core-concepts/kademlia-dht.md#subscriptions): the storing nodes push changes to a watcher instead of it polling, through NAT * Dual-stack IPv4/IPv6 on a single port * Dual serialization (JSON and CBOR) for RPC messages * Security blacklist for misbehaving peers * Interactive DHT developer shell (`boson-node shell`) ### Layer 2 - application services All four services are production-ready and ship in the current distribution: | Service | Protocol | Description | | ---------------- | --------------- | ------------------------------------------------------------------------------------------------------------- | | **web-gateway** | HTTPS | Exposes the DHT as an authenticated REST API for Light Nodes (browsers, HTTP-only clients) | | **messaging** | MQTTS | Federated, end-to-end encrypted instant messaging with offline delivery and multi-device support | | **ion-store** | HTTPS | Distributed binary object storage with TTL, per-user quotas, content deduplication, and cross-node federation | | **active-proxy** | TCP (encrypted) | NAT traversal - gives any NATted service a stable public TCP endpoint without port forwarding | ### Director (super-node supervisor) * Lifecycle management for the DHT node and all Layer-2 services * User identity and client device management * CWT (CBOR Web Token) authentication - Ed25519-signed, CBOR-encoded bearer tokens * Subscription and billing framework (operator-defined plans) * Federation between super nodes - signed proposals, shared service registrations, cross-node traffic routing * DHT node auto-ban for misbehaving peers * Optional Prometheus metrics endpoint * Built-in admin dashboard (`/admin/`) and user portal (`/portal/`) * Setup wizard for first-run configuration * Passkey sign-in, and passphrase recovery by recovery code, passkey or linked OAuth account (3.2.0) * Web sign-in through the Boson Identity app, and administrator enrollment by QR code (3.2.0) * Sign-in for community apps, by client ID metadata document and PKCE, with a consent page (3.2.0) * A security log of account events, kept for 90 days or each user's newest 200 (3.2.0) ### Distribution and packaging * ZIP archives for macOS (Apple Silicon), Linux (x86\_64 + aarch64) and Windows x86\_64, plus a portable `any.zip` for everything else * DEB packages for Linux: full super-node package and lightweight bootstrap-node package * Bundled minimal JRE via `jlink` (no system Java required at runtime) * Command line tools: `boson-node` (DHT node), `boson-director-cli` (Director API) and `boson-cli` (account and key utilities) ### Identity and cryptography * W3C DID Core and W3C Verifiable Credentials compatible identity layer * All identities anchored to Ed25519 key pairs - fully self-sovereign, no central registry * TLS on every HTTPS and MQTTS service, with either a certificate from a public authority or a self-signed certificate bound to the node's identity * CWT token authentication with clock-skew-aware validation and audience binding ### Java SDK * Core API library (`boson-api`) and the full DHT node (`boson-dht`) * A light node that works through a super node's Web Gateway (`boson-higgs`) * Client libraries for the Director and all four services The SDK is published to **Maven Central** as `io.bosonnetwork`, starting with 3.1.2. See [Java SDK Setup](/build-applications/java-sdk.md). ### Applications Open-source apps built on Boson, which are also the reference for what the platform supports: | App | Platform | What it shows | | --------------------------------------------------------------- | ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | [Boson Identity](https://github.com/bosonnetwork/BosonIdentity) | Android 13+ | Holding a user key on a phone, approving devices and web sign-ins, administering a node. See [Manage Your Identity](/getting-started/identity-app.md) | | [Photon](https://github.com/bosonnetwork/PhotonMessenger) | Android 13+ | Federated, end-to-end encrypted messaging over Photon Messaging and Ion Store | iOS versions follow the Rust libraries below. *** ## In progress / planned ### Native SDK (Rust) A Boson DHT node implemented in **Rust** is planned for embedding Boson into native applications that cannot use the JVM - native desktop and mobile apps, IoT/embedded devices, and (via a C FFI) other languages. It runs a full Regular Node, participating directly in DHT routing. **Status**: Coming soon. No public timeline has been committed. ### JavaScript SDK (browser light node) A **JavaScript** light-node SDK for browser applications is planned. It will let web apps act as [Light Nodes](/core-concepts/node-types.md) against a super node's Web Gateway without hand-rolling HTTP calls. **Status**: Coming soon. ### Additional services No additional Layer-2 services have been publicly announced beyond the current four. You can also build your own - the open-source core supports [custom Layer-2 service development](/build-services/custom-service.md). If you have a use case that needs a new built-in service type, open a discussion in [Boson.Core](https://github.com/bosonnetwork/Boson.Core). ### Mobile SDKs On Android, the Java SDK runs today on the standard JVM support. Native mobile integration (including iOS) will be served by the **Rust native SDK** described above. ### Incentive / economic layer As noted in the [FAQ](/resources/faq.md), no built-in incentive token or on-chain economic mechanism exists today. Whether one will be added is an open design question. *** ## Version line The current stable release is **3.2.0**. The SDK has been on Maven Central since 3.1.2. The 3.x line reached **general availability with 3.1.0** (2026-08-23), concluding the Community Technical Preview series that ran through 3.0.x. Note that 3.1.0 reworked the configuration syntax and is *not* backward compatible with 3.0.x - existing configuration files must be regenerated before upgrading. See [Release Notes](/resources/changelog.md) for the version history. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.bosonnetwork.io/resources/roadmap.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.