|
|
@@ -0,0 +1,41 @@
|
|
|
+ActivityPub is a protocol published by the World Wide Web Consortium (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 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 JSON-LD format. This data format is also an official W3C standard with the aim to record meta data of an action in a human-friendly but machine-processable syntax.
|
|
|
+
|
|
|
+The principle behind Activity Pub 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 own mailbox.
|
|
|
+
|
|
|
+\subsection{Client to Server (Social API)}
|
|
|
+\label{sec:social-api}
|
|
|
+Users are called actors in ActivityPub and are represented by an associated account on the server. Since there can be several servers, it is important to emphasize that an account is only ever located on one server and user names must always be unique only within a server. Each actor has an inbox and an outbox on the server on which he is registered with his account. These are the two endpoints with which the client application communicates via HTTP requests. More is not necessary, because the server ensures that all messages and information for the user end up in his inbox and that the messages in his outbox are forwarded to the desired recipients (see \ref{sec:federation-protocol}). To ensure that only authorized clients store content in an outbox, the posts must be signed.
|
|
|
+
|
|
|
+\begin{figure}[h]
|
|
|
+ \includegraphics[width=1.0\textwidth]{activitypub-communication}
|
|
|
+ \label{fig:activitypub-communication}
|
|
|
+ \caption{Concept behind ActivityPub}
|
|
|
+\end{figure}
|
|
|
+
|
|
|
+The outbox of an actor holds all his published posts. When accessing the outbox of an actor without authorization, the server delivers all public posts of the actor as response. If access with authorization occurs, the explicitly shared content is also transmitted.\\
|
|
|
+The own inbox can only be queried by the corresponding actors itself. With an access to his own inbox he receives all activities delivered to him from the server. The inbox is filled by POST requests from other servers to the inbox.
|
|
|
+
|
|
|
+Each actor has some so called collections. To these collections, objects can be added and removed. The collections are used to store information related to an actor. These are the collections each actor has:
|
|
|
+
|
|
|
+\begin{itemize}
|
|
|
+ \item \textbf{Followers Collection}: List of actors who have posted the actor a follow-activity and follow him. Can be used as addressee when sharing a post.
|
|
|
+ \item \textbf{Following Collection}: List of actors followed by an actor and whose content he is interested in.
|
|
|
+ \item \textbf{Liked Collection}: List of all objects the actor has liked
|
|
|
+\end{itemize}
|
|
|
+
|
|
|
+The following interactions are defined between the client and the server, but some of them are optional to implement: Create, Update, Delete, Follow, Add (add objct to collection), Remove (remove object from collection), Like, Block, Undo. To address the activities, \textit{to}, \textit{bto}, \textit{cc}, \textit{bcc} provide the same possibilities as are known from e-mail. The server then has to ensure that the activity also reaches the addressed actors.
|
|
|
+
|
|
|
+\subsection{Server to Server (Federation Protocol)}
|
|
|
+\label{sec:federation-protocol}
|
|
|
+
|
|
|
+This protocol defines how activities are exchanged between actors of different servers. The network between the servers with all actors is called a social graph. The interactions defined in the Social 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 a 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.
|
|
|
+
|
|
|
+\subsection{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 largest implementation of the ActivityPub protocol. The Federation Protocol is used for communication between the individual servers. The Social API is not used, instead Mastodon offers its own 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 completely 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.
|
|
|
+
|
|
|
+In addition to cross-platform networking, one big advantage is that it has no major impact no matter what happens to Mastodon. The network can still exist and thanks to the open protocols and open source software it can be developed and used without restrictions. If Facebook were to go offline, all contacts would be lost and the platform would never be accessible again.
|
|
|
+
|
Carsten Porth
