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
-
@_elena These are worrying times…
-
@devnull l'articolo però riguarda soprattutto i servizi privati, quelli in cui non è necessario individuare l'identità, ma solo l'autenticazione di accesso. È qui che si nota l'importanza della mancanza di tracciamento dell'identità degli utenti
-
@informapirata @privacypride non è che mi torni tanto. Il fatto che tengano alla tua privacy non significa che non sappiano niente di te, ma che non lo divulgano e fanno il possibile affinché i dati non finiscano in mani che non hanno ottenuto il tuo consenso a trattarli. Le aziende sanitarie sanno perfettamente chi sei, dove abiti e tutti i dati sanitari: secondo la logica che proponi allora violano la privacy ed è puro marketing?
-
@evan The last time I bought MS Office was 2010, and for last 8 years I’ve had no issue opening MS Files in LibreOffice, which also does heroic work opening my really old image files like Mac PICT.
-
Thanks, everyone! I have intentionally used the first three, and Pages launches every time I download a word processing file, so I think I used it this month, too.
-
Hackaday Links: December 21, 2025
It’s amazing how fragile our digital lives can be, and how quickly they can fall to pieces. Case in point: the digital dilemma that Paris Buttfield-Addison found himself in last week, which denied him access to 20 years of photographs, messages, documents, and general access to the Apple ecosystem. According to Paris, the whole thing started when he tried to redeem a $500 Apple gift card in exchange for 6 TB of iCloud storage. The gift card purchase didn’t go through, and shortly thereafter, the account was locked, effectively bricking his $30,000 collection of iGadgets and rendering his massive trove of iCloud data inaccessible. Decades of loyalty to the Apple ecosystem, gone in a heartbeat.
As for why the account was locked, it appears that the gift card Paris used had been redeemed previously — some kind of gift card fraud, perhaps. But Paris only learned that after the issue was resolved. Before that, he relates five days of digital limbo and customer support hell, which included unhelpful advice such as creating a new account and starting over from scratch, which probably would have led to exactly the same place, thanks to hardware linking of all his devices to the nuked account. The story ends well, perhaps partly due to the victim’s high profile in the Apple community, but it’s a stark lesson in owning your digital data. If they’re not your computer, they’re not your files, and if someone like Paris can get caught up in a digital disaster like this, it can happen to anyone.
Hackaday isn’t the place readers normally turn to for fiction, but we wanted to call attention to a piece of short fiction with a Hackaday angle. Back in June, Canadian writer Kassandra Haakman contacted us about a short story she wrote focused on the 1989 geomagnetic storm that temporarily wiped out the electric grid in Québec. She wanted permission to quote our first-hand description of that night’s aurorae, which we wrote a bit about on these pages. We happily granted permission for the quote, on condition that she share a link to the article once it’s published. The story is out now; it’s a series of vignettes from that night, mostly looking at the disorientation of waking up to no electricity but a sky alive with light and energy. Check it out — we really enjoyed it.
Speaking of solar outbursts, did 6,000 Airbus airliners really get grounded because of solar storms? We remember feeling a bit skeptical when this story first hit the media, but without diving into it at the time, cosmic rays interfering with avionics seemed as good an explanation as anything. But now an article in Astronomy.com goes into much more detail about this Emergency Airworthiness Directive and exactly what happened to force aviation authorities to ground an entire fleet of planes. The article speaks for itself, but to summarize, it appears that the EAD was precipitated by an “uncommanded and limited pitch down” event on a JetBlue flight on October 10 that injured several passengers. The post-incident analysis revealed that the computer controlling the jet’s elevators and ailerons may have suffered a cosmic-ray-induced “bit flip,” temporarily scrambling the system and resulting in uncommanded movement of the control surfaces. The article goes into quite some detail about the event and the implications of increased solar activity for critical infrastructure.
And finally, if you’ve been paying attention to automotive news lately, it’s been kind of hard to miss the brewing public relations nightmare Toyota is facing over the rash of engine failures affecting late-model Tundra pickups. The 3.4-liter V6 twin-turbo engine that Toyota chose to replace the venerable but thirsty 5.7-liter V8 that used to power the truck is prone to sudden death, even with very few miles on the odometer. Toyota has been very cagey about what exactly is going wrong with these engines, but Eric over at “I Do Cars” on YouTube managed to get his hands on an engine that gave up the ghost after a mere 38,000 miles, and the resulting teardown is very interesting. Getting to the bottom of the problem required a complete teardown of the engine, top to bottom, so all the engineering behind this power plant is on display. Everything looked good until the very end; we won’t ruin the surprise, but suffice it to say, it’s pretty gnarly. Enjoy!
-
You're not a Vim user, @monnier ? 😉
Do you really manage to avoid using a word processor at all?
-
@disorderlyf @mullvadnet it was the danish government pushing this last time, not the EC motu proprio
