this post was submitted on 04 Oct 2024
0 points (NaN% liked)

Forums and Threaded Discussions Task Force

0 readers
1 users here now

Discussion and announcements related to the SWICG Forums and Threaded Discussions Task Force.

This profile is a discussion forum category and shares content from users who post in its discussions.

founded 4 months ago
0
Minutes from 3 October 2024 WG Meeting (community.nodebb.org)
submitted 1 month ago by [email protected] to c/[email protected]
23 comments fedilink hide all child comments
 

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 context is 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.
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 1 points 1 month ago (3 children)

@julian @darius I started a new FEP to define a vocabulary specifically for threads.

https://codeberg.org/fediverse/fep/pulls/406

[–] [email protected] 1 points 1 month ago (3 children)

@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?

[–] [email protected] 1 points 1 month ago (2 children)

@erincandescent @julian @evan can you give an example of the "context" property in use?

[–] [email protected] 1 points 1 month ago (2 children)

@[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",
[–] [email protected] 1 points 1 month ago

@darius @evan @julian side note: Akkoma also emits a “conversation” property containing the same URL, which is JSON-LD mapped tohttp://ostatus.org#conversation. This is because Mastodon will pass-through the conversation property to replies, but doesn’t know about context. When Mastodon generates a Conversation tag (e.g. when its absent from the parent post), it stuffs a tag URI like tag:cosocial.ca,2024-10-04:objectId=26829720:objectType=Conversation into it. This is visible in evan’s earlier post

side side note: “conversation” is misdeclared as a “@value” and not “@id” property in Mastodon’s context. Oh well.

[–] [email protected] 0 points 1 month ago (1 children)

@[email protected] @[email protected] Right, it gets a little confusing when implementors inherit context from 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 context seems to be in line with 7888 (in that it's pointing back to the resolvable context provided by NodeBB).

[–] [email protected] 1 points 1 month ago (1 children)

@julian @trwnh When Akkoma originates a thread the context it populates it with doesn’t resolve.

However, fixing that is on my plate.

[–] [email protected] 1 points 1 month ago

@julian @trwnh (Well, I guess whether it resolves or not is a matter of semantics. Arguably it resolves… just, it resolves to a 404)

[–] [email protected] 0 points 1 month ago

@[email protected] @[email protected] keep in mind we're talking about as:context and not @context

[–] [email protected] 1 points 1 month ago (1 children)

@erincandescent @julian @darius it's covered in the doc, which is free to read!

[–] [email protected] 1 points 1 month ago (2 children)

@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)

[–] [email protected] 1 points 1 month ago (2 children)

@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.

[–] [email protected] 1 points 1 month ago (1 children)

@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.

[–] [email protected] 1 points 1 month ago (1 children)

@erincandescent @julian @darius I think the best followup might be commenting on the PR or filing an issue on Codeberg.

[–] [email protected] 1 points 1 month ago

@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?”

[–] [email protected] 1 points 1 month ago

@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 context so I mostly question the advantage of us having to deal with three conversation grouping properties for the indefinite future

[–] [email protected] 1 points 1 month ago

@erincandescent @julian @evan it does mention the @context name collision which is imo a real point of confusion

[–] [email protected] 1 points 1 month ago (1 children)

@[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

[–] [email protected] 1 points 1 month ago (1 children)

@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.
[–] [email protected] 1 points 1 month ago* (last edited 1 month ago)

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