Its being done for one npub only, in the client. That really isn't much to ask of a device made in the last 20 years. Even sqlite should be near-realtime, I should think... 

 They already give up with my npub, sometimes. I have mutes bleed into my feed because they hide too slowly.

It works better in the clients that filter out mutes in the base query. 

 adding a negation to filter fields would go a long way to making that work better but the source-routing-style blacklist strategy is gonna cause big problems there too 

 It's just lists, really. So, they just need to say "include these lists and excluded these lists", right? 

 that would intrude a bit into the clean separation of the database, it requires an expansion of the query API, and the bigger these negation filters get the more problematic they will be for performance

probably at some point the simple filter query strategy will give way to a cleaner GraphQL syntax 

 Yeah, starting to outgrow the efficient complexity. 

 i think it is starting to outgrow using a simple numbered proposal list for the protocol specification in general, because implementation details like this actually make a big impact on what the protocol on the network level should be 

 we need to start thinking about Nostr 2.0 like how we have HTML 5 now 

 That is going to be a problem for gathering data for Minitru. Velvet's npub was hard to get data from, this is probably why! 

 I think the eventual solution will be relay ‘Allowlists’. For the absolute minimum ’allow’ you might have to do a PoW at a certain difficulty. That’ll cut out the bots. 

 Yeah, whitelisting instead of blacklisting. Easier. 

 Yup. 

The nice thing about these discussions on #nostr is that they are technical and nobody is trying to appeal to an amorphous moral authority. 

 It's much nicer to talk about things you could do if that's what you want instead of things that everyone must do or else. 

 Yup, I often say that ‘should’ is the worst word in the English language. 

 I take a lot of heat for that, tho. Too spergy, not moral enough. 😏 

 Happens to the best of us. 😐 

 Enough, you convinced me 😅 

 I just accidentally muted someone and went to unmute, and it's like... Damn, like looking for a needle in a haystack. 😂 

 3) network and storage load - both follow and mute lists in some cases are exceeding single figure kilobytes in size, this is a problem  

 That's true. Some relays will eventually cut off long mute lists, as well, as they have max-event-size. 

 half a megabyte is probably typical, but i can see that being reduced

there is also data storage strategies that could at least shrink those long strings of repeating pubkeys down to small, varint references, and existing data stores have compression to reduce such duplication of data but at some point the network is gonna be the big pain point 

 We'd end up muting a botfarm and losing the mutes for the hardcore porn and Neonazis. Decisions decisions. 😂 

 client devs are gonna be forced to pay attention to this soon as DAU keeps ticking up 

 DAU? 

 daily active users 

 Yeah 💯
This shit don't scale, y'all. 

 Do we need to read the list?

Performance makes sense, good point. Especially with the volume of bots.

Are you proposing a barrier that prevents bots in the first place? Some sort of filter so they don't even reach the point where they need be muted? 

 Well, some relays already remove them with spam filters.

I'm suggesting client settings set to whitelisting schemes, rather than blacklisting. 

 Right 

 You then need to think about discovery, so that people can find more npubs to whitelist. Otherwise, they'll get bored. 

 You can see mutes in listr.lol or Nostrudel under Lists. 

 I remember there was another tool. It had throughthemetaverse in the domain name. I think there was other queries in it as well. Had it in my nostrnet .work but the domain expired. I’ll try to find it. 

 Ok found it 🤙🏾

https://toolstr.hitchhikersguidethroughthemetaverse.info/ 

 Ah, okay, but that would only find the ones that you were following, not the ones that you had muted.

nostr:nprofile1qythwumn8ghj7un9d3shjtnwdaehgu3wvfskuep0qy28wumn8ghj7un9d3shjctzd3jjummjvuhsz9thwden5te0wfjkccte9ejxzmt4wvhxjme0qydhwumn8ghj7argv4nx7un9wd6zumn0wd68yvfwvdhk6tcpz9mhxue69uhkummnw3ezuamfdejj7qgcwaehxw309anxjmr5v4ezumn0wd68ytnhd9hx2tcqyzvmk4v3eygkvq8cg5g86v0ekk0z7lr7pxsllqpwsncag0d92l9xgxt6qmv   Is that a possible DVM? 

 It shows who muted a particular npub. 
I agree, this would be awesome on the DVM bot 👀 

 The way mute lists work now is that mutes are either public or private (encrypted). Amethyst for example uses private mutes only, which is better for privacy, but also means other people, as well as external tools can't see who muted who anymore.  

 See NIP-51 https://github.com/nostr-protocol/nips/blob/master/51.md 

 Thanks for the info! 

 Damus uses afaik still the old kind 30000 which complicates things even further 🥲