Blocks due to lack of incompatibility with Mastodon and its culture may happen; CW: long (3,750 characters), Fediverse meta, non-Mastodon Fediverse meta, user blocking meta, instance blocking meta
View article
View summary
This whole thread gave me to think.
Could it be that countless Friendica, Hubzilla and (streams) users are blocked on countless mostly Mastodon instances by the admins because reporting users the Mastodon doesn't work on these projects?
So there's a user who doesn't fully act according to the Mastodon community standards. That user's posts appear on some Mastodon instance.
The wrongdoing: For example, what's perceived as hashtag abuse; see the linked thread. Or no Mastodon-style content warning where Mastodon culture would demand one*. Or something like that.
What does the admin do? Use the report system to report that user to the admins and moderators of their own home instance.
Problem: That particular user isn't on Mastodon. Not on anything that was modelled after Mastodon either. That user is on Friendica or Hubzilla or (streams). Correct me if I'm wrong, but AFAIK, neither has Mastodon's report system implemented.
The report never reaches the admin of that instance. And the instance doesn't have any more staff.
Well, then they could write directly to the admin of that instance. If only the Fediverse contact of the instance admin was available on the instance frontpage. Or anywhere on the instance Web interface.
Even if they could, they might get the idea that they could catch the admin's attention by mentioning them in a public post. Spoiler: Doesn't work with Friendica accounts, Hubzilla channels and (streams) channels.
Oh, and at least Hubzilla and (streams) allow you to restrict from whom you receive direct messages. Regardless of whether or not that's a good idea, it's possible to make it so that DMs from random Mastodon users no longer end up in your stream. Worse yet: These Mastodon users don't even know that their DMs don't reach the recipient.
Okay, last resort, complaints about that user can be posted publicly under the hashtag #MastoAdmin. Should reach lots of admins, right?
Yes, but almost exclusively Mastodon admins. It's MastoAdmin, after all. Why should an admin of, say, a Friendica node or a Hubzilla hub follow that hashtag? Neither of them is Mastodon, and neither of them has anything to do with Mastodon. They didn't even federate with Mastodon, Mastodon federated with them.
Oh, and besides, to my best knowledge, they can't even follow hashtags in the first place. Or is Hubzilla the only one out of the three that doesn't have that feature yet?
Anyways, the warning with the #MastoAdmin hashtag doesn't reach them either.
So whatever you try to let some Friendica or Hubzilla or (streams) admin know that a user on their instance "misbehaves", the admin doesn't react and "moderate" that user.
Conclusion for your typical Mastodon admin: That instance is unmoderated. From the point of view of people who only know Mastodon beyond the name, the admin must ignore all reports.
We can be glad if this leads only to blocking the "misbehaving" user on lots of Mastodon instances and not to what's standard for unmoderated or undermoderated instances on Mastodon: blocking the whole instance.
*Footnote: Neither of the three projects mentioned here has a "Content Warning" field. Hubzilla and (streams) have a "Summary" field which is the same thing, but especially newbies and those who are hardly in touch with the ActivityPub side of the Fediverse don't know it's the same. Also, that field is only available for posts (= first posts) and not for comments (= replies which are something entirely different on these projects). Friendica doesn't even have that; a pair of BBcode tags is needed for a Mastodon-style content warning, and AFAIK, this isn't documented anywhere.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #BlockingMeta #BlocklistMeta #CWBlocklistMeta
Could it be that countless Friendica, Hubzilla and (streams) users are blocked on countless mostly Mastodon instances by the admins because reporting users the Mastodon doesn't work on these projects?
So there's a user who doesn't fully act according to the Mastodon community standards. That user's posts appear on some Mastodon instance.
The wrongdoing: For example, what's perceived as hashtag abuse; see the linked thread. Or no Mastodon-style content warning where Mastodon culture would demand one*. Or something like that.
What does the admin do? Use the report system to report that user to the admins and moderators of their own home instance.
Problem: That particular user isn't on Mastodon. Not on anything that was modelled after Mastodon either. That user is on Friendica or Hubzilla or (streams). Correct me if I'm wrong, but AFAIK, neither has Mastodon's report system implemented.
The report never reaches the admin of that instance. And the instance doesn't have any more staff.
Well, then they could write directly to the admin of that instance. If only the Fediverse contact of the instance admin was available on the instance frontpage. Or anywhere on the instance Web interface.
Even if they could, they might get the idea that they could catch the admin's attention by mentioning them in a public post. Spoiler: Doesn't work with Friendica accounts, Hubzilla channels and (streams) channels.
Oh, and at least Hubzilla and (streams) allow you to restrict from whom you receive direct messages. Regardless of whether or not that's a good idea, it's possible to make it so that DMs from random Mastodon users no longer end up in your stream. Worse yet: These Mastodon users don't even know that their DMs don't reach the recipient.
Okay, last resort, complaints about that user can be posted publicly under the hashtag #MastoAdmin. Should reach lots of admins, right?
Yes, but almost exclusively Mastodon admins. It's MastoAdmin, after all. Why should an admin of, say, a Friendica node or a Hubzilla hub follow that hashtag? Neither of them is Mastodon, and neither of them has anything to do with Mastodon. They didn't even federate with Mastodon, Mastodon federated with them.
Oh, and besides, to my best knowledge, they can't even follow hashtags in the first place. Or is Hubzilla the only one out of the three that doesn't have that feature yet?
Anyways, the warning with the #MastoAdmin hashtag doesn't reach them either.
So whatever you try to let some Friendica or Hubzilla or (streams) admin know that a user on their instance "misbehaves", the admin doesn't react and "moderate" that user.
Conclusion for your typical Mastodon admin: That instance is unmoderated. From the point of view of people who only know Mastodon beyond the name, the admin must ignore all reports.
We can be glad if this leads only to blocking the "misbehaving" user on lots of Mastodon instances and not to what's standard for unmoderated or undermoderated instances on Mastodon: blocking the whole instance.
*Footnote: Neither of the three projects mentioned here has a "Content Warning" field. Hubzilla and (streams) have a "Summary" field which is the same thing, but especially newbies and those who are hardly in touch with the ActivityPub side of the Fediverse don't know it's the same. Also, that field is only available for posts (= first posts) and not for comments (= replies which are something entirely different on these projects). Friendica doesn't even have that; a pair of BBcode tags is needed for a Mastodon-style content warning, and AFAIK, this isn't documented anywhere.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #BlockingMeta #BlocklistMeta #CWBlocklistMeta
show all 12 comments
@jupiter_rowland
My Two Cents...
IMO, #MastoAdmin tag should not be used for user moderation at all, even if it's just for Mastodon related moderation.
There are plenty of hashtags out there for that.
Same for direct communication to end users, like notifying end users of planned downtime or server updates, esp version updates.
That's my two cents.
My Two Cents...
IMO, #MastoAdmin tag should not be used for user moderation at all, even if it's just for Mastodon related moderation.
There are plenty of hashtags out there for that.
Same for direct communication to end users, like notifying end users of planned downtime or server updates, esp version updates.
That's my two cents.
@jupiter_rowland and this is exactly why we need to focus on empowering users and not admins, so that users can shape their own experiences without relying on that complicated dance of admins that may never really result in a satisfactory outcome.
Empower users.
So that they don’t have to rely on all of these other structures to shape their experiences for them.
You could say it’s why so many of us left the big platforms in the first place.
Empower users.
So that they don’t have to rely on all of these other structures to shape their experiences for them.
You could say it’s why so many of us left the big platforms in the first place.
It is good and important that we empower users to moderate their own friends and inbox by giving them tools and instructions on how to do so, but there are also some other things that could be done.
For example, it might be useful to implement the following:
1. A standard way to announce to other projects who the administrators or moderators are.
2. A standard way to report a post via ActivityPub that automatically gets delivered to the correct people.
3. A moderation system for handling reports on each platform.
4. Bounce messages if a message cannot be delivered.
It would still be up to the projects to implement this, but developers are more likely to implement it if there is a standard.
For those concerned about privacy, if you are in a country that does not require you to disclose who runs the website, you could just put "Administrator" as the name of the Administrator. Even though you did not give a person or organization's name, there is still a listed Administrator for the instance.
For example, it might be useful to implement the following:
1. A standard way to announce to other projects who the administrators or moderators are.
2. A standard way to report a post via ActivityPub that automatically gets delivered to the correct people.
3. A moderation system for handling reports on each platform.
4. Bounce messages if a message cannot be delivered.
It would still be up to the projects to implement this, but developers are more likely to implement it if there is a standard.
For those concerned about privacy, if you are in a country that does not require you to disclose who runs the website, you could just put "Administrator" as the name of the Administrator. Even though you did not give a person or organization's name, there is still a listed Administrator for the instance.
@volkris If done the Friendica/Hubzilla/(streams) way, that'd be disturbing to Mastodon users again.
I think nobody on Mastodon knows this, but these three projects have a Facebook-like/Tumblr-like/blog-like one-post-many-comments thread structure as opposed to Mastodon's Twitter-like many-single-posts-tied-together thread structure.
This means the thread starter owns the whole thread. This also means the thread starter can moderate their own thread and even delete comments from their own thread. Even if they weren't appointed moderators by the admin. AFAIK, the deletion is actually forwarded to the source.
So a Mastodon user may e.g. troll around in a thread started on Hubzilla or attack the thread starter. A bit later, that Mastodon user will discover that their toots in reply to that Hubzilla posts are gone. Maybe the thread starter even mentions they've moderated their own thread and deleted comments.
The short form: Regular users of Friendica, Hubzilla and (streams) can delete Mastodon toots. In fact, posts from anywhere. Only toots/posts in reply to their own posts, but yes, they can. And they could before Mastodon even existed.
If this started happening often enough, and word started spreading around especially Mastodon, it'd be perceived as invasive and disruptive by many. It might cause such a big uproar that even more Mastodon users would call for defederating Friendica, Hubzilla and (streams) completely.
As for actual, traditional moderation, I'm not saying it's bad per se.
I'm saying that many Mastodon admins really don't know anything about the Fediverse outside Mastodon.
They think everything else that does *blogging is basically Mastodon with a different UI. Like an alternative mobile app for Mastodon itself. Or it's Mastodon + feature x on top. But otherwise like Mastodon.
And then they act accordingly. They try to interact with Friendica, Hubzilla and (streams) admins the same way as they interact with other Mastodon admins. And they neither know nor realise that these three projects are too different from Mastodon for these methods to even work!
Again:
You can't report a Hubzilla user to a Hubzilla admin using the report system because Hubzilla does not have Mastodon's report system!
You can't expect Hubzilla admins to follow hashtags for Mastodon instance admins either. Not only because they aren't Mastodon admins, and they probably don't even know that hashtag. But because you can't follow hashtags on Hubzilla!
And so forth.
So what appears to be a Hubzilla admin's laziness or carelessness or ignorance are actually technical differences between Mastodon and Hubzilla that Mastodon admins are unaware of.
This has nothing to with moderation by admins/mods only being bad. This has everything to do with Hubzilla being vastly different from Mastodon. And with Mastodon admins/mods not knowing jack shit about Hubzilla.
(Good thing this is so long that nobody will read it. Otherwise it'll empower those who say that Friendica, Hubzilla and (streams) must be redesigned to be exactly like Mastodon or face full defederation otherwise for being too different.)
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta
I think nobody on Mastodon knows this, but these three projects have a Facebook-like/Tumblr-like/blog-like one-post-many-comments thread structure as opposed to Mastodon's Twitter-like many-single-posts-tied-together thread structure.
This means the thread starter owns the whole thread. This also means the thread starter can moderate their own thread and even delete comments from their own thread. Even if they weren't appointed moderators by the admin. AFAIK, the deletion is actually forwarded to the source.
So a Mastodon user may e.g. troll around in a thread started on Hubzilla or attack the thread starter. A bit later, that Mastodon user will discover that their toots in reply to that Hubzilla posts are gone. Maybe the thread starter even mentions they've moderated their own thread and deleted comments.
The short form: Regular users of Friendica, Hubzilla and (streams) can delete Mastodon toots. In fact, posts from anywhere. Only toots/posts in reply to their own posts, but yes, they can. And they could before Mastodon even existed.
If this started happening often enough, and word started spreading around especially Mastodon, it'd be perceived as invasive and disruptive by many. It might cause such a big uproar that even more Mastodon users would call for defederating Friendica, Hubzilla and (streams) completely.
As for actual, traditional moderation, I'm not saying it's bad per se.
I'm saying that many Mastodon admins really don't know anything about the Fediverse outside Mastodon.
They think everything else that does *blogging is basically Mastodon with a different UI. Like an alternative mobile app for Mastodon itself. Or it's Mastodon + feature x on top. But otherwise like Mastodon.
And then they act accordingly. They try to interact with Friendica, Hubzilla and (streams) admins the same way as they interact with other Mastodon admins. And they neither know nor realise that these three projects are too different from Mastodon for these methods to even work!
Again:
You can't report a Hubzilla user to a Hubzilla admin using the report system because Hubzilla does not have Mastodon's report system!
You can't expect Hubzilla admins to follow hashtags for Mastodon instance admins either. Not only because they aren't Mastodon admins, and they probably don't even know that hashtag. But because you can't follow hashtags on Hubzilla!
And so forth.
So what appears to be a Hubzilla admin's laziness or carelessness or ignorance are actually technical differences between Mastodon and Hubzilla that Mastodon admins are unaware of.
This has nothing to with moderation by admins/mods only being bad. This has everything to do with Hubzilla being vastly different from Mastodon. And with Mastodon admins/mods not knowing jack shit about Hubzilla.
(Good thing this is so long that nobody will read it. Otherwise it'll empower those who say that Friendica, Hubzilla and (streams) must be redesigned to be exactly like Mastodon or face full defederation otherwise for being too different.)
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta
@Scott M. Stolz
Good luck getting Mastodon to implement any standard they haven't invented themselves.
This will end in
This won't change much about many public, open-registration Friendica/Hubzilla instances not providing a link to the account/channel of the admin. Or any admin contact at all. All because the admin didn't bother to edit that page/hasn't gotten to it yet.
And it changes nothing about Mastodon users/admins trying to reach Friendica/Hubzilla/(streams) admins the exact same way as they always try to reach other Mastodon admins. And failing because it doesn't work like on Mastodon. Even less in a mobile app that's geared towards Mastodon and Mastodon only.
Don't forget: On Hubzilla, everyone's on a Linux PC using a standard browser. On Mastodon, everyone's on a phone using a Mastodon app.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta
For example, it might be useful to implement the following:
1. A standard way to announce to other projects who the administrators or moderators are.
2. A standard way to report a post via ActivityPub that automatically gets delivered to the correct people.
3. A moderation system for handling reports on each platform.
4. Bounce messages if a message cannot be delivered.
It would still be up to the projects to implement this, but developers are more likely to implement it if there is a standard.
Good luck getting Mastodon to implement any standard they haven't invented themselves.
This will end in
- Mastodon trying to push their own standard upon everyone else, Mike Macgirvin having it in dev alreeady, but Mario Vavti staunchly refusing it because he doesn't let Mastodon push anything upon him
- Mike Macgirvin making his own proposal, the best one of them all, which is rejected by everyone from the W3C to Eugen Rochko
- maybe, if they get their act together, the W3C making a proposal which Mike Macgirvin either rejects for being ridiculously weak or implements within 15 minutes, which Mario Vavti rejects because it'd be next to impossible to weave into Hubzilla and Zot6, and which Eugen Rochko rejects because Mastodon already has something that covers this, and everyone else must adopt this or else
For those concerned about privacy, if you are in a country that does not require you to disclose who runs the website, you could just put "Administrator" as the name of the Administrator. Even though you did not give a person or organization's name, there is still a listed Administrator for the instance.
This won't change much about many public, open-registration Friendica/Hubzilla instances not providing a link to the account/channel of the admin. Or any admin contact at all. All because the admin didn't bother to edit that page/hasn't gotten to it yet.
And it changes nothing about Mastodon users/admins trying to reach Friendica/Hubzilla/(streams) admins the exact same way as they always try to reach other Mastodon admins. And failing because it doesn't work like on Mastodon. Even less in a mobile app that's geared towards Mastodon and Mastodon only.
Don't forget: On Hubzilla, everyone's on a Linux PC using a standard browser. On Mastodon, everyone's on a phone using a Mastodon app.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta
"Regular users of Friendica, Hubzilla and (streams) can delete Mastodon toots."
Not really. Here's the deal...
If you post kiddie porn and it arrives on my site, I can delete it from my site. I can also refuse to share it with my followers or anybody else on my site. Of course I can, because I can go to jail if I don't delete it. I don't care who posted it. This is common sense and applies to all fediverse software.
I can't delete something you own from your own site. Only you or your site admin can do that.
@Mike Macgirvin 🖥️ Ah, okay. But AFAIK you can remove comments from your own threads, even if that deletion isn't forwarded to its origin.
That's true. My thread is a container for posts and comments and I own it. So is my stream or home timeline. And if I'm the admin, so is my site. These are all different aspects of the same issue. You might own the post, but I own the container, and I get to decide if something goes into it. Not you.
@jupiter_rowland oh it’s even “worse” than @mikedev indicates.
A basic design choice of the Fediverse protocol is that ANY content that leaves the origin instance goes into a wild west where nobody has technical ownership of the content, period.
As Mike said, you can delete content from your own instance, no matter where the content came from, but you have no way to require anyone else to delete the content from theirs.
So even if you start a thread, don’t like how it’s going, and then decide to delete it, you have no way to enforce the deletion. The thread is free to continue on other instances.
Basically, you can send out a deletion request, but nobody else has to respect the request.
And BTW this gets even worse when considering that the privacy control is similarly just a request. A key element of the protocol is that nobody has to respect post privacy controls.
A basic design choice of the Fediverse protocol is that ANY content that leaves the origin instance goes into a wild west where nobody has technical ownership of the content, period.
As Mike said, you can delete content from your own instance, no matter where the content came from, but you have no way to require anyone else to delete the content from theirs.
So even if you start a thread, don’t like how it’s going, and then decide to delete it, you have no way to enforce the deletion. The thread is free to continue on other instances.
Basically, you can send out a deletion request, but nobody else has to respect the request.
And BTW this gets even worse when considering that the privacy control is similarly just a request. A key element of the protocol is that nobody has to respect post privacy controls.
@volkris
If "the protocol" refers to ActivityPub, maybe.
If it refers to Zot, nope. If it refers to Nomad, even less.
When it comes to privacy control, Zot could do things when first implemented in 2012 that Mastodon users can't even imagine in 2024.
#FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta
And BTW this gets even worse when considering that the privacy control is similarly just a request. A key element of the protocol is that nobody has to respect post privacy controls.
If "the protocol" refers to ActivityPub, maybe.
If it refers to Zot, nope. If it refers to Nomad, even less.
When it comes to privacy control, Zot could do things when first implemented in 2012 that Mastodon users can't even imagine in 2024.
#FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta
@jupiter_rowland yeah, I was referring to ActivityPub since (as far as I can tell) for better or worse, that’s what people around here are referring to with the term Fediverse.
Conversation Features
Loading...
Login
Login
- Copyright © 2024 WisTex TechSero Ltd. Co. All rights reserved.
Web hosting provided by TechSero Web Services.