@ Anuj Ahooja This makes me wonder if a decentralised, anyone-can-host-it third-party bridge that's only a bridge would be feasible.

Of course, it'd be the easiest to integrate such a bridge directly into Fediverse server software. But we've only got so many multi-protocol Fediverse server applications right now already, and the only one that's still occasionally adding new protocols or even a bridge is Friendica. It is therefore the only Fediverse server software that can connect to Bluesky without Bridgy Fed.

CC: @ A New Social

# Long # LongPost # CWLong # CWLongPost # FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # Fediverse # Friendica # Bluesky

Hey, Filmmaker Fedi! We have some filmmaker friends who are thinking of joining the Fediverse. We'd like to help them find good homes.

Are there filmmaking or flim-friendly instances you'd recommend? Please let us know.!

@film @art

#Film#Filmmaking#FilmFedi #FilmMastodon#Flmmakers#AskFedi #FediMeta#MastodonMeta

Hey, Filmmaker Fedi! We have some filmmaker friends who are thinking of joining the Fediverse. We'd like to help them find good homes.

Are there filmmaking or flim-friendly instances you'd recommend? Please let us know.!

@film @art

#Film#Filmmaking#FilmFedi #FilmMastodon#Flmmakers#AskFedi #FediMeta#MastodonMeta

New #blog post:

"'Here's what I do' versus 'You should'"

A bit of a gripe about people who tell others what they should do.

https://neilzone.co.uk/2025/08/heres-what-i-do-versus-you-should/

#fedimeta#Linux#FOSS

@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

@silverpill

The dataset doesn't include some other popular platforms like Friendica, but I am sure they also display long form content just fine.

Friendica and its descendants from the same creator, Hubzilla, (streams) and Forte, can produce long-form content just fine. With just about all bells and whistles from a title plus six levels of headlines to an unlimited number of images embedded within the text.

So yes, they can display it as well. However, outside of their own communities, hardly anyone knows what they're capable of. Thus, Fediverse developers often try to solve problems that aren't even really there because they were solved before they became problems.

Mastodon's lack of support for articles, linking to the originals instead, is not really a lack. It's a deliberate design decision from around 2017 or so.

See, the first ActivityPub implementation was on Hubzilla. That was in July, 2017. And Hubzilla implemented ActivityPub by the book.

Mastodon followed two months later. But Mastodon has always had its own "interpretation" of ActivityPub that was limited by Mastodon's own intentional design limitations in order to remain Twitter-like, purist, minimalist, old-school, original-gangsta microblogging with as few features that Twitter didn't have as possible.

This is also why Mastodon has a HTML "sanitiser" built in. Up until the release of Mastodon 4.0 in October, 2022, that "sanitiser" reduced any and all incoming HTML to plain text. And it did so for all object types, including the Article-type objects which Hubzilla sent. After all, Hubzilla can act as a fully-fledged long-form blogging platform.

However, the ActivityPub spec defines Article-type objects as formatted long-form content. Still, Mastodon defaced Hubzilla's Article-type objects by reducing them to plain text.

So Mike Macgirvin got into contact with Eugen Rochko and told him to adhere to the spec and deactivate Mastodon's "sanitiser" and make it support full HTML rendering for Article-type objects.

And Eugen Rochko said that bold type and italics and bullet-point lists and images in the middle of the content have nothing to do with old-school microblogging, so they have no place on Mastodon, so he won't implement them.

This head-butting went back and forth. Eventually, Eugen presented a "solution". And that was not to render Article-type objects at all anymore. Instead, Mastodon links to them and adds their title above if they have one.

This was only done to shut Mike up so he'd stop complaining about Mastodon defacing Hubzilla posts and breaking the spec by doing so. From Mike's perspective, however, what Eugen did was flip Hubzilla the bird by completely refusing to show actual Hubzilla content and practically lock out a competitor.

Mike's reaction was to break the spec himself and switch Hubzilla from sending Article-type objects to sending Note-type objects, regardless of Mastodon still defacing them.

With the exception of a very short period after the release of Hubzilla 9.0 when Mario Vavti and Harald Eilertsend learned the hard way that Mastodon still links to Article-type objects, Hubzilla has only sent its posts as Note-type objects ever since.

Mike's other creations have different ways of handling object types.

Friendica, by default, sends posts with titles as Article-type objects and posts without titles as well as comments as Note-type objects. This can be deactivated so that Friendica only sends Note-type objects.

CC: @ Laurens Hof

# Long # LongPost # CWLong # CWLongPost # FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # Fediverse # ActivityPub # Mastodon # Friendica # Hubzilla # Streams # (streams) # Forte # ArticleType # NoteType # LongFormContent

@silverpill

The dataset doesn't include some other popular platforms like Friendica, but I am sure they also display long form content just fine.

Friendica and its descendants from the same creator, Hubzilla, (streams) and Forte, can produce long-form content just fine. With just about all bells and whistles from a title plus six levels of headlines to an unlimited number of images embedded within the text.

So yes, they can display it as well. However, outside of their own communities, hardly anyone knows what they're capable of. Thus, Fediverse developers often try to solve problems that aren't even really there because they were solved before they became problems.

Mastodon's lack of support for articles, linking to the originals instead, is not really a lack. It's a deliberate design decision from around 2017 or so.

See, the first ActivityPub implementation was on Hubzilla. That was in July, 2017. And Hubzilla implemented ActivityPub by the book.

Mastodon followed two months later. But Mastodon has always had its own "interpretation" of ActivityPub that was limited by Mastodon's own intentional design limitations in order to remain Twitter-like, purist, minimalist, old-school, original-gangsta microblogging with as few features that Twitter didn't have as possible.

This is also why Mastodon has a HTML "sanitiser" built in. Up until the release of Mastodon 4.0 in October, 2022, that "sanitiser" reduced any and all incoming HTML to plain text. And it did so for all object types, including the Article-type objects which Hubzilla sent. After all, Hubzilla can act as a fully-fledged long-form blogging platform.

However, the ActivityPub spec defines Article-type objects as formatted long-form content. Still, Mastodon defaced Hubzilla's Article-type objects by reducing them to plain text.

So Mike Macgirvin got into contact with Eugen Rochko and told him to adhere to the spec and deactivate Mastodon's "sanitiser" and make it support full HTML rendering for Article-type objects.

And Eugen Rochko said that bold type and italics and bullet-point lists and images in the middle of the content have nothing to do with old-school microblogging, so they have no place on Mastodon, so he won't implement them.

This head-butting went back and forth. Eventually, Eugen presented a "solution". And that was not to render Article-type objects at all anymore. Instead, Mastodon links to them and adds their title above if they have one.

This was only done to shut Mike up so he'd stop complaining about Mastodon defacing Hubzilla posts and breaking the spec by doing so. From Mike's perspective, however, what Eugen did was flip Hubzilla the bird by completely refusing to show actual Hubzilla content and practically lock out a competitor.

Mike's reaction was to break the spec himself and switch Hubzilla from sending Article-type objects to sending Note-type objects, regardless of Mastodon still defacing them.

With the exception of a very short period after the release of Hubzilla 9.0 when Mario Vavti and Harald Eilertsend learned the hard way that Mastodon still links to Article-type objects, Hubzilla has only sent its posts as Note-type objects ever since.

Mike's other creations have different ways of handling object types.

Friendica, by default, sends posts with titles as Article-type objects and posts without titles as well as comments as Note-type objects. This can be deactivated so that Friendica only sends Note-type objects.

CC: @ Laurens Hof

# Long # LongPost # CWLong # CWLongPost # FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # Fediverse # ActivityPub # Mastodon # Friendica # Hubzilla # Streams # (streams) # Forte # ArticleType # NoteType # LongFormContent

@Tim Chambers There isn't much that we can do.

These standards, just like the various laws that triggered their creation, suppose that all social networks and social media are

• commercial and corporate with loads of money behind them
• centralised silos
• staffed with thousands upon thousands upon thousands of employees in office blocks all around the world

For comparison, Hubzilla probably shows what's the best the Fediverse can do. It has an optional field for new registrations to confirm that they're over a certain age.

However, almost all Hubzilla hubs have a "staff" of exactly one. A hobbyist. Unlike Mastodon servers, Hubzilla hubs don't even have moderators because Hubzilla is all about self-empowerment and self-moderation.

Is that one admin honestly expected to verify the authenticity of the IDs and the birth certificates of newly-registrated users with the authorities in almost 200 different nations?

There used to be a time when such regulations only applied to services from a certain size upward or from a certain revenue upward. But now something that can only be done by big corporations becomes mandatory for tiny hobbyist projects.

Besides, how are these measures supposed to keep 13-year-olds from spinning up their own single-user Fediverse servers on machines at home? If this is supposed to be absolutely, 100% guaranteed to be absolutely, 100% water-tight, the two Hubzilla devs would have to check and verify the identity of everyone who wants set up their own hub before they allow the git-based installer to clone the repository from Framagit onto their servers.

CC: @ IEEE Spectrum

# Long # LongPost # CWLong # CWLongPost # FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # Fediverse # Hubzilla # AgeVerification

@Tim Chambers And again, Friendica, Hubzilla, (streams) and Forte are way ahead. They were all made modular right from the start, and they can all be expanded with third-party add-ons and third-party themes (provided someone makes them) by adding third-party git repositories to your server. It helps that they themselves are all installed via git in the first place.

For example, it's possible to add entirely new protocols as add-ons. On Hubzilla, protocols that aren't Zot (ActivityPub, diaspora*, RSS/Atom etc.) are add-ons and off by default for new channels. Hubzilla's counterpart to Mastodon's lists, only vastly more powerful, is called "privacy groups" and an official add-on that's off by default again. CalDAV calendar server? Wikis? Webpages? All add-ons. (streams) and Forte have a somewhat different set of add-ons and a different set of add-ons that are on or off by default for new channels.

You can bolt all kinds of stuff to these four as third-party add-ons. Want a dating platform in the Fediverse? Just write an add-on for one or several of these four that ties into their (main, public) profiles with their dozens of fields, and you've got one.

Better yet: You can upgrade the whole server, the core, the official add-ons, the official themes, third-party add-ons, third-party themes, in one fell swoop. Not first the official stuff and then each third-party repo one by one, but all at once. At least on Hubzilla, (streams) and Forte, util/udall is the little helper that does it all for you.

# Long # LongPost # CWLong # CWLongPost # FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # Fediverse # Friendica # Hubzilla # Streams # (streams) # Forte # git # ThirdParty # AddOns # PlugIns

@ Anuj Ahooja Friendica has had full support for formatted long-form articles since its inception 15 years ago. The same goes for all its surviving descendants, created by the same developer: Hubzilla from 2015, (streams) from 2021, Forte from 2024. In addition, Hubzilla can be used to post federating long-form articles (which are automatically sent to Fediverse connections and Atom feed subscribers) and optionally also to post non-federating long-form articles (which aren't sent anywhere).

Friendica has also been able to subscribe to both RSS and Atom feeds since its inception. The same goes for Hubzilla.

This is not new to the Fediverse at all.

See also my Mastodon vs Friendica, Hubzilla, (streams) and Forte feature comparison tables here: https://hub.netzgemeinde.eu/item/0a75de76-eb27-4149-b708-f20b2f79d392. (By the way: This is a non-federating Hubzilla article.)

CC: @ Michael Marek @ Elias Probst

# Long # LongPost # CWLong # CWLongPost # FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # Fediverse # Friendica # Hubzilla # Streams # (streams) # LongForm # LongFormText # LongFormContent

@liaizon @steffenloewe Good finds! Added to #Wikidata. https://www.wikidata.org/w/index.php?title=Special:Contributions&target=Nemo+bis&dir=prev&offset=20250615163651&limit=4 #FediMeta

@Strypey

Is there a test server where I can have a look at this?

I don't think there's a public hub that's reliably always switching to release candidates. But if you're daring, you may try zotum.net; it's running dev code, so it's always ahead of the others.

# FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # Hubzilla

@Strypey

You say this like it's a bad thing.

Not at all.

One advantage is, as you've said, that the backend and the Web frontend can have their own developers, development of both can largely be detached, and they can be upgraded separately from one another.

Separate Web frontends can be developed by people who actually know a thing or two about frontend development and UI design. I mean, look at the Web UIs of some all-in-one Fediverse server applications. They're often the digital counterpart of random knobs and switches poked through a piece of cardboard and labelled with a ball pen, just so that these knobs and switches are there. Sometimes they're the equivalent of expecting all kinds of end users to operate DIP switches, but hey, they're still better than soldering and unsoldering wires.

Another advantage is that server software for which alternative frontends exist does not have to drag its default frontend around. There are Mastodon servers with alternative frontends, but they still have to have the two official Web UIs installed (the default one and the Tweetdeck-style one) because they're firmly welded to the backend. I guess we all know what a heavyweight Mastodon is, and I'm certain that part of the weight is caused by the built-in Web UIs. In stark contrast, you can set up an Akkoma server with Mangane instead of Akkoma-FE, as in without having to also install Akkoma-FE.

By the way, Hubzilla is an interesting case here. Not only is its default UI very configurable, but Hubzilla itself is highly themeable, and third-party themes almost amount to entirely new UIs. At the same time, however, practically all official development efforts went only into the backend for most of its existence.

Any Hubzilla UI has to wrestle an immense wealth of features, and not exactly new features were added over time. This, however, caused Hubzilla's UI to gradually turn into a jumbled mess because some of the new UI elements were seemingly added in totally random places. Not only was the UI never cleaned up, but the default theme is perpetually stuck in 2012 (the name "Redbasic" says it all, it was made for Hubzilla when Hubzilla was still named Red), it was derived from an early Friendica theme, and even Friendica wasn't pretty back then. Also, the documentation was completely neglected.

So the situation last year was that there was only one working Hubzilla theme left, and that was Redbasic. It was the only theme that was even only upgraded to work with newer Hubzilla versions. There used to be other official themes, but they eventually ended up so outdated that they were removed altogether. @Sean Tilley's third-party themes were last touched seven years ago, that must have been around the time when Hubzilla 3 came out. At the same time, the official documentation was not only highly incomplete, but it was so outdated that parts of it were simply false. It partly referred to features that had been axed many years ago (tech levels) and features that simply were never there (four different mention styles), and parts of it even still spoke of Red. Thus, nobody even knew how to develop new themes for current Hubzilla.

That was when the community stepped in. @ Der Pepe (Hubzilla) ⁂ ⚝ sat down and rewrote the entire help. @ Scott M. Stolz not only started working on his NeuHub themes, but in the same process, he reverse-engineered Hubzilla's theming system to write documentation for theming Hubzilla which had never been written before AFAIK. Around that time, @ ????? was dabbling with specialised themes for certain purposes, e.g. one very clean theme for Hubzilla channels used as long-form blogs. Later on, @ Saiwal joined the fray with his now-popular Utsukta themes.

Granted, Hubzilla still carries Redbasic around, not only as the default for new channels unless the admin chooses another one, but also as a fallback in case a new Hubzilla version doesn't support existing third-party themes anymore. The latter is becoming less likely as the Utsukta themes are being built against Hubzilla's development versions now. Besides, it's in Hubzilla's nature that everything on a hub is updated at the same time, including third-party repositories.

In general, the Hubzilla community is no longer that easily satisfied with a UI that "just works", and the devs have taken notice. Hubzilla 10.4, now a release candidate, will spruce up certain core parts of the UI. It will introduce a tree-style thread view as the new default instead of its current chronological view, something that Friendica, (streams) and Forte have had for significantly longer. That is, this is actually a side-effect of the introduction of "lazy loading" conversations to reduce the server workload. Also, upon user request, it will add a button to add images to comments.

If (streams) and Forte grow bigger, the same could happen there. They have two official themes to choose from, fairly new Fresh and an older version of Redbasic. However, they don't have a large enough community for all the same things to happen to them that happened to Hubzilla, although Pepe has said he'd rewrite the (streams) and Forte help as well, seeing as Mike had ripped them out entirely with no replacements as they were too outdated at that point. Maybe someone will even write a guide on how to adapt Hubzilla themes to (streams) and Forte.

That is, (streams) and Forte are both already the result of several years of UI and UX advancement and improvements and making them fit for a Mastodon-dominated Fediverse (where Hubzilla is still geared towards a Fediverse which it will dominate itself by the mid-to-late 2010s). This is stuff which can't be taken care of in themes because it concerns the UI engine itself, and it's partly tied deeply into the backend.

While Hubzilla, (streams) and Forte won't be able to do without their official themes anytime soon, the official themes don't significantly weigh them down. Still, they require some maintenance work to keep up with the backend.

Wouldn't Mastodon would be better if it specialised in developing apps, and outsourced the server side to people who know how to do back-end engineering?

This makes me wonder which half Mastodon would be willing to outsource. I think they'd rather hold on to the backend and pass all the frontends on. Of course, this would come with the advantage of the official Mastodon mobile app actually becoming somewhat decent rather than remaining the "we need an official app, no matter how" kluge that it is today.

CC: @Tim Chambers @rakoo

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

@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

I wish there was an option to stop a specific account's posts from appearing in the local timeline. I could use a feature like that to avoid that in smaller instances the local timeline gets less useful to me by being dominated by users that, although often interesting, post very frequently. 'Cause if I go and mute them, then I can't see their posts even if I create a list exclusively for accounts that post very frequently and add them to it; I tried this earlier.

#FediMeta

@Strypey Still, the headbutting was often justified for Mike. Unless, of course, you say that Mastodon is and has always been the one and only Fediverse gold standard and the one and only ActivityPub reference implementation.

I'll give you an example: In July, 2017, Mike's Hubzilla was the very first Fediverse server software to implement ActivityPub. Mike played strictly by the rules. As Hubzilla has a character limit of over 16.7 million and supports text formatting on the same level as the best long-form blogging platforms out there, he declared Hubzilla long-form and made Hubzilla send Article-type objects. Just as the spec demands.

In September, Mastodon became the second Fediverse server software to implement ActivityPub. But Gargron did not play by the rules. He only implemented a tiny subset of the protocol, namely what suited him. And he also broke it: Mastodon could display Article-type objects at their full length. But Gargron staunchly refused to implement any support for anything that goes beyond plain text. The ActivityPub spec explicitly says that Article-type objects are formatted. But Gargron wanted Mastodon to be a purist, minimalist, old-school, original-gangsta, Twitter-cloning microblogging platform. And stuff like bold type, italics, headlines, embedded in-line images or titles aren't purist, minimalist, old-school, original-gangsta, Twitter-cloning microblogging.

And so Mastodon took fully formatted, long-form-blog-style posts from Hubzilla and ripped everything out that wasn't plain text. It basically defaced Hubzilla posts. That is, it had been defacing Friendica and Hubzilla posts all the same ever since it was launched. But this time, there was a spec that actually defined what Mastodon was doing as wrong. And that spec had been finalised and pronounced a W3C standard meanwhile.

So Mike asked Gargron to please follow the official ActivityPub spec and make Mastodon support full HTML rendering for Article-type objects.

Gargron refused. Old-skool microblogging is plain text and only plain text, full stop.

This went back and forth. Eventually, Gargron presented a "solution": Mastodon now "renders" Article-type objects by showing the title and, right below, a link to the original. That is, basically not at all anymore. Of course, this meant that the vast majority of Mastodon users no longer read what came from Friendica and Hubzilla because they couldn't be bothered to open that link.

Mike saw this as a direct assault against Friendica and Hubzilla and an attempt at excluding both from "the Fediverse" which was almost entirely Mastodon at that point already. So he himself had to break the spec and make Hubzilla send Note-type objects instead so that Mastodon renders them at all. It still defaces them to this day.

(Friendica's solution was to send an Article-type object when a post has a title and a Note-type object when it doesn't have a title. Optionally, it can always send Note-type objects.)

By the way: This very same head-butting has returned. Not between Gargron and Mike, though, but between Gargron and much bigger players. Platforms like Flipboard and Ghost have introduced ActivityPub, and they send Article-type objects just as the ActivityPub spec demands. The same goes for WordPress. And, of course, they don't send plain-text "long tweets". They send fully formatted news articles and blog posts.

And now they demand Mastodon, as the biggest player in the Fediverse by user count, make their Article-type objects look just like they look at the source. They demand Mastodon not only render bold type, italics, headlines and the rest of the subset of text formatting that was introduced with Mastodon 4 in October, 2022. They also demand Mastodon show the titles and, most importantly, leave the images embedded within the articles in place, no matter how many they are.

This is no longer Gargron and his devs vs a guy in the Australian outback. This is Gargron and his devs who try hard to bend the Fediverse to their will and assume supreme control over it vs the Ghost Foundation, Flipboard, Inc. and Automattic, Inc. that play strictly by the ActivityPub rules. And I dare say that Automattic, Inc. alone has more money and more market power than Mastodon gGmbH and Mastodon, Inc. combined.

Mastodon has always gotten away with ignoring and breaking standards, re-inventing wheels and implying towards its religious followers that the whole Fediverse was built upon Mastodon and around Mastodon, and that everything that does things differently from Mastodon is inherently a broken add-on to Mastodon or an evil intruder. This time, they won't. And I guess they've actually taken it into consideration.

CC: @Tim Chambers @rakoo

# Long # LongPost # CWLong # CWLongPost # FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # Fediverse # ActivityPub # Mastodon # Friendica # Hubzilla # WordPress # Ghost # Flipboard

@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)

@StrypeyLocally writing content to the database of an ActivityPub-based server will inevitably require a local user account on that very server.

I mean, we already have OpenWebAuth magic sign-on which was invented by @ Mike Macgirvin ?️ for Hubzilla in 2017, and which also has full implementations in his later server applications (streams) and Forte and a client-side implementation on Mike's first project, Friendica. But without an actual account on another server, OpenWebAuth can only authenticate you on that other server as a guest and grant you certain guest permissions. It does not give you all the powers of a local user, at least not without a local account.

Also, if you want to actually log in on another server, you will inevitably need local login credentials on that server. Which means that a user account with these login credentials must be created prior to you logging in on that server so that that server knows your login name and your password. Even if you want to use something like OAuth, that server will still require to know your credentials. They will have to be in that server's database before you can successfully log in.

A server cannot and will not authenticate you against credentials in a wholly different remote server's database. What you and many other Fediverse users dream of can only be solved in two ways and both only theoretically because, in practice, they are just as impossible or at least very unfeasible.

Either if you register an account on one Fediverse server, that account with the exact same credentials is simultaneously created on literally all other Fediverse servers, and on Hubzilla, (streams) and Forte, you also automatically get a channel along with that account. This also means that each Fediverse server that's installed and spun up for the first time will immediately have to create tens of millions of accounts so that everyone all over the Fediverse automatically has login credentials on that server. I guess it should be clear that this is impossible, also because this requires a) a centralised list of absolutely all Fediverse accounts and identities and b) a centralised list of all Fediverse servers to be hard-coded into every last instance of every last Fediverse server out there.

Now, I keep reading stuff like, "But I don't want to use all Fediverse servers!" No, but you want to be able to use any Fediverse server. And then you will have to have an account there. How is the Fediverse supposed to know in advance which servers you will visit this year, the next two years, five years, ten years so that accounts can be automatically created for you exactly there and nowhere else?

See? And that's why, if you want to be able to use any server like with a local account, every server must be prepared for it before you arrive.

Or drive-by registration: You visit a Fediverse server for the first time, your active login is recognised by that Fediverse server, and an account is created for you on the fly with the exact same login credentials as where you're already logged in. That's its own can of worms.

Also, it requires remote authentication. OpenWebAuth. As I've already said: This is technology that's eight years old, and that's being daily-driven right now. But: You will never have this on Mastodon. There actually is a pull request for Mastodon from two years ago that would have implemented client-side OpenWebAuth support. It was never merged. It was silently rejected by the Mastodon developers. The PR was closed in November, 2024.

Some people go even further: They don't just want their login credentials wherever they go, they want their whole identity cloned to everywhere. They want all their stuff, all their posts and comments and DMs, all their followers and followed, all their settings, all their filters etc. etc. pp., they want it everywhere all the same. Like a nomadic identity (an invention by Mike from 2011, first implemented in 2012) across up to 30,000 servers.

Now, you and many others on Mastodon are probably going to cry out, "YES, YES, PLEASE MAKE THIS REALITY!"

But seriously: I myself have actually cloned enough Hubzilla and (streams) channels of mine in my time. None of them even had nearly as much content on them as your Mastodon account. And I can tell from a lot of personal experience that this cannot be done within a blink of an eye.

Nomadic identity won't come to Mastodon anyway. Nomadic identity via ActivityPub is probably being daily-driven already. Forte has it, and it relies on it. But Mastodon will never implement it. In particular, Mastodon would rather re-invent the "nomadic identity" wheel in a way that's incompatible with what we already have than implement something made by Mike Macgirvin. Not after all the head-butting that has happened between Mike and Gargron over the years.

And OpenWebAuth won't come to Mastodon either. Probably also for the same reason.

CC: @Tim Chambers @rakoo @ Ben Pate 🤘🏻

# Long # LongPost # CWLong # CWLongPost # FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # Fediverse # Mastodon # Friendica # Hubzilla # Streams # (streams) # Forte # OpenWebAuth # SingleSignOn # NomadicIdentity