In my ideal world, "mute user" is a protocol reaction, and I have a bot that I configured to mute any user who replies with specific keywords. The bot has a website where I can go and mute/unmute users too.

Dad, geek, entrepreneur. Conversation liquidity provider. Home is vrypan.net, work is @weatherxm and fun is @l--o--l.

An intermediate solution is warpcast provides a mute API, and allows third party apps with a token signed by me to mute/unmute users on my behalf.

🎩🍌Ethereum builder & people connector. @juicebox revnet.eth.limo defifa.net d33m:liv

There is a plan for "extended reactions" that will allow an app to write more expressive reactions to the protocol. (If this is what you mean).

Yes & 
Why aren’t all Actions Reactions?

Head of Developer Relations at /pinata | Technical Writer | Building honeythread.xyz | Tinkering Photocaster | stevedylan.dev/links

I was thinking very high level. But a nice way to do this would be some kind of reaction that clients could honor (or not). 
MESSAGE_TYPE_LINK_ADD already supports this.

Would the protocol level mute user just be a Boolean for clients to do what they want with? How would that look on a hub level?

Technowatermelon. Elder Millenial. Building Farcaster. 

nf.td/varun

OK. But what if Warpcast agreed to honor MESSAGE_TYPE_LINK_ADD("mute")? No pressure to use it, maybe not even offer the option, but honor it if I use it.

Most people don’t want their mute to be public. 

There is an expectation of privacy given how Twitter and other networks  treat it.

It should really be an action saving state to a json, so any client could integrate it