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.
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.