An overview of mapping a federated link aggregator web application on top of the ActivityPub vocabulary using go-activitypub packages, FedBOX and BrutaLinks.
The nomenclature we're using in the BrutaLinks ecosystem might not match perfectly with what other ActivityPub services might use, so we have compiled a list of the terms and how we are using them. Most of the time we tried to match the high level concepts to the ActivityPub specification vocabulary, but not always.
A service usually refers to a server that "speaks" the ActivityPub protocol, in our case it is represented by the FedBOX backend. To improve discoverability, we have chosen to map it directly to a Service actor that can be loaded at the root path of the serice. Eg: https://federated.id/
By an instance we understand the frontend application that maps the plain ActivityPub vocabulary into a specific user experience. For our case, we consider the BrutaLinks frontend to represent an instance. It maps to an Application actor on the instance. Eg: https://littr.me
This is unlike most of the federated service, which generally have both the service and the instance be the same application.
An ActivityPub object that fits the types the instance can operate on. This can map to different types of objects corresponding with what the instance can operate on. BrutaLinks understands objects of type Article, Note, Video, Image, Audio, Page, Document.
For text objects BrutaLinks can use the Content/Summary properties to display, but also can make use of the Source property and render the content for various mime-types: Markdown, plain text.
A tag represents a way to group items by including hashtag keywords in its content. It maps to an object without a type.
A user represents a regular user of the instance. It maps to a Person actor on the service.
A user with enhanced permissions. It reprents a normal Person actor, but which has a specific tag in it's tag collection. This relationship does not have an exact ActivityPub equivalent, the roles and permissions are concepts implemented in BrutaLinks. See the expanded concept in the moderation document.
A mention represents a way to include a mention of a user in the content of an item. It maps to an link type object with the type Mention. It also represents a way to include the user in the CC list of recipients.
A request made by a user for moderating a specific item, user or instance. It can map to an activity type object with one of the types Flag, Ignore, Block.
An action taken by a moderator as a response to one, or multiple moderation requests. It can correspond to different activities: Delete, Update, Remove, Move, etc.
A page where we can see items matching specific filters.
Front page listing: This is the main page of the BrutaLinks instance where we display all items that have been addressed to this instance. It mostly corresponds to the inbox collection of the Application actor representing the instance on the service filtered by items which have no inReplyTo properties (top level).
Federated listing: This is a page that filters the items on the current instance to just the ones received from users not belonging to it. This filters items in the inbox collection by their Actor's hostname on top of the top level filter from previously.
User followed listing: This is a listing corresponding to the items the current logged user received explicitly. It mainly corresponds to the actor's inbox.
User profile listing: This is the listing of items a user has submitted. It mainly corresponds to the actor's outbox.
Tag listing: A page listing all items that have been tagged with a specific tag. It filters the instance's inbox by items that have that specific tag in their tag property.
Domain listing: A page listing all items that have URLs pointing to a specific domain. It filters the instance's inbox by items which have URLs matching that domain.
Moderation listing: A page listing all moderation requests received by the instance.