Reviewing AP storage #101

Related to #98

As I understand from the spec, Create/Update activities reference an object, so they're used for notifying the remote instances, which then dereference the object by downloading it from the local instance. This quickly turned out to be untrue, because Mastodon expects the object to be embedded and won't derefence it. I had to do this for the jekyll-activity-pub plugin, so it creates a Note object and then embed it on an Create/Update activity that gets relayed to the Social Inbox for notifications.

Conversely, when the Social Inbox receives a remote activity, it stores it on the inbox for the site, and indexes the object by storing it on the database. This is where things get blurry for me because I don't fully understand how the indexing currently works on SI. I see actor, activity and object stores, but I'm not sure how they relate to each other.

I think the SI should behave like this, can we discuss and check if these expectations are fulfilled?

• Before storing an activity, the object is stored on the ObjectStore and referenced by url on the activity, then the activity is added to the ActivityStore. This ensures that if an object is removed, any activity like Create and Update won't have copies of its contents included, after a Delete. We're doing this on the moderation queue already.
  • The added benefit besides deduplication, is that if I fetch the inbox and iterate over its items, and try to dereference objects, the remote instance would be the source of truth for objects. For instance, if a Delete didn't reach the Social Inbox or failed previously, I'll still get a Tombstone for a deleted object when dereferencing it.
  • Which actually makes me think we shouldn't be storing/caching objects at all?
• Delete is always honored by removing the object from ObjectStore.
• Undo is always honored by removing the activity from ActivityStore.
• Create, Announce, Like approval/rejection depend on blocklist/allowlist status.
• Update depends on previous Create or Update status, if it's the first one received, it behaves as a Create.
  • Unless we want versioning edits, the object contents will be replaced.
• The actor's inbox should have a way of distinguishing between activities pending approval and approved. Now it's mixing everything together, so if I fetch it and iterate over its orderedItems, I don't know which ones are approved or not. Only by fetching each of my Notes replies, shares and likes collections I can get the actually approved activities (this is what's currently happening on the templates with federated interactions enabled). Maybe have a different collection for pending activities?
  • We'll need a way to compact the inbox on clients it so it only has the latest relevant activity. For instance, only the latest Update is relevant, Delete cancels all previous Update and Create, similar with Undo. Maybe serve the compacted version by default and in full with a param?