Secure Scuttlebutt (SSB)

Each user's identity is a cryptographically signed, append-only log of messages. Every new post, like, or follow is a signed entry appended to the user's local log. This creates an immutable, verifiable history where:

• Integrity is guaranteed by digital signatures.
• Replication is simple: peers sync by requesting missing sequence numbers.
• The log is the source of truth, enabling offline-first operation.

SSB nodes discover and connect directly using a gossip protocol. There is no central server; data propagates through a mesh network. Key mechanisms include:

• Local Discovery: Finding peers on the same WiFi via UDP broadcasts.
• Pub Servers: Optional relay servers (pubs) help bootstrap connections.
• Epidemic Broadcast Trees: Efficiently gossiping new messages to minimize redundant traffic across the network.

All messages are stored and referenced by their cryptographic hash (SHA256). This means:

• Data is immutable: The hash uniquely identifies the content.
• Deduplication is automatic: The same message hash is stored only once.
• Integrity is verifiable: Any tampering changes the hash, breaking the reference. This forms a Merkle DAG structure, similar to Git, enabling efficient syncing of partial histories.

Data replication is driven by the social graph. You primarily sync data from people you follow (1-hop) and from people they follow (2-hops). This creates a friend-of-friend replication model that:

• Scales naturally with social interest.
• Preserves privacy by limiting unnecessary data propagation.
• Allows for partial replication, where nodes only store data relevant to their local community.

SSB is designed for local-first software. All your data and social graph are stored on your device. This enables:

• Full functionality offline: Read and compose posts without a network connection.
• Asynchronous sync: Changes are replicated when peers connect later.
• User sovereignty: You own your data and identity, independent of any service provider.

The core protocol defines the replication layer, while application logic is built via message schemas. Developers create new message types (e.g., post, vote, about) to build applications like:

• Social feeds (Patchwork, Manyverse)
• Blogging platforms (Oasis)
• Collaborative tools (e.g., chess games, code repositories) This separation allows for innovation without forking the underlying network.

The core data structure in SSB is a cryptographically signed, append-only log (or feed). Each user controls their own feed, where every new message is:

• Signed with the user's private key.
• Linked to the previous message via a hash.
• Immutable once published. This creates a verifiable, tamper-proof history of a user's activity, forming the basis for decentralized social graphs and data replication.

SSB nodes discover and connect directly using a gossip protocol. Instead of centralized servers, peers:

• Share their contact lists (who they follow).
• Replicate the logs of users they follow, and the logs of those users' followers.
• Propagate updates across the network organically. This creates a resilient, serverless mesh network where data flows based on social connections, not infrastructure.

SSB is designed for environments with poor or intermittent connectivity. Key principles include:

• Local database: All replicated data is stored permanently on the user's device.
• Eventual consistency: The network syncs and reconciles logs when peers connect.
• No global consensus: There is no requirement for all nodes to agree on a single state. This enables applications that work seamlessly offline and prioritize user data sovereignty.

All data in SSB is referenced by its cryptographic hash, using a scheme called SSB URIs (e.g., %hash123...=.sha256). This means:

• Content is immutable; changing the data changes its address.
• Data integrity is automatically verified upon retrieval.
• It enables efficient deduplication across the network. This system ensures that shared content, like images or posts, is uniquely identified and cannot be corrupted.

Identity in SSB is derived from a user's long-term Ed25519 signing key pair. A user's public key is their permanent identifier (e.g., @key123...=.ed25519). This provides:

• Self-sovereignty: No central authority issues or controls identities.
• Verifiable authorship: Every message is signed, proving it came from that key.
• Portability: Identity and social graph are not tied to any specific server or domain.

While both are decentralized, SSB differs from traditional blockchains in key ways:

• No global ledger: Each user maintains their own log; there is no single chain.
• No native cryptocurrency or mining: The protocol is designed for social data, not value transfer.
• No global consensus: Agreement is only needed between directly interacting peers.
• Social replication: Data spread is based on social graphs, not proof-of-work or proof-of-stake.

SSB is designed for eventual consistency and offline operation. Data is stored locally in an append-only log (the user's feed) and gossiped between peers when they connect. This architecture:

• Eliminates reliance on central servers.
• Ensures data availability even without an internet connection.
• Shifts the security model from perimeter defense to local data integrity.

Each user is identified by a public key, which also signs their entire append-only log of messages. This creates a cryptographically verifiable history where:

• Every message is signed and immutable.
• Identity is self-sovereign, not issued by a central authority.
• The feed's hash chain ensures data integrity and prevents tampering with past entries.

Data propagates via a gossip protocol where peers exchange messages from feeds they follow. This creates a redundant, distributed network without central hubs. Key security aspects include:

• Selective replication: You only store data from people you choose to follow.
• Network obfuscation: The social graph is not globally visible, only to connected peers.
• Resilience against single points of failure or censorship.

Privacy in SSB is enforced by client-side access control and encrypted messages. Users have complete control over their data because:

• All data is stored on the user's own device.
• Private messages use end-to-end encryption using the recipient's public key.
• Visibility of content is managed by the client software, not a network rule.

The trust model is based on a web-of-trust established through following relationships. Security implications are:

• You primarily see content from people you follow or are transitively connected to (friends-of-friends).
• Sybil resistance is social, not computational; creating many fake identities doesn't grant influence without being trusted by the existing graph.
• Moderation and blocking are performed at the client level.

SSB's design introduces specific trade-offs. Key considerations for developers and users include:

• Metadata Exposure: While content can be private, the fact that two peers are communicating may be visible to other nodes in the gossip network.
• Storage Burden: Users must store all data from feeds they replicate, which grows over time.
• Denial-of-Service: Peers can be overwhelmed by large volumes of data from malicious feeds they've chosen to follow.

The gossip protocol is the core replication mechanism in SSB, where peers exchange and forward messages in a decentralized manner. Each node maintains connections to a subset of other nodes, periodically sharing new messages it has received. This creates an eventually consistent, resilient network without central servers.

• Epidemic Dissemination: Messages spread like a rumor or 'scuttlebutt' through the network.
• Partial Replication: Nodes only replicate the logs of peers they follow, not the entire network state.

In SSB, a user's identity is defined by a cryptographically signed, append-only log (also called a feed). Every post, like, or follow is a message appended to this log. The log's integrity is secured by linking each new message to the previous one via a hash, creating an immutable chain.

• Immutable History: Once published, messages cannot be altered or deleted.
• Verifiable Origin: Anyone can cryptographically verify that all messages in a log were created by the same private key holder.

SSB replicates data based on a user's social graph. When you follow someone, your node subscribes to their append-only log and begins replicating its messages. This model means you store the data of people you follow and, transitively, the data of people they follow, creating a decentralized social network where data distribution mirrors human relationships.

• Selective Storage: Data storage is scoped to your social connections.
• Offline-First: The replicated data allows for local, offline access to your social feed.

SSB uses structured message types to define different kinds of content. Common types include post for text updates, contact for following/unfollowing, and vote for likes. These types are defined using JSON schemas, allowing applications to interpret and display content consistently.

• Extensible: Developers can create custom message types for new applications.
• Interoperable: Different SSB clients can understand core message types, enabling a multi-app ecosystem on the same protocol.

A unique feature of SSB is its support for off-grid or local networking. Peers can discover and sync directly over a local Wi-Fi network or via USB drives using the 'Dark Crystal' or 'sneakernet' method, enabling communication without an internet connection.

• Pub Servers: For internet connectivity, users often connect to persistent peers called 'pubs' to find others.
• Resilience: This hybrid approach makes the network highly resilient to internet outages or censorship.

While both are decentralized, SSB differs from blockchain in key ways. SSB uses individual append-only logs instead of a global chain, and consensus is social (what your peers have signed) rather than computational (Proof-of-Work).

• No Global State: There is no single ledger everyone must agree on.
• No Native Token: The protocol operates without a cryptocurrency or mining incentive.
• Identity-Centric: Data is organized by author, not by a global transaction history.