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, add link to gun

This commit is contained in:
Jay Graber 2020-06-15 12:27:04 -07:00
parent a2ad7de88f
commit dda8d1cd7d
2 changed files with 53 additions and 45 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
protocols/gun.md
View File

@ -69,3 +69,4 @@ GUN is used for p2p chat/social apps, encrypted video conferencing, realtime GPS
### Links
- [Site](gun.eco)
- [3box comparison of p2p DBs](https://medium.com/3box/3box-research-comparing-distributed-databases-gun-orbitdb-and-scuttlebutt-2e3b5da34ef3)

97
protocols/ssb.md
View File

@ -1,100 +1,107 @@
# Scalable Secure Scuttlebutt (SSB)
# Scalable Secure Scuttlebutt (ssb)
[ssb repo](https://github.com/dominictarr/scalable-secure-scuttlebutt)
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, 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.
Ssb is based on the idea that your social network mirrors your actual communication network, and your network peers mirror your actual peers.
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 (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:
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 others that a user knows 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. 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.
### 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
### 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. 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
### Data
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.
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
### 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
### 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.
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 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.
"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, 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.
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.
Multi-writer applications?
### 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.
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 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.
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.
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.
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.
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.
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.
### 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.
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.
[Discussion of tradeoffs of using IPFS for blob data storage in ssb](https://github.com/ssbc/ssb-server/issues/454)
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
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.
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.
Another potential scalability issue is the size of the append-only log feeds stored on a user's device growing over time.
A 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](https://twitter.com/andrestaltz/status/1191821144040574984) run by a developer in Nov 2019, there are around 16,000 nodes on ssb.
[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.
### Tradeoffs
### Implementations & Applications
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.
A list of [applications built on ssb](https://handbook.scuttlebutt.nz/applications).
Ssb focuses more on moving lightweight social data rather than large data, unlike protocols like bittorrent, Hypercore/Dat, and IPFS.
Social application clients on the ssb network include:
- [Patchwork](https://handbook.scuttlebutt.nz/applications#patchwork), a desktop application
- [Manyverse](https://handbook.scuttlebutt.nz/applications#manyverse), a mobile application
- [Planetary](https://planetary.social/), a mobile application
Other applications include:
- [git-ssb](https://handbook.scuttlebutt.nz/applications#git-ssb), a git interface using ssb
- [Ticktack](https://handbook.scuttlebutt.nz/applications#ticktack), a blog publishing app with private messaging
- [Infinite Game](https://handbook.scuttlebutt.nz/applications#infinite-game), a calendar, event tool, and time picker.
### Links
[Overview](https://scuttlebot.io/more/protocols/secure-scuttlebutt.html)
[Ssb concepts](https://handbook.scuttlebutt.nz/concepts/)
[Article on Manyverse and ssb](https://www.zdnet.com/article/manyverse-and-scuttlebutt-a-human-centric-technology-stack-for-social-applications/)
[Dark Crystal ssb protocol docs](https://darkcrystal.pw/ssb-protocol-docs.html)
[3box comparison of p2p dbs](https://medium.com/3box/3box-research-comparing-distributed-databases-gun-orbitdb-and-scuttlebutt-2e3b5da34ef3)
[3box comparison of p2p DBs](https://medium.com/3box/3box-research-comparing-distributed-databases-gun-orbitdb-and-scuttlebutt-2e3b5da34ef3)