Mentre scrivo — dovrei arrivare a una versione stabile tra poco, sarà la v1.0.1 — il mio server ActivityPub, trasformando la fork in qualcosa di diverso, mi sono imbattuto in un pezzo di codice che descrive il comportamento della funzione block.

La fork la trovate qui: https://git.keinpfusch.net/loweel/Aktor-2.

Nota di servizio: non usatelo sullo stesso database della versione precedente, cioe' GoToSocial. Non funzionerebbe. Il database è cambiato. Ho aggiunto e tolto troppe cose. Aktor non e' piu' GotoSocial. 

Dicevo: mi sono imbattuto in questo pezzo di vecchio codice, e il modo in cui la funzione block viene implementata — e, per quanto vedo, la implementano così tutti i server che conosco — non mi piace per nulla.

Facciamo un esempio semplice.

Bob e Alice sono coinvolti in un thread. Il thread è stato aperto da Bob, e ci partecipano altre dieci persone. Bob e Alice non sono d’accordo. Succede. A un certo punto, in un impeto di democrazia pratica, Bob decide di bloccare Alice.

La domanda è: che cosa sta facendo Bob, esattamente?

Ci sono due possibili risposte.

1. Bob non vuole più leggere le cose che scrive Alice.
2. Bob non vuole che Alice scriva ancora.

E sono due cose molto diverse.

Nel primo caso, siamo davanti a una scelta perfettamente legittima. Bob dice al proprio server: “ehi, ricordati di non mostrarmi più quello che scrive Alice”. Ha senso. È una scelta ottima, se l’obiettivo è la famosa peace of mind. Bob si protegge dal contenuto che non vuole vedere, e finisce lì. Alice continua a parlare, gli altri continuano a leggerla, Bob non la vede più. Tutti felici, o almeno tutti meno infelici.

La seconda scelta implementativa, invece, è quella che di fatto zittisce Alice.

Magari gli altri dieci partecipanti al thread erano interessati a sapere cosa dice Alice. Magari la discussione non era più davvero “tra Bob e Alice”. Magari, come spesso succede, il thread si era evoluto, aveva preso una direzione diversa, e Bob era ormai soltanto quello che aveva acceso il cerino iniziale. Però, siccome il creatore del thread blocca Alice, in tutte le implementazioni che vedo in giro Alice non può più scrivere nel thread.

E questo succede perché tutte le implementazioni che vedo usano il campo in_reply_to per identificare un thread. Quindi, quando qualcuno ti blocca, il tentativo di rispondere viene trattato come se fosse una risposta al primo post, cioè al post di Bob. E siccome Bob ti ha bloccato, la tua risposta non passa.

La scelta è stupida.

È stupida perché confonde due concetti che dovrebbero rimanere separati: “non voglio vedere Alice” e “Alice non deve più parlare”. La prima è moderazione personale. La seconda è controllo della conversazione.

Ed è ancora più stupida se pensiamo al modo in cui funzionano davvero le discussioni online. Un thread non è necessariamente proprietà morale di chi lo ha aperto. Lo ha aperto, certo. Ha scritto il primo messaggio, certo. Ma se poi arrivano dieci persone, e quelle dieci persone cominciano a discutere tra loro, il thread non è più soltanto “la cosa di Bob”. È diventato una conversazione collettiva.

Se Bob non vuole più leggere Alice, benissimo: il suo server non gliela mostra. Ma non si capisce perché il blocco di Bob debba impedire agli altri dieci di leggere Alice. Non si capisce perché il fastidio personale di Bob debba trasformarsi in un silenziamento tecnico valido per tutti.

Perché magari Alice sta rispondendo a Carol. O a Dave. O a una delle altre persone coinvolte. Magari Bob non c’entra più nulla, se non per il fatto storico di avere scritto il primo messaggio. Ma il software, invece, continua a trattare tutto come se ogni risposta fosse ancora, in ultima analisi, una risposta a Bob.

E qui il problema non è morale. È architetturale.

Il software sta prendendo una scorciatoia concettuale: usa in_reply_to come se bastasse a definire il controllo del thread. Ma così facendo assegna al creatore del primo post un potere che, socialmente, non è affatto ovvio che debba avere. Gli dà una specie di diritto feudale sulla conversazione: hai aperto tu il thread, quindi puoi decidere chi può ancora parlare dentro quel territorio.

È una visione molto comoda da implementare. Ma non è detto che sia una buona visione del comportamento sociale che vogliamo modellare.

Perché una cosa è dire: “Bob non riceve più le attività di Alice”. Un’altra cosa è dire: “Alice non può più produrre attività che gli altri vedranno in quel contesto”. Nel primo caso stiamo filtrando la vista di Bob. Nel secondo stiamo cambiando la realtà per tutti gli altri.

E questa differenza, nei software federati, conta parecchio.

Perché se la federazione deve servire a distribuire potere, non ha molto senso ricostruire, dentro ogni thread, un piccolo principato assoluto del primo che ha parlato. Bob apre il thread, Bob si irrita, Bob blocca Alice, Alice sparisce dalla conversazione per tutti. Molto federato, certo. Sembra più che altro il Sacro Romano Impero dei malumori personali.

Secondo me il comportamento corretto dovrebbe essere più vicino alla prima interpretazione: il blocco serve a proteggere chi blocca, non a zittire chi viene bloccato davanti agli altri.

Se Bob blocca Alice, Bob non deve più vedere Alice. Punto. Ma se Alice risponde a Carol, e Carol non ha bloccato Alice, Carol dovrebbe poter leggere quella risposta. E anche gli altri partecipanti che non hanno bloccato Alice dovrebbero poterla leggere. Il blocco di Bob dovrebbe modificare la timeline di Bob, non la geometria dell’universo.

Poi, certo, ci sono casi più complicati. Ci sono thread abusivi, molestie coordinate, conversazioni che diventano ingestibili. Ma quelli sono problemi di moderazione, non dovrebbero essere risolti facendo finta che il primo autore del thread sia il proprietario ontologico di ogni messaggio successivo.

In altre parole: bloccare qualcuno dovrebbe voler dire “non mostrarmelo più”, non “impediscigli di parlare con chiunque altro, purché tutto sia nato sotto un mio post”.

E invece molte implementazioni finiscono proprio lì. Per semplicità tecnica, per eredità del modello, per pigrizia, o perché nessuno ha davvero separato i due casi.

Ma sono due casi diversi.

E quando un software confonde “io non voglio ascoltare” con “tu non devi parlare”, il problema non è più solo nel codice. È nella visione sociale che quel codice sta imponendo.

Perché tutto il Fediverso ha fatto questa scelta, cioè quella di zittire Alice?

Erano tutti dei feticisti dello stupro? No. Non credo che la spiegazione sia questa, e non credo nemmeno che serva ricorrere a psicopatologie assortite per capirlo. Ma se andiamo a vedere le origini culturali del Fediverso, o almeno di una parte molto rumorosa e molto influente del Fediverso delle origini, il quadro diventa più chiaro.

Chi c’era, all’inizio?

1. C’erano istanze comuniste, spesso sudamericane.
2. C’erano istanze anarchiche, spesso sudamericane.
3. C’erano istanze femministe, lesbiche, o entrambe le cose.
4. C’erano istanze LGBT di qualche tipo, spesso molto militanti.

Paticamente, un centro sociale occupato.

Ora, capiamoci: non sto dicendo che queste categorie siano automaticamente identiche, né che ogni istanza fosse uguale all’altra. Sto dicendo che il brodo culturale nel quale sono nate certe implementazioni non era esattamente quello del liberalismo classico da salotto, dove Alice partecipa al dibattito, dice qualcosa che non piace a Bob, Bob storce il naso, e tutti concludono che il diritto di Alice a parlare vada comunque conservato.

No.

Il principio culturale dominante, in molti di quegli ambienti, era un altro. Era più vicino a: “Alice partecipa al dibattito e dice qualcosa di contrario all’ortodossia? Bene. Allora picchiamola, stupriamola (a parole o nei fatti) , mettiamola a tacere e cacciamola a calci, quella puttana fascista.”

Che poi, naturalmente, nella versione educata diventa “safety”, “community standards”, “protezione degli spazi”, “non dare piattaforma ai fascisti”, “difendere le persone vulnerabili”, "safe space" ,  e tutta la liturgia del caso. Ma il meccanismo sociale rimane quello: chi devia dall’ortodossia non viene contraddetto o ignorato, viene ostracizzato. E prima ancora di essere espulso, viene silenziato.

E questo, secondo me, è lo spirito con cui si è implementato il comportamento attuale delle istanze. Non perché qualcuno si sia seduto a un tavolo dicendo: “oggi inventiamo un sistema per dare al creatore del thread il potere di cancellare la voce altrui”. Sarebbe persino troppo razionale. Più banalmente, quando si è trattato di decidere cosa dovesse fare un blocco, nessuno ha avuto troppi dubbi: se Bob blocca Alice, Alice deve sparire. Non solo dagli occhi di Bob, ma dalla conversazione.

Da lì nasce la scelta tecnica.

Se il creatore del thread ti blocca, non ti sta semplicemente dicendo: “io non voglio più leggerti”. Ti sta dicendo: “tu qui non parli più”. E il software, invece di distinguere tra queste due cose, gli dà ragione.

Quindi Alice non viene soltanto filtrata dalla timeline di Bob. Alice viene zittita dentro quel contesto. Anche se gli altri partecipanti alla discussione non l’hanno bloccata. Anche se volevano leggerla. Anche se la risposta era diretta a qualcun altro. Anche se Bob, ormai, nella conversazione non c’entrava più nulla se non per il fatto di avere scritto il primo post.

Ma non importa.

Il thread è nato sotto Bob, Bob blocca Alice, e quindi Alice deve sparire. E vaffanculo quella fascista di Alice.

Questa è la logica. Non necessariamente dichiarata, non necessariamente formalizzata, magari nemmeno consapevole. Ma è la logica sociale che il codice finisce per incarnare.

E quando una scelta tecnica nasce dentro una cultura che considerava il dissenso come contaminazione, poi non bisogna stupirsi se il software non implementa il dissenso come parte della conversazione. Implementa la bonifica.

Ovviamente, oggi non è più possibile continuare in questo modo.

La procedura del canceling non può funzionare se, per esempio, nel gioco entra l’intera società. Finché il Fediverso resta una nicchia popolata da gruppi relativamente omogenei, tutti convinti più o meno della stessa ortodossia, il meccanismo del “zittiamo Alice” può anche sembrare sostenibile. Ma se la UE continua davvero a promuovere il Fediverso sempre di più, esiste il rischio concreto — o, a seconda dei punti di vista, la possibilità concreta — che questo ambiente diventi, come si dice, mainstream.

E quando una piattaforma diventa mainstream, cioè quando dentro ci finisce tutta la società con tutte le sue divergenze, idiosincrasie, maggioranze, minoranze, rancori e abitudini tribali, chi vince in un sistema fondato sullo zittire l’altro?

Vince la fazione più numerosa.

E siccome femministe, comunisti, anarchici, lesbiche, GLBT, non sono la fazione più numerosa, questo modo di fare finirà molto presto per ritorcersi contro di loro. È inevitabile. La cultura del silenziamento non resta mai proprietà privata di chi l’ha inventata o sdoganata: appena il campo si allarga, diventa un’arma della maggioranza del momento. E a quel punto quelli che ieri applaudivano perché Alice veniva zittita, domani scopriranno che a essere zittiti sono loro.

Per questa ragione, credo che la scelta migliore sia lasciare parlare Alice.

Poi spetterà al moderatore decidere che cosa fare. Ma, nella stragrande maggioranza dei casi, il moderatore non è Bob. E soprattutto, non dovrebbe esserlo per diritto dinastico solo perché Bob ha scritto il primo post del thread. Una discussione pubblica non può essere trasformata in un feudo personale nel quale chi apre il cancello decide chi ha diritto di parola e chi no.

Ed è esattamente questo che ho implementato.

C’è chi dice — partendo, ovviamente, dall’ipotesi che Alice dica solo cazzate — che tutto questo contribuisca alla cosiddetta enshittification del Fediverso. Ma diciamolo apertamente: lo stato attuale, nel quale Bob chiude la discussione insultando Alice e poi le impedisce di replicare semplicemente bloccandola, è davvero il modello sociale che vorreste vedere riprodotto in scala?

Davvero pensate che, portato a dimensione di massa, questo meccanismo produca una società migliore?

Perché a me sembra il contrario. Mi sembra il modo perfetto per trasformare una conversazione in un piccolo abuso di potere automatizzato. E francamente, se il futuro del Fediverso deve essere questo, allora non stiamo costruendo un luogo di discussione: stiamo solo distribuendo a più persone il pulsante per tappare la bocca ad Alice.

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.

1. Bob no longer wants to read the things Alice writes.
2. Bob does not want Alice to write anymore.

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?

1. There were communist instances, often South American.
2. There were anarchist instances, often South American.
3. There were feminist, lesbian, or both feminist and lesbian instances.
4. There were LGBT instances of some kind, often very militant.

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.