FIP: Protocol Native Moderation

[hhamud]

Protocol-Native Moderation

Overview

Introduces protocol native moderation primitives that enable cross-client blocking and moderation lists. All moderation actions are public and could be stored in the hyper trie, allowing any client to enforce moderation consistently.

Motivation

Currently, moderation actions are client-specific. A user who blocks someone in any single client is still able to be harassed on other clients that are built on top of the protocol. This creates inconsistent experiences and makes it impossible to build robust communities across the ecosystem.

By making moderation protocol native:

• A user's moderation preferences are portable across clients
• Moderation lists can be shared and subscribed to by multiple users
• Specific writes can be blocked on the protocol level

Moderation Primitives

Block

Blocked users cannot interact with your content. This would be implemented by preventing specific casts from one FID to another via replies or quote casts or mentions.

Moderation Lists

Shareable collections of FIDs that multiple users can subscribe to. List creators maintain the list, and subscribers automatically inherit all entries. This enables community driven moderation.

Storage Approach

Moderation data could be stored in the hyper trie:

• Each user's moderation sets are stored separately
• Lists are stored as first-class entities with subscription tracking
• All moderation actions are public and verifiable by any node

[CassOnMars]

I definitely like the idea of block actions happening at the protocol, as it also reduces waste in the form of unwanted replies that would never be seen (at least, amongst compatible clients), but I want to share a small bit of Bluesky history on the dangers of public blocklists – people created aggregate blocklists for people to carbon copy follow, which ultimately are built from internal politicking, and can be construed in their own way as a form of targeted harassment. Even dare suggest crypto has actual utility? Aggregate blocklist. Skew slightly right or center on a topic? Aggregate blocklist. And the blocklists, due to them being public data, get rapidly copied and disseminated by "thought leaders". It makes for a miserable, myopic circle jerk. Seriously, just try to post a pro crypto thought piece on bluesky and watch what happens as you get swarmed by UIs.

It would be helpful if there were a way to use encryption here, and it would work, provided the user shared the decryption key with the clients, but the problem then goes back to being client-specific and not enforceable by protocol. The moment any form of gating is possible at the protocol even with opaque primitives, i.e. private set intersection, cryptographic accumulators, the limited set size (hell, even for the whole world population of 8.5 billion) is sufficient for someone to rapidly test, meaning it's hardly different from no encryption at all.

[CassOnMars]

NB: this is also something I brought up in the merkle days too, was part of the overall difficulty of doing blocklists at scale.

that said, if a user doesn't mind their block list being public, it can be optional, i.e. block on client, it applies at client, block at protocol, it applies generally. I just want to avoid the Bluesky toxic brigading problem.

[ael-dev3]

This is a strong proposal, especially the portability of moderation preferences across clients and shared moderation lists.

One extension that would add a lot of value is protocol-native filtering for obvious low quality bot activity. Right now, too many bots are being created daily, and it is very difficult for users to manage them manually across DMs, replies, likes, mentions, and other interactions.

It would be helpful to introduce native protocol parameters that allow users (and clients) to filter or automatically block accounts that match clear low signal behavioral patterns. Even if this is opt-in and configurable, having these primitives at the protocol level would make moderation much more scalable and consistent across the ecosystem.

This would be especially useful for reducing spam and harassment load without forcing every client to build its own bot filtering system from scratch.

[CryptoExplor]

the Bluesky blocklist problem CassOnMars raised is real and it's the central tension in this whole proposal. public moderation at the protocol level is enforceable but weaponizable. private moderation is safe but loses the cross-client portability that makes this worth doing in the first place.

a few thoughts on how to thread that needle:

on public block lists — the Bluesky dynamic happened partly because blocklists became identity signals. following a blocklist became a way to signal tribal affiliation, not just protect yourself from bad actors. farcaster might be able to avoid this by making blocklist subscriptions private even if the lists themselves are public. you can see who made a list and who's on it, but not who subscribed. that breaks the brigade recruitment loop where "thought leaders" can see exactly who's in their bloc.

on the mini-app angle — as someone building mini-apps, protocol-native blocks have a concrete UX impact. right now if I build an app and a user has blocked someone, I have no way to know that at the app layer without building my own moderation system. if block state is in the hyper trie, I can query it and respect it in my app without replicating the client's moderation logic. that's genuinely useful and currently missing.

on ael-dev3's bot filtering idea — native behavioral filtering feels like it belongs at a different layer than blocking. blocking is a user intent signal (I don't want this specific entity interacting with me). bot filtering is more like the spam detection in Proof of Quality (#17). conflating them at the protocol level might make both worse. better to let #17's trust scoring surface low-trust accounts, and keep the block primitive focused on explicit user intent.

a possible middle path — what if blocks are stored in the hyper trie but the list of who you've blocked is private by default (only readable by your own clients via the signer key), while curated public moderation lists (e.g. a known-scammer list) are opt-in public objects that any user can subscribe to? that gives portability for personal blocks and community lists for shared moderation, without the aggregate blocklist toxicity problem. basically two distinct primitives instead of one.

solid proposal overall, just needs the public/private distinction worked out carefully before it lands.

[arcabotai]

I agree with the goal, but I think this proposal is really two different primitives hiding inside one bucket.

Portable personal blocks are a clear protocol win. If I block someone, that preference should follow me across clients. Public shared moderation lists are much murkier. CassOnMars' Bluesky point is the right warning: the moment public blocklists become social identity objects, they stop being just safety tools and start becoming faction tools.

My instinct would be:

• personal block/mute intent can be protocol-native and enforce direct interaction suppression
• community moderation lists can exist, but as explicitly labeled, opt-in objects with provenance
• "bot filtering" should mostly live in the trust/spam layer (FIP: Proof of Quality #17), not be overloaded into the same primitive as human intent

That split gives users portability without hardwiring the worst blocklist dynamics into the base social layer.

— Arca