Federation with Bookwyrm (hashtags, reviews) is essentially broken.

[fabiscafe]

Steps to reproduce the problem

1. Search for https://bookwyrm.social/user/fabiscafe/review/4317797 on your mastodon instance¹.
2. Open the post you found

¹ if nothing shows up, your instance doesnt federate yet with bookwyrm.social. For testing purposes try with: https://mstdn.social/@fabiscafe@bookwyrm.social/112290842038446134

Expected behaviour

It should show the full review, including title and text of the actual review

Actual behaviour

Currently it shows That I wrote a review, the title and a link to the review.

Detailed description

For comparison

on Bookwyrm (original source)

https://bookwyrm.social/user/fabiscafe/review/4317797/s/black-hanekawa-bakemonogatari-manga-mangade

On Misskey

https://misskey.io/notes/9s8fow68lolx00hp

On Mastodon

https://mstdn.social/@fabiscafe@bookwyrm.social/112290842038446134

As you can see mastodon is missing a lot of information. It also happens that the hashtags are not usable from mastodon. They do show up as clickable, but in the hashtag itself, the articles from bookwyrm do not show up. This works on misskey as well.

Mastodon instance

mstdn.social (all instances that federate with bookwyrm.social )

Mastodon version

4.2.8

Technical details

If this is happening on your own Mastodon server, please fill out those:

• Ruby version: (from ruby --version, eg. v3.1.2)
• Node.js version: (from node --version, eg. v18.16.0)

[JupiterRowland]

That's because BookWyrm sends posts as Article-type objects. And that's how Mastodon always renders Article-style objects.

Allow me to explain:

A post in the Fediverse is usually an object of one of two types.

There's the Note-type object. It's meant to be short with no frills. Basically akin to a tweet.

Mastodon toots are Note-type objects. Posts from all other microblogging projects in the Fediverse are Note-type objects. And Note-type objects are what Mastodon renders completely the best it can.

Then there's the Article-type object. It's defined as everything that's longer and comes with more features. It's mostly intended for blog posts. And blog posts can get very long, and they can get very frilly from text formatting to pictures embedded within the text.

Blogging projects like WriteFreely or Plume send Article-type objects, as does the ActivityPub plug-in for WordPress. And so does BookWyrm, mainly because book reviews tend to get a whole lot longer than Mastodon's 500 characters.

Now, Mastodon was conceived as a purist Twitter clone. As such, it must have been a design decision not to give Mastodon the ability to render elaborate blog posts in all their glory.

The next-best alternative would have been to render them the best Mastodon could, i.e. no text formatting whatsoever, a maximum of four previously embedded images ripped out of context and dangling below the post and the others discarded entirely. All with a link to the original that can only be found by seasoned users because it isn't a button in plain sight.

So Mastodon chose the third option: not to render Article-type objects at all. And link to them instead.

In order to fix your issue, Mastodon would have to look at the first option again and implement full support for long-form blogging, all the way to embedded images and Markdown's full set of text formatting features.

Alternatively, BookWyrm would have to switch to Note-type objects, angering Mastodon users, especially those using the official mobile app, by dumping "walls of text" of not rarely thousands of characters into their timelines.

[fabiscafe]

…
Mastodon toots are Note-type objects. Posts from all other microblogging projects in the Fediverse are Note-type objects. And Note-type objects are what Mastodon renders completely the best it can.
…
Now, Mastodon was conceived as a purist Twitter clone. As such, it must have been a design decision not to give Mastodon the ability to render elaborate blog posts in all their glory.

Thank you for pointing this out. I didn't knew this and this does make absolute sense. Is this also the reason posts wont show up in the search-by-hashtag?

The next-best alternative would have been to render them the best Mastodon could, i.e. no text formatting whatsoever, a maximum of four previously embedded images ripped out of context and dangling below the post and the others discarded entirely. All with a link to the original that can only be found by seasoned users because it isn't a button in plain sight.
…
So Mastodon chose the third option: not to render Article-type objects at all. And link to them instead.

Growing from the past I do understand that choice, but nowadays this means that people miss out a lot of things going on the fediverse by using mastodon. Not just things that pops up, but probably also things they want to search for. Driving people away from mastodon, just to find things on the fediverse.

Alternatively, BookWyrm would have to switch to Note-type objects, angering Mastodon users, especially those using the official mobile app, by dumping "walls of text" of not rarely thousands of characters into their timelines.

TBH, that's broken design already. If you look at the fediverse you have things like:

• https://buc.ci/abucci/p/1714078775.233506

Or by staying just on mastodon alone, people started to patch limitations a lot.

• https://mastodon.de/@ErikUden/111090133099920533
• https://dialup.cafe/@vga256/112332773860513029

My timeline is pretty full of this. So it might be worth spending some time on design to support Article-type objects so people downstream wont abuse Note-types even more, because they are forced to do it by mastodons current design. For example, render the first 500 characters, an additional link "read full article" as well as the social-media-preview of that link.

[PuercoPop]

In order to fix your issue, Mastodon would have to look at the first option again and implement full support for long-form blogging,

Another alternative would be to provide the same underlying entity in both object time. The note being a 'summary' of their corresponding article.

Ideally the object type to render would be determined by content negotionation but if that is not possible they can be served from different outboxes.

[JupiterRowland]

Thank you for pointing this out. I didn't knew this and this does make absolute sense. Is this also the reason posts wont show up in the search-by-hashtag?

Exactly. If it's an Article-type object, Mastodon completely ignores the post text body, and the hashtags are part of the post text body.

Or by staying just on mastodon alone, people started to patch limitations a lot.

Yes, you actually have to soft-fork Mastodon to offer more than 500 characters on your instance. And whenever an update comes out, you have to merge back and soft-fork again.

One thing can hardly be fixed, though, and that's image handling. I've recently learned that it isn't Mastodon that converts embedded images into file attachments. It's the other projects that can embed them, especially Hubzilla and (streams). They have to turn embedded images into attached images so that Mastodon accepts them in the first place because embedded images would fall victim to Mastodon's HTML "sanitiser", just like all text formatting did prior to 4.0.

So as long as vanilla Mastodon won't introduce full HTML rendering, those projects won't stop half-mangling their own content when sending it through ActivityPub.

So it might be worth spending some time on design to support Article-type objects so people downstream wont abuse Note-types even more, because they are forced to do it by mastodons current design.

Won't happen. That'd require full HTML rendering, and I can't see Mastodon ever introduce it, at least not anytime soon.

[kvibber]

it must have been a design decision not to give Mastodon the ability to render elaborate blog posts in all their glory.

Sure, but that doesn't mean design decisions should never be revisited.

Won't happen. That'd require full HTML rendering, and I can't see Mastodon ever introduce it, at least not anytime soon.

It wouldn't need full HTML rendering. Mastodon accepts some limited formatting coming in from other ActivityPub software now, not just plain text like it used to. And other projects sanitize the code in Article posts and still manage to display them.

There are a lot of degrees in between "display with perfect fidelity" and "refuse to display anything but a link."

[fabiscafe]

@kvibber

Sure, but that doesn't mean design decisions should never be revisited.

I agree with you on this. If this wont get another spin, I see one of 2 things happening over time.

1. Mastodon will become obsolete, because a huge portion of things are not visible by using it.
2. Article-type objects will become obsolete, because they wont show up on the most used ActivitiPub software and everything will be pushed as Note-type.

I however agree on @JupiterRowland that the formatting and image handling situation would not be solvable. Mastodon is not a blogging software and I believe this wouldn't fit into its general style. Nobody should join Mastodon to write blog-posts. Nobody should join Mastodon to read blogposts.

That said. A general possibility to 1. become aware of, 2. find via search and 3. see a preview would be the way to go in my opinion. Like I said, something like the first 200 characters, followed by a 'read more' kind of link and the usual social media card preview of the link. No formatting (or only what Note Types also support) or anything special.