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.

Not more than mentioned in that thread.

But I guess the cat’s out the bag, it’s known that this is doable, so maybe this won’t stay the only time.

That, and/or people might bolt other stuff to Hubzilla.

A lot is going on in and around Hubzilla recently. Version 9.4 has only been released a couple of weeks ago, and it already got four bugfix releases. We might actually be approaching Hubzilla 10 in the not-so-distant future which will adopt a few features from (streams).

Scott M. Stolz is back at developing his new third-party themes which we expect to improve Hubzilla’s UX. On top of that, he plans to launch a bunch of new public hubs, also so aspiring users in North America won’t have to resort to overseas hubs.

The re-writing of Hubzilla’s entire help in German and English is on-going.

Most recent surprise: Someone has managed to integrate the Bandcamp alternative Faircamp into a Hubzilla channel.

If only (streams) had more people taking care of it…

It’s technologically impossible for any search to cover all of the Fediverse. Like, absolutely 100% of it.

That’s because it’s technologically impossible for anything in or outside the Fediverse to be aware of the full extent of the Fediverse and know all its instances, all its actors, all its (public) content in real-time.

It would only be possible if there was a fully centralised search engine. And that search engine had been hard-coded into all Fediverse server apps for years so that even instances that haven’t been upgraded in two or three years know it.

If Joe Übergeek spun up his own personal CherryPick or (streams) or Forte instance or whatever on his own Raspi, that instance would immediately have to announce its existence to that centralised search engine. Otherwise, the search engine wouldn’t have any way of knowing this new instance exists. If Joe Übergeek sent his first test post into the void because he has no connections yet, it would immediately have to be pushed to that search engine. And if Joe Übergeek decided to turn off ActivityPub on his (streams) channel, his instance would immediately have to notify the search engine which would immediately have to list that channel as formerly but no longer available.

Now imagine such a search being decentralised, e.g. built into Fediverse server apps like Mastodon or Lemmy. In this case, all server apps would have to know all instances out there with Fediverse-wide search. And immediately so.

Imagine Mastodon had such search built-in. Imagine Alice started up her own personal Mastodon instance with this search at 10:30. Imagine Bob installed his own personal (streams) instance from source at 10:31.

In order for the search on Alice’s Mastodon instance to actually cover 100% of the Fediverse, it would require Bob’s (streams) instance to push all necessary information to it. In order for this to work, Bob’s (streams) instance would have to know of the existence of Alice’s Mastodon instance from the moment it’s installed.

This couldn’t be done via any form of discovery, for where would (streams) go look for search instances?

So an automatically-generated list of search instances would have to be necessary. It would have to be delivered with the code upon installation.

This means that Alice’s Mastodon instance would have to add itself to the list of search instances in the streams repository (https://codeberg.org/streams/streams) as a pull request and then immediately merge that PR into both dev and release, the latter past dev, both without Mike Macgirvin’s permission, so that Bob’s new (streams) instance knows about Alice’s less-than-a-minute-old Mastodon instance with search the very moment that Bob installs it, so that Bob’s (streams) instance knows that it will have to report everything that happens to it in public to Alice’s Mastodon instance with built-in Fediverse search.

Whenever someone spins up a new instance that has Fediverse search built in, this would cause a PR in the code repositories of all Fediverse server applications that adds this instance to the initial list of search instances, and it’d cause that PR to immediately be merged into all active branches with no consent by the maintainers. And each shutdown of an instance with Fediverse search would cause a PR and an automated merge because that instance would have to be removed from the initial list of search instances.

I guess it should be obvious what an outlandish idea this is.

Also, let Mastodon shrink if that means that the “market share” of other native Fediverse server apps grows.

The fewer people think the Fediverse is Mastodon, and the more exposure the other stuff in the Fediverse gets and what features it has over Mastodon, the better.

Mastodon wasn’t launched by a VC-backed Silicon Valley startup to become the phone app that replaces Twitter.

It was created by a German high school graduate and metalhead all alone as not much more than StatusNet with a different UI and some features cut for simplicity. It was designed by a nerd for nerds, nerds who didn’t rely on phone apps for everything. At this level, and back in 2016, not even an official native iPhone app was mandatory.

Luckily, Mastodon is working on a discorvery protocol that should offer a way to find people across the board, which will hopefully make the Fediverse “appear” centralized to the average Joe while maintaining all the benefits of decentralization to the advanced users.

I’d bet that this will be so proprietary and non-standard again that it’ll only work within Mastodon, maybe plus a few of its own soft-forks, effectively ignoring 30% of the Fediverse.

Decentralisation and having multiple instances isn’t even that much of an issue. 99.999% of all Twitter refugees were railroaded to Mastodon and what seems like 99% of these straight to mastodon.social. They genuinely thought mastodon.social was “the Mastodon website”, just like twitter.com was the Twitter website. It took many of them months to even notice that Mastodon is decentralised. And it took some of them even longer to notice that the Fediverse is, in fact, more than just Mastodon while half of them think that Fediverse = Mastodon after almost two years.

No, the biggest issue is: What they were looking for was not something radically different from Twitter, now that Twitter sucked. They were looking for a Twitter without Musk. Like, a drop-in replacement that doesn’t require them to adjust in any way. A 1:1, 100% identical clone of Twitter how it was the day before Musk took over with the same UI and the same UX and the same culture.

When they were railroaded to mastodon.social, they were told that Mastodon is “literally Twitter without Musk”. And they took it as literally. By face value. And then they ended up on something that looked and felt nothing like Twitter. No matter how many of Twitter’s limitations Gargron arbitrarily and unnecessarily implemented into Mastodon, he never got close enough to Twitter itself.

People would stick around because Mastodon felt like the only alternative to Twitter there was. Of course, they kept using Mastodon exactly like Twitter, not adopting to Mastodon’s culture and relying on their toots being delivered to people by an algorithm that Mastodon simply doesn’t have. Hashtag? Fuck hashtags, I didn’t need no hashtags on Twitter, so I ain’t gonna use none on Mastodon. And then they wondered why so few people discovered them and their content.

They didn’t want to adapt. They were waiting for Mastodon to finally “fix the bugs” that made it different from Twitter. Which it didn’t.

Instead, Mastodon developed its own culture (which is a story of its own). And they were pressured to adopt Mastodon’s culture. CWs for sensitive content for any definition of “sensitive”. Twitter ain’t got no CW field. Alt-texts for all images, and it had to be actually useful and informative. They ain’t never done no alt-texts on Twitter. Of course, the right hashtags. See above.

Also, Mastodon-the-app is lack-lustre. Whereas the official apps for just about everything else are fully-featured, the Mastodon mobile app is only there for there to be a mobile app named “Mastodon” for those people who join a new online service by grabbing their iPhones and loading the app with the same name as the service from the App Store. Especially newbies often can’t wrap their minds around using an online service with an app that doesn’t have the same name. But the official Mastodon app is actually just about the worst Mastodon app out there. At the same time, for many Mastodon users, this app IS Mastodon. They’ve never seen the Web interface. What the app can’t do, Mastodon can’t do.

Lastly, Mastodon was probably also way too techy. Like, you had people talking about Linux and Open Source and Web design and whatnot all over the place, something that they themselves knew nothing about and weren’t interested in. On top came those people with their weird-looking monster posts that said the Fediverse is not only Mastodon, and they were posting from something that is not and has never even been affiliated with Mastodon.

And then Bluesky came along. And Bluesky looked exactly like what they’ve been wanting all the time: a 1:1 Twitter clone. One big reason for Bluesky’s success is that it shamelessly ripped off the UI of immediately-pre-Musk-takeover Twitter, both the website and the mobile app. A fully-featured, well-polished mobile app with all the same features as the website. And at first glance, it feels like the same monolithic walled-garden silo as Twitter with the same kinds of users as Twitter, minus the Nazis. At least not as ripe with übergeeks as Mastodon.

Also, Bluesky grew faster and quickly had more users than Mastodon. Which sounded like more followers in less time. Exactly what all those famewhores that brag about their Twitter follower counts were craving.

People wanted a pre-Musk Twitter clone. Mastodon isn’t one. Everything else in the Fediverse is one even less. Bluesky is just that. Bluesky is what people had wanted all the time.

Microblog is Twitter-like, normally plain-text only, normally limited in characters, no titles, no summaries because unnecessary for not even 1,000 characters per post. Also, conversations/threads consist of posts, posts and more posts that are loosely connected via mentions.

Blog is like WordPress or Blogger or Medium. With titles, with summaries, no character limits and the whole shebang of formatting.

Headlines

in

multiple

levels,

bold type, italics, code,

• bullet-point lists,

1. numbered lists,

images embedded in-line within the post (with text above the image and more text below the image), nicely embedded links instead of URLs in plain sight and so on. Also, conversations consist of exactly one (1) post, and replies are comments that aren’t posts and work differently from posts.

The six accounts of the Confederation had around 3,500 subscribers in total. Seriously, what did they expect?

As many followers as they’ve built up in the Birdcage? With maybe 1% of users altogether? In a much shorter timespan?

And by running the accounts as pure shoutboxes with no interaction with replies that could just as well be unmarked crossposter bots?

Do you explain the Internet to your grandparents by explaining HTTP first?

Sorry to say, but the Fediverse would be a great deal smaller if it wasn’t for millions of Twitter users who were railroaded straight to mastodon.social, not knowing anything about it except that it’s allegedly “literally twitter without musk”.

There are still people who have been on Mastodon since shortly after Musk bought Twitter out, and who shit brix upon discovering for the first time that the Fediverse is, in fact, surprisingly, who woulda thunk it, not only Mastodon.

These people wouldn’t be here, had their introduction to the Fediverse started with an explanation of ActivityPub.

The irony is that all it would take is one high profile person or a nation state to commit to using Mastodon, and slowly you would see the numbers start to increase.

Um, nope.

George Takei is on Mastodon. I’ve yet to see masses of Trekkies piling into Mastodon.

Greta Thunberg is on Mastodon. There has never been a huge influx of FFF members. Or Zoomers, for that matter.

The Dutch government has its own instance. The Federal German government has its own instance. Doesn’t lure anyone into the Fediverse.

The main cost is probably the extra workload put on their social media team having to publish to and interact with even more platforms.

They’ve yet to be caught actually interacting with someone. They’ve run the whole instance as nothing but a shoutbox.

The Fediverse is not only Lemmy and Mastodon. Even the microblogging side is not only Mastodon.

Mastodon itself has a whole bunch of forks such as Ecko, Hometown and the very popular Glitch.

There’s also Pleroma with its probably even more popular fork Akkoma.

There’s Misskey with literally dozens of forks, including but not limited to Firefish (formerly Calckey), Iceshrimp (its rewrite Iceshrimp.NET won’t be a fork anymore, though), Sharkey, CherryPick, Catodon etc. etc.

If you want something with more power, something that’s much more like Facebook, there’s Friendica and has been since 2010.

If you want something with vastly more power, think Facebook meets WordPress meets Google Cloud Services meets Fandom etc., there’s Hubzilla. Whenever someone thinks “the Fediverse” needs to introduce a certain new feature just because Mastodon doesn’t have it, chances are Hubzilla has had it for longer than Mastodon has even been around.

And so forth.

Common fallacy that the only thing in the Fediverse that people use is Mastodon.

Misskey, for example, is bigger than Lemmy AFAIK.

We’ll see what comes out of this.

Mike has already implemented FEP-ef61 on (streams), and it seemed to have worked well under lab conditions. But then he rolled it out to release in July. Channels created on accounts registered after that point have decentralised IDs already. And surprisingly, it caused tons of bugs to the point of these channels not properly federating with anything. And since he’s the only (streams) developer, he had to iron everything out himself. And quickly so because a few dozen people use (streams) as a daily driver.

In mid-August, he forked Forte from the streams repository. It was his vision of “the Fediverse of 2030”: basically (streams), but only supporting ActivityPub anymore, with both (streams)’ own Nomad and Hubzilla’s Zot6 ripped out. Guess the idea was to have something with no extra protocols standing in the way of straightening FEP-ef61 and nomadic identity via ActivityPub. But this caused even more of a workload.

On August 31st, Mike sent a private post to his immediate connections (his channel is set up to send private posts by default) that said that he quits. He wanted to stop developing for the Fediverse because it got too much. The community could carry on if they want.

Trouble is, there’s nobody among the few dozen (streams) users who has got what it takes, namely both the time and especially the skills to take over as a lead dev. One guy is ambitious, but he has only recently taught himself git just to make his own pre-FEP-ef61 branch for personal use. Then there are a few people who do know git, who may also know how to code, but who don’t have the time.

We got one offer by a guy who wanted to rewrite (streams) from scratch. He had taken a look at the (streams) code, and he said that some of it is very old and crufty and mouldy. Of course, a lot of code probably still dates back to 2012 when Mike forked Red from Friendica to implement nomadic identity and rewrote the entire backend against Zot. Problem was, I think that guy came from Mastodon, he probably hadn’t even seen Friendica in action, much less Hubzilla or even (streams), and he described himself as “thick”, so we’d have to explain everything to him. Nobody even reacted.

Luckily, Mike is still Mike. He can’t keep his fingers off improving the Fediverse. Every couple days, we see commits to the streams repository and/or Forte. It’s just that things are moving forward very slowly now. The community is trying to figure out what and where the bugs can be by examining log files and whatnot, but nobody can track them down in the source, much less fix them and submit a PR, and that isn’t talking about merging the PR.

I hope this Join the Fediverse Wiki article can help you. I’ve written it myself.

It’s mostly written to pick up Mastodon users who don’t know much about the rest of the Fediverse, so it doesn’t really explain how Hubzilla relates to Lemmy. I hope it helps anyway.