Minutes from 7 November 2024 WG Meeting
-
-
@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.
-
-
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.
-
@[email protected] In the interest of keeping the outgoing PR as small as possible, I would even kick the can down the road and keep it to 4 (postpone the discussion) for now.
Implementing something like this would be good enough for the time being
There are additional pictures in this post, click here to view the original article.
-
@[email protected] said in Minutes from 7 November 2024 WG Meeting:
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.
That is exactly what @[email protected]'s PR aims to accomplish. Core members of the Mastodon dev team (namely @[email protected] and @[email protected]) have been gracious enough to explore this opportunity to have Mastodon treat non-note objects with a kinder approach, one that we are more than happy to work with them on.
I bet that they are also tired of having the same conversations about handling non-note objects. I think I am already responsible for at least two of them
Will they support inline images? That is one point I expect to be sticky. We shall see.
One thing I will say is that Mastodon in the years since your history has expanded their support for long-form post content, which paves the way for moving the baseline behaviour even more so toward a level that other implementors would be happier with.
My end goal here is not that Mastodon should natively support every object type under the sun. However, other implementors should not feel the need to translate their content into
as:Notein order to be consumed by a significant portion of the fediverse.Nevertheless, thank you for providing your written history on the subject, it is always helpful to be reminded.
-
@Darius Kazemi The local caching of all media is one of Mastodon's "Achilles' heels", unfortunately. But I guess that's required if media files can only be handled as files attached to a post.
#FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Mastodon -
@julian Well, there are object types that Mastodon couldn't even handle if it wanted to. For example, it doesn't have anything to handle an Event-type object with. I don't think Gargron would build an event calendar into Mastodon just for Event-type objects, not unless enough people pester him to do just that.
#FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Mastodon
