[old discussion] Account Domain Blocks

#1

After a discussion on the Discord (yes yes, we know, but soon most discussions will be here) about the Domain Block feature for Accounts/Users we came to the conclusion that the feature will be implemented (there’s no going back on this now), but it may still require some tweaks.

Some of the concerns are as follows:

  • Lack of transparency and no process of appeal.

Suggested solutions:

Use-cases which address concerns:

  • Friend of friend process “Hey you are blocking my friend, on server x”
  • Admins deal with the problematic users on their server A (after they receive reports) - contact admin of server B which tells user on server B that bad accounts on server A has been dealt with

(You can also read in the etherpad here)

This is just a beginning, and we’d like your feedback both for solutions and other concerns.

Note from the admins/moderators: Posts which derail to exclaiming that the feature should not exist will be removed. Please stay on topic. Also, read the FAQ for discussion practices of this forum.

#2

i would like to mention that i am VERY Hesitant for general requests to manage unblocking requests, and would prefer there be an option to disable unblock requests in your settings, as they have a lot of opportunity to be harmful. i am not sold on the need for any changes to be made to this feature, even though i am happy to listen.

3 Likes
#3

This isn’t for “before we launch”, as I think it will not break anything launching like is. The tweaks in question is for future updates to the feature.

#4

I’m confused. I read some of the discord discussion and I’m not sure why “lack of transparency” is an issue for matters of an individual’s decision. The whole idea behind giving this power to the individual user is to remove the politics of governance and making decisions for other people. Do we demand transparency when an individual blocks an individual? That seems like it is not of the public interest.

“Haha they blocked me” is also often used as a component of mass-harassment/lolcow forums. Worn as a kind of badge of honor. Being able to see that a user has blocked a certain set of instances can be used to target a user. A tweet I made stating that I made a point of not hate-reading /r/KotakuInAction made me a target on Mastodon.

The goal of blocking is to discreetly and silently disconnect from a user.

The very concept of an “unblock request” doesn’t make sense to me. It’s uncomfortable for me. Why is it anybody’s business who an individual user blocks? It’s one thing if it is an instance admin who has blocked this domain for all of their users. An individual who has made a block already knows who they blocked. The act of blocking someone is a statement of “I don’t want to have anything else to do with you. Leave me alone.” The idea of an “unblock request” runs counter to that. It violates freedom of association and runs counter to the idea of anti-harassment.

Essentially, the user-level instance-block is a way to “not exist” from the perspective of an instance they want nothing to do with.

7 Likes
#5

Simply put, if you decentralize the power you also decentralize the responsibility. Without oversight we have mob justice and that’s just not good for the long term stability of a community. Accountability is central to building reciprocal relationships, that same lack of accountability, let’s not forget, is exactly what enables the abuse we are trying to stop.

Personally, I don’t agree that we should have as much focus as we do on destroying connections. In terms of community design that’s incredibly problematic. I’d prefer to see this trigger a remediation action. I can agree that getting someone out of your feed, or even a whole server, when they are causing you harm is a good end goal but when it comes down to it I don’t trust people to be able to hold themselves accountable for their own actions. Especially not when it’s for something as difficult to conceptualize as long term network impacts. This is simply not an issue the wisdom of the crowd is fit to solve.

I really want to see a realistic effort to counter this trend. I would ideally see a system that encourages active problem resolution between individuals with admin moderation.

My proposed model was for a personal domain block to act as a stop gap for a more socially aware process. E.G. It gets the abuse out of the user’s feed until an admin has time to review it.
This was the commonly cited point of having a domain block outside of an admin tool.

#6

I disagree and would request the feature be delayed until the concerns are addressed.

#7

This may be a strong philosophical disagreement. You do not trust individuals to make the decisions they believe to be best for themselves. I believe users are not children and we do not need to treat them like children. Even children should be trusted to make the decision for themselves about who they do and do not feel safe interacting with. I have no interest in being the bad parent who pushes someone to tolerate the creepy uncle that doesn’t respect boundaries. I think the point of a decentralized system is to give users and communities agency. Our users are adults and I think we should trust them to decide for themselves what is in their own best interest. We give users and communities tools, it is our responsibility to not give swords. Blocks at the individual level are shields, not swords. IRL I can physically remove myself from the presence of a group that I feel unsafe around. That is what the user-level instance block is. The online equivalent of me stepping away from the lion’s den.

We are not destroying connections by giving users the choice to block an entire domain. Those are not connections that would have been made anyway. As an example: My only connection to sealion.club is 1. being harassed by them and 2. their instance MITM-attacking my instance. Enabling me to block them is not “destroying connections” it is me protecting myself and curating my experience. I don’t think it’s Halcy’s business if I do that. It’s especially not sealion.club’s business as the entire way this is meant to make me safe is for, from their perspective, me to have totally disappeared, silently, without notification. Anything else increases my visibility for further harassment.

If a user’s block is going to send a notification to someone, that means it is not a private action. It’s one thing for me to personally decide I don’t want to interact with someone. I would be more uncomfortable honestly making that decision if I knew somebody else would see that I have done it. That is a breach of privacy imo.

If users can block an instance on their own, silently, and privately, it means they have no incentive to publicize that they have done so. It is not mob-rule to make a personal individual action. It is also not the responsibility of the Mastodon software to “rule over” people in their place. If users must interact with an admin to approve of their block, they will feel less safe doing so, and will feel unsafe on Mastodon. The domain “block lists” were an issue because instance admins using those lists were making decisions for entire populations without their consent. It also was an issue because of degrees of separation issues. With an individual block, nobody needs to know if I don’t block that instance because it’s irrelevant to them. I can make my own personal decision and nobody is going to block me, as an individual, for doing so. They won’t even know that I haven’t made that decision.

The purpose of user-level domain blocking is to solve the problem of instances having to make decisions for all of their users. There’s no need to publish your personal block list because it only affects you whereas an instance-level domain block affects all of your users.

Of course it’s ideal for people to work out their issues. I don’t think forcing users to involve other people in their personal decisions about who they want to interact with is encouraging them to work out their issues. This wouldn’t be an interpersonal conflict.

It’s also not necessarily about conflicts. Users often want to curate their experience. “I think X or Y shouldn’t be on the public timeline.” They want users to conform to their expectations. User-level domain blocking enables instances to block each other less because users who wish to not be exposed to certain communities can just make their own personal decision to hide those communities, rather than make an appeal for someone else to make that decision. If early on, individual users could decide to block, say, shitposter.club, not because of harassment but just because they don’t want to be exposed to the content shared on that community; then that would have prevented so much conflict between shitposter.club and mastodon.social. Because there would be no need to publicly discuss it or expect a decision to be made by someone else for someone else. “I don’t wanna see it, so I wont.” If user X doesn’t like domain Y, letting them just block it makes it none of domain Y’s business and they can proceed to behave business as usual without having to worry about conflicts being started when user X badmouths them.

I am extremely opposed to anyone besides the user making the block knowing who any individual blocks, at the individual or domain level.

I also think that this feature has been desperately needed since November and if it’s finished and functional then we should deploy now and if there’s issues with how it’s being used we can fix later. In the meantime, users are being harassed. I say give them shields and trust them to know who does and doesn’t make them feel safe.

5 Likes
#8

The concerns are being addressed by discussing it in this thread. And solutions need not apply with immediate effect, but can grow over time, as use-cases and situations appear. The goal of this thread here is to talk about possible solutions and tweaks to improve this feature.

If we can get specific concerns that we can work on a solution for moving this discussion forward would be a lot easier.

#9

I’ve been testing it on glitch.social.

Gave some feedback about bugs and a couple enhancements.

Not sure if the fixes are in yet because I’m at work still.

1 Like
#10

I think this section synthesizes the discussion and the need for the account domain blocks quite well.

This makes sense. As mentioned in the OP the suggested solutions were just to be further discussed.
And I definitely see the issues. I guess however it could be combined with a modal which asks if we want to report the issue as well? (I do not know how it is functionally working right now, I probably should test it out)

It may be worth for us to get accounts on glitch.social and try out how it works functionally.
@beatrix-bitrot can you please tell us / link to feedback for enchancements you gave, if it’s on the github?

#11

I think this is a good point. I believe that the intended functionality of the modal will be along the lines of “Have you reported the issue to your admin?” “Are you sure you want to block this entire domain and not just the user”, etc.
That would be a first step to a resolution, while also protecting the user in the meanwhile, do you agree?

1 Like
#12

No.
I do not trust people not to be lazy. I entirely trust people to do what they believe is best for them, and even their kin group. I do not trust people not to stop there though. We are not all idealists striving for a better world. We are, the vast majority of us, normal people who do not want to be bothered by second guessing our choices.

Your sealion example is a poor one IMO because it got handled by instance admins. I would still see it as supportive of the need for the stop gap, but not as justification for dropping the concern of this feature harming the network. Despite what you’re insisting here, dropping a connection is dropping a connection. That is a destructive act even if you consider it essential for the greater good. Weeding still destroys life, the question is if we pull the weeds or spray herbicide.

I can accept the need for the ability to quickly disengage from harassment, but I will not accept the position that we should only think about this in terms of harassment. It is far more wide impacting a feature than that. If we do not consider the impact of this feature at a system level we are not being responsible in our deliberation.

Your personal privacy is important, I agree, which is why I was against this feature in the first place. I honestly do not see a way to implement this safely without signaling. Without a signal, we can’t fix the problem. This solution, independent of that signal, will only drive community divides deeper by removing discussion around the problems.

I will not accept the position that just because a process will be more uncomfortable that constitutes grounds alone for abandoning seeking a compromise. It may be awkward to have your instance bans gone over by an admin, I don’t see how it’s any more awkward than the instance admin being able to view literally anything you type. Maintaining the illusion of privacy here doesn’t convince me that I should abandon my concerns as to the community impact.

"The purpose of user-level domain blocking is to solve the problem of instances having to make decisions for all of their users. There’s no need to publish your personal block list because it only affects you whereas an instance-level domain block affects all of your users."
The freedom to associate is good, but giving someone the tools to conveniently exclude someone based on their own stereotypes is bad. Recontextualizing that to online groups does not suddenly make it less bad. Enabling private prejudice is not something we should be in the business of doing, especially not when our end goal is to end harassment.

Content ‘curation’ is what following is for. Excluding people entirely is not.

1 Like
#13

Another tweak which occurred to me, which may be slightly offtopic, but I will keep it here for discussions sake.
One of the problems seems to be this usecase

New users make an account and do not realize that they are talking to the entire fediverse when they first step in and get their feet wet.

One thing which could help solve this issue is Local only post as initial default for new users (when we have local only posts) (see discussion here and here, and this pdf.

#14

I did not post on GH, just told Gargron directly.

This was my list:

  1. (bug) unhiding doesn’t work. i don’t get new posts from users on domains i hid and then unhid appearing in my FTL
  2. (bug) my local TL is completely blank
  3. (enhancement) don’t send toots to blocked domains
  4. (enhancement) only show a valid choice in the dropdown

You welcome on glitch.social but it is not ready for more testing yet since the above have not been addressed.

1 Like
#15

No.
I actually think that a simple prompt will no systematic way of re-evaluating the choice will make it even harder to counter choice bias. When we feel we have made an informed choice, we are even more confident and will be even less likely to re-evaluate it in the future.

1 Like
#16

Could you synthesize 5-10 bullet points for us with your concerns.

And any proposed solutions accompanying them, so we can get a decent overview?

#17

Would you also want to elaborate of what you feel is a good systematic way to re-evaluate?

1 Like
#18
  1. There is no accountability built into a very powerful feature.
  2. It allows discrimination based on stereotyping communities.
  3. There is nothing about it that counters the systematic effect well known biases.
  4. It signals an emphasis on punitive action rather than reconciliation.

We already had a crisis about this at the admin level and we are still trying to put infrastructure in place to handle that adequately. I find it incredibly irresponsible to claim that offloading a such a difficult issue to the user is somehow going to counter that.

2 Likes
#19

Look, I’m not a community director, I feel like this conversation is something we need to have a real deep soul searching look at. I don’t know of a good way to include all of the voices that need to be here, but I do know that implementing something with such a large network effect before we have our community stratigy really fully developed is irresponsible.

I have my own hang ups on the issue and I acknowledge that, but this is a /huge/ thing. It is a fundamental change in the way we tell people to associate (make no mistake, this is definitely signaling the community how to behave), and I think the rush to get it out of the door means we haven’t really tried to look at it from all the lenses that need to go over it.

1 Like
#20

I am kind of in between on this. On one hand, it is a particular user choice and it is certainly way better than admin-mandated domain-level blocking (which are very bad in my opinion). On the other hand, @irick concern’s are valid too, especially about the “unknown unknowns” of the network effect.

A bit about my perspective: I have participated in building network infrastructure, both wires, hardware and software. I believe that “network” is something different than “a product” or “a project”. Many Internet endeavors make this mistake, mixing the product-thing with a network-thing, mostly under the disguise of the “community”. So I might be biased towards the issues of building the network and keeping in running, as opposed to curating the actual information being sent over the wire.

From that point of view, I think that the proposal of user-controlled domain-level blocking (as well as some other content-curating initiatives) seem to make one unspoken assumption. It is the notion that the Mastodon instance is a meaningful thing. I am not sure about that and here is why:

Depending on the dynamic and the differences between the local and federated timelines, there are two directions the network may evolve:

  • an IRC-like flat model - it does not matter where you are coming from (which server). Almost everything federates anyway. Local timeline is just a slower version of the global one, not much different in terms of content. The choice of the instance to attach is almost random. In the end, instances become just network nodes relaying messages, much like Tor or IRC.
  • an instance camping model - the instances try to capture and describe their spirit and attract/distract certain kinds of audience. They can do it via the instance name, graphical, design, terms and conditions, subscription model, moderation level, free/paid etc. etc. In this model user’s attachment to the instance may be more though out. Instance camping doesn’t have to imply curated communities; some maybe very picky about membership, while other maybe openly inviting to break all rules. (Newsgroups example shows both schemes can live under one protocol in a federation).

I believe that the user-controller-domain-blocking (or any domain blocking, for that matter) makes sense and carries little negative impact in the second model, that one of instance camping. Being on an instance is actually meaningful, so blocking one (for example some open-everything-is-allowed instance) carries some weight.

But if flat model prevails, or at least majority of casual users live in a “I’d don’t care which instance I am on” world, this feature, although completely user-controlled, may exhibit adverse effects on the whole network. Something that - as I understand it - @irick warns us about. “We are not sure how this whole thing is going to develop (if anything at all), so let’s hold the horses a bit not to break that new-born thing”.

I don’t think we can safely predict which model will be the major mode of operation right now. My current bet is that the flat model may become more popular. As somebody occasionally using some funky instances but mainly living on mastodon.social, I experience local timeline on mastodon.social to be a slightly slower variant of a federated one, with a somewhat reduced ratio of a Japanese language. That’s it. Of course, toot.cafe perspective may be completely different. I also do not believe that users will make or want to make truly informed choices prior to signing up. You need to actually learn that thing a bit and try it out. By that time, you might have invested too much in your current identity to be persuaded to switch. (There are markets easily where customers are extremely loyal mostly because they are too lazy to ever bother switching). So you might be stuck with your fluffy domain for some time.

There is no “this instance only” toot distribution/reach setting currently, so it is harder to build a more inward community based on the instance public. Even if it were, I am not sure most users would bother to carefully switch between the fully federated and local instance models.

And I think it was not introduced for the purpose - other instances should always have a chance to federate, based only on individual (or bots’ ) decisions to remote follow.

There is one factor that could strengthen the instance camping behaviour: if instances based on non-Mastodon software would start to appear that offer some completely different mode of operation with the network. One could imagine that Wordpress blogs would automatically join the federation, and offering identity to the authors and the commenters (while accepting federated input as well). Or OStatus gateways to some very specific communities. Or instances running some special bots only. If the network will mostly run uniform software (or highly compatible software with a similar premise), it will tend to work like an IRC flat model. Software and use case diversity may strengthen camping.

For example, presidentielle.tech was the only one I was remotely considering suitable for domain-level blocking for me. An all-bot instance replicating things which mostly didn’t interest me, in the language I don’t know. In the end I have muted few very active candidates there, but I think I have found also one or two interesting tweet-toots that I wouldn’t have a chance to see; that makes me to side with a part of @Irick 's argument (that is also raised generally about various forms of filtering of Internet messages), that we will not have a chance to re-evaluate our choices and see how life looks like without a filter. Some people have experienced this when lifting their killfile for a moment on newsgroups; some might know the feeling once having their ad blocker disabled for a while :slight_smile:

On the other hand I was genuinely concerned about the chance that social.tchncs.de might get blocked by my instance. We even went as far as sending probe messages with some of my contacts to figure out “can you hear me?”. This is a very disconcerting symptom - an uneasy feeling that the connectivity is broken and unreliable. And we need to concentrate on checking the “signal level” in the conversation instead of just going with the flow.

Having written the above up, I find myself even less convinced if the instance camping will be a dominant model (although it will always exist to some extent). If that’s the case, then network-adverse effects of conversation blocking might (or might not) kick in, making at least part of @Irick’s concerns valid.

[details=little note on IRC]
Update As @cwebber@mastodon.social points out there are different IRC networks. Here I am referring to an operation of a single IRC networks. Different IRC networks are not federating to each other at all.

Some people on Mastodon disagreed with my comparisons of Mastodon to IRC or newsgroups. I will continue to make them until a useful comparative analysis will be done between older and new models of federated networking. But I am a frequent user of IRC to this day, on the other hand I have left newsgroups long time ago and without attachment.[/details]