Implementation of FEP-7888 (Demystifying the context property)
-
As of today, the NodeBB-ActivityPub implementation now supplies both
context
andaudience
properties with every post.N.B. When I say
context
andaudience
, these are also terms used by the ForumWG that refer to "topic" and "category", in NodeBB parlance.
Early indications from the last ForumWG meeting indicate movement towards the inclusion of
context
in a low-levelas:Note
object (a federated NodeBB post), resolvable as anas:Collection
oras:OrderedCollection
. The latter is what NodeBB will send, ordered by post time.Discussions with @angus@socialhub.activitypub.rocks also suggest that Discourse has the ability to parse an
as:OrderedCollection
context
if provided, but currently does not if encountered as a property in a Note.A minor change today also updates the
audience
property, which used to erroneously point to the context/topic, but now points to the audience/category. This change aligns usage of this property with FEP-1b12's expectations.
This change should allow other implementors to:
- automatically group objects together given a the provided context, and
- more thoroughly backfill a given object's context, without relying on
inReplyTo
traversal
-
@trwnh@mastodon.social follow-up question re: 7888...
Right now when a post is made, the context is the topic. If I later on add the ability for NodeBB to send activites to contexts (and parse the resultant
Add
), is there an expectation that that context replaces my own local context?Perhaps I could send an array of contexts, although I am not certain whether that is going to cause problems.
-
@julian context can be an array but generally isn't expected to be. posts aren't usually part of multiple threads. it sounds like your concern is mostly in establishing equivalence between contexts? at least that's what it sounds like with the talk about "my own local context". it doesn't particularly matter if the context is local or remote.
-
infinite love ⴳreplied to infinite love ⴳ on last edited by
@julian to clarify: this is mostly about "canonical" identifiers vs. aliases. there is generally one canonical identifier for the conversation collection, and this is what should be used as the value of `context`. this could get a bit complicated but there are potential ways to coordinate replication between equivalent conversation collections, probably involving mutual following/follower relationship, plus some indicator of aliases like `alsoKnownAs` or some other extension property.