First, Bluesky’s nomadic identity isn’t worth shit if nobody knows that there’s more than one instance.

Next, it has yet to be proven to work because nobody has daily-driven it yet.

Finally, if you want nomadic identity that’s actually proven to work, don’t join Bluesky. Join Hubzilla. Nomadic identity, established in 2012, some four years before Mastodon, daily-driven by probably hundreds or thousands of people since then.

I’m not even kidding. The Fediverse had nomadic identity four years before it had Mastodon.

No, but it used to. And that’s enough for some people.

I bet you that there are people who steer clear of anything related to BASIC not because it’s a kiddy language, but because it was invented by Bill Gates.

Misskey and the actual Forkeys are in TypeScript and Vue.js. And they all have the same bugs that you can’t just simply get rid of.

Iceshrimp.NET is a rewrite of Iceshrimp in C#, that’s why it’s named Iceshrimp.NET. It promises to get rid of all issues inherited from Misskey because it doesn’t have a bit of Misskey left in it anymore.

But maybe we need more rewrites in more languages to satisfy as many people as possible. A Catodon rewrite in Ruby on Rails for Mastodon fanbois and fangurlz, no matter what a chonker it’ll end up being. Sharkey rewritten in PHP to satisfy those who like things as easy and lightweight as Friendica & Co. And even more because not few say that both C# and Ruby on Rails and PHP suck.

Or is there anything that doesn’t suck at all? Go sucks because Google. Rust sucks because Mozilla. Python sucks because it’s Python being Python. And so forth.

People want a 100%, 1:1, perfect clone of immediate pre-Musk Twitter. They want Twitter without Musk.

Bluesky is a 100%, 1:1, perfect clone of immediate pre-Musk Twitter. It is Twitter without Musk.

It looks exactly like Twitter, it feels exactly like Twitter (both the Web interface and the official app), and it’s for tech-illiterate dumb-dumbs.

Only recently has an instance selector been added to the sign-up process of the official app, but Bluesky still markets itself to its users as the self-same kind of centralised monolithic silo as Twitter and Facebook.

Mastodon has a vastly different UI and UX from immediate pre-Musk Twitter, but people don’t want to learn anything new. And truth be told, I’ve read from Misskey/Forkey users that Misskey and the Forkeys actually have an easier-to-use Web UI than Mastodon.

Also, Mastodon advertises the fact that it’s decentralised with lots of instances to choose from, even though the gGmbH would rather want everyone to be on mastodon.social. This freaks people out.

Joining Mastodon is actually no more difficult than joining Bluesky in practice because the official app railroads everyone to mastodon.social without forcing them. But people won’t know until they’ve actually installed and opened that app.

The only reason why Mastodon grew so quickly to such an enormous size in late 2022 was because it was the only alternative to Twitter that anyone knew, including those who pulled Twitter users onto Mastodon. The only other advantage it had over anything else was that, unlike Twitter, it didn’t have Musk and uncontained droves of Nazis. Had people been sent to Akkoma or Calckey instead of Mastodon, it would have exploded the same.

Inb4 “How can people use e-mail then?” That’s because everyone’s on Gmail, and many think e-mail is a proprietary Google product.

Good to know.

Strangely, people don’t seem to mind.

I guess then a key difference is that Bluesky is presented to 𝕏 users as the same kind of monolith as 𝕏 whereas Mastodon is presented to them as a huge number of instances from which they absolutely have to pick one.

If it randomly mentions other users, and if it comes in such masses that Mastodon admins have to raise the shields and Fediblock the hell out of dozens of instances, then it’s spam all right.

That said, the last spam wave was organised on Misskey again, but carried out by bots from Mastodon instances largely abandoned by their admins. At least partially, this was the case for the first big spam wave as well.

Hubzilla. Closely followed by the intentionally nameless fork of a fork… of Hubzilla that’s colloquially being referred to as (streams).

Perks of both (excerpt):

• not based on ActivityPub, it’s actually optional; you can turn/keep it off if you want to
• nomadic identity; my channels are resilient against instance shutdown because they aren’t restricted to one instance
• multiple channels = IDs on one and the same account/login; no need to register additional user accounts for this, and you can easily switch back and forth between channels
• OpenWebAuth magic single sign-on, both client-side and server-side support
• very extensive permission settings that let me control what I see, what I don’t see and what others can see and do
• per-contact permission settings
• per-channel blacklist/whitelist filter plus per-contact blacklist/whitelist filters plus keyword-triggered, automatically generated, reader-side content warnings, supporting regex and (except the latter) a special filter syntax for extra features
• what’s “lists” on Mastodon is actually useful because you can use it both to filter your stream and to limit whom you send a post to, not to mention much easier to maintain
• a concept of conversations, you can follow entire discussions, and you generally receive all replies to a post (something that at least Mastodon doesn’t have, by the way)
• not only native support for discussion groups/forums, but they can and do host their own moderated discussion groups/forums (Mastodon has neither)
• no arbitrary character limits, characters only limited by the instance database (on (streams), that’s theoretically over 24,000,000 characters for one post)
• probably more text formatting options than your typical blogging platform and definitely more than any microblogging project in the Fediverse
• full-blown blog posts rendered gracefully
• non-standard BBcode tags for special features, often observer-aware
• embedded links; no need to plaster URLs into your posts in plain sight
• images can be embedded “in-line” within the post with text above them and text below them
• no limit on how many images a post can have
• unlimited poll options
• multiple-word hashtags
• post categories in addition to hashtags
• tag cloud plus category cloud/list
• quotes
• “quote-tweets”
• extensively customisable Web UI
• built-in file storage with a built-in file manager, per-file and per-directory permissions settings and WebDAV support that’s used for images and other media you embed in your posts (unlike on Mastodon and Lemmy, you know where your uploaded images land, and you can delete them yourself if you need to)
• federated event calendar with support for Event-type objects
• built-in CalDAV calendar server (headless on (streams))
• built-in CardDAV address book server (headless)
• support for OAuth and OAuth2
• modular; can be extended with official or, if available, third-party “apps”, widgets and themes

Extra perks of Hubzilla:

• currently more reliable
• more active development
• easier to get new users on board because hubs are listed on various Fediverse sites, and more public hubs are available
• newer and more configurable version of the Redbasic theme
• switchable night mode
• multiple profiles per channel which can be assigned to certain connections
• you can configure new connections before you confirm them
• can also connect to diaspora*
• can also subscribe to RSS and Atom feeds
• event calendar also doubles as a basic frontend for the CalDAV server
• non-federating, long-form articles
• “cards” that work largely the same
• built-in wiki engine based on either BBcode or Markdown for as many wikis of your own as you want to, each with as many pages as you want
• support for webpages (the official Hubzilla website is on a Hubzilla channel itself)

Extra perks of (streams):

• more advanced
• better integration of ActivityPub into the two supported nomadic protocols
• contact suggestions also include ActivityPub contacts
• new default theme in addition to an older Redbasic version
• reworked, more powerful but easier-to-use permissions system
• easier to use once you’re on board
• supports BBcode, Markdown and HTML within the same post
• can set Mastodon’s sensitive flag for images
• built-in announcement/boost/repost/renote/repeat remover, no need to use filter syntax for that
• extra protection against both mention spam and hashtag spam
• alt-text can be added to images upon upload, no need to graft it into the image-embedding markup code
• verification of external identities (available on Mastodon as well, but not on Hubzilla)

• https://joinfediverse.wiki/Main_Page (admittedly quite Mastodon-centric)
• https://fediverse.party

It technically still is in development. But all the devs lack time, and the devs themselves officialy recomment WriteFreely on the Plume website.

Even though Plume has features that are nothing but TBD plans for WriteFreely (e.g. comments, built-in image storage).

Ackchually, most of the Fediverse runs on professionally-operated Hetzner rack iron at huge data centres in Germany.

Even if this comes from 22% of the Fediverse being mastodon.social.

• https://joinfediverse.wiki/What_is_Mastodon%3F
• https://joinfediverse.wiki/What_is_Misskey%3F

Many Mastodon users are against both Bluesky and Threads federation because they want the Fediverse to remain only Mastodon.

Little do they know that the Fediverse has never been only Mastodon.

I’d pretty routinely have federation issues, missing posts from my TL, and posts that would just repeat endlessly in the TL until I reloaded the page. And those are problems I experienced on every fork I tried.

From what I’ve heard, they’ve all inherited these very same issues from Misskey. And apparently, they aren’t trivial to fix, otherwise either Misskey or any of the Forkeys would have succeeded.

I guess your best bet is to wait for Iceshrimp.NET going fully public and ideally stable. It’s no longer a Forkey. It’s rather a complete re-write from scratch of Iceshrimp, no longer in TypeScript and Vue.js, but in C#. Apparently, Misskey’s codebase (plus what Calckey/Firefish added) was so bad that this was the most promising step to take.

Also, app support isn’t great.

Found the former Sharkey user.

Sharkey’s Mastodon API implementation is infamously terrible. The Sharkey community is still waiting for someone to step in and re-write the Mastodon API implementation from the ground up, so bad is it.

But another issue is that everyone who could theoretically develop a mobile Fediverse app is on Mastodon. And so, instead of a good *key app, you get yet another Mastodon-only iPhone app and yet another Mastodon-only iPhone app from people who don’t even know that the Fediverse is more than Mastodon.

Bluesky:

• Download official, fully featured app and not something utterly crippled
• Looks and feels like Twitter
• No weird tech mumbo-jumbo (WTF is a server, is that like a Discord server, what’s that gotta do with Twitter) confusing you because there are no instances to choose from
• Make an account
• UI, UX, look & feel 100%, 1:1 fully identical with immediate pre-Musk Twitter
• No need to get used to anything because literally everything stays precisely the same as what you’re used to, only that it’s no longer “Twitter” or “X” or “tweets”
• Use it literally precisely the same as Twitter
• Pretend you’re still on Twitter, it won’t make a difference

If Mastodon wanted to compete with this, it would have to

• replace its default Web UI with an even more faithful clone of the immediate pre-Musk Twitter Web UI,
• replace its official app with something that’s absolutely identical to the immediate pre-Musk Twitter app in all but name and branding
• remove the instance chooser without introducing any other option of joining any other instance than mastodon.social
• completely hide decentralisation and instances from newbies, ideally for a few months or years after they’ve joined
• introduce a content-forwarding algorithm like the one on X, but better
• forcibly ban Mastodon’s user-grown culture and force pre-Musk Twitter culture upon everyone
• mollycoddle its users for months or years so that Mastodon really feels like “literally Twitter without Musk” by shielding them from not only all hints that Mastodon is different, but also from the entire rest of the Fediverse

You can choose. But you don’t have to.

The official Mastodon app has a box where you can pick one out of several hard-coded instances. It defaults to mastodon.social. You can pick a different instance if you want to. But you can also ignore it, scroll past it and let yourself be conveniently railroaded to mastodon.social without even knowing what an instance is.

If you’ve never in your live chosen anything that has to do with IT, if all you know is centralised, monolithic silos, then you can’t be expected to first choose one out of literal dozens of microblogging projects in the Fediverse and then one out of dozens, hundreds or thousands of instances.

The Fediverse would be a whole lot smaller if not all newbies who didn’t come from Reddit were railroaded hard to mastodon.social. Oh, and Lemmy would be a whole lot smaller without Redditors having been railroaded first to lemmy.ml and now to lemmy.world.

Firefish will be discontinued around the end of the year.

Here’s the context: Calckey/Firefish, a direct Misskey soft fork was mostly a one-person show, entirely run by Kainoa who was also the sole tech admin of the lighthouse instance. There were other devs, but Kainoa was the sole maintainer and the only one who could merge patches into production code. Nobody else was ever authorised to do so. Calckey/Firefish was Kainoa’s baby.

In late 2023, Kainoa largely disappeared from the face of the Earth. No engagement with the Fediverse at all anymore. There were sparse signs of life, but that was all. Turned out Kainoa had graduated and started a job and didn’t even have a few seconds to post anything into the Fediverse. In the meantime, Firefish didn’t follow Misskey’s development and got stuck on Misskey 12 level while Misskey went to version 14. Also, the lighthouse instance whose only tech admin was Kainoa completely crapped off and became entirely unuseable.

All other devs jumped ship. I think both Iceshrimp and Sharkey were launched by former Firefish devs (at least one of them was, Iceshrimp being a former hard fork of Firefish which was quickly rebased into a more up-to-date Misskey soft fork whereas Sharkey started out as a Misskey soft fork right away.

After about half a year, Kainoa came back and promised that things would continue. But someone else had to continue it. And that was Naskya. It was up to her to continue, but with zero help from Kainoa. The latter didn’t want to continue any of the existing Firefish sites, not the website, not the lighthouse instance, not even the code repository because all three ran on Firefish-specific domains which Kainoa probably couldn’t be bothered to transfer. All three were scheduled to shut down which is why many people think Firefish is dead: The old links no longer work.

So when Naskya took over, she had to set up a wholly new code repository, essentially fork Kainoa’s repository as long as it still existed (Naskya’s Firefish is a hard fork of Kainoa’s Firefish, technically speaking) and set up a new llighthouse instance. But since she ended up the only dev, it became much too much work. And so she announced to discontinue Firefish by the end of 2024.

Iceshrimp was designed for stability which is also why a number of Firefish features had been kicked out. It itself is on maintenance for as long as it will continue to exist, which won’t be that long.

The reason: Iceshrimp.NET. The Iceshrimp devs decided to no longer put up with Misskey’s mangled, faulty code base and no longer try to patch what’s broken on Misskey’s side. And besides, a Fediverse server application entirely based on JavaScript (TypeScript + Node.js) doesn’t sound that much like a good idea. Instead, the Iceshrimp devs decided to re-write all of Iceshrimp from scratch, from the ground up, in C#. This is far from done which means it’s even farther from being daily-driveable.

So you’ve got two Iceshrimps now: One is a Forkey and only receives bugfixes or security patches anymore, if anything. One is not a Forkey and not ready for public deployment yet either.

Sharkey used to be the king of features, but at the cost of reliability. Especially Sharkey’s Mastodon API implementation is infamously bad. The Sharkey community has been waiting for someone to step up and develop a completely new Mastodon API implementation for Sharkey for I don’t know how long.

Also, the Sharkey devs lost a whole lot of community support when they collected donations for a server for Sharkey purposes and then took the money to set up a Minecraft server. Make of that what you want.

News on Catodon are sparse, if there are any. But then again, Catodon is Iceshrimp dumbed down for Mastodon converts’ convenience with a UI that’s as close as possible to the default Mastodon Web UI. That’s probably not what you’re looking for.

And it being Iceshrimp-based may pretty well mean that the Catodon development is halted and waiting for Iceshrimp.NET to be released so that Catodon can be rebased from the dead TypeScript/Node.js Iceshrimp codebase to the new C# Iceshrimp.NET codebase.

And then there’s CherryPick. AFAIK, it’s a Japan-based Sharkey soft-fork in which a whole lot of Misskey and Sharkey issues have been fixed; don’t ask me for details, I only know this stuff from hearsay. Basically, CherryPick is Sharkey in good. Or in better.

Caveats: Like Misskey, CherryPick is developed in Japan. I wouldn’t count on any of the devs, much less all of them, being fluent in English or anything else that isn’t Japanese. Also, there’s one (1) public instance outside of East Asia; it’s located in the Washington, D.C. metropolitan area. All the other instances are in and around Tokyo and Seoul.

All this combined may be why next to nobody in the West even knows that CherryPick exists.

I’m not even only talking about a 24-hour lag. I’m talking about parts of the Fediverse never being discovered at all. After all, the Fediverse doesn’t have a centralised DNS of its own in which all instances are registered but only them, where a search crawler could simply look them up.

Even if someone developed a Web search crawler much like the Google Bot, something that crawls the entire WWW looking for Fediverse instances, how is it supposed to tell Fediverse instances from websites that aren’t Fediverse instances?

I bet the first two proposals for solutions wouldn’t work with (streams).

The first proposal would probably be to go for the instance type, like “mastodon” or “lemmy” or “mbin” or “akkoma” or “misskey” or whatever. This, however, would require valid instance types to be manually added to a kind of config file from which the search crawler could look valid instance types up. This, in turn, would only work if this list was constantly kept complete and up-to-date.

This means: Whenever someone launches a new project, the identifier of this project will have to be added to the list. Whenever someone forks something into a new project, ditto. Now let the devs of the crawler have as little time as the Plume devs or as the sole Firefish dev early this year, and the list of Fediverse instance types will spend months outdated with new projects missing, and the crawler won’t recognise the instances of these new projects as Fediverse projects.

Oh, and it wouldn’t work with (streams) at all. See, (streams) is intentionally without a name, without a brand identity and even without a unified, pre-defined, fixed instance type. It isn’t like all instances identify as “streams” or “(streams)”. Some identify as “streams”, but many others have unique types. The crawler wouldn’t know these identifiers as valid Fediverse instance types (how is that crawler supposed to know that “bunny of doom” is a Fediverse identifier), and thus, it wouldn’t be able to identify (streams) instances as Fediverse instances.

Now you could say that (streams) is so tiny that it wouldn’t hurt to sweep it under the rug. Nobody would notice.

But that’d exactly be the problem. One of the (streams) users is the guy who created (streams) and everything before it all the way back to Mistpark in 2010, the one man who developed more Fediverse protocols and server applications than anyone, the man who invented nomadic identity and magic single sign-on: Mike Macgirvin. He is on one out of only two instances that identify as “y” (because Y is not X).

He is one of the few people in the Fediverse who actually post about what’s possible in the Fediverse that goes way beyond Mastodon. Not only possible, but readily available right now. He started advertising (streams) in the wake of the mass-migration of Twitter users to Mastodon. And if his most recent creation, Forte, manages to take off, he’ll probably advertise that. If (streams) wasn’t caught by crawlers, nobody would read his advertisement except those who already follow him, and I guess half of them already know his creations and what they can do.

Hard-coding the custom identifiers of (streams) instances into the list is a stupid idea, too. The instance type is not defined upon installation in a config file. It’s an admin-side free-text field that can be changed anytime with no consequences for connections, just because the admin feels like it.

Okay, so here’s the second proposal: Go for nodeinfo. The problem this time: Mike has also intentionally removed almost all nodeinfo code from (streams). He didn’t want (streams) to participate in that eternal rat race between Fediverse projects and Fediverse instances for the best stats on FediDB, Fediverse Observer and The Federation. In fact, (streams) is entirely absent from all three. This, too, is intentional.

If anyone has a better idea, I’m all ears.

And what do you know, HUGO was bolted to Hubzilla.

Still, the issue would be to find all instances of all Fediverse server applications.

I mean, the idea was to cover the whole Fediverse with that search. Literally everything.

Like, imagine I spin up my own instance of Forte on a home server to try it out and see if it already works.

How’s a Fediverse search engine supposed to know about my brand-new Forte instance? Clairvoyance? Hah. A crawler? Yeah, right, as if any crawler out there was fast enough to discover a brand-new instance of something that doesn’t have a running instance at all yet. At least not beyond enclosed, experimental instances detached from the rest of the Fediverse.

I mean, instead of Forte, I could also install what Forte was forked from, namely something colloquially referred to as (streams). Something that intentionally doesn’t have a name, doesn’t have a brand identity, doesn’t have a unified server identifier. Unlike Mastodon whose instances all identify as “mastodon” and Lemmy whose instances all identify as “lemmy” and Hubzilla whose instances all identify as “hubzilla”, (streams) instances don’t all identify the same. That field is customisable. And it has been customised for as long as (streams) has been around. You can’t reliably crawl (streams) instances. Instead of “streams”, they can identify as “y” (because Y is not X) or “get ready to rumbly” (public instance actually) or “bunny of doom” or “diversi spiritus”.

In fact, crawlers would have to be able to identify any kind of Fediverse server software. Even if someone has only just forked something, a crawler would be able to recognise it as Fediverse server software. If you hard-code server identifiers into the crawler, it’d be out-of-date as soon as someone decides to fork Mastodon or Misskey or Firefish or Sharkey or whatever again. And, as mentioned above, you can’t crawl (streams) instances by identifier.

It simply is impossible to discover and index the whole Fediverse by crawling, Google-style. And if a Fediverse search engine can’t discover a (streams) instance that identifies as “y”, it can’t index the content coming from the man who created (streams) and Forte and still occasionally develops both. The man who created the oldest still existing Fediverse project, Friendica, as well as the Swiss Army knife of the Fediverse, Hubzilla, and the very concept of nomadic identity. One of the most competent and experienced Fediverse devs ever. A crawler couldn’t find him.

Still, the search engine needs to know all Fediverse instances, right?

Well, if crawling fails, and crawling does fail, there’s only one way to achieve that: Each instance would have to announce its presence to anything that’s supposed to be able to search the Fediverse.

But in order to be able that, each instance would have to know everything that can search the Fediverse. And all instances of it. Every single one of them.

And if it shall announce its existence when it spins up for the first time, it will have to know all these search instances immediately before spinning up.

How can it possibly know them all before even going online itself?

Two options. Either a centralised list of all search instance that’s being updated as soon as a new one is spun up.

But you said, “federated.” As in not centralised.

Or the list would have to be built into the source code as it’s being git pulled from the code repository. In fact, the list would have to be git pulled from the code repository immediately before the server spins up so that it’s up-to-date when the server spins up. This would mean that the whole server software would have to be updated before start-up.

Of course, each Fediverse server software project that’s started from scratch would have to implement this list, otherwise its instances couldn’t be found.

But how is this list supposed to be kept up-to-date?

I mean, let’s suppose what has been spun up here is something that has Fediverse search built in. It itself would have to be added to this list so that other new instances can announce themselves to this new instance, so that it can find them and index their content.

So how is this new search-equipped instance supposed to be added to the list of search instances?

Shall it add itself to the list by manipulating the production code of all Fediverse server applications that have Fediverse search built in? Past the maintainers and without their consent?

Perfect search that covers 100% of the Fediverse has to rely on lists of some kind, that’s clear. The Fediverse changes too quickly to be crawlable. It’s too diverse to be crawlable. And it has server software which itself is inherently uncrawlable because it’s undiscoverable by design.

But such lists are impossible to always be kept up-to-date, too.