Skip to content

design

This section gives an overview of some design choices that have influenced bovine_store.

Storing and indexing

The basic idea is to store three things

  • The object
  • The id as an index
  • The actor / attributedTo property of the object as the owner

For this objects are decomposed into parts with their own ids to prevent storing duplicated objects. This is achieved using bovine.jsonld.split_into_objects <https://bovine.readthedocs.io/en/latest/reference/bovine.jsonld.html#bovine.jsonld.split_into_objects>_.

This approach doesn’t work yet for Collections that are often changing. For these just the membership is stored in CollectionItem. Furthermore, who can see an object is stored in VisibleTo.

Further topics

  • 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.