@Alison Wilder Because if you want full-blown user rights and all the same features as a local user on all over 30,000 Fediverse instances, you need a local user account on each one of them.

This means two things:

• If you come over to the Fediverse for the first time, and you register your first account on Mastodon, you automatically also register an account on 30,000+ more instances.
• If you decide to host your own instance of whatever, and you spin it up for the first time, your instance immediately creates tens of millions of user accounts. One for everyone who has ever joined the Fediverse. Because anyone may decide to come over to your instance and use it, just like so.

For one, this is utter overkill.

Besides, this is technologically impossible. This would require all Fediverse instances to know all other Fediverse instances. With no exceptions. Like, if I start up my own (streams) instance for the first time, and half a second later, someone on the other side of the globe starts up a Gancio instance, they would immediately have to know each other. And all the other instances in the Fediverse.

And, of course, it would require a newly-launched instance to know all Fediverse users. Again, with no exception.

How and from which source are they supposed to know?

That said, there is a single sign-on system for the Fediverse. It's called OpenWebAuth. It was created by @Mike Macgirvin (creator of Friendica and all its descendants) in the late 2010s already for now-defunct Zap, a fork (of a fork?) of Hubzilla which, in turn, is a fork of the currently hyped Facebook alternative Friendica. It was backported to Hubzilla in 2020. Everything that came after Zap, including the still existing streams repository, got it, too.

However, first of all, OpenWebAuth is only fully implemented on Hubzilla, (streams) and Forte. Plus, it has client-side support on Friendica. This means that Hubzilla, (streams) and Forte recognise logins on all four, but Friendica doesn't recognise logins from anywhere.

As for Mastodon, OpenWebAuth implementation was actually developed to the point of an official merge request in Mastodon's GitHub repository. As far as I know, it was rejected. Mastodon won't implement OpenWebAuth, full stop.

Besides, it doesn't give you all the same power as a local user. You can't log into Friendica, go to a Hubzilla hub and create a wiki or a webpage or a CalDAV calendar, just like so.

OpenWebAuth is only for guest permissions. Because on Hubzilla, (streams) and Forte, permissions are everything.

For example, let's assume you have an account and a channel on (streams). Let's also assume that your (streams) channel and this Hubzilla channel of mine here are connected. Furthermore, let's assume that I've decided to only allow my own full connections to see my profile.

If you're logged out, and you go to my profile page, you see nothing.

But then you log in. And you come back to my profile page (provided your browser is configured so that the Hubzilla hub that I call home is allowed to create cookies). My home hub recognises your login on (streams). It identifies you as you, as one of my contacts. Thus, it identifies you as someone who is permitted to see my profile.

And all of a sudden, you see my profile.

That, for example, is what OpenWebAuth is for.

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

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