|
|
@@ -1,4 +1,4 @@
|
|
|
-ActivityPub is a protocol published by the \ac{W3C} in January 2018 as an official standard\footnote{https://www.w3.org/TR/activitypub}. The protocol regulates communication within an open, decentralized social network. There are two levels: client to server (Social \ac{API}) and server to server (Federation Protocol). The two protocols are designed in such a way that they can be used independently of each other. If one of them is implemented, it is easy to implement the other. The Activity Streams\footnote{https://www.w3.org/TR/activitystreams-core} data format is used to describe activities in \ac{JSON-LD} format. This data format is also an official \ac{W3C} standard with the aim to record meta data of an action in a human-friendly but machine-processable syntax.
|
|
|
+ActivityPub is a protocol published by the \ac{W3C} in January 2018 as an official standard \cite{w3c2018activity-pub}. The protocol regulates communication within an open, decentralized social network. There are two levels: client to server (Social \ac{API}) and server to server (Federation Protocol). The two protocols are designed in such a way that they can be used independently of each other. If one of them is implemented, it is easy to implement the other. The Activity Streams \cite{w3c2017activity-streams} data format is used to describe activities in \ac{JSON-LD} format. This data format is also an official \ac{W3C} standard with the aim to record meta data of an action in a human-friendly but machine-processable syntax.
|
|
|
|
|
|
The principle behind ActivityPub is similar to that of e-mail. Servers can be uniquely identified via the domain. Within a server, each mailbox is accessible via a unique name. Thus, users can communicate with each other via different servers by having their messages forwarded to their mailbox.
|
|
|
|
|
|
@@ -28,12 +28,10 @@ The following interactions are defined between the client and the server, but so
|
|
|
|
|
|
\subsubsection{Server to Server (Federation Protocol)}
|
|
|
\label{sec:federation-protocol}
|
|
|
-
|
|
|
This protocol defines the exchange of activities between actors of different servers. The network between the servers with all actors is called a social graph. The interactions defined in the Social \ac{API} must be implemented by the server so that they reach the addressed actors. The starting point is always the outbox of an actor. If a new activity is created using an \ac{HTTP} POST request and, for example, the follower collection of the actor is selected as the addressee, the server must ensure that every actor in the follower collection receives the activity in its inbox. The recipients and their addresses can be found by following the links in the activities. It is also up to the server to ensure that there is no duplication of content.
|
|
|
|
|
|
\subsubsection{Application Examples}
|
|
|
\label{sec:mastodon}
|
|
|
-
|
|
|
The most popular application example is the social network Mastodon\footnote{https://joinmastodon.org/}. Mastodon is a decentralized network based on free and open source software. Everyone is invited to host their own platform. With currently 1.6 million users it is the most significant implementation of the ActivityPub Protocol. The Federation Protocol is used for communication between the individual servers. The Social \ac{API} is not used, instead Mastodon offers its own \ac{API}\footnote{https://docs.joinmastodon.org/api/guidelines/} for communication with the client.
|
|
|
|
|
|
Networking with other users is not limited to mastodon instances. Each service that has implemented the ActivityPub Protocol allows its actors to network with actors of entirely different applications because the communication is standardized. So it is possible without problems to follow an actor of the video platform PeerTube\footnote{https://joinpeertube.org/en/} as Mastodon actor and be notified when he uploads a new video there.
|
