FEP-7888: Demystifying the context property

[trwnh]

@eprodrom

If there’s an intention to include a link to a collection that contains the full replies tree from an original (no inReplyTo) post, using a very specific term in an extension namespace is a better practice.

The intent is that this is completely parallel and unrelated to replies.

@eprodrom

It’s perfectly OK to use context for this or any other use – that’s what it’s there for – but if you’re trying to define a new specification with clear semantics and functional interoperability, it’s better to define a new, specific term.

In “The existing definition” and its subheadings, I talk more about why context is used and what “context” means in various linguistic senses:

context exists to form a purposeful grouping, regardless of the specific purpose

I derive this from the definition of the AS2-Vocab term (emphasis mine):

The intended function is to serve as a means of grouping objects and activities that share a common originating context or purpose

Looking further into the intent, there is this Github issue in which James Snell describes context and audience (previously called scope) as similar properties (emphasis again mine): scope v context · Issue #300 · w3c/activitystreams · GitHub

The scope indicates that the audience for the note is only members of the Organization.
The to indicates specific people who should be actively notified.
The context indicates a larger context within which the note exists.

To be clear: scope is not access control… it is closely related to to/bto/cc/bcc in that a consuming implementation can use it to determine who it ought to display the content to. So, for instance, given the note example above, a consuming implementation may include the note on the activity timeline of anyone associated with the ‘My Employer’ organization, but it would only activity notify two individuals listed by the to property. The context property, on the other hand, has absolutely nothing to do with audience targeting. The above note is essentially saying, “This is a note that was created in relation to A Project. Make the note available to anyone in the My Employer organization but specifically notify John and Sally”

From another issue (emphasis mine): [Proposal] Drop `context` from AS Vocabulary to avoid confusion with `@context` · Issue #238 · w3c/activitystreams · GitHub

The context is really intended to allow objects and activities to be
logically grouped. For instance, in an enterprise setting, the context may
group activities by project while the scope would identify one or more
teams for which the activity is considered relevant, while the to/cc fields
are used to indicate specific individuals to notify.

So there’s plenty of precedent and design intent to use context for “purposeful grouping”. In the FEP, I contrast this with tags, which are a much looser relation:

The key property of such a tag is to signal a general, implicit association by reference. We might then consider a context to be an explicit association

context should be something that helps you process the activity or object. Ignoring the context may lead to misunderstanding the activity or object; the object or activity exists within that context.

Everything that follows from this point is a series of logical conclusions and progressive enhancements layered on top of each other:

• If there is no context, then there is nothing to do
• If there is a context, then use it for grouping
• If the context resolves, then use its id for grouping, and also you may want to look at that object and do something with it.
• If the context resolves to specifically a Collection, then use its id for grouping, and also you might want to look at that collection and do something with it.

Put another way, it’s a series of SHOULDs and MAYs intended to provide guidance on what to do with a context if you encounter one. Any functionality is in keeping with the intent of the term, the semantics of its definition, and its existing usage in fediverse implementations like Pleroma and (streams) – and since then, Discourse and NodeBB have adopted its usage along these lines. I could list these implementations within the FEP, but I don’t do this because there aren’t any hard requirements to comply with… just some guidance on how it could be used. I don’t really see a reason to define some specific term that doesn’t meaningfully differ from the existing term we already have. My hope with writing this FEP was merely to clarify the “intended usage” while clearing the air on the “intentionally vague” bit, which I believe was meant to caution against locking into any specific interpretation of what the value of context ought to be.