@Tim Chambers @marcelcosta @Jon If either are accurate. All I know is that CalcKey is growing like crazy because it gets a whole lot of exposure and publicity in the Fediverse, and because it's currently the most feature-rich ActivityPub-based project while still having a decent UI.

In this regard, I think the refusal to include Akkoma and CalcKey because Pleroma and MissKey are already there isn't quite smart. Pleroma barely matters because Akkoma outshines it, and MissKey only matters in Japan while CalcKey is booming over here.

I’d say: it’s a start…and I could see from an analysis standpoint how the researcher started with what was doable directly via the #mastodon API. But hopefully to add others as they can.

Just a comment. @spla queried APIs from servers with many software installed, not just mastodon.

@ophiocephalic 🐍 @Tim Chambers @Fediverse Report @Spread Mastodon As a #FederatedSocialWeb veteran and former self-hoster of my own private #Friendica and #Hubzilla instances, I have to say that I can hardly see literally absolutely the whole Fediverse fediblocking #Meta.

You have to keep a few things in mind.

First of all, the Fediverse is not only #Mastodon. Nor is the Fediverse only about a dozen big projects. The Fediverse is dozens upon dozens of big and small projects.

For the whole Fediverse to fediblock Meta, every single last one of them, even just recently launched private proof-of-concept alphas of brand-new projects which nonetheless will federate, will require not only a mandatory instance-wide blocking mechanism, but a mandatory standard blacklist with Meta's instance on it. Otherwise developers can't test-drive their new Fediverse server application without their test instance being defederated left and right for not blocking Meta.

Of course, this would also mean that everything that even only as much as understands #ActivityPub would require such a mandatory default blacklist with Meta on it. Even if it isn't based on ActivityPub. Even if ActivityPub is an add-on, a plug-in, maybe even third-party like in the case of #WordPress. Even if ActivityPub has to be manually activated instance-wide by the admin and then separately by the users for each one of their channels like in Hubzilla's case.

That is, putting Meta on the same list as all other defederated instances would probably be considered not enough. Blocking Meta would have to be hard-coded into the engine of the project itself, also to mandatorily roll it out to all instances of all projects. Instance block lists aren't part of the source code, and if they became that, lots of not-so-techy instance admins would end up with file conflicts they can't solve because the git pull involved in the upgrade would try to create a file that already exists.

Still, this wouldn't be 100% water-tight. An absolutely mandatory fediblock for Meta would mean certain death for lots and lots of small private instances. Admins of such tiny instances often only do the very bare necessities to keep them running. Sometimes they rarely or never even upgrade the underlying operating system, much less the Fediverse project running on it. Why should they? It runs. And an upgrade means a) a hassle and b) probably more of a hassle if stuff breaks.

Just to prove my point: There are still Mastodon 3.x instances in the Fediverse. There are still a very few running small instances of #Osada and #Zap, both of which have been discontinued on New Year's Eve 2022. These projects are no longer maintained. They won't get any updates anymore. They were superseded by #Streams, and not everyone who still runs these old projects wants to do the switch.

And then there are those projects that are technically still in development, but whose development has slowed down dramatically. Look at how often #Pleroma rolls out new versions. And Pleroma isn't exactly obscure, it has public instances. Or look at #Plume which counts as still actively developed, but whose devs barely find any time to do anything, so it often doesn't get any updates in many months. I don't even think that Plume has any means of blocking instances by blacklist.

So if blocking Meta becomes mandatory, you can fediblock an entire long-form blogging project out of the Fediverse with all its private and public instances because not a single instance will participate in blocking Meta, because not a single instance is even capable of doing that, because the capability is not included and rolled out in time, because the devs can't find the time to include it.

@Jupiter Rowland

Doesn’t the entire ”blocking” argument fall on the logical hurdle of ”blocking everyone who doesn’t block…” as that literally will be a never-ending and forever incomplete route to go. Shouldn’t white-listing be what they (kolektiva) actually are after? That they only allow a named appointed set of instances.

That will also, obviously, mean that unless they have some VERY dedicated community managers, they will only be whitelisting instances of certain sizes…this is clearly a case where centralization wins over decentralization; as an instance with 30k users require as much admin work as an instance-of-one. All the small instances will likely be shut out, simply due to the admin burden of adding them.

By that point it becomes worthwhile to do a re-take on if a whitelist-only Fediverse is the correct solution for those communities. I obviously don’t mean I personally do not want them here, I am talking about that the community leaders of such a community should perhaps reconsider if using a completely open protocol with absolutely no privacy built-in to it, to be the best safety barrier for privacy and to keep the dragons out.

It is a tricky thing to both be open and ”findable” whilst also locking everyone out by default unless they’ve proven themselves in some way, which is impossible unless manual action is taken in the first place.

I’m mostly thinking out loud, reflecting on the conundrum of both viewpoints, so I mean no offence this or that way.

@Tim Chambers @ophiocephalic 🐍 @Fediverse Report @Spread Mastodon

@Mathias Hellquist (Friendica) It's mostly people on large-enough Mastodon instances who barely (or not at all) know there's a Fediverse outside Mastodon who are in favour of a whitelist-only Fediverse.

A Fediverse that only works on whitelists would mean certain death not only to smaller instances and thereby to self-hosting your own private instance, but also to new instances in general and new projects. Developers who create new projects couldn't test-drive them with working federation unless their experimental test instance started out right away as a "lighthouse" instance with thousands of unique active users and 24/7 moderation.

In fact, entire projects would end up defederated because they don't have a single instance that's what the whitelisting crowd deems large enough. Hubzilla and (streams) could just as well remove ActivityPub support because all their instances are too small to be whitelisted; at least, it wouldn't matter anymore if their instances had ActivityPub on or not. Since Plume and WriteFreely would probably end up with not a single instance on the whitelists, and WordPress blogs don't count as Fediverse instances, the Mastodon-centric Fediverse would lose its long-form blogging capability.

But maybe that's what the whitelist supporters want. Maybe they want to make the Fediverse what they themselves have spent months believing what it is: only Mastodon.

@Tim Chambers @ophiocephalic 🐍 @Spread Mastodon