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 (@[email protected]) 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 (@[email protected]) 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.
@[email protected] @[email protected] @[email protected] 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
- It defines a new property,
thread, to identify the conversation thread of an object, instead of thecontextproperty, which can be used for other things besides threading. - It uses an existing type,
OrderedCollection, for the thread, instead of creating a new type. - It defines a
rootproperty to quickly navigate from a thread collection to the root object. - The thread contains objects that point to each other using the
inReplyToproperty.
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
- It defines a new property,
@erincandescent @julian @darius it’s covered in the doc, which is free to read!
@erincandescent @julian @darius great. You can definitely use both.
contextis 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.
@erincandescent @julian @evan it does mention the @context name collision which is imo a real point of confusion
@erincandescent @julian @evan can you give an example of the “context” property in use?
@[email protected] @[email protected] @[email protected]
curl -H "Accept: application/ld+json" https://akko.erincandescent.net/objects/6d40d43e-9929-4bf9-9a9b-725ef3a682cd | jq{ ... "context": "https://community.nodebb.org/topic/18328", "id": "https://akko.erincandescent.net/objects/6d40d43e-9929-4bf9-9a9b-725ef3a682cd", "inReplyTo": "https://cosocial.ca/users/evan/statuses/113250578296473665",@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.
@[email protected] @[email protected] 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).
@[email protected] @[email protected] keep in mind we’re talking about
as:contextand not@context
@erincandescent @julian @darius you can also file an issue here:
@silverpill @darius @julian thank you!
