FEP-7888: Demystifying the context property

[trwnh]

@devnull

One thing I want to point out is that the current implementations set as:context, the context resolves, but resolves to an OrderedCollection.

Are we considering that this is no longer an accepted implementation of 7888, or can this still be accepted, as backfill is already working in-practice between a number of implementors

See fep/fep/2931/fep-2931.md at main - fediverse/fep - Codeberg.org and its discussion thread FEP-2931: Representing context with a Collection for this usage.

I think 7888 is more general than just “backfill” and therefore it straddles a line between “informational” and “implementation”. Right now, 7888 is a bundle of recommendations:

• SHOULD have purpose
• SHOULD resolve
• SHOULD have an associated Collection of things included in a context (as acknowledged by a moderator), which MAY be signaled by context.type
  • SHOULD NOT assume an object is included in such a Collection just because it declares context / SHOULD make effort to verify inclusion / SHOULD treat claims as unverified by default
• SHOULD consume objects sharing the same context in the same processing context
• MAY set same / different / no context when interacting with an object that has context
  • SHOULD notify context.attributedTo and maybe context.followers

I want to caution against the view that context MUST be a Collection, since this is too restrictive. It would be like saying audience or to or cc must be a single Collection. Rather, one should think of context as an object that provides a reason or purpose for existing to the current object. In a lot of cases today, that purpose is threading (insofar as the thing you’re looking at is a “post”, it might exist in a “conversation”). Think of it as a way to construct a bag of things that belong together.