FEP 11dd: Context Ownership and Inheritance

The object SHOULD inherit a context other than its own.

I don't quite understand what "its own context" means here. Do root (top-level) objects have their own contexts?

When publishing an object with a context property outside the local domain, the context owner SHOULD be addressed (to, cc, bto, bcc).

I think the owner should be addressed even if the context is local, because to and cc are important for access control.

silverpill@mitra.social You’re right! I should be clearer in my wording on both those points

> I don’t quite understand what “its own context” means here.

This line was lifted from an earlier draft where additional examples of defining ones own context, removing a context, or inheriting a context, is spelled out explicitly.

I realized after drafting that that was already more or less described in 7888 and so brevity won out.

I will need to reword that.

@julian i am still kind of confused what this fep adds over 7888 which already describes ownership and inheritance. i guess upgrading some SHOULDs to MUSTs? which i don't think are actually MUSTs in practice... any missing info can be skipped over.

Good question — in my opinion, 7888 serves as a gentle introduction into the entire concept of conversational contexts. It’s meant to be descriptive in order to capture the variety of existing implementations of context that are found in the wild (e.g. Pleroma context which doesn’t resolve, contexts that are not URLs, etc.)

Each subsequent FEP “down the tree” (or up, depending on how you look at it) narrows the scope and upgrades verbiage in order to enable additional functionality.

Specifically pertaining to 11dd:

• Ownership is explicitly defined and is now a requirement, 7888 mentioned attributedTo and context ownership as examples only.
  • This upgrade was done to set the stage for subsequent FEPs for forking, merging, moving, etc.
• Activities should be sent to the context owner. This is identical to 7888, but re-stated as a reminder.
• A specific recommendation for inheritance is included (adopt the immediate parent’s context, more if able), while 7888 allows for one to drop context altogether, inherit, or create your own.

This is not to say that 7888 is deficient in any manner. On the contrary, it’s working entirely as intended!

In practice, Lemmy has adopted 7888, but at this time will not adopt 11dd. nutomic@lemmy.ml creates a context local to the instance, for each post because each instance is expected to be the canonical representation of the context, even if they are cached representations of remote federated content.

It means it would preclude Lemmy from adopting further upgrades like forking/merging/moving/locking, but it doesn’t mean they are wrong in doing so.

trwnh@mastodon.social