Change template, move user exp to applications

applications/ssb-applications.md

@@ -0,0 +1,9 @@
+# Ssb Applications
+
+### User Experience
+
+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.
+
+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.

applications/template.md

@@ -0,0 +1,25 @@
+### Identity
+
+### Networking
+
+### Data
+
+### Moderation & Reputation
+
+### Social & Discovery
+
+### Privacy & Access Control
+
+### User experience
+
+### Interoperability
+
+### Scalability
+
+### Metrics
+
+### Monetization
+
+### Implementations
+
+### Links

protocols/ssb.md

@@ -11,6 +11,8 @@ A user's identity is their ed25519 key pair which is used to sign posts, verifyi
 
 Users can pick a human-readable nickname that is associated with their key, but nicknames are not unique because there is no global registry.
 
+Ssb does not currently support multi-device login, because keys are stored on devices.
+
 ### Networking
 
 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.
@@ -33,6 +35,8 @@ Each message contains:
 - An identifier of the hashing algorithm in use (currently only "sha256" is supported)
 - A content object
 
+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.
+
 ### Moderation & Reputation
 
 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.
@@ -55,16 +59,6 @@ The ssb ecosystem is supported through a variety of grants, donations, income fr
 
 Pubs, the most resource-intensive nodes, are currently volunteer supported.
 
-### User Experience
-
-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.
-
-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.
-
-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
 
 [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.

protocols/template.md

@@ -10,7 +10,7 @@
 
 ### Privacy & Access Control
 
-### User experience (if applies)
+### User experience
 
 ### Interoperability
 
@@ -18,8 +18,8 @@
 
 ### Metrics
 
-### Monetization
+### Governance & Business Models
 
-### Implementations
+### Implementations & Applications
 
 ### Links

topics/data.md

@@ -1,6 +1,26 @@
-# Data
+# Data & Discovery
 
 Data structures, data availability, persistence, and mutability in decentralized applications.
 Data portability
 
 Decentralized systems do not have a single central system to coordinate updates.
+
+### Data availability
+
+No server has a unified global view of a decentralized network.
+
+Data is only available along user connections or the follow graph, whether that is determined by node or by server.
+
+Mastodon - No global search functionality
+
+### Mutability
+
+Ssb & Hypercore - Messages added to the append-only log are immutable. Applications can choose not to display messages indicated as deleted, but the data cannot be overwritten.
+
+IPFS - Once added to a network, content is discoverable by its hash. If a copy remains stored on the network, it is re-discoverable by this reference.
+
+### Data structures
+
+JSON-LD
+
+RDF

topics/discovery.md

@@ -3,3 +3,5 @@
 In decentralized networks, whether federated or p2p, there is often no global search functionality.
 
 This issue being discussed in Mastodon: https://github.com/tootsuite/mastodon/issues/9529
+
+Hashtags are used to filter and discover content in ssb, diaspora, mastodon