Farcaster

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, conversation liquidity provider. vrypan.net (home), @l--o--l (fun). devcoin:$lemon3

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.

Technowatermelon. Elder Millenial. Building Farcaster. 

nf.td/varun

This way, 99% of the users will keep using the default functionality offered by clients, but some users (probably the ones that need it the most), could use more advanced tools.

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.

DX Engineer | DevRel at OpenZeppelin | Building orbiter.host | stevedylan.dev/links | opinions are my own

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?

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

Sounds interesting‼️ Hope, you don‘t mute me‼️