Minutes from 3 October 2024 WG Meeting
from julian@community.nodebb.org to swicg-threadiverse-wg@community.nodebb.org on 04 Oct 2024 18:12
https://community.nodebb.org/post/101250
from julian@community.nodebb.org to swicg-threadiverse-wg@community.nodebb.org on 04 Oct 2024 18:12
https://community.nodebb.org/post/101250
The minutes from yesterday's Forum and Threaded Discussions Task Force monthly meeting can be found at this Google Docs link
Apologies in advance if I misrepresented anybody or missed any crucial bits of information.
Of note:
Mastodon and its treatment of non-note items
- Darius Kazemi (@darius@friend.camp) reports that Hometown already supports improved conversion of non-note items (like
as:Article) into statuses, and that this serves as a working proof-of-concept towards getting this merged upstream into Mastodon proper. - We discussed briefly the Mastodon PR approval process and how it sometimes drives away contributions
- Darius emphasized the importance of showing real user support to facilitate the merging of pull requests.
Context Collections and FEP Convergence
- Julian proposed consolidating various FEPs (7888, 400e, 171b) to publish a unified recommendation.
- Evan (@evan@cosocial.ca) objected to the use of the "context" property in FEP 7888, advocating for a new vocabulary instead.
- The discussion included differing views on the utility of the context property and its historical usage.
- Darius utilized his data observatory (TBD) data set to hopefully prove that
contextis not a properly currently seeing any usage.
"Convenings" and Collaboration Initiatives:
- Darius, representing the Applied Social Media Lab, proposed organizing physical meetings to enhance interoperability in the fediverse.
- He will provide a blog post detailing the ActivityPub Data Observatory and related goals.
ActivityPub Trust & Safety Task Force
- A new task force will focus on protocol-level issues within ActivityPub, including proper content warnings and labeling.
- Meetings are tentatively scheduled for the second Tuesday of each month (starting November), with a call for input on scheduling.
threaded - newest
@julian @darius @evan I've been missing these meetings. When is the next and/or is there a calendar?
@librenews@mastodon.social Indeed! The meetings are listed on the SocialCG calendar, and here is the next meeting as scheduled
@julian @darius I started a new FEP to define a vocabulary specifically for threads.
https://codeberg.org/fediverse/fep/pulls/406
@evan @julian @darius How does the “thread” property differ from the “context” property which basically every implementer is already using and has been doing so for 6+ years?
@erincandescent @julian @evan can you give an example of the "context" property in use?
@darius@friend.camp @erincandescent@akko.erincandescent.net keep in mind we're talking about
as:contextand not@context@julian @darius @erincandescent self-referential: https://browser.pub/https://mastodon.social/@erincandescent@erincandescent.net/113250586247164172
@trwnh (same braincell!)
@erincandescent side note it is cool that browser.pub handles redirects seamlessly
@trwnh yeah i couldn’t remember the flag to pass to curl
@trwnh side note: this subthread is a totally perfect illustation of why being able to “fork” the thread would be useful.
@erincandescent right! it's not about replies at all, you can reply to something in a different thread, so it's wrong to define a "thread" as equivalent to a "reply tree"
@erincandescent@akko.erincandescent.net after we deal with conversational contexts we should probably define forking threads. I've been thinking on that a bit recently.
@julian @erincandescent likewise. my initial thought was using Move to signal something like "these 6 posts were moved to another thread by a moderator"
@trwnh @julian @erincandescent I guess there you'd need to look at Move and make sure the target/actor/objects weren't Actors but where other objects?
@thisismissem @julian @erincandescent yeah, honestly the existing use of Move for migrations is really unfortunate because you're saying "i moved myself from myself to another person" which makes no sense. it should have been defined some other way (Migrate activity? intransitive, takes `actor` and `target` but no `object`). Move makes more sense to manipulate collections (and that's the example provided in AS2-Vocab)
@trwnh @julian @erincandescent agreed, another FEP? 😂
@thisismissem @julian @erincandescent for Migrate, or Move? i think Migrate might not get much traction so idk if it's worth writing it up, and as for Move i think it makes sense for a FEP building off of the work of the forum TF or maybe even their final CG report. (there's a very skeletonized draft of fep-9988 "federated forums" still on my laptop, which was abandoned more or less when the forum TF was launched)
@trwnh @julian @erincandescent there is already a Move for migration FEP
@thisismissem @julian @erincandescent yeah, and it mostly describes existing practices rather than proposing any particular path forward
in any case i think the whole "migration" flow right now suffers from some poor semantics all around, and is actually one of the reasons we can't have nice things (proper support for alsoKnownAs instead of using it as a glorified rel-me)
so maybe i *will* write up a FEP anyway, even if no one implements it at least it would be recorded as a potential approach
@trwnh @thisismissem @julian For all that the current use of as:alsoKnownAs disagrees with its definition… I’m not sure that’s a problem (except for the need to amend the spec)
We have reasonably straightfoward ways to indicate “This is also me” (alsoKnownAs) vs “This is an exact alias for me” (xrd:alias)
@erincandescent @julian @thisismissem well the real problem is it has undefined implicit "real-world" usage in fedi... and then separately the DID WG tried to (re?)define it in DID Core. but there's already stuff out there in DID world that uses alsoKnownAs the way it's defined in DID Core!
@thisismissem @julian @erincandescent after some slight reconsideration i think i might hold off on a FEP because the bigger issue with migration and a so-called Migrate activity is that what i should *really* be doing is accounting for multihoming. in that sense, Migrate might not make too much sense. anyway i'm moving it to the "requires further thought" section of my todoist list
@erincandescent @trwnh so by my reckoning, Mastodon and Misskey don't use context, akkoma does... ugh, I need to add more sources to my observatory
@darius @trwnh and I believe Lemmy & co do? But I honestly haven’t followed them
@erincandescent @darius Lemmy uses `audience` instead, referring to the Lemmy community, which is a Group actor, and you're expected to look through the `outbox` and reconstruct replies on your own. the only hint you have is that the root of a reply tree is represented by an Announce Create Page.
good luck
@trwnh @darius :akko_AAH:
@trwnh@mastodon.social @erincandescent@akko.erincandescent.net
Arguably, when Lemmy uses
audiencethey mean one level of abstraction higher than we do (the community). Like Mastodon, Lemmy doesn't actively support the concept of a context... I think.cc @darius@friend.camp
@julian @trwnh @darius yeah I don’t really object to their use of audience to refer to a community here, its basically the same as
to: the communityor similarTheir non-use of context is… disappointing, but then much of how Lemmy uses AP is disappointing and Weird.
@erincandescent @julian @darius this reminds me i was going to write a FEP for addressing to signal when you should use to/cc/audience based on some archaeology i did https://socialhub.activitypub.rocks/t/overlapping-taxonomies-and-the-audience-property/4229/8
@julian @erincandescent @darius right, so Lemmy basically forces you to start one level higher and then work your way down, on top of all the reply-tree reconstruction you're expected to do from one big outbox haystack
it reminds me of how we should actually try to flesh out the concept of Group actors and maybe alongside it the concept of a Forum (bc they're not the same to me, there are differences that need to be called out)
@darius @julian @evan
@darius @evan @julian side note: Akkoma also emits a “conversation” property containing the same URL, which is JSON-LD mapped to
http://ostatus.org#conversation. This is because Mastodon will pass-through theconversationproperty to replies, but doesn’t know aboutcontext. When Mastodon generates a Conversation tag (e.g. when its absent from the parent post), it stuffs a tag URI liketag:cosocial.ca,2024-10-04:objectId=26829720:objectType=Conversationinto it. This is visible in evan’s earlier postside side note: “conversation” is misdeclared as a “@value” and not “@id” property in Mastodon’s context. Oh well.
@erincandescent@akko.erincandescent.net @trwnh@mastodon.social Right, it gets a little confusing when implementors inherit
contextfrom the objects they're replying to (or maybe the root node?), but that's exactly what 7888 tries to codify/demystify.But Akkoma's use of
contextseems to be in line with 7888 (in that it's pointing back to the resolvable context provided by NodeBB).@julian @trwnh When Akkoma originates a thread the context it populates it with doesn’t resolve.
However, fixing that is on my plate.
@julian @trwnh (Well, I guess whether it resolves or not is a matter of semantics. Arguably it resolves… just, it resolves to a 404)
@julian @erincandescent if you want your post to be in the same context as the thing you're replying to, then it's inherited from the thing you're replying to.
7888 also describes what could happen if you decide to set your own context, or set *no* context. in fact, this is how you would self-fork a topic.
@trwnh @julian (For people following along: I did a quote post experiemnt branching off form here that it seems NodeBB dropped on the floor)
@erincandescent @julian @darius it's covered in the doc, which is free to read!
@evan @julian @darius That doesn’t really cover the why other than “context is vaguely defined” (maybe, but its’ been used in this exact way for… 7 years now? And is being used in this way by multiple interoperating implementations)
@erincandescent @julian @evan it does mention the @context name collision which is imo a real point of confusion
@darius @erincandescent @julian @evan well, the json-ld keyword has an @ in front of it for a reason: https://www.w3.org/TR/json-ld11/#syntax-tokens-and-keywords
id and type got aliased but they're really supposed to be @\id and @\type: https://github.com/w3c/activitystreams/issues/232
other point of confusion re: @\context vs context was overruled: https://github.com/w3c/activitystreams/issues/238
@darius @erincandescent @julian @evan there was probably a time when `context` could've gotten renamed in the same way that `scope` was renamed to `audience`, but we're about 10 years too late on that discussion
@trwnh @darius @julian @evan I will be the first to admit that I’m not a massive fan of the “context” property name but given it is baked into likely billions of posts at this point I mostly feel it’s the lesser of two evils. If this were an misuse of the property that was blocking some preferable use (e.g. Mastodon’s abuse of the “summary” property for CWs) then I would agree that it would be worth dealing with the pain, but in this case I feel pretty much any use of the property would be better off picking a more specific name so we may as well grandfather the use of “context” for “conversational context” (which is a valid use, per the definition)
Truthfully the Original Sin here is the inclusion of such vaguely defined terms in the original AS2 specification
@trwnh @darius @evan @julian (I have converted these thoughts and a few more into an issue. It’s a bit strange to see discussion for a FEP moved to an issue tracker - for pretty much all of them historically a SocialHub thread has been made, and that has worked quite well)
@erincandescent @julian @darius @trwnh it was offered as an option and I vastly prefer being able to resolve question by question rather than a long conversation thread that doesn't ever finish.
@erincandescent @julian @darius great. You can definitely use both.
`context` is fine for any kind of grouping of objects, as is noted in AV.
https://www.w3.org/TR/activitystreams-vocabulary/#dfn-context
If you want to specifically talk about a conversation tree, a more specific property is better.
@erincandescent @julian @darius finally, if you'd like to talk to me as part of the Threads TF or even as part of the FEP process, where there's a code of conduct, I'd appreciate it if you dial back your derisive tone. It's not OK to talk to me or anybody else working on AP that way.
@erincandescent @julian @darius I think the best followup might be commenting on the PR or filing an issue on Codeberg.
@evan @julian @darius Would the same line of argumentation not apply for “Why is this a new FEP and not an issue raised against FEP-7888?”
@evan @julian @darius I don’t really have a horse in this race but we’ll probably never get rid of the existing use of
contextso I mostly question the advantage of us having to deal with three conversation grouping properties for the indefinite future@evan @erincandescent @julian @darius I can leave this as a comment on the PR or the issue tracker, but my position is that "conversation tree" is entirely the wrong way to look at it, because a "conversation" and a "reply tree" are not the same thing. You can fork the conversation, you can reply to something in a different conversation, and you can have your post moved to a different conversation. I could define a property for it, but my intent was to gracefully degrade to using it for grouping
@trwnh @erincandescent @julian @darius great, definitely comment.
@trwnh@mastodon.social Yes! Exactly... and one could prune a branch (and all of its descendents) off of a reply tree and plant it anew, making it a new conversational context.
Heck, while I'm abusing this analogy, one could even graft a branch onto another context's object!
... but let's not do that lest my brain explode.
@erincandescent @julian @darius you can also file an issue here:
https://codeberg.org/evanp/fep/issues
@evan @darius @julian Merged: https://codeberg.org/fediverse/fep/src/branch/main/fep/76ea/fep-76ea.md
@silverpill @darius @julian thank you!
@evan @julian @darius Quick question, and forgive me for my ignorance: how is this different from the proposal for Conversation Containers?
https://codeberg.org/silverpill/feps/src/branch/main/171b/fep-171b.md
@deadsuperhero @julian @darius
1. It defines a new property, `thread`, to identify the conversation thread of an object, instead of the `context` property, which can be used for other things besides threading.
2. It uses an existing type, `OrderedCollection`, for the thread, instead of creating a new type.
3. It defines a `root` property to quickly navigate from a thread collection to the root object.
4. The thread contains objects that point to each other using the `inReplyTo` property.
Having a separate thread property may be useful. One possible use case would be where threads or posts are labelled or categorized or placed in a list, and this is exposed as a context.
In that case, the thread and the context would be different.
cc: @Evan Prodromou @Sean Tilley @julian @Darius Kazemi