@julian So all this is just an elaborate ploy to convince Mastodon devs to display summary? It might make sense, but then I don't understand why it is presented as a protocol problem.

The FEP won't make any difference. I've spent of lot of time tweaking my software in order to make rich content look good across the Fediverse (including Mastodon), and I can confidently say that Long form text FEP is not helpful at all. It is a mix of obvious requirements (which are already present in AP & AS), some arbitrary recommendations (like the set of allowed tags), and bad ideas (like the preview property). This is because it is not written by a developer: the author simply doesn't know what needs to be done in order to render an article across 10 different implementations.

When it comes to long form content, the best resource is @helge 's support tables. For example, there is an analysis of what HTML tags are supported in Article.content: https://funfedi.dev/support_tables/generated/html_tags_article/

No one talks about this project, but it is far more useful than anything done so far by the so called "longformers".

@developer @mikedev @jupiter_rowland @feb

@silverpill Who are the longformers anyway?

They're those who either are commercial or looking for professional/commercial users or both. Flipboard. Automattic (WordPress). Ghost. These kinds.

They know themselves. They know each other. And they know Mastodon. And that's it.

None of them has ever heard of Pleroma or Akkoma.

None of them has ever heard of Misskey or the Forkeys.

None of them has ever heard of Mitra.

None of them has ever heard of GoToSocial.

None of them has ever heard of Hollo.

None of them has ever heard of Friendica, Hubzilla, (streams) or Forte, even though Friendica and Hubzilla are both older than Mastodon. And apparently, neither has @ Helge. But then again, Friendica and its nomadic, security-enhanced descendants are being overlooked by almost everyone. That's why there's always on-going work for features to be "introduced to the Fediverse" which Friendica has had for a decade and a half.

Granted, the HTML support on Friendica, Hubzilla, (streams) and Forte can be summarised with "yes". But elaborate tables that show what either of them supports how would be very useful.

Also, granted, everything I've mentioned above (normally) uses something else than HTML for formatting in the frontend. For example, Misskey and all Forkeys use MFM ("Misskey-Flavoured Markdown"). Friendica uses extended BBcode with the option to use Markdown instead. Hubzilla uses even more extended BBcode. (streams) and Forte can use the same even more extended BBcode and Markdown and HTML at the same time within the same post, although not all markup languages support all features.

# Long # LongPost # CWLong # CWLongPost # FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # Fediverse # Mastodon # Pleroma # Akkoma # Misskey # Forkey # Forkeys # Mitra # GoToSocial # Hollo # Friendica # Hubzilla # Streams # (streams) # Forte # LongFormContent # BBcode # Markdown # HTML # TextFormatting

@Strypey So Pleroma and Akkoma (which, for some reason, is missing from the list) actually use the ActivityPub C2S API to connect their frontends? Even though Pleroma predates ActivityPub and started out as an alternative GNU social frontend, much like Mastodon?

I mean, they're famous for having separate repositories for the server and the Web frontend (same name with "-FE" attached). And they're equally famous for having servers that forgo the official frontend in favour of third-party stuff, most notably Mangane.

So if Mangane actually makes use of that API rather than a homebrew *oma client API, it could be used as or, if need be, modified into a sparrings partner for API-testing purposes, not to mention that it's living proof that the API actually works. As it integrates with Pleroma and Akkoma that well, I've got my doubts that it only uses the Mastodon client API.

In the cases of (streams) and Forte which are almost the same software save for protocol support, the Web UI is much closer to the server backend, as flexible and modifyable it is. In their cases, the question would be whether they could be used to test just how far feature support in the ActivityPub C2S API can possibly go, maybe even whether it'd be possible to use the ActivityPub C2S API to build an almost fully-featured (streams)/Forte client app (except, of course, Web UI configuration and (streams)' per-channel ActivityPub switch which might cut the whole app off the server).

CC: @Tim Chambers @rakoo

# Long # LongPost # CWLong # CWLongPost # FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # Fediverse # ActivityPub # Pleroma # PleromaFE # Akkoma # AkkomaFE # Mangane # Akkomane # Streams # (streams) # Forte # API

@Tim Chambers I guess the main obstacle in development right now is that there are no clients to pair the server applications with and test them against.

Then again, it would take a whole lot of clients. One unified client that covers e.g. Pleroma just as neatly as (streams) is impossible, seeing as how extremely different the two are.

CC: @Strypey @ just small circles 馃晩 @ Ben Pate 馃馃徎 @rakoo

# FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # ActivityPub # Pleroma # Streams # (streams)