Proofread and edit applications
This commit is contained in:
Jay Graber
parent
2c2cd9ea28
commit
ffa92f43ae
|
|
@ -32,7 +32,7 @@ Moderator elections begin once a community has more than 100 active users within
|
|||
|
||||
Users who wish to be mods can enable 'mod mode', which allows them to proactively attempt to approve or delete posts. Their moderation history can be observed by others considering electing them as an official mod.
|
||||
|
||||
Whitelists and blacklists are used to moderate the collection of communities. When users join, the default is to only display SFW communities on a vetted whitelist, to ensure the safety and comfort of a user's initial experience.
|
||||
An allow-list is used to moderate the collection of communities. When users join, the default is to only display SFW communities on a vetted allow-list, to ensure the safety and comfort of a user's initial experience.
|
||||
|
||||
### Spam
|
||||
|
||||
|
|
|
|||
|
|
@ -36,7 +36,11 @@ Other than depending on Steem price appreciation, Steemit monetizes through user
|
|||
|
||||
# Peepeth
|
||||
|
||||
[Peepeth](https://peepeth.com/welcome) is a “permanent Twitter” built on Ethereum and IPFS. Account information is stored on the Ethereum blockchai. Data is stored in IPFS, and a link to the IPFS address is stored on the Ethereum blockchian. Permanent posts are embraced as a design choice meant to encourage users to be more mindful of what they write. The main Peepeth client has a few monetization strategies, including a 10% fee on user tips, and charging for verifications of social accounts. Users log in to Peepeth through Metamask, and their identities are registered by posting account information to a smart contract that associates it with their address.
|
||||
[Peepeth](https://peepeth.com/welcome) is a “permanent Twitter” built on Ethereum and IPFS. Users log in to Peepeth through [Metamask](https://metamask.io/), and their identities are registered by posting account information to a smart contract that associates it with their address. Account information is stored on the Ethereum blockchain.
|
||||
|
||||
Post data is stored in IPFS, and a link to the IPFS address is stored on Ethereum. Permanent posts are embraced as a design choice meant to encourage users to be more mindful of what they write.
|
||||
|
||||
The main Peepeth client has a few monetization strategies, including a 10% transaction fee on user tips, and charging for verifications of social accounts.
|
||||
|
||||
# Bitcoin Fork Social Networks
|
||||
|
||||
|
|
|
|||
|
|
@ -1,22 +1,22 @@
|
|||
# Diaspora
|
||||
|
||||
Diaspora was a federated social network released in 2010. It is still in existence, although not widely used. It does not use the ActivityPub federation protocol. In the diaspora protocol, messages are passed between servers.
|
||||
Diaspora is a federated social network released in 2010. It uses a server to server federation protocol, and is compatible with Friendica and Hubzilla. Diaspora [chose not to implement compatibility with ActivityPub](https://schub.wtf/blog/2018/02/01/activitypub-one-protocol-to-rule-them-all.html).
|
||||
|
||||
The federated nodes, called "pods", are hosted by different individuals and institutions. User accounts, which are tied to pods, are called "seeds".
|
||||
Diaspora nodes, called "pods", are hosted by different individuals and institutions. User accounts, which are tied to pods, are called "seeds".
|
||||
|
||||
### Identity
|
||||
|
||||
Users joining Diaspora pick a pod to register their identity with. User identities contain the username, the hostname, and the port if their server does not listen on the default ports.
|
||||
Users joining Diaspora pick a pod to register their identity with. User identities contain the username, the hostname, and the port if their server does not listen on the default ports. An example username:
|
||||
|
||||
`alice:example.org`
|
||||
|
||||
Diaspora uses the Webfinger protocol to discover users from other pods. User information is returned via hCard, an open microformat standard for identity.
|
||||
Diaspora uses [Webfinger](https://tools.ietf.org/html/rfc7033) to discover users from other pods. User information is returned via hCard, an open microformat standard for identity.
|
||||
|
||||
It is not possible to move a user account to another pod once created.
|
||||
|
||||
### Network
|
||||
|
||||
Messages sent between servers are serialized to XML, then signed using the Salmon Magic Signature protocol.
|
||||
Messages sent between servers are serialized to XML, then signed using the [Salmon Magic Signatures](https://cdn.rawgit.com/salmon-protocol/salmon-protocol/master/draft-panzer-magicsig-01.html) protocol.
|
||||
|
||||
### Data
|
||||
|
||||
|
|
@ -28,9 +28,9 @@ Like Mastodon, moderation is done at the server level. When ISIS joined the Dias
|
|||
|
||||
In this [Github issue about admin reports](https://github.com/diaspora/diaspora/issues/7316), it is possible to see how communities struggle when tools for moderation are not built into federated networks from the start. This user requested a way to forward spam reports to the source pod, as that was the only way to remove content from the entire network. Without this feature, pod administrators resorted to manually searching for and contacting other administrators.
|
||||
|
||||
### Social &Discovery
|
||||
### Social & Discovery
|
||||
|
||||
Like Twitter, Diaspora includes hashtags and mentions.
|
||||
Like Twitter, Diaspora uses hashtags and mentions for content discovery.
|
||||
|
||||
### Privacy & Access Control
|
||||
|
||||
|
|
@ -40,11 +40,11 @@ Private messages in Diaspora are encrypted.
|
|||
|
||||
Diaspora allows users to group their contacts into "aspects". Limited posts will only be shown to contacts in the selected aspect.
|
||||
|
||||
Communication between pods is encrypted, but data stored on pods is not. Administrators could access all profile and post data.
|
||||
Communication between pods is encrypted, but data stored on pods is not. Administrators have access to all profile and post data.
|
||||
|
||||
### Monetization
|
||||
|
||||
Diaspora was initially funded through a kickstarter that raised $200,000.
|
||||
Diaspora was initially funded through a kickstarter that raised $200,00. It has not developed a business model.
|
||||
|
||||
### Interoperability
|
||||
|
||||
|
|
@ -52,7 +52,7 @@ Friendica instances are a part of the diaspora network, and natively support the
|
|||
|
||||
Diaspora posts can be propagated to accounts on [WordPress, Twitter, and Tumblr](https://wiki.diasporafoundation.org/Integrating_other_social_networks).
|
||||
|
||||
Diaspora has not integrated with ActivityPub, despite the similarities of approaches to federated social. Discussion of this topic can be found on the [Discourse forum](https://discourse.diasporafoundation.org/t/lets-talk-about-activitypub/741).
|
||||
Diaspora has not integrated with ActivityPub. Discussion of this topic can be found on the [Discourse forum](https://discourse.diasporafoundation.org/t/lets-talk-about-activitypub/741).
|
||||
|
||||
### Metrics
|
||||
|
||||
|
|
@ -61,6 +61,4 @@ Diaspora has not integrated with ActivityPub, despite the similarities of approa
|
|||
### Links
|
||||
|
||||
- [Diaspora Federation Protocol](https://diaspora.github.io/diaspora_federation/)
|
||||
- [Webfinger](https://tools.ietf.org/html/rfc7033)
|
||||
- [Salmon Magic Signatures](https://cdn.rawgit.com/salmon-protocol/salmon-protocol/master/draft-panzer-magicsig-01.html)
|
||||
- [Discourse Forum](https://discourse.diasporafoundation.org/)
|
||||
- [Diaspora Discourse Forum](https://discourse.diasporafoundation.org/)
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Mastodon
|
||||
|
||||
Mastodon is a federated Twitter alternative. It is the most popular client using the ActivityPub federation protocol. It started out using OStatus, and switched to ActivityPub.
|
||||
Mastodon is a federated Twitter alternative. It is the most popular client using the [ActivityPub](../protocols/activitypub.md) federation protocol.
|
||||
|
||||
Each server is called an "instance". The entire constellation of instances that can interoperate is called the “Fediverse”.
|
||||
|
||||
|
|
@ -18,15 +18,13 @@ If a user moves to a new instance, they can redirect or migrate their old accoun
|
|||
|
||||
Account credentials are managed by the user’s instance, so if users forget their password, they can ask for a password reset. Whether users can delete their own accounts or not is a setting dependent on the instance admin.
|
||||
|
||||
For user verification, there is no central authority to check identity documents, but link-based verification can help cross-reference links associated with a user. For example, a user can link to their Mastodon profile from their personal homepage, and receive a verification checkmark to confirm that they are the owner. In addition, an identity proof framework was added in 2019, which currently only supports Keybase. It allows users to [link their Keybase cryptographic identity](https://github.com/keybase/keybase-issues/issues/2948) to their Mastodon account.
|
||||
For user verification, there is no central authority to check identity documents, but link-based verification can help cross-reference links associated with a user. For example, a user can link to their Mastodon profile from their personal homepage, and receive a verification checkmark on their Mastodon profile by their personal homepage link, to confirm that they are the owner. An identity proof framework was added in 2019, which currently only supports Keybase. It allows users to [link their Keybase cryptographic identity](https://github.com/keybase/keybase-issues/issues/2948) to their Mastodon account.
|
||||
|
||||
Webfinger is used to look up users. The Webfinger endpoint is always under `/.well-known/webfinger`, and it receives queries such as `/.well-known/webfinger?resource=acct:bob@my-example.com`.
|
||||
Mastodon uses [Webfinger](https://docs.joinmastodon.org/spec/webfinger/) to translate user mentions to actor profile URIs. Webfinger specifies the path at which to find a user's profile information provided by the server. The Webfinger endpoint is always under `/.well-known/webfinger`, and it receives queries such as `/.well-known/webfinger?resource=acct:alice@mastodon.social`.
|
||||
|
||||
### Network
|
||||
|
||||
Mastodon uses [Webfinger](https://docs.joinmastodon.org/spec/webfinger/) to translate user mentions to actor profile URIs. Webfinger specifies the path at which to find a user's profile information provided by the server.
|
||||
|
||||
ActivityPub federation defines a common set of APIs and formats for passing messages between servers. ActivityPub messages consist of the message itself, and a wrapper that communicates what's happening with the message, defining the "activity". The activities Mastodon implements are documented [here](https://docs.joinmastodon.org/spec/activitypub/).
|
||||
Mastodon started out using OStatus for federation, and later switched to ActivityPub. [ActivityPub](../protocols/activitypub.md) is both a server-to-server and client-to-server standard. Mastodon only implements the server-to-server protocol, which is all that is necessary for federation with other ActivityPub servers. The ActivityPub "activities" Mastodon implements are documented [here](https://docs.joinmastodon.org/spec/activitypub/).
|
||||
|
||||
### Data
|
||||
|
||||
|
|
@ -36,21 +34,21 @@ Mastodon is a Ruby on Rails application that uses PostgreSQL and Redis for data
|
|||
|
||||
Moderation takes place at the server level in Mastodon. Each instance sets its own moderation policies, either through the unilateral decisions of an admin, or through collective discussion and agreement. 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.
|
||||
|
||||
Users can also report posts to moderators, submitting it for a moderation decision. Users can also apply content warnings to their posts themselves, to indicate the nature of the content and hide it behind a click.
|
||||
Users can apply content warnings to their posts themselves, to indicate the nature of the content and hide it behind a click.
|
||||
|
||||
Some documented [challenges with moderation in Mastodon](https://nolanlawson.com/2018/08/31/mastodon-and-the-challenges-of-abuse-in-a-federated-system/amp/) from 2018. One recommended solution is to provide open APIs for third-party tools to help with moderation, which was [added in 2019](https://github.com/tootsuite/mastodon/pull/9387).
|
||||
Users can report posts to moderators, submitting it for a moderation decision.
|
||||
|
||||
Some documented [challenges with moderation in Mastodon](https://nolanlawson.com/2018/08/31/mastodon-and-the-challenges-of-abuse-in-a-federated-system/amp/) (2018). Open APIs for third-party tools to help with moderation were [added in 2019](https://github.com/tootsuite/mastodon/pull/9387).
|
||||
|
||||
### Social & Discovery
|
||||
|
||||
There is [no unified global search in Mastodon](https://github.com/tootsuite/mastodon/issues/9529), as each server monitors a different set of messages. Searching for the same keyword on different instances yields different results. The federated timeline shows public posts that the user's server knows about. Essentially, users have access to posts of people followed by people on their instance.
|
||||
Mastodon users are presented with three timelines: a home timeline with posts from accounts the user follows, a local timeline with posts from the local instance, and a federated timeline with all public posts that the user's server has received from remote instances. Users essentially have access to posts of people followed by people on their instance.
|
||||
|
||||
Mastodon users are presented with three timelines: a home timeline with posts from accounts the user follows, a local timeline with posts from the local instance, and a federated timeline with all posts that have been retrieved from remote instances.
|
||||
There is [no universal search in Mastodon](https://github.com/tootsuite/mastodon/issues/9529), as each server monitors a different set of messages. Searching for the same keyword on different instances yields different results. To aid content discovery, Mastodon has [public relays](https://source.joinmastodon.org/mastodon/pub-relay) which rebroadcast anything sent to it to anyone who subscribes to the pub.
|
||||
|
||||
Mastodon has [public relays](https://source.joinmastodon.org/mastodon/pub-relay) which rebroadcast anything sent to it to anyone who subscribes to the pub.
|
||||
A "Profile Directory" tab allows users to browse recently active profiles or new arrivals from both their own instance or the fediverse to discover who to follow. [Trunk](https://communitywiki.org/trunk/) is a community-built tool that helps users find and follow people by category.
|
||||
|
||||
A [2019 analysis](https://emilianodc.com/PAPERS/mastodonIMC19.pdf) of the Mastodon ecosystem found that the majority of posts are concentrated on a few instances, and outages in 10 instances would remove almost half of all posts from the network.
|
||||
|
||||
Mastodon's interface has a "Profile Directory" tab, where users can browse recently active profiles or new arrivals from both their own instance or the fediverse to discover who to follow. Users can select featured hashtags to be displayed on their public profile so people can browse their posts by hashtag.
|
||||
Users can select featured hashtags to be displayed on their public profile so people can browse their posts by hashtag.
|
||||
|
||||
### Privacy & Access Control
|
||||
|
||||
|
|
@ -58,6 +56,8 @@ Posts can be public, unlisted, private, or direct. Public posts are shown on loc
|
|||
|
||||
Mastodon can be served through Tor as an onion service.
|
||||
|
||||
Mastodon is currently [adding e2e encryption](https://github.com/tootsuite/mastodon/pull/13820). Previously, direct messages were unencrypted.
|
||||
|
||||
### Monetization
|
||||
|
||||
Federated social networks require both hosting and development costs to maintain. Each instance is funded by its own administrator and community. Mastodon’s development is funded through a Patreon run by the main developer, Eugen Rochko. It currently brings in about 70k a year, which supports him working on it full time, and covers hosting costs and a moderation team for the popular mastodon.social instance.
|
||||
|
|
@ -68,18 +68,16 @@ Mastodon's main initial selling point was its familiar interface that behaved li
|
|||
|
||||
Notable design choices in Mastodon that differ from Twitter: Instead of a 280 character limit, there is a 500 character limit. "Likes" are not broadcast to third-parties. "Retweet" and "Like" numbers are not shown until a post is clicked on. If a user with an unlocked account gets a follow request from an account that has been silenced by the server's moderators (either manually, or at their domain), the user will get a follow request instead of automatically allowing the new account to follow.
|
||||
|
||||
User-level content controls include: Users can set content warnings on their own posts. Filtering on posts can automatically hide keywords and phrases. "Boosts" (like retweets) from someone can be hidden. Accounts can be muted or blocked. Entire servers, including all of its posts, can be blocked by a user. Following, muting, blocking, and domain-blocking lists can be imported.
|
||||
User-level content controls include: Users can set content warnings on their own posts. Filtering on posts can automatically hide keywords and phrases. "Boosts" (retweets) from someone can be hidden. Accounts can be muted or blocked. Entire servers, including all of its posts, can be blocked by a user. Following, muting, blocking, and domain-blocking lists can be imported.
|
||||
|
||||
Upload options include: Users can choose where the thumbnail of a picture is focused when opening. Users can enter custom alt-text to image uploads. There is an OCR button to help extract text from an image for the visually impaired.
|
||||
Audio files can be uploaded.
|
||||
|
||||
Admins can upload custom emojis to their servers
|
||||
Audio files can be uploaded. Admins can upload custom emojis to their servers.
|
||||
|
||||
### Interoperability
|
||||
|
||||
Mastodon is compatible with all federated applications that use ActivityPub. These include Pleroma, another social application, PixelFed, a photo-sharing application, and PeerTube, a video-sharing application. Mastodon users can follow a PixelFed or PeerTube user from Mastodon.
|
||||
Mastodon is compatible with all federated applications that use ActivityPub. These include Pleroma, another social application, PixelFed, a photo-sharing application, and PeerTube, a video-sharing application. Mastodon users can follow a Pleroma, PixelFed, or PeerTube user from Mastodon.
|
||||
|
||||
Mastodon users used to be able to find their Twitter friends using `bridge.joinmastodon.org`, but the service was shut down after the developer lost access to API keys and was not granted another set. A user request for a global directory for [importing friends from other networks](https://github.com/tootsuite/mastodon/issues/11886).
|
||||
Mastodon users used to be able to find their Twitter friends using `bridge.joinmastodon.org`, but the service was shut down after the developer lost access to API keys and was not granted another set.
|
||||
|
||||
All Mastodon user data is available for export.
|
||||
|
||||
|
|
@ -89,7 +87,9 @@ Mastodon.Social, the instance started by Mastodon's main developer, initially be
|
|||
|
||||
When a surge of new users join an instance, server admins can run into scaling issues, as any web host who becomes unexpectedly popular does.
|
||||
|
||||
Another scalability issue is the resource requirements of Mastodon. Mastodon hosting providers have emerged as a service to help individuals interested in being admins but without sysadmin experience to spin up servers. Pleroma, another federated social app, is advertised as a more minimal implementation good for single user instances that requires fewer resources to run.
|
||||
Another scalability issue is the resource requirements of Mastodon. Mastodon hosting providers have emerged as a service to help individuals interested in being admins, but without sysadmin experience, to spin up servers. Pleroma, another federated social app, is advertised as a more minimal implementation good for single user instances that requires fewer resources to run.
|
||||
|
||||
A [2019 analysis](https://emilianodc.com/PAPERS/mastodonIMC19.pdf) of the Mastodon ecosystem found that the majority of posts are concentrated on a few instances, and outages in 10 instances would remove almost half of all posts from the network.
|
||||
|
||||
### Metrics
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,12 @@
|
|||
# Ssb Social Applications
|
||||
|
||||
### User Experience
|
||||
This section is a more in-depth examination of the user experience of social applications in the ssb ecosystem.
|
||||
|
||||
Desktop applications include [Patchwork](https://handbook.scuttlebutt.nz/applications#patchwork), and mobile applications include [Manyverse](https://handbook.scuttlebutt.nz/applications#manyverse) and [Planetary](https://planetary.social/).
|
||||
|
||||
Manyverse is the first mobile application for ssb, and the first ssb app that implemented [DHT invites](https://gitlab.com/staltz/ssb-dht-invite). Users can connect through upbs, over LAN, through a DHT, or over bluetooth.
|
||||
|
||||
## 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.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,20 +1,20 @@
|
|||
# ActivityPub
|
||||
|
||||
ActivityPub is a federated protocol that defines a set of interoperable social network interactions through specific APIs. Any server that implements this protocol can communicate with the rest of the network. It reached W3C recommendation status in 2018. It is one of several related specs produced by the Social Web Working Group.
|
||||
ActivityPub is a federated protocol that defines a set of interoperable social network interactions through specific APIs. Any server that implements this protocol can communicate with the rest of the network. It reached W3C recommendation status in 2018. It is one of several related specs produced by the [Social Web Working Group](https://www.w3.org/wiki/Socialwg).
|
||||
|
||||
ActivityPub consists of two layers: A server to server federation protocol, and a client to server protocol. In order to federate with the ActivityPub ecosystem, a service only has to implement the server-to-server protocol.
|
||||
|
||||
Mastodon is a popular federated alternative to Twitter built on ActivityPub. Other ActivityPub applications include Pleroma, PixelFed, Friendica, and PeerTube.
|
||||
ActivityPub consists of two layers: A server-to-server federation protocol, and a client-to-server protocol. In order to federate with the ActivityPub ecosystem, a service only has to implement the server-to-server protocol.
|
||||
|
||||
### Identity
|
||||
|
||||
User identities in ActivityPub are conceptualized as actor objects. To be spec compliant, each actor _must_ have an "inbox" and an "outbox". They also _should_ have "following" and "followers". They _may_ have "liked" collections, and many other predefined possibilities. These are endpoints, URLs which are accessible on the server.
|
||||
Users in ActivityPub are conceptualized as actor objects. Actor to actor communication bears a resemblance to email. To be spec compliant, each actor _must_ have an "inbox" and an "outbox" endpoint, as URLs which are accessible on the server. They also _should_ have "following" and "followers". They _may_ have "liked" collections, and many other predefined possibilities.
|
||||
|
||||
Each actor has a publicly accessible JSON-LD document.
|
||||
[Authentication](https://www.w3.org/wiki/SocialCG/ActivityPub/Authentication_Authorization): Server to server federation is authenticated using HTTP Signatures. Each actor has a public and private keypair, and a publicly accessible JSON-LD document retrievable over HTTP which contains its public key. Each message the server sends on behalf of an Actor is signed by this key. When a remote server receives a POST to its inbox, it verifies the signature on the HTTP request. To verify object integrity, linked data signatures are used to sign the object with the publicKey of the actor who authored it.
|
||||
|
||||
A [paper](https://github.com/WebOfTrustInfo/rwot5-boston/blob/master/final-documents/activitypub-decentralized-distributed.md) from the 2017 Rebooting the Web of Trust conference describes how distributed, cryptographic identities could be added to ActivityPub.
|
||||
|
||||
### Networking
|
||||
|
||||
ActivityPub is federated through a server-to-server protocol that passes messages between systems.
|
||||
ActivityPub is a federated server-to-server protocol that passes messages between systems.
|
||||
|
||||
ActivityPub servers do not proactively network with each other, so they are unaware of each other's presence until a user finds and follows someone on another server. Servers maintain a list of remote accounts its users follow and subscribe to their posts.
|
||||
|
||||
|
|
@ -22,38 +22,32 @@ ActivityPub messages are not limited to HTTP only. This allows it to potentially
|
|||
|
||||
### Data
|
||||
|
||||
ActivityPub messages are objects wrapped in an "activity", indicating what it is. There is an [Activity Vocabulary](https://www.w3.org/TR/activitystreams-vocabulary/) that defines Activity, Object, and Actor types that are common to social web applications.
|
||||
ActivityPub messages are objects wrapped in an "activity", indicating what it is. There is an [Activity Vocabulary](https://www.w3.org/TR/activitystreams-vocabulary/) that defines Activity, Object, and Actor types common to social web applications.
|
||||
|
||||
ActivityPub is not opinionated about how messages are persisted on the server as long as each server follows the protocol message requirements.
|
||||
|
||||
Server implementions may [cache](https://flak.tedunangst.com/post/what-happens-when-you-honk) frequent requests, such as follower actor objects, public keys of other servers, and images and attachments on posts.
|
||||
ActivityPub is not opinionated about how messages are persisted on the server as long as each server follows the protocol message requirements. Server implementions may [cache](https://flak.tedunangst.com/post/what-happens-when-you-honk) frequent requests, such as follower actor objects, public keys of other servers, and images and attachments on posts.
|
||||
|
||||
### Moderation & Reputation
|
||||
|
||||
Moderation is primarily handled by server implementations. ActivityPub defines a "block" activity to help users control their experience.
|
||||
Moderation is primarily handled by server implementations. Server admins can block individuals or entire instances. Banning instances can lead to the isolation of an ActivityPub server instance if it is banned by many others, limiting its users to communication with each other.
|
||||
|
||||
The use of server-level bans to block content can lead to the isolation of an ActivityPub server instance if it is banned by many other servers, limiting its users to communication within its instance.
|
||||
ActivityPub defines a "block" activity to help users control their experience.
|
||||
|
||||
ActivityPub adoption has reached a threshold where spam and harassment have become ongoing problems that protocol developers currently seek to address. [Keeping Unwanted Messages off the Fediverse](https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/topics-and-advance-readings/ap-unwanted-messages.md#org2158b95) is a list of suggested solutions.
|
||||
|
||||
### Social & Discovery
|
||||
|
||||
Messages are addressed to a user at their home server, or published to a public inbox. Normal DNS and IP address routing are used to find the server addressed.
|
||||
|
||||
If posts are limited in visibility (followers only, direct message), they will be delivered to a user's inbox, such as `https://example.com/users/alice`.
|
||||
If posts are limited in visibility (followers only, direct message), they will be delivered to a user's inbox, such as `https://example.com/users/alice`. The "outbox" is a URL where an actor's recent activities can be retrieved from.
|
||||
|
||||
Servers also may accept delivery of messages addressed as 'public' to a shared inbox available to all on the server, but are not required to. Social network implementations with public feeds may publish posts to the public inbox, such as `https://example.com/inbox`.
|
||||
|
||||
"Like"s and "Follow"s may be used by servers to determine which public messages to accept/retrieve.
|
||||
|
||||
The "outbox" is a URL where an actor's recent activities can be retrieved from.
|
||||
|
||||
There is no global search capability, as each server monitors a different set of messages. Searching for the same keyword on different instances yields different results. The federated timeline shows public posts that the user's server knows about. Essentially, users have access to posts of people followed by people on their instance.
|
||||
There is no global search capability, as each server monitors a different set of messages.
|
||||
|
||||
### Privacy & Access Control
|
||||
|
||||
Server to server federation is authenticated using HTTP signatures in conjunction with the signing key from the actor's publicKey field. To verify object integrity, linked data signatures are used to sign the object with the publicKey of the actor who authored it.
|
||||
|
||||
When a remote server receives a POST to its inbox, it verifies the signature on the HTTP request by checking it against the sending server's publicKey.
|
||||
|
||||
Mastodon is currently [adding e2e encryption to ActivityPub](https://github.com/tootsuite/mastodon/pull/13820). Previously, messages were unencrypted on the server.
|
||||
|
||||
### Interoperability
|
||||
|
|
@ -76,7 +70,7 @@ The ActivityPub ecosystem scales up by adding more server capacity to the networ
|
|||
|
||||
[W3C Implementation Report](https://activitypub.rocks/implementation-report/)
|
||||
|
||||
- [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)
|
||||
- [Mastodon](https://mastodon.social/about) (the largest federated network built on ActivityPub) has 2699 nodes and 2.6M users as of 5/2020
|
||||
- [Pleroma](https://pleroma.social/) is another federated social network. According to stats at [the-federation.info](the-federation.info), Pleroma has 620 nodes with 35K users as of 5/2020.
|
||||
- [PixelFed](https://pixelfed.org/) is an ActivityPub based image-sharing platform.
|
||||
- [Friendica](https://friendi.ca/) is a decentralized social network with support for ActivityPub, as well as the OStatus and diaspora protocols.
|
||||
|
|
@ -92,8 +86,7 @@ The IndieWeb protocols and community are also related to ActivityPub through a s
|
|||
|
||||
### Links
|
||||
|
||||
[W3C ActivityPub Spec](https://www.w3.org/TR/activitypub/)
|
||||
[Social Web Working Group](https://www.w3.org/wiki/Socialwg)
|
||||
[SocialHub, ActivityPub discussion forum](https://socialhub.activitypub.rocks/)
|
||||
[Notes from an ActivityPub implementator](https://flak.tedunangst.com/post/ActivityPub-as-it-has-been-understood)
|
||||
[Reading ActivityPub](https://tinysubversions.com/notes/reading-activitypub/)
|
||||
- [W3C ActivityPub Spec](https://www.w3.org/TR/activitypub/)
|
||||
- [SocialHub, ActivityPub discussion forum](https://socialhub.activitypub.rocks/)
|
||||
- [Notes from an ActivityPub implementator](https://flak.tedunangst.com/post/ActivityPub-as-it-has-been-understood)
|
||||
- [Reading ActivityPub](https://tinysubversions.com/notes/reading-activitypub/)
|
||||
|
|
|
|||
|
|
@ -4,9 +4,9 @@
|
|||
|
||||
#### Solid
|
||||
|
||||
Solid's data model is [RDF](https://www.w3.org/RDF/) (Resource Description Framework), which is a standard model for data exchange on the web. RDF was adopted as a W3C recommendation in 1999 as a standard for graph-based data, intended for decentralized information sharing. RDF extends the linking structure of the web to use URIs to name the relationship between things, allowing structured data to be shared across different applications. RDF is based on the idea of [making statements about resources](https://en.wikipedia.org/wiki/Resource_Description_Framework) of the form _subject-predicate-object_, known as triples. It is an abstract model with several serialization formats, so the particular encoding for resources or triples varies.
|
||||
Solid uses [RDF](https://www.w3.org/RDF/) (Resource Description Framework), which is a standard model for data exchange on the web. RDF was adopted as a W3C recommendation in 1999 as a standard for graph-based data, intended for decentralized information sharing. RDF extends the linking structure of the web to use URIs to name the relationship between things, allowing structured data to be shared across different applications. RDF is based on the idea of [making statements about resources](https://en.wikipedia.org/wiki/Resource_Description_Framework) of the form _subject-predicate-object_, known as triples. It is an abstract model with several serialization formats, so the particular encoding for resources or triples varies.
|
||||
|
||||
RDF has all the advantages and generality of structuring information using graphs. It is the foundation for publishing and linking data in the [Semantic Web](https://www.w3.org/standards/semanticweb/). If it were fully adopted, advantages of using RDF would include being able to have the same API everywhere, as opposed to requiring code to integrate with each custom web API. Disadvantages include being non-human-readable and historically [complex to use](https://hal.inria.fr/hal-01966561/document).
|
||||
RDF has all the advantages and generality of structuring information using graphs. It is the foundation for publishing and linking data in the [Semantic Web](https://www.w3.org/standards/semanticweb/). If it were fully adopted, advantages of using RDF would include being able to have the same API everywhere, as opposed to requiring code to integrate with each custom web API. Disadvantages include being non-human-readable and historically [complex for developers to use](https://hal.inria.fr/hal-01966561/document).
|
||||
|
||||
#### XMPP
|
||||
|
||||
|
|
@ -16,10 +16,9 @@ XMPP is an XML (Extensible Markup Language) protocol for near-real-time messagin
|
|||
|
||||
Matrix transports messages using JSON, instead of XML like its most similar predecessor, XMPP. In the years since XMPP was standardized, JSON has become a [popular alternative to XML](https://blog.cloud-elements.com/json-better-xml) because it's less verbose, parses quickly, and is human-readable. Conversation history in Matrix is tracked through DAGs.
|
||||
|
||||
#### ActivityPub & Mastodon
|
||||
|
||||
ActivityPub uses streams of JSON-LD, based on the ActivityStreams data format. Mastodon was formerly compatible with OStatus, which used RSS, but switched entirely to ActivityPub.
|
||||
#### ActivityPub
|
||||
|
||||
ActivityPub uses streams of JSON-LD, based on the ActivityStreams data format.
|
||||
AcvitityPub implementations mostly use a [subset of JSON-LD](https://stephank.nl/p/2018-10-20-a-proposal-for-standardising-a-subset-of-json-ld.html), related to namespacing, versioning, and extensions. JSON-LD allows for extensibility, so that ActivityStreams do not have to contain all the vocabulary needed for future applications.
|
||||
|
||||
#### IPFS
|
||||
|
|
@ -28,18 +27,22 @@ IPFS uses a custom data structure, [IPLD](https://ipld.io/), which is designed t
|
|||
|
||||
#### Ssb
|
||||
|
||||
Ssb uses append-only logs of signed JSON. Each ssb user has their own [signed hash-based linked list](https://spec.scuttlebutt.nz/feed/messages.html), called a _sigchain_. This design ensures that messages are not lost, the order is not confused, data can be moved across untrusted machines, and replication of data is simple. Drawbacks include the inability to subscribe to only parts of the data, no support for mutable data, and the inability to update from multiple machines, resulting in no multi-device usage.
|
||||
Ssb uses append-only logs of signed JSON. Each ssb user has their own [signed hash-based linked list](https://spec.scuttlebutt.nz/feed/messages.html), called a _sigchain_. This design ensures that messages are not lost, the order is not confused, data can be moved across untrusted machines, and replication of data is simple. Drawbacks include: inability to subscribe to only parts of the data, no support for mutable data, and inability to update from multiple machines, resulting in no multi-device usage.
|
||||
|
||||
#### Hypercore
|
||||
|
||||
The Dat project renamed to Hypercore to reflect a transition that placed the core of the protocol at a lower level of abstraction. The focus of Hypercore is a signed append-only log that is p2p distributed, and its main purpose is to be a building block for other applications. The core of Dat, a public-key-addressed file drive, is now implemented as Hyperdrive on top of Hypercore. In contrast to ssb, which uses a linked-list append-only log, Hypercore uses a Merkle-tree-based append-only log where each entry generates a new leaf and new root
|
||||
The Dat protocol renamed itself to Hypercore to reflect a transition that placed the core of the protocol at a lower level of abstraction. The primary data structure of Hypercore is a signed append-only log that is p2p distributed, and intended as a building block for other applications. The former Dat protocol's main structure, a public-key-addressed file drive, is now implemented as Hyperdrive on top of Hypercore. In contrast to ssb, which uses a linked-list append-only log, Hypercore uses a Merkle-tree-based append-only log where each entry generates a new leaf and a new root.
|
||||
|
||||
### Mutability
|
||||
|
||||
Federated applications allow users to edit and delete content, handled at the server level. To ensure content is deleted across the entire network, applications must honor delete messages. P2p applications have more variance around mutability.
|
||||
Federated applications allow users to edit and delete content, as these operations are handled at the server level. To ensure content is deleted across the entire network, applications must honor delete messages.
|
||||
|
||||
Ssb & Hypercore - Messages added to the append-only logs used by ssb and hypercore are immutable. Applications can choose not to display messages indicated as deleted, but the data cannot be overwritten.
|
||||
P2p applications have more variance around mutability, as some data structures can lead to immutable content.
|
||||
|
||||
IPFS - Data is content-addressed, so once added to a network, content is discoverable by its hash. If users stop hosting it and no copies are left online, it will be inaccessible. However, if a copy remains stored on the network, it is re-discoverable by its immutable reference hash.
|
||||
**Ssb & Hypercore** - Messages added to the append-only logs used by ssb and hypercore are immutable. Applications can choose not to display messages indicated as deleted, but the data cannot be overwritten.
|
||||
|
||||
Aether - Aether attempts to design a more ephemeral p2p content network. "Stale" threads that have not been referenced for 6 months get dropped by clients in the network.
|
||||
**IPFS** - Data is content-addressed, so once added to a network, content is discoverable by its hash. If users stop hosting it and no copies are left online, it will be inaccessible. However, if a copy remains stored on the network, it is re-discoverable by its immutable reference hash.
|
||||
|
||||
**Aether** - Aether attempts to design a more ephemeral p2p content network. "Stale" threads that have not been referenced for 6 months get dropped by clients in the network.
|
||||
|
||||
**Blockchain social applications** - Many [blockchain social applications](../applications/blockchain-social.md) do not allow deletion of content, as data posted on a public blockchain is immutable.
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ Mastodon servers store content from users followed by members of the server. Use
|
|||
|
||||
Mastodon has [public relays](https://source.joinmastodon.org/mastodon/pub-relay) which rebroadcast anything sent to it to anyone who subscribes to the pub.
|
||||
|
||||
To overcome the difficulties of new users finding people to follow to get connected to the network, [Trunk](https://communitywiki.org/trunk/) is a community-built tool that helps users find and follow people by category.
|
||||
To overcome the difficulties of new users finding people to follow to get connected to the network, [Trunk](https://communitywiki.org/trunk/) is a community-built tool that helps users find and follow people by category. Users have requested a global directory for [importing friends from other networks](https://github.com/tootsuite/mastodon/issues/11886). Mastodon users used to be able to find their Twitter friends using `bridge.joinmastodon.org`, but the service was shut down after the developer lost access to API keys and was not granted another set.
|
||||
|
||||
Hashtags are used to filter and discover content in ssb, Diaspora, and Mastodon.
|
||||
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ In 2001, Zooko Wilcox-O'Hearn named three desirable properties of decentralized
|
|||
|
||||
- Blockstack - Blockstack originally registered names on the Bitcoin blockchain, and later became a general purpose blockchain platform.
|
||||
|
||||
- Handshake - Handshake is a blockchain for name registrations.
|
||||
- Handshake - [Handshake](https://handshake.org/) is a blockchain for name registrations.
|
||||
|
||||
- Microsoft - [ION](https://techcommunity.microsoft.com/t5/identity-standards-blog/ion-booting-up-the-network/ba-p/1441552) is a Microsoft-led digital identity system built on Bitcoin.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
# Privacy
|
||||
|
||||
Designing for public communication requires less focus on privacy than social applications designed for close social circles. However, privacy for user metadata is still important, and private direct messaging is a feature that may need to be supported.
|
||||
Designing for public communication requires less focus on privacy than social applications designed for close social circles. However, privacy is still important to consider on several counts: protecting user metadata, respecting private account settings, and supporting private direct messaging.
|
||||
|
||||
### Direct messaging
|
||||
|
||||
Many decentralized social applications use e2e encryption to preserve the privacy of direct messages.
|
||||
|
||||
|
|
@ -13,7 +15,7 @@ Some more e2e messaging encryption options:
|
|||
- [Noise protocol](http://www.noiseprotocol.org/), used by WhatsApp
|
||||
- [Messaging Layer Security (MLS)](https://messaginglayersecurity.rocks/)
|
||||
|
||||
A few decentralized social applications focus on privacy.
|
||||
### Decentralized applications that focus on privacy
|
||||
|
||||
- [Peergos](../protocols/peergos.md) - Peergos provides [capability-based access control](https://github.com/Peergos/Peergos) for files on top of IPFS. Files are kept private. All encryption happens on the client, which could be a native Peergos client or a browser. Data is always encrypted on the servers. Servers do not have access to metadata or sensitive information. Access is controlled through cryptographic capabilities. Access is hierarchical, and stored in an encrypted structure called [cryptree](https://book.peergos.org/security/cryptree.html).
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue