Minutes from 6 November 2025 WG Meeting
Uncategorized
15
Posts
4
Posters
50
Views
-
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
contextproperty 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
btoandbcc. - Julian asks if anybody uses
btoandbcc, 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
Afederates context/topic/1, NodeBBBreceives the topic and assigns it/topic/4bdffa.AlaterRemoves the context.Bdoesn't know whatA/topic/1is so needs to resolve it, get its' root post, and see if it matches any know context onB, 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 steps through an example. NodeBB
- Julian (myself) and Ted (tallted@mastodon.social) began the session discussing moderation tools in USENET
-
Pinging related users for visibility: trwnh@mastodon.social silverpill@mitra.social melroy@kbin.melroy.org angus@socialhub.activitypub.rocks jesseplusplus@mastodon.social
-
Seems like the conclusion is missing
-
trwnh@mastodon.social ForumWG moving toward recommending that the root node's
contextMUST 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.
-
Seems like the conclusion is missing
sabrew4k3@lazysoci.al indeed, we ran out of time :smile:
-
sabrew4k3@lazysoci.al indeed, we ran out of time :smile:
Ah, makes sense. But 🤬 you all. I was reading and it was gripping and then cliffhanger! 😭
-
Ah, makes sense. But 🤬 you all. I was reading and it was gripping and then cliffhanger! 😭
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!
-
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
btoandbccare 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.
-
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!
Thank you. I appreciate that.
-
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. -
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
btoandbccare 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.
@silverpill @julian @forum-wg @dmitri
POST to inbox instead of sharedInbox implies bto/bcc if the inbox owner is not present in to/cc.
what this has to do with threaded discussions i'm not sure, but for delivery and signing, SMTP has the same issue which they solved by making delivery *not* depend on the payload headers but instead on the SMTP envelope (there is a RCTP TO instruction in the SMTP connection, specifying inboxes that should receive the payload)
-
@julian @jesseplusplus i don't think that's the right way to look at it. the reply tree and the context are separate things. you can *try* to find the root of the reply tree, but even if you do, there is no hard requirement to copy that context vs any other context. you get to choose which conversation you want to be a part of, including choosing *not* to be part of a conversation. also, any id may be equivalent to other ids. what you want is to arrive at the same information.
-
@julian @jesseplusplus i don't think that's the right way to look at it. the reply tree and the context are separate things. you can *try* to find the root of the reply tree, but even if you do, there is no hard requirement to copy that context vs any other context. you get to choose which conversation you want to be a part of, including choosing *not* to be part of a conversation. also, any id may be equivalent to other ids. what you want is to arrive at the same information.
@julian @jesseplusplus so generally creating your own context is something you'd want to do if you e.g. "fork" the thread, but you can also be like what lemmy is proposing and just always create your own local context, as long as you give consumers a way to link/merge equivalent contexts together (via something like as:alsoKnownAs or owl:sameAs, or otherwise something like rel=canonical)
-
@julian > strict inheritance of the root object's context
only if the "root" (of the reply tree, i assume) has the same context you want to participate in. there are plenty of situations where you *don't* necessarily want to do this. replies can cross contextual boundaries, so you need to account for this.
-
@julian > strict inheritance of the root object's context
only if the "root" (of the reply tree, i assume) has the same context you want to participate in. there are plenty of situations where you *don't* necessarily want to do this. replies can cross contextual boundaries, so you need to account for this.
trwnh@mastodon.social Yes, you're right. There are nuances and situations where you would explicitly not want to inherit the root object's context.
I am dealing with the typical day-to-day use case of replying to an object with the expectation that is be part of the same existing context.
However I am more than happy to make this clear in the FEP and spell out alternative situations where context inheritance would not apply.
The situation I found myself in was one where anybody can (and does) include whatever context they want. In that case, it's difficult to determine whether disparate contexts are actually referring to a common set of the same objects, or whether they were disparate on purpose (i.e. a fork.)
To that end, it meant that as a receiver there was no guarantee that any contexts I'd be sent would map to any contexts I know.
Strict root-level inheritance for the common use-case would at least disambiguate a lot of this.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@atoponce i think that would be awesome!
-
@MattHatton lol you're joking, Northern Sydney is beautiful.
-
@MattHatton what's the right side of Sydney?
-
@cowlet @scruss and yes this does lead to fuzzy areas such as amateurs playing with professional rules or in tournaments of different officiality, or at least to some varying degree of playfulness: the more personally one plays, the less of a game it is.
2/2
-
@cowlet @scruss I'm perfectly fine with professional anything not falling into the “game” category. By name already, it is being done as a profession, not to entertain the player, even if the player does enjoy the activity, and yes, even if the rules of the subject are exactly the same (which in cases are not, as you need additional implements e.g. to track time, or judges to validate moves, etc).
1/
-
-
Boicottiamo il turismo nell' Egitto assassino di Regeni
Terrore sul Nilo, un’italiana muore nella collisione tra due navi
-
Did you know that NaN stands for Not a NaN because it doesn't compare equal to itself?
