The state of conversational contexts (February 2025)
-
A conversational context is what the ForumWG uses to describe what you might see as a reply tree or comment thread. One of the short-to-medium term goals of the ForumWG is to get conversational backfill working reliably.
What this means — conversational backfill means that when you encounter a post/status/note/etc. (e.g. you're mentioned or boosted/shared something), there is a reliable and comprehensive way to retrieve the entire conversation around it, so you are not interacting with the object on its own, but in its proper context with all its sibling replies.
We plan to achieve this with a combination of a top-down (FEP-driven) and bottom-up (implementor-first) approach. While this sounds incongruent, top-down approaches tend to overcomplicate and bottom-up approaches tend to violate the protocol (unintentionally of course
.)
There are a number of independent top-down efforts to achieve this:
- FEP-7888: Demystifying the context property
- FEP-171b: Conversation Containers
- FEP-76ea: Conversation Threads
These FEPs are in the R&D phase.
State of the Top-Down approach
At this time, the ForumWG is only recommending the following:
- Publishers SHOULD use
context
for grouping related objects in a thread (but this is not the only way to use context).
There is general agreement over:
- A
context
SHOULD resolve to a resource.
There are concerns over:
- What that resource is (
as:OrderedCollection
, a new type, something else?) - What is included in that
context
(plain objects or activities)
State of the Bottom-Up approach
The bottom-up approach is results-oriented, and while certain implementors may follow certain FEPs, the overarching goal is "cross-compatible conversational backfill".
Separately, these implementors are (or have signalled interest in) implementing conversational backfill:
- NodeBB and Discourse (@angusmcleod@mastodon.social)
- Following FEP 7888
- Attaches
context
to objects context
resolves to anOrderedCollection
- Two-way conversation backfill is tested and working.
- WordPress (@pfefferle@mastodon.social) and Frequency (@jesseplusplus@mastodon.social)
- Following FEP 7888
- Attaches
context
to objects context
resolves to anOrderedCollection
- One-way conversational backfill is tested and working — others can backfill an entire conversation from these implementors.
- Lemmy (@nutomic@lemmy.ml) and PieFed (@rimu@mastodon.nzoss.nz)
- Have signalled interest (neither positive nor negative) in conversational backfill and are waiting and watching at this time.
Of note:
- Mitra (@silverpill@mitra.social)
- Following FEP 171b
- One-way conversational backfill is tested and working — Mitra can backfill an entire conversation from FEP 7888 implementors
What's Next
This thread will likely contain updates and discussion from related parties about their implementations and what they wish to do next. In the cruelest irony of ironies, because conversational backfill is not ubiquitous yet, you will need to "View Original URL" in order to see all of the replies.
The ForumWG will meet again on 6 March 13h00 EST where all of this will be discussed, as well as planning out the future focus items for the ForumWG.
If you are an implementor, there is no reason you cannot join the fray. Boost this post, reply to it, join the conversation(al context)!!
If you're not an implementor, boost me anyway
-
Streams and Hubzilla also implement
context
collection. They attachcontext
to activities, it is anOrderedCollection
, and its items are activities. -
Streams and Hubzilla also implement
context
collection. They attachcontext
to activities, it is anOrderedCollection
, and its items are activities.@silverpill@mitra.social can Mitra, Streams, and Hubzilla backfill from each other (full two-way backfill) or one-way at this time?
-
@julian Mitra can backfill from Streams and Hubzilla, but it doesn't publish any collections yet.
Streams and Hubzilla have interoperable FEP-171b implementations, but I don't know about pulling the collection. They are more focused on private conversations where backfilling is not needed.
-
@julian Mitra can backfill from Streams and Hubzilla, but it doesn't publish any collections yet.
Streams and Hubzilla have interoperable FEP-171b implementations, but I don't know about pulling the collection. They are more focused on private conversations where backfilling is not needed.
@silverpill@mitra.social thank you! I've updated the original post to reflect that now.
-
@julian Mitra can backfill from Streams and Hubzilla, but it doesn't publish any collections yet.
Streams and Hubzilla have interoperable FEP-171b implementations, but I don't know about pulling the collection. They are more focused on private conversations where backfilling is not needed.
@silverpill I've yet to see Hubzilla backfill an entire existing thread at once. It does backfill posts from new connections on certain server apps, though. And it sometimes appears to backfill threads bit by bit over prolonged periods.
As for (streams), I can't see inhowfar it backfills because I barely actually follow anyone from there. -
@silverpill I've yet to see Hubzilla backfill an entire existing thread at once. It does backfill posts from new connections on certain server apps, though. And it sometimes appears to backfill threads bit by bit over prolonged periods.
As for (streams), I can't see inhowfar it backfills because I barely actually follow anyone from there.@jupiter_rowland@hub.netzgemeinde.eu if you're seeing Hubzilla backfill "bit by bit" it is likely doing
inReplyTo
traversal, which is what NodeBB does if it cannot find a resolvable context.