Minutes from 4 September 2025 WG Meeting
Forums and Threaded Discussions Task Force
1
Post
1
Autori
0
Visualizzazioni
-
Apologies in advance if I misrepresented anybody or missed any crucial bits of information.
- Jesse Karmani (jesseplusplus@mastodon.social), Ted Thibodeau Jr. (tallted@mastodon.social, and Julian Lam (julian@activitypub.space) in attendance
- Julian provided an update on adoption of FEP 7888
- Both Piefed and Lemmy have adopted 7888, and will begin publishing resolvable context collections in their next release
- Jesse opened a PR to Mastodon, which received preliminary approval from Gargron@mastodon.social (ed. it was later merged, rolled back, updated, a new PR opened, which was then merged)
- This PR is the first of two planned pull requests.
- The first generates the outgoing context (the same as what Lemmy/Piefed have done recently)
- The seconds handles incoming contexts and backfills
- Jesse was asked whether it would conflict with existing reply-tree crawling methods, but the two are complementary. She expects additional discussion before the PR is opened.
- Julian noted that it would be helpful if statistics/analytics were gathered by the Mastodon team to see how conversation contexts and backfill works at scale; admits that existing implementations and testing has been small scale and may not reflect real-world usage.
- Julian noted that Lemmy's implementation (nutomic@lemmy.ml) does not paginate their resolvable context implementation. All objects are listed in one
OrderedCollection- Jesse noted that she followed Mastodon's pagination convention for collections.
- Context inheritance
- Julian asked for opinions on whether contexts were inherited in existing implementations. Notes that NodeBB inherits parent context, but checks further up the known parent chain for further contexts
- Julian admits that not everybody can and should do this, is also not sure anymore whether NodeBB actually does this.
- Julian notes the ideal implementation would be every object referencing their immediate parent, which would lead to the entire collection referring to the same context collection.
- Jesse: Decodon inherits immediate parent context only
- Ted: notes that this is a reinvention of
inReplyTo - Julian and Jesse note that there are marked differences between crawling the reply chain.
- A short discussion about how netnews and usenet handled reply chains was had.
- Julian notes that Lemmy will not inherit context. Every object will point back to its own server's context collection. This was a conscious decision by Nutomic as each instance is meant to consider its own representation of remote content as the canonical representation
- ActivityPub.Space
- Julian made a short shout-out to a new site called ActivityPub.Space, meant to be a hub for AP development discussions ("A federated space for ActivityPub discussions so that they don’t just get lost in ephemeral replies")
- A short double-back to NNTP and how they approach "eventual consistency"
- Ted: “Cloud of NNTP servers are all hosts of articles and replies.”
- Strictly speaking it’s not a reply tree as replies can be inReplyTo multiple parents
Gli ultimi otto messaggi ricevuti dalla Federazione
-
Apologies in advance if I misrepresented anybody or missed any crucial bits of information.
Jesse Karmani (jesseplusplus@mastodon.social), Ted Thibodeau Jr. (tallted@mastodon.social, and Julian Lam (julian@activitypub.space) in attendance Julian provided an update on adoption of FEP 7888 Both Piefed and Lemmy have adopted 7888, and will begin publishing resolvable context collections in their next release Jesse opened a PR to Mastodon, which received preliminary approval from Gargron@mastodon.social (ed. it was later merged, rolled back, updated, a new PR opened, which was then merged) This PR is the first of two planned pull requests. The first generates the outgoing context (the same as what Lemmy/Piefed have done recently) The seconds handles incoming contexts and backfills Jesse was asked whether it would conflict with existing reply-tree crawling methods, but the two are complementary. She expects additional discussion before the PR is opened. Julian noted that it would be helpful if statistics/analytics were gathered by the Mastodon team to see how conversation contexts and backfill works at scale; admits that existing implementations and testing has been small scale and may not reflect real-world usage. Julian noted that Lemmy's implementation (nutomic@lemmy.ml) does not paginate their resolvable context implementation. All objects are listed in one OrderedCollection Jesse noted that she followed Mastodon's pagination convention for collections. Context inheritance Julian asked for opinions on whether contexts were inherited in existing implementations. Notes that NodeBB inherits parent context, but checks further up the known parent chain for further contexts Julian admits that not everybody can and should do this, is also not sure anymore whether NodeBB actually does this. Julian notes the ideal implementation would be every object referencing their immediate parent, which would lead to the entire collection referring to the same context collection. Jesse: Decodon inherits immediate parent context only Ted: notes that this is a reinvention of inReplyTo Julian and Jesse note that there are marked differences between crawling the reply chain. A short discussion about how netnews and usenet handled reply chains was had. Julian notes that Lemmy will not inherit context. Every object will point back to its own server's context collection. This was a conscious decision by Nutomic as each instance is meant to consider its own representation of remote content as the canonical representation ActivityPub.Space Julian made a short shout-out to a new site called ActivityPub.Space, meant to be a hub for AP development discussions ("A federated space for ActivityPub discussions so that they don’t just get lost in ephemeral replies") A short double-back to NNTP and how they approach "eventual consistency" Ted: “Cloud of NNTP servers are all hosts of articles and replies.” Strictly speaking it’s not a reply tree as replies can be inReplyTo multiple parents
