You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Helge af0c7a4851 bovine 0.2.5 1 day ago
bovine_store Move specific code to bovine_web 1 day ago
docs Initial move of json-ld 1 week ago
examples Code cleanup 1 week ago
tests Code cleanup 1 week ago
.gitignore First round in getting bovine_store to properly handle collections 3 months ago Finish cleaning up config 1 week ago
context_cache.sqlite testcase for plemora 2 months ago
poetry.lock Move specific code to bovine_web 1 day ago
pyproject.toml bovine 0.2.5 1 day ago
setup.cfg Migrating towards bovine_store containing most logic 2 months ago


bovine_store is meant to be the module handling storing of local ActivityPub objects and caching of remote ActivityPub objects.


bovine_store assumes that a database connection is initialized using tortoise-orm. See examples/ for how to do this in the context of a quart app.


  • When properties of actor are updated, send an update Activity
  • Generally rework the actor properties mechanism. It is currently not possible to emulate say Mastodon featured collection with it.
  • bovine_store.models.BovineActorKeyPair needs renamings; and work, e.g. a future identity column should have a uniqueness constraint.
  • Generally the code quality is not as high as it should be.

Design discussion

Some goals and design decisions:

  • Objects with an id are stored separately and can be looked up via this id. This is done by json-ld magic.
  • Collections are not stored. Instead for local items, the information that the item belongs to a collection is stored. contains the coroutines necessary to build the collection from this information. All collections are assumed to ActivityStreams 2 OrderedCollection and ordered by the database id.
  • Every object is currently assigned an owner. The idea was that an activity is owner by its actor. This can then be propagated to the subobjects, e.g. the object, attachments, and so on. Unfortunately, this is too naive:
    • Some implementations include remote objects, e.g. the object being liked in a Like Activity.
    • Mastodon includes its custom emojis. These have an id and should probably belong to the server.
  • There are three kinds of visibility.
    • An object is always visible to its owner
    • Public Objects are assigned VisibilityType.PUBLIC. These can viewed by all users providing valid authentication.
    • Furthemore, by adding actors to the VisibileTo list of an object. This can be made visible to the corresponding actors.
  • An item is visible to be inside a collection if and only if said item is visible. This should probably be augmented by visible to the owner of the collection.
  • bovine_store.blueprint contains a quart blueprint with the basic retrievel mechanism for the stored objects.
  • bovine_store.collection contains the helper routine for collection responses.


A demonstration webserver can be seen using

poetry run python examples/

Note this is a very basic example. Instructions what the example does are printed to the command line after start.

Note: This example creates two files db.sqlite3, which contains the database and context_cache.sqlite, which contains the cache of json-ld contexts.