Implementation of FEP-7888 (Demystifying the context property)

julian

As of today, the NodeBB-ActivityPub implementation now supplies both context and audience properties with every post.

N.B. When I say context and audience, 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-level as:Note object (a federated NodeBB post), resolvable as an as:Collection or as:OrderedCollection. The latter is what NodeBB will send, ordered by post time.

Discussions with @[email protected] 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

julian

@[email protected] 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.

infinite love ⴳ

@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 ⴳ

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