Protecting SSB from yuge orange face or anyone like him
In our #ngipointer chat, @cryptix and I were talking about the capitol hill attack, worried overall, and worried for SSB. We do not want to be building all this censorship-resistant tech just to see it used to rotten the world. So things we're worried about are: centralized platforms did the right thing to deplatform orange face, if it were the case that SSB were used by millions, how could we deplatform them? Besides the deplatforming concerns, there's also an eye on https://en.m.wikipedia.org/wiki/Network_Enforcement_Act and https://en.wikipedia.org/wiki/Digital_Services_Act and how these EU directives could affect SSB if/once SSB is widely used. Similar concerns as "GDPR on SSB".
We don't have a centralized switch on SSB that can immediately deplatform anyone. We don't have that power, by design. And we actively mitigate against accumulation of such power and enforcement features.
That said, we have power. It's just evenly distributed to all peers. Per peer, it may seem small, but in aggregate it's as much power as an admin would have. We just need better mechanisms of putting that power into effect.
Some ideas how to put our decentralized power into effect. One of them is 'done', #trustnet, and I believe it's absolutely the future of SSB moderation, despite it not being implemented anywhere here, yet. I had two other ideas, last night, one of them is an extension of #trustnet:
Trustnet looks at blocks in a community, computes numbers, and the outcome is a binary decision to block or not based on 2nd and 3rd party blocks. We could utilize the trustnet numeric computation to provide fuzzy results before the binary decision is applied. For instance, say orange face is blocked by one of your 500 friends. Let's say Trustnet computes the number
0.2 but deems it not enough for a block (let's say it would have to be 0.5). But
0.2 could be fed into a news feed algorithm that deprioritizes posts from orange face. This way we can get a smooth transition from "fully present" to "fully absent", and this can change without any user input, it's just based on the user's community and how blocks are occurring in the community.
Another idea is reblocks. We seem to have agreed that we don't want 'retweets' or 'reboost' mechanisms in SSB, because these are ways of propagating viral content, which turns out to boost attention-seeking behaviors, which in turn boosts controversial and toxic content. Social networks are good at propagating things by gossip, and retweets are essentially a gossip mechanism. And SSB already functions with gossip, it just uses it for technical data replication and networking. What if we would use gossiped blocks? This is just a small UI tweak: when someone is blocked, there would be a prominent button "reblock" that makes it easy for you to also choose to block them. SSB already functions quite different from Twitter, because block events are shown on Patchwork and Manyverse's feed, I don't think Twitter does this. And people here already use this information to choose to block-them-too, so our blocks are already more "gossipy" than on Twitter for instance. We could reinforce this culture by doing a small UI tweak.
Now I'm trying to think how to factor in blocks (done with
contact messages) into the new design of #ssbroom. It's a bit harder because rooms by design don't replicate SSB msgs. But there's space for something to be done, and I need to figure it out soon before we start implementing rooms.
I'm open to discussion and critical thoughts.