devol
/
ecosistema-social-decentralizzato
mirror of https://gitlab.com/bluesky-community1/decentralized-ecosystem.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Edit ssb

This commit is contained in:
Jay Graber 2020-06-15 12:50:36 -07:00
parent dda8d1cd7d
commit e22b600c8d
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
protocols/ssb.md
View File

@ -13,9 +13,11 @@ Users can pick a human-readable nickname that is associated with their key, but
### 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.
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.
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.
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.
### Data
@ -43,8 +45,6 @@ There is no global feed of content in ssb. All content is surfaced through socia
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.
"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 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, so a user can join one or multiple pubs.
### 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.
@ -65,7 +65,7 @@ To attempt to address the problem of key management, a project in the ssb ecosys
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.
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.
### Interoperability