Merge branch 'gvelez_ecosystem_activity_pub_and_solid' into 'master'

ecosystem activity pub and solid, also update matrix preexisting doc

See merge request arnoldjun/bluesky!47

protocols/activitypub.md

@@ -12,12 +12,26 @@ Account credentials are managed by the user’s instance, so if users forget the
 
 ### Data Storage/Message Persistance
 
+As a federated system, ActivityPub is not opinionated about how messages are persisted as long as each server follows the protocol requirements.  Each server is expected to maintain an inbox and outbox for each of its users.   
+
 ### Moderation/Reputation
 
 Each instance sets its own moderation policies, either through the unilateral decisions of an admin, or through some sort of collective vote. Admins can ban entire instances, cutting off their visibility. If an instance gets banned by many others, its users can still talk with each other, but they will be isolated from the rest of the Fediverse. This happened to Gab.com, which set up an instance.
 
 ### Social/Discovery
 
+Messages are addressed to a user at a specific server, and normal DNS and ip address routing are used to find the server addressed.
+
+Users can push messages to the special 'public' group which makes them available to all interested users. "Like"s and "Follow"s may be used by servers to determine which public messages to accept/retrieve.  For example, the followers of a user who Likes a post may receive the post in their feed.
+
+Instances may accept delivery of messages addressed as 'public' to a shared inbox on the instance but are not required to.
+
+Not clear if there is a global search capability.
+
+### User experience
+
+Currently the primary user experience is in a twitter-like UI (Mas.to or Pleroma)
+
 ### Privacy and Access Control
 
 ### Monetization
@@ -26,12 +40,22 @@ Federated social networks require both hosting and development costs to maintain
 
 ### Interop with other systems
 
+The spec mentions delivery to third-party apps but unsure how/how much this happens in the wild.  
+
+Requirements for interop: implement the ActivityPub protocol  (are there different requirements for 3rd party receivers?)
+
 ### Scalability
 
 ### Metrics
 
 ### In the wild
 
+[Mastodon](https://mastodon.social/about) (the largest federated network built on ActivityPub) has 2699 nodes and 2.6M users as of 5/2020  (Mastodon home page asserts 4.4M, a bit more than what the-federation.info stats provide; maybe some servers are not counted)
+
+[Pleroma](https://pleroma.social/) is compatible but running different software, also talking the ActivityPub protocol. According to stats at [the-federation.info](the-federation.info), Pleroma has 620 nodes with 35K users as of 5/2020  Users on Mastodon and Pleroma can communicate.
+
+Gab is running a fork of the Mastodon software but has been banned; technically users there could communicate with the others if they were not explicitly banned.
+
 ### Links
 
 [https://www.w3.org/TR/activitypub/](https://www.w3.org/TR/activitypub/)

protocols/matrix.md

@@ -1,15 +1,46 @@
 # Matrix
 
-(stub)
-
 Matrix is a protocol for replicating a signed history of JSON objects in realtime across a set of nodes with (optional) end-to-end encryption.
 
 It's designed to support multiple communication cases - Chat, VoIP, IoT, VR/AR, Social etc, but so far effort has been concentrated on providing a federated chat experience with good UX at scale. The public network currently (Feb 2020) has 14.7M known addressable users, with many others in private federations or on servers which don't report stats.  Matrix supports multiple clients (most notably [Riot](https://riot.im), the flagship app from the core team), and has bridges to many other chat systems (IRC, Slack, Discord, Telegram etc).
 
-Matrix is governed by [The Matrix.org Foundation CIC](https://matrix.org/foundation) (a UK non-profit foundation), with the largest contributor being [New Vector](https://vector.im), a startup formed by the original Matrix dev team, which raised $8.5M series A in October 2019.
+Note: In particular, we may be interested in the [Proposal for Aggregation via Relations](https://github.com/matrix-org/matrix-doc/blob/matthew/msc1849/proposals/1849-aggregations.md)
+
+### Identity
 
 Matrix has a more flexible identity solution than most decentralised protocols - users have a Matrix user ID, but can also use 3rd party IDs.  A Matrix account can link to ids such as email addresses, social accounts, and phone numbers.  A globally federated cluster of trusted identity servers verify and replicate the mappings, although this is a stopgap solution until a fully decentralised identity solution is adopted.
 
+### Data Storage/Message Persistance
+
+JSON objects representing pieces of the conversation are replicated across nodes.
+
+### Moderation/Reputation
+
 The Matrix team has also been working intensively on tools for moderation, detailed [here](https://matrix.org/docs/guides/moderation/), and is in the final stages of releasing a [P2P variant of the protocol](https://fosdem.org/2020/schedule/event/dip_p2p_matrix/).
 
-In particular, we may be interested in the [Proposal for Aggregation via Relations](https://github.com/matrix-org/matrix-doc/blob/matthew/msc1849/proposals/1849-aggregations.md)
+### Social/Discovery
+
+### User experience
+
+Currently the primary user experience is in Riot, a slack-like chat app
+
+### Privacy and Access Control
+
+### Monetization and Governance
+
+Matrix is governed by [The Matrix.org Foundation CIC](https://matrix.org/foundation) (a UK non-profit foundation), with the largest contributor being [New Vector](https://vector.im), a startup formed by the original Matrix dev team, which raised $8.5M series A in October 2019.
+
+? Income is primarily from contracts with governments and large clients ?
+
+### Interop with other systems
+
+Bridges that allow communication with IRC, Slack, Discord, Telegram and others
+
+### Scalability
+
+### Metrics
+
+### In the wild
+
+### Links
+

protocols/solid.md

@@ -0,0 +1,23 @@
+# Solid
+
+### Identity
+
+### Data Storage/Message Persistance
+
+### Moderation/Reputation
+
+### Social/Discovery
+
+### Privacy and Access Control
+
+### Monetization
+
+### Interop with other systems
+
+### Scalability
+
+### Metrics
+
+### In the wild
+
+### Links

protocols/ssb.md

@@ -4,11 +4,11 @@
 
 Ssb, or secure-scuttlebutt, is a distributed gossip protocol designed for social sharing. 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. Users are distributed across a few different client apps that work on desktop (Patchwork) and mobile (Manyverse, Planetary).
 
-Data Model
+### Data Model
 
 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 you follow a user, you will begin to store and sync their posts. An ssb application is constantly sharing data with other nodes in the background while you use it.
 
-Identity
+### Identity
 
 Every user has a public/private keypair which is used to sign posts, verifying their authenticity.
 
@@ -20,10 +20,10 @@ Users can pick a human-readable nickname that is associated with their key, but
 Key management is one of the biggest challenges, 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.
 
-Moderation
+### Moderation
 
 At the ssb protocol level, there is a “flag” feature to send a strong negative signal about bad actors. There is no global moderation, and no specialized moderators. Applications built on top of ssb allow users to “block” and “ignore”. A block in ssb functions more strongly than a block in centralized networks because it means that blocked users no longer have their data passed through those nodes. If enough people block a user or group of users, their part of the network will become cut off from the rest.
 
-Monetization
+### Monetization
 
 Maintainers of p2p networks do not have to pay for hosting costs, since there are no servers and the network naturally grows in capacity as new users join. Developers who want to work on more than a volunteer basis need to find their own funding. 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.