Field Notes

entity

Secure Scuttlebutt

StatusWorkingReviewdue UpdatedStands on3 sourcesSupportsnotes

Secure Scuttlebutt is an offline-first P2P protocol family for replicating signed social feeds. Each author appends messages to a local log, and peers exchange missing messages when they meet over a local network or through Internet rendezvous infrastructure. The design makes intermittent connectivity ordinary rather than treating a server as the canonical copy of a conversation.

Secure and decentralized communication stacks places SSB beside messengers, federated systems, and other replicated protocols. Secure Scuttlebutt protocol sources preserves the main protocol guide and current ecosystem evidence used here.

Signed feeds are the unit of authorship

A classic SSB identity is an Ed25519 key pair. Its feed is an append-only sequence in which each signed message names the previous message. Recipients can verify the author and detect alteration or an invalid fork without asking a central account service.1

Replication is interest-driven. Clients commonly use a public follow graph to decide which feeds to fetch and how many social hops to retain. EBT exchanges compact feed clocks and then transfers missing ranges. Because peers store complete signed records locally, the same data can arrive through direct contact, a local network, or several intermediaries.

flowchart TD
  A[Author appends signed feed] --> B[Nearby peer]
  B --> C[Offline local store]
  C --> D[Later peer contact]
  D --> E[Missing feed ranges replicate]
  F[Pub or room] -. discovery or tunnelling .-> B
  F -. discovery or tunnelling .-> D

Pubs and rooms solve different reachability problems

Legacy pubs are always-online peers that accept connections, replicate member feeds, and place newcomers near an existing social graph. This improves discovery and availability but gives pub operators observable network and membership relationships.

Rooms instead help peers discover one another and tunnel connections through a reachable server. They are not intended to retain every participant’s feed. This reduces the relay’s storage role without eliminating its visibility into connection timing and membership.

The distinction matters when comparing SSB with federation. A pub is useful infrastructure, but it is not the authoritative home of an identity or feed. A user can replicate through other peers without migrating a server-side account.

Offline resilience moves costs to devices and identity

The append-only model supports disconnected reading and writing, local-area synchronization, and eventual delivery through social peers. The same model creates several hard product problems:

  • traditional replication may require downloading and indexing long feed histories before recent content becomes usable;
  • immutable signed messages make global deletion or correction impossible to guarantee after replicas have spread, which puts the feed past even Advisory deletion: the data structure forbids retraction rather than merely failing to compel it;
  • a long-lived feed key binds identity to one secret, making loss, compromise, rotation, and multiple devices difficult;
  • availability depends on useful peers retaining and forwarding the desired feeds;
  • public follow relationships can expose a social graph even when message content is encrypted.

Metafeeds and partial-replication designs attempted to separate applications and devices, support newer feed formats, and fetch recent slices instead of every historical message. The protocol guide now marks its metafeed material as archived, which is evidence about documentation state rather than proof that every implementation abandoned the design.1

Ecosystem maturity is now the main constraint

Patchwork, the early desktop application, was archived in May 2021 and its maintainers directed contributors toward other clients.2 Manyverse carried the architecture onto mobile devices, but a July 2024 project update described a new protocol direction and said continued compatibility with the existing SSB network was unlikely. The public Manyverse repository shows later maintenance activity, so this is a transition signal rather than evidence that all SSB software stopped immediately.3

The protocol therefore remains valuable as a design reference for offline-first social data, socially scoped replication, and identity independent of a home server. For a new deployed communication system, its fragmented and migrating client ecosystem is a material adoption, security-update, and interoperability risk.

Evaluation rule

Evaluate an SSB deployment as a complete profile:

  1. the exact feed and replication formats;
  2. peer discovery through local networks, pubs, rooms, or other relays;
  3. private-message and group cryptography;
  4. device linking, key rotation, compromise recovery, and backups;
  5. deletion and moderation semantics;
  6. active maintainers, releases, audits, and compatible clients.

At the present evidence level, SSB is a technically important branch rather than a default recommendation for confidential everyday messaging.

  1. Secure Scuttlebutt protocol sources § Protocol guide (Scuttlebutt Protocol Guide, ssbc.github.io); saved copy. First-party documentation covering keys, signed append-only feeds, replication, the follow graph, pubs, rooms, and private messages. ↩↩

  2. Secure Scuttlebutt protocol sources § Patchwork archive (ssbc/patchwork repository page, GitHub); saved copy. Archived 12 May 2021, with a final notice directing contributors to Oasis and Manyverse. ↩

  3. Secure Scuttlebutt protocol sources § Manyverse transition (Manyverse project update, July 2024); saved copy. A maintainer’s statement about one client’s direction, so it does not establish the status of other SSB implementations. ↩

Built on 3 sources (3 external).

Working out connections…