The full minutes from the Forum and Threaded Discussions Task Force monthly meeting (held on 7 November) can be found at this Google Docs link
Apologies in advance if I misrepresented anybody or missed any crucial bits of information.
Of note:
SWICG ForumWG GitHub repo used to keep track of high level discussion items
- Repo url: https://github.com/swicg/forums
- Issue tracker contains details regarding high-level items discussed at monthly meetings (and on the fediverse between meetings)
- Very early draft report of Conversational Contexts in ActivityPub accessible at https://swicg.github.io/forums/ — just headers and an intro so far
Mastodon and its treatment of non-note items
- Darius Kazemi (@darius@friend.camp) of Hometown put together a light fork of Mastodon that could be merged upstream. It utilises the “read more” functionality to display longer-form content and runs the content of non-note objects through the same parsing that regular notes get.
- Emphasizes that it is not an open PR yet, while discussions are ongoing with Renaud and the Mastodon team. “This is 118 lines of code, touches 4 files. Not huge.”
- Some edge cases: How do we handle additional media beyond the cap of 4 currently in place by Mastodon?
- Emelia (@thisismissem@hachyderm.io) also brings up concerns re: text-field length and a sensible maximum across implementations.
- Evan (@evan@cosocial.ca) brings up the possibility of this PR making it into Mastodon 4.4, Claire (@claire@sitedethib.com) acknowleges the possibility
- Darius will write up a summarization and demo video for presentation to the Mastodon team
FEP 7888 and 76ea
- There are still outstanding conflicts between FEPs 7888 and 76ea
- Beyond the main difference (7888 uses
as:context, 76ea usesthr:threadsunder a new namespace), some philosphical differences persist. - e.g. whether the 76ea’s definition of an explicit “reply tree” is adequate to describe the multitude of shapes that a conversation can take
- Beyond the main difference (7888 uses
- a (@trwnh@mastodon.social) and Evan informally pledge to work together to come to a resolution
Voting re: FEP convergence
- A motion was made by Julian to defer a subsequent motion regarding FEP convergence to a later to-be-determined date pending resolution of the 7888/76ea conflict
- Majority abstained, with two ayes. Resolved.
Context collection items: activities or objects?
- Julian: should a resolvable context collection contain activities (create, like, EmojiReact, etc.), or simple objects?
- Evan makes the case that simpler is better (needing to diff. activities may present a complication for implementors)
- a suggests a reframing as a two-way negotiation of what gets declared vs. approved
- This topic was cut short due to timing
I need to chime in here because I guess it’s unclear why Mastodon handles Article-type objects the way it handles them. @Darius Kazemi, in case you read this, this should be interesting for you as well. For it all dates back to a “kerfuffle” between Mastodon and Hubzilla in 2017 when only these two supported ActivityPub.
All this is not due to the length of Article-type objects. It is due to their tendency of having extensive HTML formatting and Mastodon’s total refusal to support the latter, save for a tiny subset that was introduced with Mastodon 4.0 about two years ago.
For example, Mastodon does not support any embedded images. At all. Its HTML sanitiser removes them entirely. If you see images as file attachments under posts from Friendica or Hubzilla or (streams), it’s because Friendica, Hubzilla and (streams) themselves add images as file attachments to posts going out via ActivityPub in addition to embedding them. Without this step on their side, Mastodon wouldn’t show these images at all.
The first two Fediverse projects to adopt ActivityPub were Hubzilla in July, 2017, and Mastodon in September, 2017. Well into 2018, these two were the only projects to support ActivityPub. But they were as different as night and day, and they still are.
Hubzilla posts fulfill all criteria of Article-type objects: their length, their formatting, the presence of a title (not to be confused with the summary a.k.a. Mastodon’s CW) etc., and so Hubzilla started sending its posts as Article-type objects. Mastodon, however, kept stripping out any and all formatting from Hubzilla posts, leaving only the bare plain text. It also ignored the title and treated the summary as a content warning.
Mike Macgirvin, creator of Friendica and Hubzilla and still maintainer of Hubzilla, complained about this to Eugen Rochko, I think he even filed a bug report on Mastodon’s GitHub repository. Rochko staunchly refused to cooperate and include anything into Mastodon that isn’t old-school, purist, Twitter-style microblogging. Not even read-only. This went back and forth for a while.
And then, I guess in order not to look like Mastodon is completely and utterly butchering long-form content on purpose, Rochko introduced Mastodon’s current way of handling Article-type objects. Namely essentially not at all. Or rather, by linking to the original.
Macgirvin saw this as an attempt at spiting Hubzilla and effectively excluding any and all Hubzilla content from Mastodon and switched Hubzilla to sending its extensively formatted posts as Note-type objects henceforth. Mastodon still butchers them, but at least, Mastodon users don’t have to open each and every post and comment from Hubzilla separately to read them.
Fast-forward to 2023. Mario Vavti has been the Hubzilla maintainer since 2018. It was in 2023 that he released Hubzilla 9.0. It returned to Article-type objects by default, even for existing channels, with a per-channel (not per-post) switch to return to Note-type objects.
After the upgrade, complaints came in that Mastodon messes with Hubzilla posts now. At this point, Hubzilla had all-but forgotten how Mastodon treats Article-type objects. Hubzilla 9 with its Article-type objects brought it back to memory and proved that Mastodon had changed nothing about its treatment of Article-type objects.
Vavti promptly rolled out a hotfix that hard-coded Hubzilla back to Note-type objects only and defeated the per-channel switch. He vowed to not have Hubzilla send Article-type objects for as long as Mastodon refuses to display Article-type objects with full HTML rendering. The switch was removed in Hubzilla 9.1.
So the appropriate way for Mastodon to support Article-type objects can only include no longer “sanitising” all the formatting out of them and finally allowing a much, much larger subset of HTML formatting, explicitly including an unlimited number of embedded inline images.
@jupiter_rowland very helpful context, thanks.
One problem here is the “unlimited” in your last sentence. Mastodon servers cache and rehost images to protect the IP address of individual users. This means that an unlimited number of images opens up to an unlimited hit to the media storage cache. My plan is to make it some larger-than-4 but bounded number like 20. Then we need to figure out a way to indicate to the reader that there are further images you need to go to the original post to see.
@julian looks pretty accurate, though:
> Have already seen interop issues with character limits
was specifically in reference to reports where content-length validations bit us as a bug.
@julian oh and: “T&S task force working on codifying how summary should be used”
We’re actually working on a proper property for content warning / labelling, instead of using summary.
