8.3 KiB
Scalable Secure Scuttlebutt (SSB)
Ssb, or secure-scuttlebutt, is a distributed gossip protocol designed for social sharing. Identities are cryptographic key pairs, feeds are a signed append-only sequence of messages, and nodes use a gossip protocol to disseminate content. Feeds can be thought of as essentially personal blockchains.
Users are distributed across a few different client apps that work on desktop (Patchwork) and mobile (Manyverse, Planetary).
Identity
A user's identity is their ed25519 key pair which is used to sign posts, verifying their authenticity.
The public key is used as the identifier. For example:
@3QHXrXl762sf7P/Q1RMtscA7IRipfUFnE5tpie5McvE=.ed25519
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 others that a user knows attest to the authenticity of an account, that account is assumed to be authentic.
Data Storage/Message Persistence
Each post is appended to the last, in an append-only log establishing chronological ordering from the very first. Because every post is chained to the last, there’s currently no way to delete or edit posts. 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.
Each message contains:
A signature The signing public key A content-hash of the previous message A sequence number A timestamp An identifier of the hashing algorithm in use (currently only "sha256" is supported) A content object
Networking/Message Passing
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, which are always online, are a necessary component to improve data availability in the ssb ecosystem. Otherwise, user's nodes which are hosting content would go offline too often, preventing access to the latest state.
Moderation/Reputation
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.
Social/Discovery
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 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.
"Pubs" are essentially the bootstrap nodes and mail-bots of ssb. They are bot-user nodes with public IPs which stay online and offer invite codes to new users. They also follow users and rebroadcast the messages to other peers. Ssb has no DHT or NAT-traversal utilities, so users must connect to a Pub to distribute their messages. Pubs ensure uptime and availability. Identity is not tied to pubs, unlike homeservers in Matrix or ActivityPub, and a user can join one or multiple pubs.
Privacy/Access Control
Ssb applications can easily support encrypted DMs, as 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.
Monetization
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.
Pubs, the most resource-intensive nodes, are currently volunteer supported, but at scale could encounter incentive problems.
User Experience
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 also 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, 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.
Getting connected to ssb is also much more cumbersome than the on-boarding experience for social applications. The p2p bootstrapping process introduces many frictions. First, new users much join a pub to connect to the network after they download an ssb application. Then, there is a long 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 initial sync again while their node catches up to the state of the network.
Another design choice that defies user expectations is the inability to edit or delete content. 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.
Interoperability
Ssb applications generally do not bridge to other applications, although a proof-of-concept experiment involving cross-posting to Twitter, and importing tweets into ssb, has been tried.
Discussion of tradeoffs of using IPFS for blob data storage in ssb
Scalability
Because ssb is entirely p2p, new users add capacity to the network as they will also be hosting and sharing content. The one point of possible centralization, pub servers, would need to be expanded to keep up with a sudden influx of new users.
Another potential scalability issue is the size of the append-only log feeds stored on a user's device growing over time.
Metrics
Every node has a partial view of the network, which makes it hard to get a count of how many total users there are, but according to a network crawl run by a developer in Nov 2019, there are around 16,000 nodes on ssb.
Tradeoffs
Feeds being append-only logs means content cannot be easily edited or deleted, but ensures the network converges towards the same state. It is a design choice that maximizes partition tolerance at the expense of mutability.
Ssb focuses more on moving lightweight social data rather than large data, unlike protocols like bittorrent, Hypercore/Dat, and IPFS.
Links
Overview Ssb concepts Article on Manyverse and ssb Dark Crystal ssb protocol docs 3box comparison of p2p dbs