Incorporate Andre feedback to ssb

protocols/ssb.md

@@ -2,22 +2,20 @@
 
 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).
+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 and mobile.
 
 ### Identity
 
 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:
 `@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 nodes that a user trusts attest to the authenticity of an account, that account is assumed to be authentic.
+Users can pick a human-readable nickname that is associated with their key, but nicknames are not unique because there is no global registry.
 
 ### Networking
 
-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.
+Nodes request all messages in the feed that are newer than the latest message they know about. 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, 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.
+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 NAT-traversal utilities, so users connect to a Pub to distribute their messages. Users can also sync over LAN. 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 2018.
-
-A [scuttlebutt DHT invite](https://gitlab.com/staltz/ssb-dht-invite) plugin that shares connection invites over a DHT was created in 2020.
 
 ### Data
 
@@ -37,29 +35,31 @@ Each message contains:
 
 ### 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.
+There is no global moderation, and no specialized moderators in ssb. A “flag” message is used 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 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 clients decide the number of hops away from primary follow relationships to store or replicate data. For example, a client could store data from 2 hops away, but replicate data from 3 hops away to keep it available for others, but not show it in the user interface.
 
-### Privacy/Access Control
+### Privacy & Access Control
 
-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.
+Ssb applications can easily support encrypted DMs (with up to 7 participants) 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.
 
-### Monetization
+There is ongoing research and development on providing ["Facebook Groups" style of access control](https://github.com/ssbc/ssb-private2) to larger private groups (in the dozens/hundreds of users).
 
-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.
+### Governance & Business Models
+
+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 [Ahau](https://ahau.io/) and [Planetary](https://planetary.social/).
 
 Pubs, the most resource-intensive nodes, are currently volunteer supported.
 
 ### 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 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.
+Key management is one of the biggest challenges of ssb, as users often 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. To address the problem of key management in a decentralized manner, 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.
 
-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.
+Ssb does not currently support multi-device login, because keys are stored on devices.
 
 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.
 
@@ -67,13 +67,19 @@ The inability to edit or delete content also runs contrary to user expectations.
 
 ### Interoperability
 
+[Ssb viewer](https://github.com/ssbc/ssb-viewer), an HTTP server for read-only views of ssb content, brings read-only interop from ssb to the web.
+
 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.
 
 ### Scalability
 
-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.
+New users add capacity to the network as they join as their nodes participate in hosting and sharing content.
+
+A growing number of [room servers](https://github.com/staltz/ssb-room) help with scalability since rooms host no data, but allow tunnel connections between clients, so the more clients there are, the more connections there are available.
+
+Pub servers would need to be expanded to keep up with a sudden influx of new users.
 
 A potential scalability issue is the size of the append-only log feeds stored on a user's device growing over time.
 
@@ -88,6 +94,9 @@ A list of [applications built on ssb](https://handbook.scuttlebutt.nz/applicatio
 Social application clients on the ssb network include:
 
 - [Patchwork](https://handbook.scuttlebutt.nz/applications#patchwork), a desktop application
+- [Patchbay](https://github.com/ssbc/patchbay), a fully compatible alternative to Patchwork
+- [Oasis](https://github.com/fraction/oasis), a desktop application
+- [Feedless](https://github.com/rogeriochaves/feedless) an iOS application
 - [Manyverse](https://handbook.scuttlebutt.nz/applications#manyverse), a mobile application
 - [Planetary](https://planetary.social/), a mobile application