Add activitypub

This commit is contained in:
Jay Graber 2020-06-08 12:29:01 -07:00
parent 77ba1d18ee
commit 87eaac675b
1 changed files with 42 additions and 24 deletions

View File

@ -1,63 +1,81 @@
# 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.
Mastodon, built on ActivityPub, is a popular federated alternative to Twitter with around 2.2 million users. Prior to Mastodon, projects like GNU social and Diaspora tried and failed to get federated social networks to scale. Mastodon succeeded in large part because it created a familiar user interface that looked and behaved like Twitter, allowing users who were dissatisfied to find a new place to land with minimum effort.
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 consists of two layers: A server to server federation protocol, and a client to server protocol.
Mastodon is a popular federated alternative to Twitter built on ActivityPub.
### Identity
Users create an account on a server (an “instance”), but can communicate with users on other instances. The entire constellation of instances that can interoperate is called the “Fediverse”. A full username is a users handle plus the name of the instance the user belongs to, for example:
`@arcalinea@mastodon.social`
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.
Account credentials are managed by the users instance, so if users forget their password, they can ask for a password reset.
### Networking/Message Passing
### Data
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.
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.
ActivityPub messages are objects wrapped in an "activity", indicating what it is.
### Moderation & Reputation
ActivityPub messages are not limited to HTTP only. This allows it to potentially be extended in more [p2p directions](https://nbviewer.jupyter.org/github/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/final-documents/activitypub-decentralized-distributed.pdf).
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.
### Data Storage/Message Persistence
### Social & Discovery
ActivityPub is not opinionated about how messages are persisted on the server as long as each server follows the protocol message requirements.
Messages are addressed to a user at a specific server, and normal DNS and ip address routing are used to find the server addressed.
### Moderation/Reputation
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.
Moderation is primarily handled by server implementations. ActivityPub defines a "block" activity to help users control their experience.
Instances may accept delivery of messages addressed as 'public' to a shared inbox on the instance but are not required to.
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.
Not clear if there is a global search capability.
### Social/Discovery
Messages are addressed to a user at their home server. 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. Servers may accept delivery of messages addressed as 'public' to a shared inbox available to all on the server, but are not required to. "Like"s and "Follow"s may be used by servers to determine which public messages to accept/retrieve.
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.
### User experience
Currently the primary user experience is in a twitter-like UI (Mas.to or Pleroma)
ActivityPub is most widely used in Twitter-like applications (Mastodon, Pleroma). Some other applications that federate using ActivityPub include PixelFed and PeerTube.
### Privacy & Access Control
### Monetization
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 hte publicKey of the actor who authored it.
Federated social networks require both hosting and development costs to maintain. Each instance is funded by its own administrator and community. Mastodons development is funded through a Patreon run by the main developer. 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 mastodon.social instance.
A [2017 discussion](https://github.com/w3c/activitypub/issues/225) of how to do encrypted messaging in ActivityPub.
### Interoperability
The spec mentions delivery to third-party apps but unsure how/how much this happens in the wild.
Any service that implements the ActivityPub protocol can interoperate with the ecosystem. A service like Twitter would need to add Webfinger and JSON-LD representations of users and tweets.
Requirements for interop: implement the ActivityPub protocol (are there different requirements for 3rd party receivers?)
Diaspora, another federated social network, chose not to adopt ActivityPub. A Diaspora developer's reasoning for the decision is detailed in [this blog post](https://schub.wtf/blog/2018/02/01/activitypub-one-protocol-to-rule-them-all.html).
### Scalability
The ActivityPub ecosystem scales up by adding more server capacity to the network. This [study on the Mastodon ecosystem](https://emilianodc.com/PAPERS/mastodonIMC19.pdf) analyzes the emergence of points of centralization as the network scales up.
### Metrics
### Implementations & Applications
[fediverse.network](https://fediverse.network/) maintains statistics of the known oStatus/ActivityPub fediverse.
List of ActivityPub projects: https://github.com/BasixKOR/awesome-activitypub
### Implementations
[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)
[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.
[Pleroma](https://pleroma.social/) According to stats at [the-federation.info](the-federation.info), Pleroma has 620 nodes with 35K users as of 5/2020.
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.
### Related
ActivityPub inherits from a few other protocols that will not be covered in full, but are briefly summarized here.
ActivityPub was based on pump.io and ActivityStreams. Conceptually, these were preceded by OStatus. Pump.io is an activity streams social networking server. [OStatus](https://en.wikipedia.org/wiki/OStatus) is an open standard for federated microblogging, and describes how a suite of protocols can be used together.
The IndieWeb protocols and community are also related to ActivityPub through a shared vision of social federation developed around the same time period. The IndieWeb was [inspired by the Federated Social Web Summit in 2010](https://www.manton.org/2019/07/08/interview-with-indieweb.html), and formed around the idea of interconnecting individual websites rather than federating social platforms. A co-founder described the vision as, "someone should be able to take their web site and be able to use their web site to participate in the same distributed social network — federated social network."
### Links
[https://www.w3.org/TR/activitypub/](https://www.w3.org/TR/activitypub/)
[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/)