Yes, unless they do it at query level and are very clever with the query design.
They have to use the mute list to filter the feed, notifications, DMs, etc., so they have to pass the data past it. Longer it is, the longer it takes.
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!
Oddbean new post about login | logout