Scalable Secure-Scuttlebutt (ssb) is a distributed gossip protocol designed for social sharing. Identities are cryptographic key pairs, feeds are a signed append-only log sequence of messages, and nodes use a gossip protocol to disseminate content. Feeds can be thought of as essentially personal blockchains, as they consist of immutable, timestamped content.
Ssb is based on the idea that your social network mirrors your actual communication network, and your network peers mirror your actual peers. Ssb focuses more on moving lightweight social data rather than large data, unlike protocols like bittorrent, Hypercore, and IPFS. Users are distributed across a few different client apps that work on desktop (Patchwork) and mobile (Manyverse, Planetary).
A user's identity is their ed25519 key pair which is used to sign posts, verifying their authenticity. Messages are addressed to a users public key, for example:
Users can pick a human-readable nickname that is associated with their key, but nicknames are not unique because there is no global registry. Identity is verified based on a web-of-trust - if nodes that a user trusts attest to the authenticity of an account, that account is assumed to be authentic.
Nodes request all messages in the feed that are newer than the latest message they know about. Scuttlebot, the networking component of ssb, maintains a table of known peers which it cycles through asking for updates for all followed feeds. Messages are passed through the ssb network via a gossip protocol. Messages may be passed through third parties (unless the user is blocked by that party), which improves availability.
Pubs, bot-user nodes with public IP addresses that stay online, ensure uptime and availability. Pubs are essentially the bootstrap nodes and mail-bots of ssb. Pubs offer invite codes to new users, follow users, and rebroadcast messages to other peers. Ssb has no DHT or NAT-traversal utilities, so users must connect to a Pub to distribute their messages. Identity is not tied to pubs, unlike homeservers in Matrix or ActivityPub, so a user can join one or multiple pubs.
A [scuttlebutt DHT invite](https://gitlab.com/staltz/ssb-dht-invite) plugin that shares connection invites over a DHT was created in 2020.
Each post is appended to the last in a linked list append-only log establishing chronological ordering from the first post. Once appended, posts are immutable. Content cannot be easily edited or deleted, but the append-only log ensures that the network converges towards the same state despite partitions.
When a follow relationship is initiated, the posts of the user being followed begins to be synced to the follower's node. Those messages and files are stored locally on the user's computer, indefinitely, for applications running ssb to read. An ssb application is constantly sharing data with other nodes in the background.
There is no global moderation, and no specialized moderators in ssb. At the protocol level, there is a “flag” feature to send a strong negative signal about bad actors. Applications built on top of ssb allow users to “block” and “ignore”. An ignore will simply not show that data to the user's node, although their node will continue to pass their data through the network. A block will cause the user's node to refuse to replicate data from that feed, segmenting it off from their portion of the network. If enough people block a user or group of users, their part of the network will become partitioned from the rest.
There is no global feed of content in ssb. All content is surfaced through social discovery. Out-of-band sharing, sending an ssb link through another channel, can also surface new content.
Ssb clients decide how many hops away from primary follow relationships should content be shown. The default is 2 hops: data from friends and FoaFs (friend of a friend's). Messages from 3 hops out are replicated to keep them available for others, but not shown in the user interface.
Ssb applications can easily support encrypted DMs because user identities are cryptographic keypairs. Whoever controls the private key of an identity can publish to that feed. Messages canot be faked, omitted, or re-ordered, due to the signed append-only log nature of the feed.
The ssb ecosystem is supported through a variety of grants, donations, income from side projects and consulting, and a few companies that have raised money to build applications on ssb, including Planetary.
Key management is one of the biggest challenges of ssb, as users inevitably lose and forget their passwords. Users are in complete control of their identity. That means if they lose their cryptographic key, they can permanently lose access to their account. Keys are currently stored on devices, which makes it impossible to sign in to one account across multiple devices — a basic feature of social networks users have come to expect.
To attempt to address the problem of key management, a project in the ssb ecosystem, [Dark Crystal](https://darkcrystal.pw), has implemented a social key recovery system. It splits keys into shards to store with family and friends who can be trusted to help reconstruct a lost key.
The p2p bootstrapping process introduces frictions for new users. First, new users typically join a pub to get connected to the network after they download an ssb application. Then, there is a period of waiting time during the initial sync when logs are being downloaded, like the syncing time of a blockchain. A user that has not opened an ssb application in awhile will encounter this synchronization delay again while their node catches up to the state of the network.
The inability to edit or delete content also runs contrary to user expectations. Because of the append-only nature of ssb feeds, there is no ability to permanently delete a piece of content. Applications can work around this by honoring edit or delete messages appended to the feed, but the original content stays in the append-only log that is shared among all nodes, and other applications could choose not to honor such messages. An example of a workaround is [ssb-revisions](https://github.com/regular/ssb-revisions), a basic API that enables applications to use mutable messages by displaying the updated version.
Ssb applications generally do not bridge to other applications. A proof-of-concept experiment involving [cross-posting to Twitter](https://github.com/arcalinea/twitter-ssb-import) and importing tweets into ssb demonstrates the possibility for a simple interop.
There has been community [discussion of using IPFS for blob data storage in ssb](https://github.com/ssbc/ssb-server/issues/454), but it has not been implemented as a feature.
New users add capacity to the network as they join as their nodes participate in hosting and sharing content. Pub servers would need to be expanded to keep up with a sudden influx of new users.
[According to a network crawl](https://twitter.com/andrestaltz/status/1191821144040574984) run by a developer in Nov 2019, there were around 16,000 nodes on ssb visible to his node.
### Implementations & Applications
A list of [applications built on ssb](https://handbook.scuttlebutt.nz/applications).
Social application clients on the ssb network include:
