#blocklistmeta — Public Fediverse posts

@Kevin Karhan :verified: To quote Arthur C. Clarke:

Any sufficiently advanced technology is indistinguishable from magic.

And for your average Musk escapees, Mastodon alone is more than sufficiently advanced. These people believe that there's some magic going on that makes their fully public posts private and secure regardless. They want perfect security, but with zero inconvenience, and they think Mastodon provides them with exactly this.

In fact, they expect Mastodon to be an absolutely perfectly safe haven, simply because it isn't a corporate silo. Little do they know how close to being a corporate silo Mastodon is, what with having a US-based company and a lighthouse instance that accounts for 22% of the whole Fediverse in terms of MAUs.

On top of that, more than half of all Mastodon users think the Fediverse is only Mastodon, and most of the rest can't imagine that anything in the Fediverse could possibly have features that Mastodon doesn't have. Not unless you slap them right into their faces like character limits over 500.

They cling hard to and rely on an imagination of the Fediverse that has never even been close to reality and never will.

As for The Bad Space, its blocklist looks like it's curated not by evidence, but by emotional triggers. Generally, some blocklists go so wild that you have to ask yourself whether the reason why nobody has tried to block out everything that isn't vanilla Mastodon is because that'd be too big an effort (two out of three Fediverse instances aren't Mastodon), or whether such people simply don't know how far the Fediverse extends beyond Mastodon, so they don't know what to block. I mean, there should be reasons enough to block everything that isn't Mastodon.

Blocklist import from other instances doesn't make things any better. Just like on all networks where everyone can run a server, the Fediverse, especially Mastodon, has got admins who really shouldn't run a server. It looks very tempting to pick blocklists by length rather than content, the longer, the more "secure", import a bunch of them, but not curate them because that'd be extra effort.

In this light, it's a good thing that Oliphant put the tier-1 to tier-3 blocklists onto the chopping block when switching from manual list curation to automated list aggregation a while ago. Especially tier 3 would have been easy to exploit with little to no curation, and there certainly were enough sufficiently paranoid Mastodon admins who'd subscribe to tier 3 without ever taking a single peek at the list.

Sometimes I feel like going to Mastodon's GitHub repository and submitting blocking or allowing entire Fediverse server applications by user agent, both for admins and for users, as a feature request, just to see what'll happen. Maybe dumbed down on the user side to a switch that blocks everything that isn't Mastodon. But maybe I should also mention that (streams) already has this feature on the admin side so that the Mastodon devs have to think up a way to sell this as invented by Mastodon.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #NotOnlyMastodon #FediverseIsNotMastodon #MastodonIsNotTheFediverse #Blocklist #Blocklists #BlocklistMeta #CWBlocklistMeta

@Robert W. Gehl One important thing to know about the Threads blocklist: Not all blocked instances were blocked because of bad content and/or blocking Threads. Not even all blocked instances were blocked because they do something that Threads doesn't like, but that isn't typical for their instance type.

In some cases, a block was caused by something that is inherent to the project, the server type and perfectly normal for it.

For example, an absolute requirement for Threads to allow a Fediverse instance to connect is for it to have a publicly accessible feed containing everything that happens on the instance, including federated content coming in. On Mastodon, this is called the federated timeline, and AFAIK, it is hard-coded.

On Hubzilla, it is called the public stream or, in short, pubstream. Hubzilla has a number of hub-wide options for the pubstream. It can be local or federated. Also, it can be visible to everyone out there, but its visibility can be limited in various steps, including only logged-in users identified via OpenWebAuth, only local users who can access the pubstream through their burger menu (but visitors can't), or not at all.

And indeed, by default, Hubzilla's pubstream is turned off entirely. Not only that, but good public Hubzilla hubs with capable, competent admins never make the pubstream public. That's because even with Hubzilla's extensive and powerful permission settings, it's impossible for admins to moderate the pubstream. What comes in because the users let it come in comes in, and it shows up in the pubstream, and the admin can't do much against it.

Now, there's the risk of Hubzilla hub admins being held liable for content showing up in the pubstream. They don't have any control over this content, but that doesn't count. It shows up on "their website", so they'll have to take the blame. To protect themselves and keep this from happening, they don't grant public access to the pubstream. Usually, they don't grant any access to the pubstream.

But without public access to the pubstream, Threads doesn't let a Hubzilla hub connect. This is one of the two reasons why hub.netzgemeinde.eu, the largest Hubzilla hub, is blocked by Threads.

Curiously, this is not why the second-largest Hubzilla hub, hub.hubzilla.de, is blocked, even though it doesn't have a publicly-accessible pubstream either. There seems to be a case of ToS violation in play.

I guess it's because Threads' entire ActivityPub connectivity was designed only against Mastodon and Misskey. However, Hubzilla works vastly different from these two, ranging from a different conversation model to its extensive permission settings to nomadic identity. There could be a collision somewhere.

Another possibility discussed among Hubzilla users: Whether an instance is allowed to connect to Threads is not decided by humans, but by an AI. And this AI is only trained on Mastodon and Misskey. Hubzilla has a vastly different UI, however, and it handles vastly differently. An AI trained only on Mastodon and Misskey will be unable to find certain elements in Hubzilla's Web UI. Also, it will test Hubzilla's compliance against Mastodon and Misskey standards with methods designed for Mastodon and Misskey which therefore will fail on Hubzilla.

This means that if a Hubzilla hub is blocked by Threads, that doesn't mean it's a bad actor and deserves to be Fediblocked in general. It means that Hubzilla's philosophy and/or Hubzilla's UI/UX clashes with Threads' standards which are only geared towards Mastodon and Misskey, i.e. microblogging with no permission control and a publicly-available federated feed.

I also guess that Threads doesn't bother with instances with fewer than 1,000 users. And hub.netzgemeinde.eu and hub.hubzilla.de are the only Hubzilla hubs with 1,000 users or more. Otherwise, there'd be a whole lot more Hubzilla hubs and probably also most (streams) instances on the list. But they're all too small for Threads to care.

(Sorry, I have to add this hashtag block to trigger people's filters when necessary.)

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Meta #Threads #Blocklist #Blocklists #BlocklistMeta #CWBlocklistMeta #Hubzilla #Streams #(streams)