Storage modules

This is the list of storage backends that the library currently provides:

• storage-fs: direct filesystem storage, every activity and object corresponds to a file on disk under a folder structure that closely mimics the layout found when querying server. It is generally meant to be used for development environments.
• storage-sqlite: a simple object storage on top of a single SQLite database.
• storage-boltdb: BoltDB is a performant key value store.
• storage-badger: another, more modern key value store.
• storage-pg: storage on top of PostgreSQL, but still used as an object storage, similar to the the SQLite one.
• storage-all: a wrapper around all of the above that allows using any of them.
• storage-sqlite/v2: a second storage on top of SQLite, but where databases are namespaced by their IRI hosts.

In order to simplify the API of the storage interfaces there isn’t a distinction between loading single objects and object collections.

The method Load(vocab.IRI, filters ...filters.Check) thus can receive a variable argument list of filters that can be applied when loading a collection.

This ensures that the collection contains only items that match those filters.

For more details about how filters work see the corresponding module.

Storage conformance suite

Alongside these modules, there is the storage-conformance-suite which provides a convenient helper module to make it easier for developers create their own storage backends on top of which ever foundational technology they need.

Its internal storage implementation contains some of the implicit rules that the storage backends need to implement in order to pass the suite, which are not apparent from the API.

Most of these are related to loading dependent objects that are represented just by an IRI in the stored value when the Load() method receives filters that refer to their respective properties.

Other functionality

On top of the functionality required by the ActivityPub specification through the processing module, there are some additional elements that other parts of the library make use of. The conformance suite provides tests for them also, but their absence is not fatal.

One such piece of functionality is saving and retrieving metadata based on the object IDs. This allows Actor objects for example to have an attached private key, or password, or in the cases of Application actors that are used as OAuth2 clients there are methods that facilitate the backends’ use with the osin library.