The full minutes from the Forum and Threaded Discussions Task Force monthly meeting (held on 5 December) can be found at this Google Docs link
The minutes are also inline below.
Apologies in advance if I misrepresented anybody or missed any crucial bits of information.
December 2024 Minutes
Forum and Threaded Discussions Task Force
---
Housekeeping
Julian noted that the event description in the SWICG calendar calls for a monthly meeting from 1700 to 1800 UTC, although the scheduled time is pegged to 1300 to 1400 Eastern Time (observing DST).
Dmitri (absent from meeting) to update event description
as:Article and Mastodon treatment of non-notes
Darius provided an update – been under the weather and busy with some other work-related items, but:
Mastodon team cautiously optimistic about upstream PR, some concerns were voiced over things like inline images
Hopefully by next month will have something more concrete to show to them; re: demo package
Evan (@
[email protected]) planning to get some people together in-person, to work together at FOSDEM in Brussels (Feb 2025); specifically to address long-form text issue
Discussions about this in the task force would be considered the crucial pre-work
Darius will update the group if something happens before January (re: code or PR package)
A test instance up and running, Darius plans to make it more accessible for others to check out
Silverpill’s FEP 171b is now an official draft, open for comments on SocialHub
No specifics, just a news item.
Context collections FEP Convergence
Rationale for recommendation outlined in meeting agenda.
Evan (@
[email protected]) and a (@
[email protected]) met up just prior to the WG meeting to discuss and work out differences between their FEPs; main notes:
Using context to represent a reply tree is good
Restricting usage of context is not the goal of 7888 or the ForumWG
Co-exists well with 76ea’s thr:thread property to denote a reply tree, etc.
Recommending use of as:context is one good way forward
Evan recommends that the “should” in the proposal be changed to a “may”
PROPOSAL: Publishers SHOULD use `context` for grouping related objects in a thread (but this is not the only way to use context).
RESOLVED with 8 ayes, no nays, and no abstentions
Brainstorming focus items for 2025
Emelia (@
[email protected]) – multiple contexts?
a (@
[email protected]) : we need to also handle the fact that some contexts may not resolve
Emelia: as:context can be an array of values in JSON-LD
a: inReplyTo can have multiple values too; but in general, on the producing side we generate a single value – generally expect context/thread to remain the same (singular values)
Sebi: "we thought a lot about multiple contexts" - led us to the conclusion of using profiles/describes property; per spec can only have one value
Julian: Handling when implementors (e.g. lemmy/piefed) don't have the concept of topics
a: there are multiple different models of how items are grouped together; reply tree model works for large part of the fediverse; mastodon has concept of reply tree represented internally as a conversation (vs context); this could be expanded into a conversation having an owner, etc.; mastodon has the conceptual ground to build upon
Evan: reply trees work well on microblogs, blog comment trees, threaded posting systems, forums; other applications expect a more serial model... messenger/chat systems, where ordering of objects is not in a tree, no explicit relation between them; hashtags, locations, few other ways to use context
Emelia: clarify overlap between replies collection and context collection?
a: in general will include both ancestors and descendants; could add filters, look at tags, etc. to get subsets. If you are querying by context, you are looking for all objects related by said context
Evan: full tree
Julian: Mastodon reply-tree service proposed (https://github.com/NeuromatchAcademy/mastodon/pull/44)
Julian: worried about scalability and performance of a backend service iterating through an entire reply tree; advocates that retrieving as:context is more performant especially if we build in some tooling for synchronization and member checking
Emelia: historical reports of harassment due to `inReplyTo`; when looking at context including descendents, then how do we generate the tree?
Evan: fep 76ea goes into detail about how reply trees can be managed
a: answer is "who has the authority?"; who decides what goes into the collection? the `attributedTo` actor. For the replies collection, this exists IN PARALLEL TO `context`; in some ways a subset of the thread; could be a point of contention for systems that expect all objects to exist in general vs. conversation oriented
Julian: upends expectation that objects are independent
Darius: does this relate to announce leaking? recommendations that you not forward the entire object, just the ids
Emelia: related but different; announce leaking -- should only ever do objects by ref (by the id)
a: the paradigm shift is more social rather than technical -- that you cannot just rely on inReplyTo to prove that an object is approved
some duplication as context includes replies, but they are distinct collections. They are decided by different authorities. `replies` is decided by whoever wrote the post
Ted (@
[email protected]): This sounds a lot like reinventing netnews, without taking the lessons that were learned from it; blurring the ideas of message store/relay/display; for all of this to work, the system has to pick up all replies, and let the client filter.
Julian/a: anything specific to share? lessons, etc. – definitely of interest in not repeating the same mistakes
