tl;dr — conversation backfill and synchronization via resolvable context; potential FEP.

This topic is an extension of an earlier discussion: How do you use context (if at all)?

We came out of May’s ForumWG meeting with a sense that pursuing formalisation of the context property was a step in the right direction. I later built out a resolvable context collection as part of this effort.

Currently, if you are given a standalone activitypub object, you might not have any or all of the conversation surrounding it. That’s part-and-parcel of the design of ActivityPub — that content is pushed to various federated instances, as opposed to one centralized authority —but is a source of some concern as end-users continually remark on how various instances have different reply sets, and worse yet, even the original site may not have the entire conversation.

I can hear @[email protected] now:

“ActivityPub is a push and pull-based API!!” — Evan Prodromou

Agreed! Although, while you can pull public objects via ActivityPub, you can’t pull said objects if you don’t know they exist. Here are your options for building/resolving any single object’s conversational context:

  • You may opt to do nothing (and the object is standalone; not ideal).
  • You may traverse up the inReplyTo chain and build out one direct thread of replies (better).
    • N.B. for security, it is best to limit the traversal to an arbitrary maximum
  • New — you may query the object’s context property, and if resolving to a (Ordered)Collection, build out the entire conversational context — including all conversational sub-trees — in one fell swoop.

New this week is a proof-of-concept implementation of a “context synchronization” mechanic. Using similar mechanics to Mastodon’s FEP-8fcf (Followers collection synchronization across servers), I propose servers can compute a digest for a context collection via its object ids, and serve them using the common ETag header. Recipients may opt to calculate their own digest and begin backfill on digest mismatch. Optionally, the If-None-Match header containing that digest can be sent, allowing the origin server to respond with an even simpler 304 Not Modified.

Technical details re: topic synchronization.

Backfill and sync are both still limited availability; only NodeBB supports them currently. However, I’m working with Angus (building out the Discourse AP integration) to expand support, and I’d like to eventually publish an FEP and SocialCG report to make this all pseudo-official.

We intend to discuss our research at this month’s ForumWG (August 1st; 1300 EDT), join us and let’s see where this goes!