FEP 11dd: Context Ownership and Inheritance

[julian@activitypub.space]

This is a discussion topic for the aforementioned FEP.

FEP 7888 (trwnh@mastodon.social) defines the use of context to group reply-associated objects together.
FEP f228 (silverpill@mitra.social) defines how a context resolves to a collection of posts or activities, and how this can be used to backfill a conversational context.

This proposal aims to extend these guidelines further by codifying:

1. That a context declares an owner via context.attributedTo.
2. The situations where a context may be inherited by new objects.

This FEP is a descendant of 7888 and sits alongside f228.

Until it is merged into the main repository, this FEP can be viewed here:

https://codeberg.org/devnull/feps/src/branch/fep-11dd/fep/11dd/fep-11dd.md

[silverpill@mitra.social]

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.

[julian@activitypub.space]

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

[julian@community.nodebb.org]

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

[trwnh@mastodon.social]

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

[julian@community.nodebb.org]

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

[trwnh@mastodon.social]

@julian @nutomic i think it's unavoidable that at some point you will end up having to recognize that two context ids may be equivalent, perhaps with one of them being canonical. "cached representation of remote content" is fine and there isn't necessarily a problem there. it depends on how much you embrace the idea of each publisher being allowed to make their own claims (and how much you allow "clean up" after the fact)

[trwnh@mastodon.social]

@julian @nutomic for example, some impls attach replies even if they do not share the same context, as a compatibility measure. that kind of stuff

[julian@community.nodebb.org]

trwnh@mastodon.social Yes you're right, some messiness is bound to happen.

I'm not trying to force all implementations into a specific inheritance pattern, that's why it's a "should", not a "must".

Even then one of my concerns is that while in an ideal scenario, everybody inheriting their parent context leads to an entire collection all referencing the same context... in reality a lot of messiness will occur, objects will reference other contexts all over the place, etc.

At the end of the day it's best effort, and if we are able to handle all that and still get to a point where backfill is achievable, then that's a win in my books.

> it depends on how much you embrace the idea of each publisher being allowed to make their own claims (and how much you allow "clean up" after the fact)

Part of me would like this to not happen, but it is unavoidable.

[julian@activitypub.space]

I have amended the text of the FEP to clarify a couple of things, but also changed the inheritance logic following this month's WG meeting and subsequent discussion on ActivityPub.space.

Instead of recommending that replies inherit context from the object it is in reply to, implementors must find the root node (how, is out of scope; tree traversal or context resolution are two ways that come to mind) and inherit its context.

This will simplify context resolution and pave the way for other actions like moving, crossposting, forking, locking, etc.

I also added in a blurb about situations in which a context would explicitly not be inherited.