Protocol field guide · Checked 13 July 2026

Where Riot fits.

Riot is a community application runtime built on Willow—not a new universal social protocol. It is being designed so a group can carry mergeable data and small, signed tools across its own devices, even when no home server can be reached.

Prototype Claims separated by evidence No universal winner

Start with the category

These systems are not the same layer

A fair comparison begins by refusing false equivalence. Some distribute public posts, some federate rooms, some move encrypted messages nearby, and some provide a substrate on which products can be built.

Social publishing + federation

AT Protocol and ActivityPub organize public social activity across internet services.

Signed relay or chain networks

Nostr, Farcaster, and DFOS make signed identity or content portable across infrastructure with different trust models.

Nearby private messaging

Bitchat and Briar focus on conversations that can move directly between devices.

Offline-first social feeds

Secure Scuttlebutt replicates signed, append-only author feeds between peers.

Federated communication rooms

Matrix synchronizes event graphs across participating homeservers, with optional end-to-end encryption.

Mergeable data + community apps

Willow supplies a generic data model. Riot adds community meaning, policy, native UX, and a signed miniapp runtime.

Choose by the job

Orientation by situation

Public reachPublish into a global social web

Start with AT Protocol, ActivityPub, Nostr, or Farcaster.

See publishing systems →

Portable accountMove identity across providers

AT Protocol, Nostr, Farcaster, and DFOS each anchor identity differently.

Compare authority →

Private chatMessage a known person or group

Briar, Bitchat, and encrypted Matrix rooms make confidentiality a first-order concern.

See messaging systems →

No internetCommunicate across nearby devices

Bitchat and Briar ship direct transports; Secure Scuttlebutt was built for peer replication.

See offline behavior →

Shared toolsCarry community state and its apps

This is Riot's target: data and small approved tools travel together.

See Riot + Willow →

Compact orientation

One matrix, shared questions

This is an architectural map, not a scorecard. “Offline” means useful creation, reading, or exchange without a reachable home service—not merely a client cache.

Design centers and trust boundaries · scroll horizontally for all columns
System	Design center	Canonical data	Authority	How data moves	Without internet	Privacy boundary	Extension model
Riot + Willow	Community state and signed miniapps	Willow entries in namespaces, subspaces, and paths; Riot projects app values	Device keys, namespace policy, organizer approval	Transport-independent sync frames over available carriers	Local read/write works; tested exchange is loopback/Bonjour, not two-phone BLE	Current public spaces are plaintext; private groups are planned	Signed, content-addressed offline miniapps with a narrow bridge
AT Protocol	Large-scale public social apps	Signed public account repository on an authoritative PDS	DID plus rotatable keys and service location	PDS hosting, HTTP APIs, relay firehose, AppViews	Repo export/backups exist; normal network participation is service-oriented	Account repository content is public	Lexicons define records and APIs
ActivityPub	Federated social activity	ActivityStreams actors, inboxes, outboxes, objects, activities	Server-hosted actor account and implementation policy	Client-to-server and server-to-server HTTP	Clients may cache or draft; federation depends on reachable servers	Varies by implementation; participating servers process delivered content	Extensible ActivityStreams vocabularies
DFOS	Verifiable identity and content chains	Signed identity/content operations committing to document CIDs	`did:dfos` identity chains and credentials	HTTP web relays ingest, verify, store, and serve	Proofs and signed artifacts can be verified locally; distribution still needs carriage	Proof public; content access-controlled, not E2EE; storing relay sees plaintext	Application-defined documents plus standard schemas
Nostr	Signed social events over relays	Immutable signed events; replaceability depends on event kind/NIP	secp256k1 keypair; optional external naming	Clients publish to and query WebSocket relays	Events can be created/read locally; reaching others typically needs a relay path	Public events are public; encrypted-message NIPs protect payloads, not all metadata	Event kinds and optional NIPs
Farcaster	Permissionless social apps	Signed offchain social messages tied to onchain accounts	OP Mainnet contracts plus delegated app keys	Peer server network (Snapchain) stores and syncs messages	Local signing is possible; ordinary propagation relies on server network access	Core social messages are public; infrastructure observes network activity	Clients, APIs, and feed-embedded Mini Apps
Bitchat	Nearby, serverless chat	Ephemeral chat packets and local identity state	Device keys plus out-of-band fingerprint verification	BLE and peer gossip with TTL	Core purpose: direct nearby exchange without servers	Noise sessions protect private messages; nearby traffic metadata remains observable	Messaging application protocol, not a general data runtime
Secure Scuttlebutt	Offline-first social feeds	Per-author signed append-only feed	Long-term author key; social graph shapes replication	Peer replication on LAN, direct links, pubs, or rooms	Strong: create, read, and later replicate from device stores	Public feeds replicate in plaintext; private-message formats encrypt content	Message types, client conventions, metafeeds
Briar	Private resilient messaging	Locally stored conversations and application data	Contact exchange and per-contact cryptographic relationships	Bluetooth, Wi-Fi, and Tor over internet	Direct Bluetooth/Wi-Fi exchange is a shipping product behavior	End-to-end protected content and metadata-minimizing design	Purpose-built messaging/forums/blogs, not a general third-party app runtime
Matrix	Federated real-time communication	Room event graph plus deterministic state resolution	Homeserver-scoped user IDs, room membership, power levels, devices	Clients sync with homeservers; homeservers federate over HTTPS	Clients can cache; normal multi-party exchange depends on homeservers	Optional Olm/Megolm E2EE; homeservers retain graph and delivery metadata	Custom event types, clients, bots, bridges, application services

Maturity differs radically: ActivityPub and Matrix are deployed standards; AT Protocol, Nostr, Farcaster, SSB, Briar, and Bitchat have operating networks or products; DFOS, Willow, and Riot are earlier-stage efforts. Read the sources and threat models, not just this summary.

The central distinction

Why Willow?

Willow is deliberately below the product layer. It gives Riot a compact vocabulary for mergeable, selectively replicated bytes without dictating what a community, profile, checklist, or app must be.

Willow provides

Namespaces, subspaces, hierarchical paths, timestamps, and payload digests.
Deterministic rules for which entries remain relevant and tools for reconciling partial replicas.
A data model independent of any single network transport.
Meadowcap capabilities for scoped read and write authority when an implementation adopts them.

Willow does not define profiles, feeds, moderation, group membership, a miniapp catalog, or a WebView sandbox.

Riot adds

Community and profile semantics, including organizer authority and app approval.
Signed, content-addressed HTML/CSS/JavaScript bundles reviewed before launch.
A nonpersistent native WebView with no network access and a narrow app-scoped data bridge.
Preview/accept policy, persistence, transport adapters, catalog UX, and community-facing native screens.

Riot currently instantiates only part of the wider Willow family; using Willow does not imply interoperability with every Willow draft.

Concrete, not abstract

One checklist change, end to end

A person checks an item inside an approved miniapp.

The bridge validates the app-relative key and JSON value.

Riot writes a signed Willow entry under that app's community path.

Another device reconciles the entry over an available transport.

Riot projects the current value for the app key.

The open miniapp receives a change notification and redraws.

Proved: the native simulator app lifecycle, app bridge, redraw path, and headless loopback/Bonjour replication. Assumed, not proved: that the same path completes over BLE between two physical iPhones. That radio run has not been executed successfully yet.

Standardized deep dives

A field guide, on each system's own terms

Each profile asks the same questions: what is canonical, how data moves, who is trusted, what works offline, what privacy means, and how applications extend it.

Riot + Willow

Community-owned state and approved small apps that can travel with it.

Canonical: Willow entries organized by namespace, subspace, path, timestamp, and digest. Riot maps app keys into isolated path prefixes and projects values for the runtime.
Movement: A sync state machine carries signed entries over transport adapters. Transport independence is architectural; current real-radio coverage is incomplete.
Trust + privacy: Devices validate signatures and authorization; organizers approve executable bundles. Current public spaces are not confidential, and private encrypted groups are not shipped.
Offline + extensions: Local state and installed apps run without a server. Signed bundles use get, put, list, watch, identity, and profile APIs inside a network-disabled WebView.
What it learns: From SSB and Briar: the device must remain useful during a partition. From Willow: data architecture should not be welded to one carrier.
Deliberate difference: The unit is shared application state, not only a social post, feed, room event, or message.

Primary source: Willow specifications ↗

AT Protocol

An open protocol for large-scale public social applications.

Canonical: Each account has a signed, content-addressed public repository. The account's PDS is its authoritative repository location.
Movement: PDS hosts serve accounts; relays aggregate repository events; AppViews index application-specific views.
Trust + privacy: DIDs bind account keys and service location. Repository records are explicitly public and verifiable; private messaging needs additional application protocols.
Offline + extensions: Repositories can be exported for backup or migration, but normal social propagation is server-oriented. Lexicons define records and HTTP/WebSocket APIs.
What Riot learns: Portable identity and self-authenticating data reduce provider lock-in.
Deliberate difference: Riot targets community replicas on end devices and small offline apps, not a billion-account public firehose.

Primary source: AT Protocol specification ↗

ActivityPub

A W3C protocol for decentralized social networking.

Canonical: ActivityStreams actors expose inboxes and outboxes containing activities and objects. The protocol does not mandate a universal content store or merge model.
Movement: A client-to-server API creates and manages activity; server-to-server HTTP delivers it across federated sites.
Trust + privacy: Actors live at server-controlled URLs and implementations enforce policy. Delivered content is processed by the participating servers; privacy and encryption are not uniform protocol guarantees.
Offline + extensions: Federation requires reachable servers. ActivityStreams vocabulary extensions let communities build many social applications.
What Riot learns: A small shared vocabulary can unlock a diverse social ecosystem.
Deliberate difference: Riot begins with replicated device state under partitions rather than server inbox delivery.

Primary source: W3C ActivityPub Recommendation ↗

DFOS

Verifiable identity and content chains with application-defined documents.

Canonical: Signed identity and content operations form chains; content operations commit to CIDs of canonical documents.
Movement: The Web Relay receives, verifies, stores, and serves chains, artifacts, countersignatures, and content blobs.
Trust + privacy: The proof plane is public. Content is access-controlled plaintext, not end-to-end encrypted: a relay operator can read what it stores.
Offline + extensions: Proofs and signed artifacts can be created and verified locally, but reaching another person needs a carrier or relay. Standard JSON Schemas are optional application vocabulary.
What Riot learns: Separate cryptographic proof from evolving social semantics, and name custody honestly.
Deliberate difference: Riot adds mergeable community state, device reconciliation, and a constrained executable app runtime; DFOS centers verifiable chains.

Primary source: DFOS Protocol v1 ↗

Nostr

A simple protocol of signed events exchanged through relays.

Canonical: The base object is a signed event with an ID, author public key, time, kind, tags, and content. NIPs add replaceable events and domain-specific conventions.
Movement: Clients publish events to relays and subscribe with filters. Relays choose storage and access policy.
Trust + privacy: Signatures authenticate events without trusting a relay. Public events expose content; encrypted DMs protect payloads while relays can still observe routing metadata.
Offline + extensions: Events can be signed and cached offline, then published later. New applications mostly emerge as event kinds and NIPs interpreted by clients.
What Riot learns: Simple, portable signed objects let clients and infrastructure evolve independently.
Deliberate difference: Riot reconciles app-scoped values inside a community namespace rather than distributing a global stream of immutable events.

Primary source: NIP-01 ↗

Farcaster

A hybrid onchain/offchain network for permissionless social apps.

Canonical: Accounts and key authority are anchored in OP Mainnet contracts; most social actions are signed offchain messages.
Movement: Snapchain is a peer-to-peer network of servers that stores and synchronizes user data.
Trust + privacy: Onchain identity and delegated keys authorize public social messages. The core architecture is not a private-messaging system.
Offline + extensions: Normal distribution requires server reachability. Clients can vary widely, and Mini Apps run inside Farcaster feeds.
What Riot learns: A social graph can distribute applications where people already gather.
Deliberate difference: Riot miniapps run from signed bundles against a local community store with network access disabled, rather than as internet applications embedded in a global feed.

Primary source: Farcaster architecture ↗

Bitchat

Secure peer-to-peer messaging over ephemeral nearby networks.

Canonical: Compact chat packets carry message, acknowledgment, routing, and fragmentation data; identity state remains on devices.
Movement: Peers use BLE-like transports and gossip packets with time-to-live limits; central routing servers are absent.
Trust + privacy: Noise XX establishes encrypted sessions. Human identity still requires out-of-band fingerprint verification, and nearby observers can detect radio activity.
Offline + extensions: Nearby operation without internet is the primary use case. The application layer is chat-specific rather than a general replicated datastore.
What Riot learns: Nearby exchange must tolerate loss, small frames, fragmentation, and ambiguous human identity.
Deliberate difference: Riot aims to reconcile durable community data and applications; Bitchat prioritizes ephemeral conversation.

Primary source: Bitchat protocol whitepaper ↗

Secure Scuttlebutt

A peer-to-peer protocol family for offline-first social applications.

Canonical: Each identity appends signed messages to its own hash-linked feed. Feed history is immutable; applications interpret message content.
Movement: Peers replicate feeds directly, on a LAN, or through pubs and rooms; EBT uses vector-clock-like state to exchange missing messages.
Trust + privacy: Author signatures authenticate feed messages. Public feeds are copied in plaintext; private-message formats encrypt selected content.
Offline + extensions: Local-first operation is foundational: write and read locally, replicate later. Message types, metafeeds, and client conventions form the extension surface.
What Riot learns: People can own useful local replicas instead of treating devices as thin server clients.
Deliberate difference: Willow permits mutable path-oriented projections and partial areas; classic SSB centers append-only author feeds.

Primary source: Scuttlebutt Protocol Guide ↗

Briar

A private messenger built to survive surveillance and network disruption.

Canonical: Conversations, groups, forums, and blogs are stored on participants' devices rather than a central service.
Movement: Devices can exchange through Bluetooth and Wi-Fi nearby, or through Tor when internet is available.
Trust + privacy: Contact exchange establishes cryptographic relationships. Briar states that neither content nor communication metadata is available to its project service.
Offline + extensions: Nearby communication is a real product path. Features are purpose-built; Briar is not a general third-party miniapp runtime.
What Riot learns: Threat modeling, metadata restraint, and direct device transports must shape the whole product—not sit in a privacy page.
Deliberate difference: Riot's first shipped model is public communal data and tool use; it must not borrow Briar's privacy language before encrypted groups exist.

Primary source: Briar — How it works ↗

Matrix

Open APIs for decentralized, federated real-time communication.

Canonical: Room events form a partially ordered event graph. Deterministic state resolution selects room state when events conflict.
Movement: Clients sync history with a homeserver; homeservers replicate room history over signed federation APIs.
Trust + privacy: Room authorization uses membership and power levels. Olm/Megolm can protect message content end to end, while homeservers still process graph and delivery metadata.
Offline + extensions: Clients can retain local history, but ordinary exchange depends on homeservers. Custom event types, application services, bots, and bridges are broad extension points.
What Riot learns: Deterministic conflict handling and explicit room authority are essential once multiple parties write shared state.
Deliberate difference: Riot places canonical replicas and miniapps on participant devices; Matrix's normal architecture synchronizes clients through federated homeservers.

Primary source: Matrix specification ↗

Prototype means prototype

What Riot does not provide yet

Confidentiality

Private encrypted groups are not shipped. Current public spaces are not confidential.

Physical radios

The complete sync path has not been verified over BLE between two physical iPhones.

Persistence

Durable multi-community storage is not complete across every app surface and lifecycle.

Interoperability

Riot is not an interoperable implementation of every Willow draft or transport specification.

Security review

The signed miniapp catalog and runtime are a prototype, not an audited app store.

Availability

A carrier can still delay or deny exchange. Local-first removes a mandatory home server; it does not repeal radio range, device loss, or hostile peers.

Maintainer documents, not vibes

Primary source ledger

Checked 13 July 2026. Protocols evolve; follow these specifications for current normative behavior and status.

WillowData Model · Meadowcap · Willow'25 · WTP
AT ProtocolProtocol · Repository · Accounts
ActivityPubW3C Recommendation · ActivityStreams Core
DFOSProtocol v1 · Content Model · Web Relay
NostrNIP-01 · NIP-44
FarcasterArchitecture · Mini Apps
BitchatProtocol whitepaper · Reference project
Secure ScuttlebuttProtocol Guide
BriarHow it works · Privacy Policy
MatrixSpecification · Room versions · Federation API