Noosphere Network

Noosphere is a framework for decentralized off-chain applications. It combines peer-to-peer networking, group coordination and threshold signing. Your app defines the rules; participants approve operations and sign together without assembling the complete private key.

FROST does the threshold cryptography. ROAST coordinates signing. Iroh connects the peers. Your application decides what to sign.

Source on GitHub · Architecture docs · Desktop demo

A release-announcement app: the app-owned releases topic contains a message, ‘Ship version 1.0.’ A coordinator routes events to three signers: Ada, Bo and Cy. Ada and Bo contribute in this 2-of-3 example; Cy sits out. The app verifies and saves one group signature. — A small app, end to end. Topics and history belong to your app; coordination and shared signing belong to Noosphere.

What is this for?

Shared wallets and treasuries. Require several owners to authorize a payment.
A wallet across your devices. Spread signing authority across separate devices.
Team operations. Approve an administrative command or policy document together.
Collective attestations. Sign a statement, document digest or release manifest as a group.

These are things you can build, not bundled apps. Your app constructs the payload, shows signers what it means, and acts on the result. The receiving system must recognize the group public key and support the signature scheme.

How it works

1. Make a group and generate a key

Choose a roster and a threshold, for example three out of five participants. Distributed key generation (DKG) produces a shared public key and a private share for each participant. No dealer first creates a complete private key and hands out pieces.

2. FROST: sign together

Flexible Round-Optimized Schnorr Threshold signatures. Enough participants contribute to a single Schnorr signature under the group public key. Ordinary signing never assembles the complete private key. Each signer keeps their own share.

3. ROAST: keep signing moving

Robust Asynchronous Schnorr Threshold signatures. ROAST coordinates FROST signing attempts so slow, unavailable or uncooperative participants need not stall the operation when enough responsive, cooperating signers remain. It still needs the threshold and an available coordinator.

4. Verify the result and use it

The coordinator collects contributions and returns the signature. Your app verifies it, records the outcome, and performs the operation. The coordinator role requires no FROST share and cannot sign for the group on its own.

What can be signed? Transaction requests can carry multiple signing digests. Text requests sign exact UTF-8 text (up to 1,024 bytes) using a domain-separated digest and yield a portable BIP-340 signature. Lower-level digest signing is also available; your app must deliver the original content and let signers verify it.

Networking: Iroh, P2P, one coordinator

Iroh provides authenticated, encrypted QUIC connections, endpoint discovery, direct connectivity and relay fallback. Participants pin the coordinator’s stable endpoint identity; its network address can change.

Four participants connect over Iroh to a coordinator. The coordinator receives authenticated RPCs and routes protocol events back to participants. — Same group, separate devices. P2P transport; coordinator-routed protocol.

The coordinator can run as a service or inside an application. A participant in the same process can use LocalCoordinatorApi instead of a network connection.

Transport encryption does not hide ordinary proposals or message text from the coordinator. DKG and recovery shares have additional recipient-specific encryption. Participant signatures protect authored content, but the coordinator still controls delivery.

Events are how the protocol moves

A participant submits an authenticated RPC. The coordinator updates protocol state and sends typed events to the relevant participants. Events announce proposals, deliver DKG contributions, start signing rounds, report progress, and deliver results or cancellation.

Ada proposes ‘Ship version 1.0’ through an authenticated RPC. The coordinator routes a proposal event to Bo’s client, which validates it before Bo reviews and approves or rejects it. Enough approvals lead to signing rounds, a result event, client verification and an app notification. — Receiving an event is not approval. The client still validates it.

Event: Coordinator-to-participant protocol input: proposals, contributions, rounds and results.
ClientEvent / NoosphereWorkerEvent: Selected local outcomes for your Dart app or Flutter UI. These are projections, not copies of every network event.
Optional public feed: A separate read-only, unauthenticated feed for notifications and transparency. It has a durable redacted journal and signed checkpoints, exposing operation types, timing and outcomes rather than payloads, identities or key material. It cannot approve or sign anything.

The live stream is not a durable application history or a generic message bus. Ordering holds within a session, not across all RPCs and peers. Reconnect creates a new session and current-state snapshot. Keep your own history and deduplicate side effects when results are redelivered.

Event semantics · Public feed guide

Put it in an application

Start with the desktop demo to try DKG and signing across two computers. It uses public test identities and temporary storage.

Packages in the Dart workspace
Package	What it does
`noosphere_protocol`	Domain types, encodings and wire protocol.
`noosphere_client`	Participant state machine and Iroh client.
`noosphere_server`	Coordinator state machine, Iroh server and CLI.
`noosphere_flutter`	Flutter worker; protocol and cryptography in an isolate.

Choose the Flutter facade or the Dart client/server packages. Follow their setup guides for native libraries.
Supply identities, group configuration and the trusted coordinator endpoint ID.
Implement durable storage and key-access callbacks. Subscribe to notifications before starting work.
Build the review and approval UI. Verify results and track external effects such as transaction broadcasts.

Your app owns persistence and key custody. Protect FROST shares, persist signing nonces atomically, and store resumable DKG secrets through the application callback. Restoring an identity mnemonic does not restore a FROST share.

Storage contracts · Security model · Run a coordinator