Content
@
0 reply
20 recasts
20 reactions
vrypan |--o--|
@vrypan.eth
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.
4 replies
3 recasts
20 reactions
Varun Srinivasan
@v
Most people don’t want their mute to be public. There is an expectation of privacy given how Twitter and other networks treat it.
1 reply
0 recast
0 reaction
vrypan |--o--|
@vrypan.eth
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.
1 reply
0 recast
0 reaction
vrypan |--o--|
@vrypan.eth
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.
1 reply
0 recast
0 reaction
vrypan |--o--|
@vrypan.eth
Having this info on the protocol, opens up new possibilities. For example, I'd love to import/sync mute links from some of my fc friends.
1 reply
0 recast
0 reaction
Varun Srinivasan
@v
We try to avoid shipping things that only a small minority will use at the protocol level. It’s easy for a lot of little features to spiral into complexity at the protocol layer and for app builders.
2 replies
0 recast
0 reaction
Varun Srinivasan
@v
If it’s an opt in feature like this, maybe Warpcast should just let you export a CSV that you can take to other clients
1 reply
0 recast
0 reaction
vrypan |--o--|
@vrypan.eth
Portability is one thing. But making this a protocol-level action would allow me to use my own tools to do it, automate things, maybe even collaborate with others to share mute lists, without Warpcast having to do anything (other than honoring a mute LINK message).
0 reply
0 recast
0 reaction
