This from @stefan is important!! I too conclude that technical features cannot solve cultural problems, but solving the problem of not being able to control who replies would still help a good deal
https://stefanbohacek.online/@stefan/115838969201343832
+
More specifically, not being able to control who replies isn't a cultural problem, in and of itself, however much it may facilitate cultural problems.
It is entirely a technical problem, as it does not exist but as a function of choices made in the design of a class of technical systems, which choices have thereafter been normalized, naturalized and reinscribed in the design of subsequent technical systems that emulate what came before.
A lack of reply management represents the constraints imposed by a sociotechnical imaginary, an imaginary that privileges ease and familiarity for programmers, that has become the shared vision of a wider culture by fiat alone.
I published a paper from a first-person perspective about how features on #Mastodon leave enormous loopholes for harassing behavior (OA, 🔗 ⬇️ )
I came over here in the Nov22 wave & never left, but I no longer invite people to join without giving (loud) fair warning about drawbacks. I can't in good faith recommend Mdon to anyone who's more likely to be on the receiving end of harassing behavior
We have proof of concept, but the stakes are *urgent* to improve!
https://openjournals.uwaterloo.ca/index.php/JoCI/article/view/6644
@inquiline Dr. Commensality Tools
(just reached the part where you clarified use of your name, thought it was in bounds because it was on the paper)
@inquiline depressingly bad moderation practice and probably the norm. we absolutely act against posts on other servers, and someone harrassing someone from an account on another instance is absolutely against the rules on our instance - the members of the instance agree to not violate the rules in order to be on the instance, not the accounts.
To locate responsibility in the network would mean to acknowledge power relations, not only between users and moderators; but between users, moderators, and network architects; and users and other users [...] Galaxy’s decision to not intervene when their account-holder harassed me from another instance on the network was not an off-the-cuff decision, but in fact their considered policy. [...]
[assemblag.es] administrators do not view events outside its server as irrelevant to how they moderate; this network node enacts meshy accountability between and amongst the server, its administrator, users, and other instances. This unsettles familiar patterns of domination that pervade sociality in technical cultures and spaces, undercutting plausible deniability on which bad actors may lean. It also serves as a reminder that instance-level choices, and norms, are malleable and not determined; [...] The idea is not to “control” how other users post, nor to disavow responsibility for remediating harm that interactions can cause; it is to cultivate meshy accountability in sociotechnical space such that there are preclusions and remedies for harm cultivated across the network’s architects, moderators, users, and the network itself.
very well said.
@inquiline spot on all the way through. there's a lot of work to do all over.
@inquiline the practical fixes you point to are so goddamn frustratingly doable - it is ridiculously hard to reach out mod to mod between instances, and there is absolutely no reason that replies can't be limited, if not in an absolute way, at least in a way that can mitigate a lions share of the harm by making them invisible to any well behaved instance (which most people are on). you don't fix cultural problems with technology, but sometimes the technology is just lagging embarrassingly behind and holding everything back.
@inquiline
Thank you for writing and publishing this, and I'm sorry that happened to you.
@inquiline THANK YOU for writing this. Will read and comment soon.
That's a cultural norm that usefully justifies a set of technical decisions.
In the end, the user flow diagram of the existing regime is easier for programmers to think about. In no small part because the data architecture that undergirds said UX leans into generalized patterns of reference, sequence of operations & control flow.
Absent business analysts writing up requirements specifications for how the precursors to these technical systems would operate, hobby programmers just built systems that did a thing.
Many of those decisions, still with us today, were first made during a blizzard in 1978. Programmers, being inherently conservative, do what has been done before. BBS dial-up was a distinct technological environment. Any culture of "openness" emerged from within the environment that gave it form.
The definitions were never adopted, so much as inherited. Passed down as heirlooms that took on their own meaning through sheer uninterrupted persistence.
Agreed, very well said! In terms of the imaginary, it also relates to privileging openness over safety (and as @inquiline has pointed out elsewhere, the specific definitions of "openness" that are adopted).
