|
|
@@ -2,7 +2,7 @@ ActivityPub is a protocol published by the World Wide Web Consortium (W3C) in Ja
|
|
|
|
|
|
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)}
|
|
|
+\subsubsection{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.
|
|
|
|
|
|
@@ -25,12 +25,12 @@ Each actor has some so called collections. To these collections, objects can be
|
|
|
|
|
|
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)}
|
|
|
+\subsubsection{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}
|
|
|
+\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 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.
|
Carsten Porth