Minutes from 6 November 2025 WG Meeting

[julian@activitypub.space]

Apologies in advance if I misrepresented anybody or missed any crucial bits of information.

---

• Julian (myself) and Ted (tallted@mastodon.social) began the session discussing moderation tools in USENET
  • There are comparable systems to how the threadiverse propagates content. Messages are sent to a remote server who is then responsible for distribution.
  • In relation to moderation, there was more ambiguity. Local users could set up their own kill file but whether moderation could be done from the remote server was not discussed.
• We discuss more about actions done to contexts (aka topics, threads)
  • Ted recommends a read through RFCs 2821 (SMTP) and 2822 (Internet Message Format)
  • Dmitri (dmitri@social.coop) joins at or before this point, and points out that there continues to be confusion over the context property and @context.
• Example actions are offered: Removing a context from an audience, and locking a context from new contributions
  • Re: crossposting, Ted discusses the need for implementor changes to allow for contexts to be a part of multiple audiences
  • ed: much of the discussion at this point shifts away from ForumWG terminology and toward email nomenclature for ease of understanding. ForumWG nomenclature is used for these minutes
  • Dmitri points out that a breaking change to AP might be needed in order to break apart header (addressing/recipients) and body
  • Julian asks why, and Dmitri mentions signing difficulties wrt bto and bcc.
  • Julian asks if anybody uses bto and bcc, and Dmitri says "yes, absolutely", and said we should check out darius@friend.camp's Fediverse Observatory for the answer
• Julian says that as currently implemented, resolvable contexts do not necessarily need to be inherited. Lemmy explicitly does not want to inherit contexts, and their published contexts always refer to a local representation (ping nutomic)
  • Julian steps through an example. NodeBB A federates context /topic/1, NodeBB B receives the topic and assigns it /topic/4bdffa. A later Removes the context. B doesn't know what A/topic/1 is so needs to resolve it, get its' root post, and see if it matches any know context on B, then act on it.
  • Ted and Dmitri caution that this is difficult and messy, and strongly recommend that the root-level context must be inherited

[julian@activitypub.space]

Pinging related users for visibility: trwnh@mastodon.social silverpill@mitra.social melroy@kbin.melroy.org angus@socialhub.activitypub.rocks jesseplusplus@mastodon.social

[sabrew4k3@lazysoci.al]

Seems like the conclusion is missing

[julian@activitypub.space]

trwnh@mastodon.social ForumWG moving toward recommending that the root node's context MUST be inherited is not incompatible with 7888 per se, but 7888 does allow for creating your own context.

I think this might be a blessing in disguise. In situations where the root node doesn't contain a context at all, then creating your own context has its place. I am not sure how this would work when you try to do moderation actions against a context that isn't really yours though.

I'm discussing this with jesseplusplus@mastodon.social right now.

[julian@activitypub.space]

sabrew4k3@lazysoci.al indeed, we ran out of time :smile:

[sabrew4k3@lazysoci.al]

Ah, makes sense. But 🤬 you all. I was reading and it was gripping and then cliffhanger! 😭

[julian@activitypub.space]

For what it's worth, Ted and Dmitri convinced me that we need to move toward a strict inheritance of the root object's context. It means a little more work upfront but will make it easier down the line.

This post is where we continue that discussion, asynchronously, so stay tuned!

[silverpill@mitra.social]

@julian

Julian asks if anybody uses bto and bcc, and Dmitri says "yes, absolutely", and said we should check out @darius@friend.camp's Fediverse Observatory for the answer

bto and bcc are not visible in S2S environment:

https://www.w3.org/TR/activitypub/#security-not-displaying-bto-bcc

This is a C2S feature, so maybe it is used by 2 or 3 people. I am all for removing it.

@dmitri

[sabrew4k3@lazysoci.al]

Thank you. I appreciate that.

[julian@activitypub.space]

Depending on the outcome of the ensuing discussion here, it looks like I will be updating FEP 11dd: Context Ownership and Inheritance away from:

> The object SHOULD inherit a context other than its own. It is RECOMMENDED that the object inherit the context of the object it is in reply to. Doing so will allow for all members of a context collection (per FEP f228) to refer to the same context.
>
> The object MAY inherit context further up the chain.

to

> The object MUST inherit the context from the root node, if one is reported. Otherwise the object MUST NOT publish a context. Doing so will allow for all members of a context collection (per FEP f228) to refer to the same context.
>
> Implementors SHOULD map that inherited context to a local identifier (if applicable) to support future use-cases/activities.