Picture order in post

Thu, 06 Apr 2023 23:40:07 +0200

adminsforum@hubzilla.org

Admin schrieb den folgenden Beitrag Thu, 06 Apr 2023 23:40:07 +0200

Picture order in post

When I post more than 4 pictures in post, only first 4 are visible in Mastodon. But in order from last one.

1. Who is responsible for such stupid behaviour?
2. How to avoid back order of pictures? (first is most interesting and not visible at all ?‍♂️)

show all 5 comments

Sat, 08 Apr 2023 22:19:02 +0200

Jupiter Rowland

jupiter_rowland@hub.netzgemeinde.eu

@ᄐpᄋrႷa၂ (nomadic, testing) #Hubzilla uses an optional server-side "app" for inbound and outbound #ActivityPub connections. It's named Pubcrawl, and it has to be activated for each channel by the owner. This, by the way, is why many Hubzilla newbies fail to connect to Mastodon: They don't know that they have to activate Pubcrawl first.

Anyways, what Pubcrawl does in this case is translate posts from the #Zot standard which Hubzilla uses to the ActivityPub standard and then send it to the ActivityPub connections of the channel. This also includes transcoding the BBcode markup into Rich Text because ActivityPub uses Rich Text for formatting.

Not everything is translated into Rich Text, though. Things that only work amongst instances that run anything based on Zot is not translated because instances based on ActivityPub wouldn't know what to do with it anyway. But everything that Rich Text could possibly cover from all kinds of text formatting to image embedding is translated.

The trouble starts with the implementation of Rich Text on the receiving end. Different #Fediverse projects use different subsets of Rich Text. #Mastodon, for instance, only knows embedded hyperlinks. Everything else is stripped away.

Embedded images are treated in special ways: Mastodon doesn't know embedded pictures either. So it converts them into file attachments, starting with the last picture in a post, and attaches them after the end of what it makes out of the post, one by one, until they are four. Mastodon can't handle more than four file attachments either. So from a post with more than four embedded images, only the last four are attached as files and in reverse order.

On top of that, Mastodon understands summaries. ActivityPub is pretty well capable of macroblogging with thousands upon thousands of characters, and the Friendica and Hubzilla devs had quite some influence on the development of ActivityPub due to their experiences, so summaries were included to protect people from walls of text. Mastodon, not requiring summaries for a maximum of 500 characters, uses the same functionality for content warnings.

However, Mastodon doesn't deem it necessary to warn its users about file attachments. Thus, files are being attached to converted posts after = outside the content warning. Also, since Mastodon already uses summaries for content warnings, automated content warnings à la Hubzilla, based on the content of posts, seem unnecessary, and so Mastodon doesn't have them.

The outcome of this is that Hubzilla users who don't really know what their posts end up looking like on Mastodon may post lewd pictures and put them behind two safeguards, namely a summary which states that this post contains something lewd and at least one word that should trigger the content warning app on channels where it's activated. If they've activated the "regularly posts saucy stuff" setting on their channels, they can additionally flag their uploaded pictures as naughty, thus having three safeguards.

And all three fail miserably on Mastodon. It doesn't have keyword-activated content warnings, it doesn't pull file attachments (including images) into summaries (= CWs), and it can't see the naughty flag on the images. So these lewd pictures end up below the CW'd "toot" in plain sight for everyone.

To sum this up: It works, but barely so.

Sat, 08 Apr 2023 23:38:21 +0200

Admin

admin@libera.site

@Jupiter Rowland This is terrible. ?‍?

Tue, 11 Apr 2023 16:09:08 +0200

hosh

hosh@hub.vikshepa.com

@Jupiter Rowland a very clear explanation - thanks. The support forum will be a goldmine for a future wiki.