-

2024-06-29 17:08:30

rwg@aoir.social

Latest #FOSSAcademic post: On Threads's Blocklist

https://fossacademic.tech/2024/06/28/ThreadsBlocking.html

In which I offer some quick analysis of #Meta #Threads new list of blocked servers.

There's so much more we can do to study what Threads is doing. Indeed, I will have a chapter on Threads in my book. But these are my initial thoughts a day into this event.

[Responses to this post will appear as comments on my blog, unless they are set to followers only or DM. CWs will work]

2024-06-29 17:33:14

Maike

maikek@digitalcourage.social

@rwg I looked at meta's list and wondered whether some of the instances you mention are blocked bc of them rejecting threads federation anyway? That would surely violate meta's policies ?. Others got on the list because 'privacy policy'. Whether that means theirs or meta's they don't elaborate.

2024-06-29 20:14:39

183231bcb

183231bcb@transfem.social

threads.net

Artikel ansehen

2024-06-30 10:44:55

Jupiter Rowland

jupiter_rowland@hub.netzgemeinde.eu

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