Deny lists and moderation

[kindrowboat]

The new draft of the spec says that a server in a swarm must respect the deny list of the realm. There's a certain amount of centralization implied here that makes me uneasy.

For example, if Alice is part of a realm for which Bob controls the denylist, per the spec, Alice is giving Bob the power to decide who can and who cannot post to her server. Is the price of joining a realm, that her server must obey the (hopefully) benevolent dictator Bob and hope he doles out fair punishment?

I'd rather be in cooperation with my federates in who to block. Maybe that's on me to join a realm that has some type of governence that I can get behind, but if possible, I'd like the protocol to encourage that kind of cooperation instead of consolidation.

[robinsloan]

Thanks for these thoughts; I think this is easily the trickiest/thorniest part of the entire design.

It seems to me that with any kind of shared denylist, you are always relying on other people's judgments -- a kind of multidimensional mutual dictatorship. An example is shared blocklists on Twitter, and the now-common disclaimer, "I use a shared blocklist and I don't know exactly who's on it, sorry if it catches you."

I'd rather be in cooperation with my federates in who to block

Do you have any ideas (or examples) for how that cooperation might work? As in, what might the actual mechanism be for keys to be added to some shared denylist(s)? I'm wondering about this particularly in a high-volume setting -- beyond "artisanal blocking".

For me, the prospect of managing a shared denylist on, e.g., GitHub, where many people can contribute and where there is -- importantly -- a public history, ameliorates some of the itchiness of letting other people block keys on my server. Some, but not all; I acknowledge that it's weird.

(I'll add, finally, that the shared denylist is fused to the concept of the realm. In a scenario where boards live on, and are accessed from, one server primarily, it's a much less urgent issue. In that scenario, I can imagine server operators making their own decisions and managing their own denylists, and maybe occasionally syncing with a few shared denylists, selectively.)

[royragsdale]

An unrelated denylist question. Is it intended to apply to the GET method too? It would seem to make sense that if you are preventing publishing (PUTs) you would also want to prevent whatever content caused the block in the first place. Currently the spec does not make this explicit.

Recommendation: The denylist should apply to all methods (GET, PUT, DELETE) on /<key>