The GoActivityPub library is composed of multiple modules split based on the functionality they fulfill in the ActivityPub specification.
At the most basic level there are two main elements to this purpose:
- Fetching ActivityPub objects based on their ID.
- Processing ActivityPub activities and managing their side-effects.
For the former the library provides the storage backends for storing and retreiving local objects and a custom HTTP client that for retrieving remote ones.
For the later there is an ActivityPub state machine that handles the retrieval, validation and processing of the activities. It can handle both activities coming from clients and from other servers.
And to tie them together there is the ActivityPub vocabulary module where the Vocabulary types used by everything else are defined.
ActivityPub
The module that probably serves as an introduction to the library for most developers, the vocabulary module contains the main data types for the library, with a number of additional helper functions to accomodate the Go versus JSON-LD type incompatibilities.
It offers developers a consistent data model that is identical to the types defined in the Activity Vocabulary specification.
Further details can be found on its separate page.
Processing
This module is the central point of the library, it contains the state machine for the processing of Activity Vocabulary activities as described in the ActivityPub specification and makes use of the other modules to fulfill its purpose.
Additionally there are helper functions that wrap the logic of fetching objects and processing the Activity requests, and which are compatible with the standard Go HTTP Request Handler interface.
See the details page for a lengthier description.
Storage
The library provides multiple modules that implement storage backends. Their main purpose is to store ActivityPub objects locally, but generally a library user would implement them on top of whichever data repository their application already uses.
That list can be seen on the details page alongside more details about how to write your own implementation, and which tooling we provide to help with that.
Client
The client module can be used in order to interact with ActivityPub servers
over HTTP.
One of it’s purposes is to fulfill the first requirement described at the top: fetching remote objects. The processing module makes use of this a lot in the act of validating and dereferencing objects that are required for operating on its current activity.
Additionally it can dispatch Activity requests to remote actors’ inbox and
outbox collections.
In this role the module can be used both as part of client applications that talk to their user’s server, or as part of server applications that talk to other servers.
You can check the details page for additional information.
Auth
Defines the logic for verifying HTTP-Signatures and OAuth2 compatible authorization headers for the Social API and Federation Protocol requests.
See more details on the module page.
Others
So far we have mentioned only the modules that are the most likely to be used by applications. In support of them there are a number of other ones, but their relevance for an application developer might not be as high.
Here’s a brief description of each of them with links to their individual pages.
Filters
The filters module is being used extensively by the storage
backends as it provides the main method for filtering items in locally stored
collections.
Additionally they can be used for marshaling and unmarshaling the filters as
url.Values query parameters, or generate sqlf compatible WHERE clauses.
Cache
The cache module can be used when there is a need for an in-memory cache with specialized invalidation mechanism for activities and objects.
JSON-LD
The json-ld module implements a custom json encoding and decoding mechanism for the vocabulary objects, which is used extensively across the library.
Errors
The errors module offers a number of custom errors types that are being used in the other modules, corresponding to HTTP errors.