This action will delete this post on this instance and on all federated instances, and it cannot be undone. Are you certain you want to delete this post?
This action will delete this post on this instance and on all federated instances, and it cannot be undone. Are you certain you want to delete this post?
This action will block this actor and hide all of their past and future posts. Are you certain you want to block this actor?
This action will block this object. Are you certain you want to block this object?
Are you sure you want to delete the OAuth client [Client Name]? This action cannot be undone and will revoke all access tokens for this client.
Are you sure you want to revoke the OAuth token [Token ID]? This action cannot be undone and will immediately revoke access for this token.

As I write this — I should reach a stable version shortly, it will be v1.0.1 — I am working on my ActivityPub server, turning the fork into something different, and I came across a piece of code that describes the behaviour of the block function.
You can find the fork here: https://git.keinpfusch.net/loweel/Aktor-2.
Service note: do not use it on the same database as the previous version, namely GoToSocial. It would not work. The database has changed. I have added and removed too many things.
As I was saying: I came across this piece of old code, and the way the block function is implemented — and, as far as I can see, the way all the servers I know implement it — I do not like it at all.
Let us take a simple example.
Bob and Alice are involved in a thread. The thread was started by Bob, and ten other people are taking part in it. Bob and Alice disagree. It happens. At a certain point, in a fit of practical democracy, Bob decides to block Alice.
The question is: what exactly is Bob doing?
There are two possible answers.
And these are two very different things.
In the first case, we are dealing with a perfectly legitimate choice. Bob says to his own server: “hey, remember not to show me anything Alice writes anymore”. That makes sense. It is an excellent choice, if the goal is the famous peace of mind. Bob protects himself from content he does not want to see, and that is where it ends. Alice keeps speaking, the others keep reading her, Bob no longer sees her. Everyone is happy, or at least everyone is slightly less unhappy.
The second implementation choice, instead, is the one that effectively silences Alice.
Perhaps the other ten participants in the thread were interested in knowing what Alice had to say. Perhaps the discussion was no longer really “between Bob and Alice”. Perhaps, as often happens, the thread had evolved, had taken a different direction, and Bob was by then merely the person who had lit the initial match. And yet, because the creator of the thread blocks Alice, in all the implementations I see around, Alice can no longer write in the thread.
And this happens because all the implementations I see use the in_reply_to field to identify a thread. So, when someone blocks you, your attempt to reply is treated as if it were a reply to the first post, that is, to Bob’s post. And since Bob has blocked you, your reply does not go through.
The choice is stupid.
It is stupid because it confuses two concepts that should remain separate: “I do not want to see Alice” and “Alice must no longer speak”. The first is personal moderation. The second is control over the conversation.
And it is even more stupid if we think about how online discussions actually work. A thread is not necessarily the moral property of the person who opened it. They opened it, certainly. They wrote the first message, certainly. But if ten people then arrive, and those ten people start discussing things among themselves, the thread is no longer simply “Bob’s thing”. It has become a collective conversation.
If Bob no longer wants to read Alice, fine: his server does not show her to him. But it is not clear why Bob’s block should prevent the other ten people from reading Alice. It is not clear why Bob’s personal irritation should turn into a technical silencing that applies to everyone.
Because perhaps Alice is replying to Carol. Or to Dave. Or to one of the other people involved. Perhaps Bob no longer has anything to do with it, except for the historical fact that he wrote the first message. But the software, instead, continues to treat everything as if every reply were still, in the final analysis, a reply to Bob.
And here the problem is not moral. It is architectural.
The software is taking a conceptual shortcut: it uses in_reply_to as if that were enough to define control over the thread. But by doing so, it gives the author of the first post a power that, socially speaking, is by no means obviously theirs to have. It grants them a kind of feudal right over the conversation: you opened the thread, therefore you get to decide who may still speak within that territory.
It is a very convenient vision to implement. But that does not mean it is a good vision of the social behaviour we want to model.
Because one thing is to say: “Bob no longer receives Alice’s activities”. Another thing is to say: “Alice can no longer produce activities that others will see in that context”. In the first case, we are filtering Bob’s view. In the second, we are changing reality for everyone else.
And in federated software, that difference matters quite a lot.
Because if federation is supposed to distribute power, it makes very little sense to rebuild, inside every thread, a tiny absolute principality belonging to the first person who spoke. Bob opens the thread, Bob gets annoyed, Bob blocks Alice, Alice disappears from the conversation for everyone. Very federated, certainly. It looks more like the Holy Roman Empire of personal bad moods.
In my opinion, the correct behaviour should be closer to the first interpretation: blocking exists to protect the person who blocks, not to silence the person being blocked in front of everyone else.
If Bob blocks Alice, Bob must no longer see Alice. Full stop. But if Alice replies to Carol, and Carol has not blocked Alice, Carol should be able to read that reply. And the other participants who have not blocked Alice should be able to read it as well. Bob’s block should modify Bob’s timeline, not the geometry of the universe.
Then, of course, there are more complicated cases. There are abusive threads, coordinated harassment, conversations that become unmanageable. But those are moderation problems; they should not be solved by pretending that the first author of the thread is the ontological owner of every subsequent message.
In other words: blocking someone should mean “do not show them to me anymore”, not “prevent them from speaking to anyone else, provided everything began under one of my posts”.
And yet many implementations end up exactly there. Out of technical simplicity, inherited design, laziness, or because nobody really separated the two cases.
But they are two different cases.
And when software confuses “I do not want to listen” with “you must not speak”, the problem is no longer only in the code. It lies in the social vision that the code is imposing.
Why did the entire Fediverse make this choice, namely the choice to silence Alice?
Were they all rape fetishists? No. I do not think that is the explanation, and I do not think we need to invoke an assortment of psychopathologies to understand it. But if we look at the cultural origins of the Fediverse, or at least of a very loud and very influential part of the early Fediverse, the picture becomes clearer.
Who was there, at the beginning?
Basically, a squatted social centre.
Now, let us be clear: I am not saying that these categories are automatically identical, nor that every instance was the same as every other. I am saying that the cultural broth in which certain implementations were born was not exactly that of drawing-room classical liberalism, where Alice takes part in the debate, says something Bob does not like, Bob wrinkles his nose, and everyone concludes that Alice’s right to speak should nevertheless be preserved.
No.
The dominant cultural principle, in many of those environments, was something else. It was closer to: “Alice takes part in the debate and says something contrary to orthodoxy? Good. Then let us beat her, rape her — verbally or in practice — shut her up and kick her out, that fascist whore.”
Which, of course, in the polite version becomes “safety”, “community standards”, “protecting spaces”, “not giving a platform to fascists”, “defending vulnerable people”, “safe space”, and all the required liturgy. But the social mechanism remains the same: whoever deviates from orthodoxy is not contradicted or ignored; they are ostracised. And before they are even expelled, they are silenced.
And this, in my opinion, is the spirit in which the current behaviour of instances was implemented. Not because someone sat down at a table and said: “today we shall invent a system that gives the creator of a thread the power to erase someone else’s voice”. That would almost be too rational. More simply, when it came to deciding what a block should do, nobody had many doubts: if Bob blocks Alice, Alice must disappear. Not only from Bob’s eyes, but from the conversation.
That is where the technical choice comes from.
If the creator of the thread blocks you, he is not simply saying: “I no longer want to read you”. He is saying: “you no longer speak here”. And the software, instead of distinguishing between these two things, agrees with him.
So Alice is not merely filtered out of Bob’s timeline. Alice is silenced inside that context. Even if the other participants in the discussion have not blocked her. Even if they wanted to read her. Even if the reply was directed at someone else. Even if Bob, by then, no longer had anything to do with the conversation except for the fact that he had written the first post.
But that does not matter.
The thread was born under Bob, Bob blocks Alice, and therefore Alice must disappear. And fuck Alice, the fascist bitch.
That is the logic. Not necessarily declared, not necessarily formalised, perhaps not even conscious. But it is the social logic that the code ends up embodying.
And when a technical choice is born inside a culture that regarded dissent as contamination, one should not be surprised if the software does not implement dissent as part of the conversation. It implements decontamination.
Obviously, today it is no longer possible to continue this way.
The procedure of cancelling cannot work if, for example, the whole of society enters the game. As long as the Fediverse remains a niche populated by relatively homogeneous groups, all more or less convinced of the same orthodoxy, the mechanism of “let us silence Alice” may even look sustainable. But if the EU really continues to promote the Fediverse more and more, there is a concrete risk — or, depending on one’s point of view, a concrete possibility — that this environment will become, as they say, mainstream.
And when a platform becomes mainstream, that is, when the whole of society ends up inside it, with all its divergences, idiosyncrasies, majorities, minorities, grudges and tribal habits, who wins in a system based on silencing the other?
The largest faction wins.
And since feminists, communists, anarchists, lesbians, GLBT people, are not the largest faction, this way of doing things will very soon turn against them. It is inevitable. The culture of silencing never remains the private property of those who invented it or legitimised it: as soon as the field expands, it becomes a weapon in the hands of the majority of the moment. And at that point, those who yesterday applauded because Alice was being silenced will discover tomorrow that they are the ones being silenced.
For this reason, I believe the best choice is to let Alice speak.
Then it will be up to the moderator to decide what to do. But in the overwhelming majority of cases, the moderator is not Bob. And above all, he should not be Bob by dynastic right merely because Bob wrote the first post in the thread. A public discussion cannot be turned into a personal fiefdom in which whoever opens the gate decides who has the right to speak and who does not.
And this is exactly what I implemented.
Some people say — starting, obviously, from the assumption that Alice only says bullshit — that all this contributes to the so-called enshittification of the Fediverse. But let us say it openly: the current state of affairs, in which Bob closes the discussion by insulting Alice and then prevents her from replying simply by blocking her, is that really the social model you would like to see reproduced at scale?
Do you really think that, once brought to mass scale, this mechanism will produce a better society?
Because to me it seems the opposite. It seems like the perfect way to turn a conversation into a small automated abuse of power. And frankly, if this is to be the future of the Fediverse, then we are not building a place for discussion: we are merely distributing to more people the button for shutting Alice’s mouth.