#blocklistmeta — Public Fediverse posts

@Chao-c'

Friendica is missing polls altogether and the stunt with language auto-detection is damaging built-in translation feature in Mastodon.

Mastodon has no concept of enclosed conversations which is damaging threaded conversations at least on Hubzilla, (streams) and Forte, as they were created by Mike Macgirvin for Mistpark (now Friendica) in 2010. Mastodon has no chance whatsoever to implement FEP-171b "Conversation Containers" because it lacks even the bare basics.

This is the very reason why Mike Macgirvin (creator of Friendica and Hubzilla and still maintainer of (streams) and Forte) has introduced yet another server-wide anti-Mastodon countermeasure named FedUp to both (streams) and Forte. Its effect is that it blocks all Fediverse server software that doesn't understand enclosed, one-post-several-comments conversations and the principle of all comments always going directly to the original poster who then forwards them to all other participants in the conversation.

(streams) and Forte already have the server-wide User Agent Filter that can block entire Fediverse server applications by their user channel. It was created and mostly marketed as a way of blocking Threads without a URL list, without constantly having to add new URLs to a list because Threads changed its URLs. But it's just as capable at entirely blocking all present and future Mastodon servers, and Mike even describes it as such.

Also, want to know the reason why Mike still keeps Nomad-based (streams) alive in spite of also having ActivityPub-based Forte with almost feature parity? It's because ActivityPub is optional on (streams) at channel level. The ActivityPub switch can be used as a last-resort anti-Mastodon countermeasure even though its side-effects are tremendous. The most important (streams) group, a support group, by the way, used to have ActivityPub off with the very purpose of keeping obnoxious Mastodon users out. It only turned ActivityPub on when it also became the unofficial support group for Forte.

As I've said elsewhere: It isn't Mastodon that's the ActivityPub reference implementation of ActivityPub with everything that's different being broken. Mike Macgirvin has built all his ActivityPub implementations by the book, and so have Hubzilla developers Mario Vavti and Harald Eilertsen, two months before Mastodon itself had ActivityPub support. In the meantime, Mastodon's developers deliberately and intentionally break compatibility with the rest of the Fediverse to fool Mastodon users like you into considering the non-Mastodon Fediverse broken.

I would also appreciate longer HTML files as kind of "media attachments" and not body of the post. The main problem is perhaps that Mastodon chose to ignore the post title field altogether and does not allow markup in post body (but there is entire huge fork called Glitch, which supports markup, but perhaps markup is what you want in longer texts, kind of attachments - but not short on-wall posts?)

The solution for this would lie in the dichotomy between Note-type objects (tweets are supposed to be this) and Article-type objects (longer posts are supposed to be this).

Mastodon supports both in a way. But it only renders Note-type objects. Even then, it still throws away the title and all attached images except for the first four. Its HTML sanitiser removes half of the text formatting, including embedded images. As for Article-type objects, it shows them as a small "toot" with the title and a link to the original. Only recently, probably also under pressure from commercial players like Ghost, Mastodon added the summary which it otherwise uses as the CW field.

But this is highly inconvenient. Hardly any Mastodon user can be bothered to click or tap the link to the original. They don't understand that there's a Fediverse post behind that link, much less that if they comment on the "toot" with the link, they comment on the post behind the link itself. Besides, what's behind the link won't show up on their Mastodon interface. Instead, if they're on a phone, their browser will open.

From this stems a debate that's as old as Mastodon's participation in the Fediverse. A prime example of culture clash.

The developers and users of Friendica, Hubzilla, (streams) and Forte want Mastodon as well as all its apps to fully render all their contents in the timeline. Including the title, including all text formatting, including as many embedded images as there are, as images actually embedded within the text, of course. The very same thing happens where they are. It's normal for them. It's the standard for them. It's part of their culture. What Mastodon does on their Note-type objects is crippling and defacing, and what Mastodon does on their Article-type objects is silencing to the point of wholesale censorship of several competitors.

On the other hand, the Mastodon devs refuse to add full HTML rich text rendering to Mastodon, and the Mastodon users don't want it anyway. In fact, many Mastodon users are highly disturbed by there being "toots" that are longer than 500 characters, and some are disturbed by there being any text formatting (displaying support for which was only introduced in October, 2022 with Mastodon 4.0, by the way). Their culture is that of purist microblogging in plain text with no more than 500 characters. It's already too much what Mastodon and its apps show already now. Thousands upon thousands of Mastodon users would go and block each and every server that sends anything over 500 characters if they knew that this is an option.

At the same time, hardly anyone on Mastodon even takes into consideration that whatever "long posts" come from has something like a culture of its own in the first place. It can't be culture if it isn't Mastodon's.

As I mentioned in the previous answer, Hubzilla just does too many things differently and focuses on experience of local users of instance - not on federated interoperability.

Seriously?

Hubzilla has had full-blown nomadic identity since almost four years before Mastodon came out.

Hubzilla is almost as much an omni-federational monster as Friendica.

• It has optional ActivityPub support, unlike Mastodon almost strictly by the official W3C specification, and it has had ActivityPub support before Mastodon had it.
• It used to have optional StatusNet support which is how Mastodon federated with it immediately.
• It can optionally federate with diaspora*; Mastodon can't do that.
• It can optionally federate via ActivityPump, the protocol that replaced StatusNet on Identi.ca; Mastodon can't do that.
• It can optionally cross-post to Dreamwidth, Libertree, LiveJournal and WordPress. It has been able to do either years before WordPress got its ActivityPub plug-in. Mastodon can't do either.
• It still has the optional technology to bidirectionally connect to 𝕏; Mastodon doesn't have that.
• It still has an optional built-in XMPP client; Mastodon doesn't have that.

Mastodon is simply lights years ahead.

I sincerely hope that you only mean that Mastodon is ahead of others in terms of easy on-boarding of clueless newbies. And not that Mastodon is generally ahead of Hubzilla technologically and in features.

If the latter, I'll gladly prove you wrong.

I would prefer moderation to be more collective responsibility, so posts can receive perhaps kind of negative points, and people can choose to join shared blocklists and so, instead of relying of some superhero capabilites of moderators (which I don't have).

The problem with this is blind faith in those who maintain the blocklists.

Big blocklists tend to be automatically generated from smaller blocklists, letting everything from each one of these blocklists in, only weeding out double entries, if at all. Single persons have unlimited power over who is allowed to interact with thousands upon thousands of Mastodon servers and who isn't.

Now imagine that someone who maintains a popular blocklist is too disturbed by non-Mastodon content. It's too long, it doesn't follow Mastodon guidelines, it goes against Mastodon's culture, so it has to go. And then they start adding every single server URL from which obvious non-Mastodon content comes to their blocklist. Or they even use a script to harvest FediDB and Fediverse Observer for URLs of servers of certain non-Mastodon Fediverse applications and automatically add them to their blocklist.

And all of a sudden, almost entire non-Mastodon Fediverse server applications are completely blocked from thousands upon thousands of Mastodon servers just because they aren't Mastodon, just because they don't act like Mastodon. Essentially, just because one individual wants the Fediverse to be only Mastodon "again" (which it never was).

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Mastodon #MastodonCentricity #MastodonNormativity #Friendica #Hubzilla #Streams #(streams) #Forte #CharacterLimit #CharacterLimits #CharacterLimitMeta #CWCharacterLimitMeta #Conversations #FEP_171b #ConversationContainers #Blocklist #Blocklists #BlocklistMeta #CWBlocklistMeta

@Chao-c'

Friendica is missing polls altogether and the stunt with language auto-detection is damaging built-in translation feature in Mastodon.

Mastodon has no concept of enclosed conversations which is damaging threaded conversations at least on Hubzilla, (streams) and Forte, as they were created by Mike Macgirvin for Mistpark (now Friendica) in 2010. Mastodon has no chance whatsoever to implement FEP-171b "Conversation Containers" because it lacks even the bare basics.

This is the very reason why Mike Macgirvin (creator of Friendica and Hubzilla and still maintainer of (streams) and Forte) has introduced yet another server-wide anti-Mastodon countermeasure named FedUp to both (streams) and Forte. Its effect is that it blocks all Fediverse server software that doesn't understand enclosed, one-post-several-comments conversations and the principle of all comments always going directly to the original poster who then forwards them to all other participants in the conversation.

(streams) and Forte already have the server-wide User Agent Filter that can block entire Fediverse server applications by their user channel. It was created and mostly marketed as a way of blocking Threads without a URL list, without constantly having to add new URLs to a list because Threads changed its URLs. But it's just as capable at entirely blocking all present and future Mastodon servers, and Mike even describes it as such.

Also, want to know the reason why Mike still keeps Nomad-based (streams) alive in spite of also having ActivityPub-based Forte with almost feature parity? It's because ActivityPub is optional on (streams) at channel level. The ActivityPub switch can be used as a last-resort anti-Mastodon countermeasure even though its side-effects are tremendous. The most important (streams) group, a support group, by the way, used to have ActivityPub off with the very purpose of keeping obnoxious Mastodon users out. It only turned ActivityPub on when it also became the unofficial support group for Forte.

As I've said elsewhere: It isn't Mastodon that's the ActivityPub reference implementation of ActivityPub with everything that's different being broken. Mike Macgirvin has built all his ActivityPub implementations by the book, and so have Hubzilla developers Mario Vavti and Harald Eilertsen, two months before Mastodon itself had ActivityPub support. In the meantime, Mastodon's developers deliberately and intentionally break compatibility with the rest of the Fediverse to fool Mastodon users like you into considering the non-Mastodon Fediverse broken.

I would also appreciate longer HTML files as kind of "media attachments" and not body of the post. The main problem is perhaps that Mastodon chose to ignore the post title field altogether and does not allow markup in post body (but there is entire huge fork called Glitch, which supports markup, but perhaps markup is what you want in longer texts, kind of attachments - but not short on-wall posts?)

The solution for this would lie in the dichotomy between Note-type objects (tweets are supposed to be this) and Article-type objects (longer posts are supposed to be this).

Mastodon supports both in a way. But it only renders Note-type objects. Even then, it still throws away the title and all attached images except for the first four. Its HTML sanitiser removes half of the text formatting, including embedded images. As for Article-type objects, it shows them as a small "toot" with the title and a link to the original. Only recently, probably also under pressure from commercial players like Ghost, Mastodon added the summary which it otherwise uses as the CW field.

But this is highly inconvenient. Hardly any Mastodon user can be bothered to click or tap the link to the original. They don't understand that there's a Fediverse post behind that link, much less that if they comment on the "toot" with the link, they comment on the post behind the link itself. Besides, what's behind the link won't show up on their Mastodon interface. Instead, if they're on a phone, their browser will open.

From this stems a debate that's as old as Mastodon's participation in the Fediverse. A prime example of culture clash.

The developers and users of Friendica, Hubzilla, (streams) and Forte want Mastodon as well as all its apps to fully render all their contents in the timeline. Including the title, including all text formatting, including as many embedded images as there are, as images actually embedded within the text, of course. The very same thing happens where they are. It's normal for them. It's the standard for them. It's part of their culture. What Mastodon does on their Note-type objects is crippling and defacing, and what Mastodon does on their Article-type objects is silencing to the point of wholesale censorship of several competitors.

On the other hand, the Mastodon devs refuse to add full HTML rich text rendering to Mastodon, and the Mastodon users don't want it anyway. In fact, many Mastodon users are highly disturbed by there being "toots" that are longer than 500 characters, and some are disturbed by there being any text formatting (displaying support for which was only introduced in October, 2022 with Mastodon 4.0, by the way). Their culture is that of purist microblogging in plain text with no more than 500 characters. It's already too much what Mastodon and its apps show already now. Thousands upon thousands of Mastodon users would go and block each and every server that sends anything over 500 characters if they knew that this is an option.

At the same time, hardly anyone on Mastodon even takes into consideration that whatever "long posts" come from has something like a culture of its own in the first place. It can't be culture if it isn't Mastodon's.

As I mentioned in the previous answer, Hubzilla just does too many things differently and focuses on experience of local users of instance - not on federated interoperability.

Seriously?

Hubzilla has had full-blown nomadic identity since almost four years before Mastodon came out.

Hubzilla is almost as much an omni-federational monster as Friendica.

• It has optional ActivityPub support, unlike Mastodon almost strictly by the official W3C specification, and it has had ActivityPub support before Mastodon had it.
• It used to have optional StatusNet support which is how Mastodon federated with it immediately.
• It can optionally federate with diaspora*; Mastodon can't do that.
• It can optionally federate via ActivityPump, the protocol that replaced StatusNet on Identi.ca; Mastodon can't do that.
• It can optionally cross-post to Dreamwidth, Libertree, LiveJournal and WordPress. It has been able to do either years before WordPress got its ActivityPub plug-in. Mastodon can't do either.
• It still has the optional technology to bidirectionally connect to 𝕏; Mastodon doesn't have that.
• It still has an optional built-in XMPP client; Mastodon doesn't have that.

Mastodon is simply lights years ahead.

I sincerely hope that you only mean that Mastodon is ahead of others in terms of easy on-boarding of clueless newbies. And not that Mastodon is generally ahead of Hubzilla technologically and in features.

If the latter, I'll gladly prove you wrong.

I would prefer moderation to be more collective responsibility, so posts can receive perhaps kind of negative points, and people can choose to join shared blocklists and so, instead of relying of some superhero capabilites of moderators (which I don't have).

The problem with this is blind faith in those who maintain the blocklists.

Big blocklists tend to be automatically generated from smaller blocklists, letting everything from each one of these blocklists in, only weeding out double entries, if at all. Single persons have unlimited power over who is allowed to interact with thousands upon thousands of Mastodon servers and who isn't.

Now imagine that someone who maintains a popular blocklist is too disturbed by non-Mastodon content. It's too long, it doesn't follow Mastodon guidelines, it goes against Mastodon's culture, so it has to go. And then they start adding every single server URL from which obvious non-Mastodon content comes to their blocklist. Or they even use a script to harvest FediDB and Fediverse Observer for URLs of servers of certain non-Mastodon Fediverse applications and automatically add them to their blocklist.

And all of a sudden, almost entire non-Mastodon Fediverse server applications are completely blocked from thousands upon thousands of Mastodon servers just because they aren't Mastodon, just because they don't act like Mastodon. Essentially, just because one individual wants the Fediverse to be only Mastodon "again" (which it never was).

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Mastodon #MastodonCentricity #MastodonNormativity #Friendica #Hubzilla #Streams #(streams) #Forte #CharacterLimit #CharacterLimits #CharacterLimitMeta #CWCharacterLimitMeta #Conversations #FEP_171b #ConversationContainers #Blocklist #Blocklists #BlocklistMeta #CWBlocklistMeta

@Chao-c'

Friendica is missing polls altogether and the stunt with language auto-detection is damaging built-in translation feature in Mastodon.

Mastodon has no concept of enclosed conversations which is damaging threaded conversations at least on Hubzilla, (streams) and Forte, as they were created by Mike Macgirvin for Mistpark (now Friendica) in 2010. Mastodon has no chance whatsoever to implement FEP-171b "Conversation Containers" because it lacks even the bare basics.

This is the very reason why Mike Macgirvin (creator of Friendica and Hubzilla and still maintainer of (streams) and Forte) has introduced yet another server-wide anti-Mastodon countermeasure named FedUp to both (streams) and Forte. Its effect is that it blocks all Fediverse server software that doesn't understand enclosed, one-post-several-comments conversations and the principle of all comments always going directly to the original poster who then forwards them to all other participants in the conversation.

(streams) and Forte already have the server-wide User Agent Filter that can block entire Fediverse server applications by their user channel. It was created and mostly marketed as a way of blocking Threads without a URL list, without constantly having to add new URLs to a list because Threads changed its URLs. But it's just as capable at entirely blocking all present and future Mastodon servers, and Mike even describes it as such.

Also, want to know the reason why Mike still keeps Nomad-based (streams) alive in spite of also having ActivityPub-based Forte with almost feature parity? It's because ActivityPub is optional on (streams) at channel level. The ActivityPub switch can be used as a last-resort anti-Mastodon countermeasure even though its side-effects are tremendous. The most important (streams) group, a support group, by the way, used to have ActivityPub off with the very purpose of keeping obnoxious Mastodon users out. It only turned ActivityPub on when it also became the unofficial support group for Forte.

As I've said elsewhere: It isn't Mastodon that's the ActivityPub reference implementation of ActivityPub with everything that's different being broken. Mike Macgirvin has built all his ActivityPub implementations by the book, and so have Hubzilla developers Mario Vavti and Harald Eilertsen, two months before Mastodon itself had ActivityPub support. In the meantime, Mastodon's developers deliberately and intentionally break compatibility with the rest of the Fediverse to fool Mastodon users like you into considering the non-Mastodon Fediverse broken.

I would also appreciate longer HTML files as kind of "media attachments" and not body of the post. The main problem is perhaps that Mastodon chose to ignore the post title field altogether and does not allow markup in post body (but there is entire huge fork called Glitch, which supports markup, but perhaps markup is what you want in longer texts, kind of attachments - but not short on-wall posts?)

The solution for this would lie in the dichotomy between Note-type objects (tweets are supposed to be this) and Article-type objects (longer posts are supposed to be this).

Mastodon supports both in a way. But it only renders Note-type objects. Even then, it still throws away the title and all attached images except for the first four. Its HTML sanitiser removes half of the text formatting, including embedded images. As for Article-type objects, it shows them as a small "toot" with the title and a link to the original. Only recently, probably also under pressure from commercial players like Ghost, Mastodon added the summary which it otherwise uses as the CW field.

But this is highly inconvenient. Hardly any Mastodon user can be bothered to click or tap the link to the original. They don't understand that there's a Fediverse post behind that link, much less that if they comment on the "toot" with the link, they comment on the post behind the link itself. Besides, what's behind the link won't show up on their Mastodon interface. Instead, if they're on a phone, their browser will open.

From this stems a debate that's as old as Mastodon's participation in the Fediverse. A prime example of culture clash.

The developers and users of Friendica, Hubzilla, (streams) and Forte want Mastodon as well as all its apps to fully render all their contents in the timeline. Including the title, including all text formatting, including as many embedded images as there are, as images actually embedded within the text, of course. The very same thing happens where they are. It's normal for them. It's the standard for them. It's part of their culture. What Mastodon does on their Note-type objects is crippling and defacing, and what Mastodon does on their Article-type objects is silencing to the point of wholesale censorship of several competitors.

On the other hand, the Mastodon devs refuse to add full HTML rich text rendering to Mastodon, and the Mastodon users don't want it anyway. In fact, many Mastodon users are highly disturbed by there being "toots" that are longer than 500 characters, and some are disturbed by there being any text formatting (displaying support for which was only introduced in October, 2022 with Mastodon 4.0, by the way). Their culture is that of purist microblogging in plain text with no more than 500 characters. It's already too much what Mastodon and its apps show already now. Thousands upon thousands of Mastodon users would go and block each and every server that sends anything over 500 characters if they knew that this is an option.

At the same time, hardly anyone on Mastodon even takes into consideration that whatever "long posts" come from has something like a culture of its own in the first place. It can't be culture if it isn't Mastodon's.

As I mentioned in the previous answer, Hubzilla just does too many things differently and focuses on experience of local users of instance - not on federated interoperability.

Seriously?

Hubzilla has had full-blown nomadic identity since almost four years before Mastodon came out.

Hubzilla is almost as much an omni-federational monster as Friendica.

• It has optional ActivityPub support, unlike Mastodon almost strictly by the official W3C specification, and it has had ActivityPub support before Mastodon had it.
• It used to have optional StatusNet support which is how Mastodon federated with it immediately.
• It can optionally federate with diaspora*; Mastodon can't do that.
• It can optionally federate via ActivityPump, the protocol that replaced StatusNet on Identi.ca; Mastodon can't do that.
• It can optionally cross-post to Dreamwidth, Libertree, LiveJournal and WordPress. It has been able to do either years before WordPress got its ActivityPub plug-in. Mastodon can't do either.
• It still has the optional technology to bidirectionally connect to 𝕏; Mastodon doesn't have that.
• It still has an optional built-in XMPP client; Mastodon doesn't have that.

Mastodon is simply lights years ahead.

I sincerely hope that you only mean that Mastodon is ahead of others in terms of easy on-boarding of clueless newbies. And not that Mastodon is generally ahead of Hubzilla technologically and in features.

If the latter, I'll gladly prove you wrong.

I would prefer moderation to be more collective responsibility, so posts can receive perhaps kind of negative points, and people can choose to join shared blocklists and so, instead of relying of some superhero capabilites of moderators (which I don't have).

The problem with this is blind faith in those who maintain the blocklists.

Big blocklists tend to be automatically generated from smaller blocklists, letting everything from each one of these blocklists in, only weeding out double entries, if at all. Single persons have unlimited power over who is allowed to interact with thousands upon thousands of Mastodon servers and who isn't.

Now imagine that someone who maintains a popular blocklist is too disturbed by non-Mastodon content. It's too long, it doesn't follow Mastodon guidelines, it goes against Mastodon's culture, so it has to go. And then they start adding every single server URL from which obvious non-Mastodon content comes to their blocklist. Or they even use a script to harvest FediDB and Fediverse Observer for URLs of servers of certain non-Mastodon Fediverse applications and automatically add them to their blocklist.

And all of a sudden, almost entire non-Mastodon Fediverse server applications are completely blocked from thousands upon thousands of Mastodon servers just because they aren't Mastodon, just because they don't act like Mastodon. Essentially, just because one individual wants the Fediverse to be only Mastodon "again" (which it never was).

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Mastodon #MastodonCentricity #MastodonNormativity #Friendica #Hubzilla #Streams #(streams) #Forte #CharacterLimit #CharacterLimits #CharacterLimitMeta #CWCharacterLimitMeta #Conversations #FEP_171b #ConversationContainers #Blocklist #Blocklists #BlocklistMeta #CWBlocklistMeta

@Chao-c'

Friendica is missing polls altogether and the stunt with language auto-detection is damaging built-in translation feature in Mastodon.

Mastodon has no concept of enclosed conversations which is damaging threaded conversations at least on Hubzilla, (streams) and Forte, as they were created by Mike Macgirvin for Mistpark (now Friendica) in 2010. Mastodon has no chance whatsoever to implement FEP-171b "Conversation Containers" because it lacks even the bare basics.

This is the very reason why Mike Macgirvin (creator of Friendica and Hubzilla and still maintainer of (streams) and Forte) has introduced yet another server-wide anti-Mastodon countermeasure named FedUp to both (streams) and Forte. Its effect is that it blocks all Fediverse server software that doesn't understand enclosed, one-post-several-comments conversations and the principle of all comments always going directly to the original poster who then forwards them to all other participants in the conversation.

(streams) and Forte already have the server-wide User Agent Filter that can block entire Fediverse server applications by their user channel. It was created and mostly marketed as a way of blocking Threads without a URL list, without constantly having to add new URLs to a list because Threads changed its URLs. But it's just as capable at entirely blocking all present and future Mastodon servers, and Mike even describes it as such.

Also, want to know the reason why Mike still keeps Nomad-based (streams) alive in spite of also having ActivityPub-based Forte with almost feature parity? It's because ActivityPub is optional on (streams) at channel level. The ActivityPub switch can be used as a last-resort anti-Mastodon countermeasure even though its side-effects are tremendous. The most important (streams) group, a support group, by the way, used to have ActivityPub off with the very purpose of keeping obnoxious Mastodon users out. It only turned ActivityPub on when it also became the unofficial support group for Forte.

As I've said elsewhere: It isn't Mastodon that's the ActivityPub reference implementation of ActivityPub with everything that's different being broken. Mike Macgirvin has built all his ActivityPub implementations by the book, and so have Hubzilla developers Mario Vavti and Harald Eilertsen, two months before Mastodon itself had ActivityPub support. In the meantime, Mastodon's developers deliberately and intentionally break compatibility with the rest of the Fediverse to fool Mastodon users like you into considering the non-Mastodon Fediverse broken.

I would also appreciate longer HTML files as kind of "media attachments" and not body of the post. The main problem is perhaps that Mastodon chose to ignore the post title field altogether and does not allow markup in post body (but there is entire huge fork called Glitch, which supports markup, but perhaps markup is what you want in longer texts, kind of attachments - but not short on-wall posts?)

The solution for this would lie in the dichotomy between Note-type objects (tweets are supposed to be this) and Article-type objects (longer posts are supposed to be this).

Mastodon supports both in a way. But it only renders Note-type objects. Even then, it still throws away the title and all attached images except for the first four. Its HTML sanitiser removes half of the text formatting, including embedded images. As for Article-type objects, it shows them as a small "toot" with the title and a link to the original. Only recently, probably also under pressure from commercial players like Ghost, Mastodon added the summary which it otherwise uses as the CW field.

But this is highly inconvenient. Hardly any Mastodon user can be bothered to click or tap the link to the original. They don't understand that there's a Fediverse post behind that link, much less that if they comment on the "toot" with the link, they comment on the post behind the link itself. Besides, what's behind the link won't show up on their Mastodon interface. Instead, if they're on a phone, their browser will open.

From this stems a debate that's as old as Mastodon's participation in the Fediverse. A prime example of culture clash.

The developers and users of Friendica, Hubzilla, (streams) and Forte want Mastodon as well as all its apps to fully render all their contents in the timeline. Including the title, including all text formatting, including as many embedded images as there are, as images actually embedded within the text, of course. The very same thing happens where they are. It's normal for them. It's the standard for them. It's part of their culture. What Mastodon does on their Note-type objects is crippling and defacing, and what Mastodon does on their Article-type objects is silencing to the point of wholesale censorship of several competitors.

On the other hand, the Mastodon devs refuse to add full HTML rich text rendering to Mastodon, and the Mastodon users don't want it anyway. In fact, many Mastodon users are highly disturbed by there being "toots" that are longer than 500 characters, and some are disturbed by there being any text formatting (displaying support for which was only introduced in October, 2022 with Mastodon 4.0, by the way). Their culture is that of purist microblogging in plain text with no more than 500 characters. It's already too much what Mastodon and its apps show already now. Thousands upon thousands of Mastodon users would go and block each and every server that sends anything over 500 characters if they knew that this is an option.

At the same time, hardly anyone on Mastodon even takes into consideration that whatever "long posts" come from has something like a culture of its own in the first place. It can't be culture if it isn't Mastodon's.

As I mentioned in the previous answer, Hubzilla just does too many things differently and focuses on experience of local users of instance - not on federated interoperability.

Seriously?

Hubzilla has had full-blown nomadic identity since almost four years before Mastodon came out.

Hubzilla is almost as much an omni-federational monster as Friendica.

• It has optional ActivityPub support, unlike Mastodon almost strictly by the official W3C specification, and it has had ActivityPub support before Mastodon had it.
• It used to have optional StatusNet support which is how Mastodon federated with it immediately.
• It can optionally federate with diaspora*; Mastodon can't do that.
• It can optionally federate via ActivityPump, the protocol that replaced StatusNet on Identi.ca; Mastodon can't do that.
• It can optionally cross-post to Dreamwidth, Libertree, LiveJournal and WordPress. It has been able to do either years before WordPress got its ActivityPub plug-in. Mastodon can't do either.
• It still has the optional technology to bidirectionally connect to 𝕏; Mastodon doesn't have that.
• It still has an optional built-in XMPP client; Mastodon doesn't have that.

Mastodon is simply lights years ahead.

I sincerely hope that you only mean that Mastodon is ahead of others in terms of easy on-boarding of clueless newbies. And not that Mastodon is generally ahead of Hubzilla technologically and in features.

If the latter, I'll gladly prove you wrong.

I would prefer moderation to be more collective responsibility, so posts can receive perhaps kind of negative points, and people can choose to join shared blocklists and so, instead of relying of some superhero capabilites of moderators (which I don't have).

The problem with this is blind faith in those who maintain the blocklists.

Big blocklists tend to be automatically generated from smaller blocklists, letting everything from each one of these blocklists in, only weeding out double entries, if at all. Single persons have unlimited power over who is allowed to interact with thousands upon thousands of Mastodon servers and who isn't.

Now imagine that someone who maintains a popular blocklist is too disturbed by non-Mastodon content. It's too long, it doesn't follow Mastodon guidelines, it goes against Mastodon's culture, so it has to go. And then they start adding every single server URL from which obvious non-Mastodon content comes to their blocklist. Or they even use a script to harvest FediDB and Fediverse Observer for URLs of servers of certain non-Mastodon Fediverse applications and automatically add them to their blocklist.

And all of a sudden, almost entire non-Mastodon Fediverse server applications are completely blocked from thousands upon thousands of Mastodon servers just because they aren't Mastodon, just because they don't act like Mastodon. Essentially, just because one individual wants the Fediverse to be only Mastodon "again" (which it never was).

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Mastodon #MastodonCentricity #MastodonNormativity #Friendica #Hubzilla #Streams #(streams) #Forte #CharacterLimit #CharacterLimits #CharacterLimitMeta #CWCharacterLimitMeta #Conversations #FEP_171b #ConversationContainers #Blocklist #Blocklists #BlocklistMeta #CWBlocklistMeta

@Chao-c'

Friendica is missing polls altogether and the stunt with language auto-detection is damaging built-in translation feature in Mastodon.

Mastodon has no concept of enclosed conversations which is damaging threaded conversations at least on Hubzilla, (streams) and Forte, as they were created by Mike Macgirvin for Mistpark (now Friendica) in 2010. Mastodon has no chance whatsoever to implement FEP-171b "Conversation Containers" because it lacks even the bare basics.

This is the very reason why Mike Macgirvin (creator of Friendica and Hubzilla and still maintainer of (streams) and Forte) has introduced yet another server-wide anti-Mastodon countermeasure named FedUp to both (streams) and Forte. Its effect is that it blocks all Fediverse server software that doesn't understand enclosed, one-post-several-comments conversations and the principle of all comments always going directly to the original poster who then forwards them to all other participants in the conversation.

(streams) and Forte already have the server-wide User Agent Filter that can block entire Fediverse server applications by their user channel. It was created and mostly marketed as a way of blocking Threads without a URL list, without constantly having to add new URLs to a list because Threads changed its URLs. But it's just as capable at entirely blocking all present and future Mastodon servers, and Mike even describes it as such.

Also, want to know the reason why Mike still keeps Nomad-based (streams) alive in spite of also having ActivityPub-based Forte with almost feature parity? It's because ActivityPub is optional on (streams) at channel level. The ActivityPub switch can be used as a last-resort anti-Mastodon countermeasure even though its side-effects are tremendous. The most important (streams) group, a support group, by the way, used to have ActivityPub off with the very purpose of keeping obnoxious Mastodon users out. It only turned ActivityPub on when it also became the unofficial support group for Forte.

As I've said elsewhere: It isn't Mastodon that's the ActivityPub reference implementation of ActivityPub with everything that's different being broken. Mike Macgirvin has built all his ActivityPub implementations by the book, and so have Hubzilla developers Mario Vavti and Harald Eilertsen, two months before Mastodon itself had ActivityPub support. In the meantime, Mastodon's developers deliberately and intentionally break compatibility with the rest of the Fediverse to fool Mastodon users like you into considering the non-Mastodon Fediverse broken.

I would also appreciate longer HTML files as kind of "media attachments" and not body of the post. The main problem is perhaps that Mastodon chose to ignore the post title field altogether and does not allow markup in post body (but there is entire huge fork called Glitch, which supports markup, but perhaps markup is what you want in longer texts, kind of attachments - but not short on-wall posts?)

The solution for this would lie in the dichotomy between Note-type objects (tweets are supposed to be this) and Article-type objects (longer posts are supposed to be this).

Mastodon supports both in a way. But it only renders Note-type objects. Even then, it still throws away the title and all attached images except for the first four. Its HTML sanitiser removes half of the text formatting, including embedded images. As for Article-type objects, it shows them as a small "toot" with the title and a link to the original. Only recently, probably also under pressure from commercial players like Ghost, Mastodon added the summary which it otherwise uses as the CW field.

But this is highly inconvenient. Hardly any Mastodon user can be bothered to click or tap the link to the original. They don't understand that there's a Fediverse post behind that link, much less that if they comment on the "toot" with the link, they comment on the post behind the link itself. Besides, what's behind the link won't show up on their Mastodon interface. Instead, if they're on a phone, their browser will open.

From this stems a debate that's as old as Mastodon's participation in the Fediverse. A prime example of culture clash.

The developers and users of Friendica, Hubzilla, (streams) and Forte want Mastodon as well as all its apps to fully render all their contents in the timeline. Including the title, including all text formatting, including as many embedded images as there are, as images actually embedded within the text, of course. The very same thing happens where they are. It's normal for them. It's the standard for them. It's part of their culture. What Mastodon does on their Note-type objects is crippling and defacing, and what Mastodon does on their Article-type objects is silencing to the point of wholesale censorship of several competitors.

On the other hand, the Mastodon devs refuse to add full HTML rich text rendering to Mastodon, and the Mastodon users don't want it anyway. In fact, many Mastodon users are highly disturbed by there being "toots" that are longer than 500 characters, and some are disturbed by there being any text formatting (displaying support for which was only introduced in October, 2022 with Mastodon 4.0, by the way). Their culture is that of purist microblogging in plain text with no more than 500 characters. It's already too much what Mastodon and its apps show already now. Thousands upon thousands of Mastodon users would go and block each and every server that sends anything over 500 characters if they knew that this is an option.

At the same time, hardly anyone on Mastodon even takes into consideration that whatever "long posts" come from has something like a culture of its own in the first place. It can't be culture if it isn't Mastodon's.

As I mentioned in the previous answer, Hubzilla just does too many things differently and focuses on experience of local users of instance - not on federated interoperability.

Seriously?

Hubzilla has had full-blown nomadic identity since almost four years before Mastodon came out.

Hubzilla is almost as much an omni-federational monster as Friendica.

• It has optional ActivityPub support, unlike Mastodon almost strictly by the official W3C specification, and it has had ActivityPub support before Mastodon had it.
• It used to have optional StatusNet support which is how Mastodon federated with it immediately.
• It can optionally federate with diaspora*; Mastodon can't do that.
• It can optionally federate via ActivityPump, the protocol that replaced StatusNet on Identi.ca; Mastodon can't do that.
• It can optionally cross-post to Dreamwidth, Libertree, LiveJournal and WordPress. It has been able to do either years before WordPress got its ActivityPub plug-in. Mastodon can't do either.
• It still has the optional technology to bidirectionally connect to 𝕏; Mastodon doesn't have that.
• It still has an optional built-in XMPP client; Mastodon doesn't have that.

Mastodon is simply lights years ahead.

I sincerely hope that you only mean that Mastodon is ahead of others in terms of easy on-boarding of clueless newbies. And not that Mastodon is generally ahead of Hubzilla technologically and in features.

If the latter, I'll gladly prove you wrong.

I would prefer moderation to be more collective responsibility, so posts can receive perhaps kind of negative points, and people can choose to join shared blocklists and so, instead of relying of some superhero capabilites of moderators (which I don't have).

The problem with this is blind faith in those who maintain the blocklists.

Big blocklists tend to be automatically generated from smaller blocklists, letting everything from each one of these blocklists in, only weeding out double entries, if at all. Single persons have unlimited power over who is allowed to interact with thousands upon thousands of Mastodon servers and who isn't.

Now imagine that someone who maintains a popular blocklist is too disturbed by non-Mastodon content. It's too long, it doesn't follow Mastodon guidelines, it goes against Mastodon's culture, so it has to go. And then they start adding every single server URL from which obvious non-Mastodon content comes to their blocklist. Or they even use a script to harvest FediDB and Fediverse Observer for URLs of servers of certain non-Mastodon Fediverse applications and automatically add them to their blocklist.

And all of a sudden, almost entire non-Mastodon Fediverse server applications are completely blocked from thousands upon thousands of Mastodon servers just because they aren't Mastodon, just because they don't act like Mastodon. Essentially, just because one individual wants the Fediverse to be only Mastodon "again" (which it never was).

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Mastodon #MastodonCentricity #MastodonNormativity #Friendica #Hubzilla #Streams #(streams) #Forte #CharacterLimit #CharacterLimits #CharacterLimitMeta #CWCharacterLimitMeta #Conversations #FEP_171b #ConversationContainers #Blocklist #Blocklists #BlocklistMeta #CWBlocklistMeta

@Roni Rolle Laukkarinen That's probably safer, more reliable and more sensible than those Fediverse blocklists that are compiled by easily triggered snowflakes who have never understood the Fediverse beyond Mastodon, and that are barely or not at all curated.

#FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Blocklist #Blocklists #BlockListMeta #CWBlocklistMeta

@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

@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

@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

@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

@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

@Tejan Ausland Yes, but many on Mastodon don't understand this.

For them, the Mastodon devs are the creators and keepers of the Fediverse itself as well as "the good guys" who have made the single most awesome piece of server software in decades. If the Mastodon devs even only imply that an opt-out or opt-in switch for quote-posts will bring absolute safety from being quote-posted, they take it at face value.

So when they opt out of being quote-posted, and someone from outside of Mastodon quote-posts them anyway, they won't blame it on the Mastodon devs having promised them something impossible. Never would the Mastodon devs do that.

Rather, the devs behind whatever that someone is using are the bad guys. They're rogues, they're evil hackers who have introduced quote-posts just to be able to spite and harass Mastodon users. Why else would something introduce quote-posts after all?

The one thing that'll protect wherever that someone is from their wrath is that most of them won't be able to figure out what that someone is using. Just because Mastodon users can look up a post at its source, doesn't mean they know they can, much less they actually do.

So they may try to get allegedly rogue instances Fediblocked just because these instances are non-Mastodon instances doing what they regularly do. They may succeed because at least some blocklist maintainers don't have a clue about the Fediverse outside Mastodon, its capabilities and its culture either. But it's unlikely that they'll pinpoint this culprit having used Sharkey, have all of Sharkey Fediblocked for being able to "circumvent" Mastodon's quote-post opt-out/opt-in, then pinpoint that the next quote-poster is using Akkoma and have all of Akkoma Fediblocked and so forth.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #QuotePost #QuotePosts #QuoteTweet #QuoteTweets #QuoteToot #QuoteToots #QuoteBoost #QuoteBoosts #QuotedShares #QuotePostDebate #QuoteTootDebate #Blocklist #Blocklists #BlocklistMeta #FediblockMeta

@Tejan Ausland Yes, but many on Mastodon don't understand this.

For them, the Mastodon devs are the creators and keepers of the Fediverse itself as well as "the good guys" who have made the single most awesome piece of server software in decades. If the Mastodon devs even only imply that an opt-out or opt-in switch for quote-posts will bring absolute safety from being quote-posted, they take it at face value.

So when they opt out of being quote-posted, and someone from outside of Mastodon quote-posts them anyway, they won't blame it on the Mastodon devs having promised them something impossible. Never would the Mastodon devs do that.

Rather, the devs behind whatever that someone is using are the bad guys. They're rogues, they're evil hackers who have introduced quote-posts just to be able to spite and harass Mastodon users. Why else would something introduce quote-posts after all?

The one thing that'll protect wherever that someone is from their wrath is that most of them won't be able to figure out what that someone is using. Just because Mastodon users can look up a post at its source, doesn't mean they know they can, much less they actually do.

So they may try to get allegedly rogue instances Fediblocked just because these instances are non-Mastodon instances doing what they regularly do. They may succeed because at least some blocklist maintainers don't have a clue about the Fediverse outside Mastodon, its capabilities and its culture either. But it's unlikely that they'll pinpoint this culprit having used Sharkey, have all of Sharkey Fediblocked for being able to "circumvent" Mastodon's quote-post opt-out/opt-in, then pinpoint that the next quote-poster is using Akkoma and have all of Akkoma Fediblocked and so forth.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #QuotePost #QuotePosts #QuoteTweet #QuoteTweets #QuoteToot #QuoteToots #QuoteBoost #QuoteBoosts #QuotedShares #QuotePostDebate #QuoteTootDebate #Blocklist #Blocklists #BlocklistMeta #FediblockMeta

@Tejan Ausland Yes, but many on Mastodon don't understand this.

For them, the Mastodon devs are the creators and keepers of the Fediverse itself as well as "the good guys" who have made the single most awesome piece of server software in decades. If the Mastodon devs even only imply that an opt-out or opt-in switch for quote-posts will bring absolute safety from being quote-posted, they take it at face value.

So when they opt out of being quote-posted, and someone from outside of Mastodon quote-posts them anyway, they won't blame it on the Mastodon devs having promised them something impossible. Never would the Mastodon devs do that.

Rather, the devs behind whatever that someone is using are the bad guys. They're rogues, they're evil hackers who have introduced quote-posts just to be able to spite and harass Mastodon users. Why else would something introduce quote-posts after all?

The one thing that'll protect wherever that someone is from their wrath is that most of them won't be able to figure out what that someone is using. Just because Mastodon users can look up a post at its source, doesn't mean they know they can, much less they actually do.

So they may try to get allegedly rogue instances Fediblocked just because these instances are non-Mastodon instances doing what they regularly do. They may succeed because at least some blocklist maintainers don't have a clue about the Fediverse outside Mastodon, its capabilities and its culture either. But it's unlikely that they'll pinpoint this culprit having used Sharkey, have all of Sharkey Fediblocked for being able to "circumvent" Mastodon's quote-post opt-out/opt-in, then pinpoint that the next quote-poster is using Akkoma and have all of Akkoma Fediblocked and so forth.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #QuotePost #QuotePosts #QuoteTweet #QuoteTweets #QuoteToot #QuoteToots #QuoteBoost #QuoteBoosts #QuotedShares #QuotePostDebate #QuoteTootDebate #Blocklist #Blocklists #BlocklistMeta #FediblockMeta

@Tejan Ausland Yes, but many on Mastodon don't understand this.

For them, the Mastodon devs are the creators and keepers of the Fediverse itself as well as "the good guys" who have made the single most awesome piece of server software in decades. If the Mastodon devs even only imply that an opt-out or opt-in switch for quote-posts will bring absolute safety from being quote-posted, they take it at face value.

So when they opt out of being quote-posted, and someone from outside of Mastodon quote-posts them anyway, they won't blame it on the Mastodon devs having promised them something impossible. Never would the Mastodon devs do that.

Rather, the devs behind whatever that someone is using are the bad guys. They're rogues, they're evil hackers who have introduced quote-posts just to be able to spite and harass Mastodon users. Why else would something introduce quote-posts after all?

The one thing that'll protect wherever that someone is from their wrath is that most of them won't be able to figure out what that someone is using. Just because Mastodon users can look up a post at its source, doesn't mean they know they can, much less they actually do.

So they may try to get allegedly rogue instances Fediblocked just because these instances are non-Mastodon instances doing what they regularly do. They may succeed because at least some blocklist maintainers don't have a clue about the Fediverse outside Mastodon, its capabilities and its culture either. But it's unlikely that they'll pinpoint this culprit having used Sharkey, have all of Sharkey Fediblocked for being able to "circumvent" Mastodon's quote-post opt-out/opt-in, then pinpoint that the next quote-poster is using Akkoma and have all of Akkoma Fediblocked and so forth.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #QuotePost #QuotePosts #QuoteTweet #QuoteTweets #QuoteToot #QuoteToots #QuoteBoost #QuoteBoosts #QuotedShares #QuotePostDebate #QuoteTootDebate #Blocklist #Blocklists #BlocklistMeta #FediblockMeta

@Tejan Ausland Yes, but many on Mastodon don't understand this.

For them, the Mastodon devs are the creators and keepers of the Fediverse itself as well as "the good guys" who have made the single most awesome piece of server software in decades. If the Mastodon devs even only imply that an opt-out or opt-in switch for quote-posts will bring absolute safety from being quote-posted, they take it at face value.

So when they opt out of being quote-posted, and someone from outside of Mastodon quote-posts them anyway, they won't blame it on the Mastodon devs having promised them something impossible. Never would the Mastodon devs do that.

Rather, the devs behind whatever that someone is using are the bad guys. They're rogues, they're evil hackers who have introduced quote-posts just to be able to spite and harass Mastodon users. Why else would something introduce quote-posts after all?

The one thing that'll protect wherever that someone is from their wrath is that most of them won't be able to figure out what that someone is using. Just because Mastodon users can look up a post at its source, doesn't mean they know they can, much less they actually do.

So they may try to get allegedly rogue instances Fediblocked just because these instances are non-Mastodon instances doing what they regularly do. They may succeed because at least some blocklist maintainers don't have a clue about the Fediverse outside Mastodon, its capabilities and its culture either. But it's unlikely that they'll pinpoint this culprit having used Sharkey, have all of Sharkey Fediblocked for being able to "circumvent" Mastodon's quote-post opt-out/opt-in, then pinpoint that the next quote-poster is using Akkoma and have all of Akkoma Fediblocked and so forth.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #QuotePost #QuotePosts #QuoteTweet #QuoteTweets #QuoteToot #QuoteToots #QuoteBoost #QuoteBoosts #QuotedShares #QuotePostDebate #QuoteTootDebate #Blocklist #Blocklists #BlocklistMeta #FediblockMeta

@Stefan Bohacek @Baloo Uriza At the very least, there should be such a thing as "selective import". Not just a dumb list of domains, but each domain along with the reason why it's blocked, and then a filter feature in the importer that first reads all the reasons and then lets you pick for which reasons you want to import the lines.

For one, you wouldn't blindly block any instances for reasons unknown just because they're on a blocklist.

Besides, this would keep you from blocking instances added by some Mastodon instance admin because they're too un-Mastodon-like. And yes, I can see Mastodon admins block Friendica or Hubzilla or (streams) instances just because their users, or only one user even, refuses to act like they're on Mastodon and do everything only the Mastodon way. In fact, I can see Mastodon users pester Mastodon admins into blocking non-Mastodon instances because someone there behaves too much not like Mastodon users.

If such lines were shared from instance to instance without anyone ever checking that and why they're on the list, that'd lead to the increasing defederation of non-Mastodon instances from more and more of Mastodon.

I've heard of someone with a personal Mastodon instance who blocks all (streams) instances they can find for whatever petty reasons. If other Mastodon instance admins discovered that personal instance, decided that's a good, trustworthy admin and downloaded and used the blocklist from that instance without checking it, that'd disconnect pretty much the entirety of (streams) from large parts of Mastodon.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Blocklist #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)

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

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

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

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