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 uses thr:threads under 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
  • 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
  • Jupiter Rowland@hub.netzgemeinde.eu
    1·
    12 hours ago

    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.

    • Darius Kazemi@friend.camp
      1·
      5 hours ago

      @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@community.nodebb.orgOP
      0·
      4 hours ago

      @jupiter_rowland@hub.netzgemeinde.eu 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 @darius@friend.camp’s PR aims to accomplish. Core members of the Mastodon dev team (namely @renchap@oisaur.com and @claire@sitedethib.com) 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 :stuck_out_tongue:

      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:Note in 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.