97c70 - 1mo
Combining `p` , `e` , `t` , and `word` mutes into a single list is so stupid. In order to properly support any of these features, you need an interface for two separate scenarios (private and public mutes). If you want to support all four, you need eight separate inputs. A perfect case study in why it's annoying to overload event kinds.
Anthony Accioly @Anthony Accioly - 1mo
Agreed. And there are exactly zero clients I know of that actually support all the variations. With rare exceptions, even p-mutes are restricted to either public or private, at least when it comes to writing. (Reading is a bit better; a lot of clients can handle it). NIP-51 really needs a reality check. Kind 10000 and 30007 are just two of many, many things I struggle to find a good reference implementation for. From a relay perspective, you wouldn’t believe how much junk those lists contain, and how much clients spam them. I have some generous rate limits to my relays, but as soon as I open certain clients I know that they will reach rate limits in seconds reading 10000, kind 10002, etc. Even on personal relays 🤣.
Coracle is probably one of those clients 😅
hzrd149 @hzrd149 - 1mo
I managed to build a pretty clean implementation of it in applesauce. but I agree, NIP writers and us developers need to think twice before putting yet another tag into an existing event kind I like the idea of encrypted lists though, but maybe they should be different kinds?
Been a while since I last used it, but Coracle and Nosotros were / are mostly well behaved (to be honest I'm not a heavy user of Coracle advanced list features so this may be the reason, but I don't remember Coracle getting rate limited while rendering my follows feed). Amethyst, which is my most used client is one that often ends up rate limited in a few seconds 😅 (but Vitor is working on the Outbox model, so hopefully this will improve soon).
