> ActivityPub prevents that a social media platform becomes a silo (see photo) that can’t communicate with other platforms.
I wish that were true. In practice, server admins are more than happy to block federation with entire other domains (and all associated users, hundreds or thousands at a time) based on little more than gossip and rumor.
Imagine if email services worked this way! “subscriber@otherhost is rumored to be slightly politically oriented in a way we don’t like, so we as admins have prevented everyone@thishost from mailing everyone@otherhost, and vice versa”.
“the internet treats censorship like damage and something something”
I’m glad that, in practice, you can still email people who are destination-server-adjacent to users your local mailserver admin hates. (Of course, mailservers can configure to drop mail from specified MXes too—but they don’t. Usually they get spam-foldered.)
PS: I’m on the fediverse at @sneak@sneak.berlin and would love more people to follow.
> In practice, server admins are more than happy to block federation with entire other domains (and all associated users, hundreds or thousands at a time) based on little more than gossip and rumor.
If that is easily possible this is doomed from the start, IMO.
You get into situations where you are at the mercy of a single person.
The linked issue's closing comment is even more backward.
The issue opener did not asked for talking to people which do not want talk to him.
Blocking between users is one thing, and can be good to have. Their issue was that the whole federate instance doesn't peers with him, out of theirs or the federated instance in questions people choice or support.
Peering needs to be done unconditionally, even over edges, IMO. Blocking needs to be in the sole control of the user, not the admin of a federation server. All else doesn't makes this better than Facebook, or any other single server instance without federation.
> How is it worse than Twitter, which can also ban you?
Who said anything about twitter and worse?? Shouldn't this be better than Twitter?
> What about instances that are mostly spam? What about instances that are dedicated to harassment (eg. Kiwifarms)?
Why is that an issue? You do not get spewed their spam in your face as long as you do not follow anybody?
It has to be the users decision, anything else is doomed to be abused against users.
And if this would become an issue, and one want's to have a more drastic approach to handle bad apples a decision of the a federates instances users, i.e., a conses or quorum, needs to decide.
> you're free to use an instance with a block policy that aligns with your opinion
No, you do not understand the basic issue here. Not only the block policy of the instance I'm on is the issue, but all the others. So how does your proposal solves this?
Agreed on all points, except that with Mastodon is always possible to create a single-user instance where (a) you are in control of the blocklists and (b) admins of other instances will be less likely to block you.
(b) less likely is, well, less likely. Better but not of use, as seen in the linked issue you can easily "loose" access to 19000 other people, just due to one admin with whatever reasoning, good or bad, they have - in a "Fediverse" it should be never the decision of the admin for the users.
At least if the goal is not having silos and decentralization.
> Imagine if email services worked this way! “subscriber@otherhost is rumored to be slightly politically oriented in a way we don’t like, so we as admins have prevented everyone@thishost from mailing everyone@otherhost, and vice versa”.
This actually does happen. It's not as common as it is with ActivityPub servers, but it exists. Most mail servers do have ways of rejecting or blackholing content from specific addresses or domains. The functionality became necessary for dealing with spam mail. :/
Yeah, you are not wrong but to me this seems something of a mastodon-exclusive cultural issue. They are confusing federation with tribalism. I've also already read some excuse like "you can always create an account in the other instances if you want to follow anyone there" but to me this just seems like they are missing the point and/or coming up with a way to avoid the harder of work of implementing proper user-level filtering controls.
You can do that on email no problem, and its common as heck for major email providers to block on little more than a mail server being in the same IP block as a bunch of spammers.
Its not the same you say? Yet no email admin is prevented from doing things as you describe.
>I wish that were true. In practice, server admins are more than happy to block federation with entire other domains (and all associated users, hundreds or thousands at a time) based on little more than gossip and rumor.
That's the prerogative of the instance owner. If the instance owner doesn't want to see certain posts, or undesirable posts from certain users, they don't have to. It's their own server, and they can choose what content to host on there.
If you don't like that fact, you can go to an instance which has few or little in the way of defederation (and there are many), or you can host your own instance. But what's unreasonable is to demand that server owners should have to allow certain communication on their platforms. If the owner demands you must wear a chicken hat when you post, you'd better wear the chicken hat. Or just go elsewhere, if you don't like that rule.
Would you demand the same thing of HN? Should there be no moderation at all? What about Twitter? If I were the owner of an instance, and I found out I'm seeing child porn on my server's timeline, would it be unreasonable of me to unsubscribe from that user, or defederate with their instance, if their instance has a habit of allowing that material? Let's say it's not illegal, but morally undesirable to the owner of the instance. Why should that change anything?
You have freedom of speech, but you (and the instance owners) have freedom of association. To take away one necessarily lessens the other. By joining to an instance, you agree to the administration policy, and that includes defederation policies. Just as you shouldn't be annoyed at being banned for spamming (e.g. on the basis of an anti-spam rule), you shouldn't be annoyed at the instance owner defederating (e.g. on the basis of a "no child porn" rule).
You seem to be confusing my complaining about a behavior (instance operators being stupid) and my being entitled to force them to behave in a non-stupid way. This is a common misunderstanding.
You're preaching to the choir about "their server, their rules". I just think that censorship is dumb, and server admins that do this are dumb. They're entirely within their rights to be dumb on their own hardware.
I do run my own instance. And thousands of people, some of whom I wish to read, have been denied the possibility of me following them (despite their toots still available on the public internet for anyone, myself included, to view) because one such admin has been this type of dumb.
I agree that's a problem. But I don't think we can blame the technology for that. After all, an email server admin can do the same thing, but they rarely do.
This is a cultural thing, and instances that engage in excessive blocking tends to become isolated islands eventually.
If you don't properly moderate your instance, your instance will have to be blocked entirely because you can't expect every instance host to moderate every user on every instance individually. This is the solution to decentralized moderation and I think it's great.
> Imagine if email services worked this way! “subscriber@otherhost is rumored to be slightly politically oriented in a way we don’t like, so we as admins have prevented everyone@thishost from mailing everyone@otherhost, and vice versa”.
Entire instances don't get blocked just because of one user's political opinion.
The most extreme case I can imagine is that of a couple of subscriber@otherhost being harmful to other instances, and the admins of "otherhost" refusing to do anything about it. So some instances ("thishost") would preventively block "otherhost" if they don't want to deal with every single harmful user from that instance.
But if that block policy of "thishost" is publicly advertised, then what's wrong with that? It's like users choosing a blocklist provider on Twitter.
> Entire instances don't get blocked just because of one user's political opinion.
Not often, but it has happened with a couple of instances. There's a group of 7 or so that's trying to wall itself off entirely from anybody who federates with anyone who federates with the crap instances, which I think is excessive – just defederate with the crap ones and soft-block those that don't at least soft-block the crap ones; that's sufficient for most cases.
However, it's a minority of instances that do that, and I don't know of one where the users don't know. The system works; I can still see stuff on the utter shithole corners of the Fediverse, if I choose (hint: I don't), but it's not pushed in my face.
Just because they want to push things in my face, doesn't mean everybody has to let them “unless I opt out”. That's an opt-in kind of thing, in my book.
I wish that were true. In practice, server admins are more than happy to block federation with entire other domains (and all associated users, hundreds or thousands at a time) based on little more than gossip and rumor.
Imagine if email services worked this way! “subscriber@otherhost is rumored to be slightly politically oriented in a way we don’t like, so we as admins have prevented everyone@thishost from mailing everyone@otherhost, and vice versa”.
https://github.com/tootsuite/mastodon/issues/12600
“the internet treats censorship like damage and something something”
I’m glad that, in practice, you can still email people who are destination-server-adjacent to users your local mailserver admin hates. (Of course, mailservers can configure to drop mail from specified MXes too—but they don’t. Usually they get spam-foldered.)
PS: I’m on the fediverse at @sneak@sneak.berlin and would love more people to follow.