HOSN-app/thesis/content/03-related-work/activitypub.tex

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.

\subsubsection{Client to Server (Social \ac{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 bound to 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 \ac{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}). For ensuring that only authorized clients store content in an outbox, the sender must sign the posts.

\begin{figure}[h!]
	\includegraphics[width=1.0\textwidth]{activitypub-communication}
	\caption{Concept of the Social \ac{API} protocol: The actor fetches messages with an \ac{HTTP} GET request to his inbox and posts messages using an \ac{HTTP} POST request. The inbox is filled by \ac{HTTP} POST requests from other actors. \cite{w3c2018activity-pub}}
	\label{fig:activitypub-communication}
\end{figure}

The outbox of an actor holds all his published posts. When accessing the an actor's outbox without authorization, the server delivers all public posts of the actor. If access with authorization occurs, the explicitly shared content is also transmitted. The corresponding actors can only access their own inbox. On access, the messages are downloaded from the server. New messages get in the inbox per \ac{HTTP} POST request from another server.

Each actor has some so-called collections. Objects (depends on the collection, e.g., accounts, posts) can be removed or added to the collections. 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 an object to a collection), Remove (remove an object from a collection), Like, Block, Undo. To address the activities, \textit{to}, \textit{bto}, \textit{cc}, \textit{bcc} provide the same possibilities as they are known from e-mail. The server then has to ensure that the activity also reaches the addressed actors.

\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. A new activity is created using an \ac{HTTP} POST request to the outbox. If, for example, the follower collection of the actor is selected as the addressee, the server has to 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 2 million users it is the most significant implementation of the ActivityPub Protocol \cite{mastodonXXXXstats}. 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.

In addition to cross-platform networking, another advantage is caused by decentralization and independence. 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 would go offline, all contacts would be lost, and the platform would never be accessible again.