What do you mean? It's a single badge for each profile. Or you mean it's too heavy to fetch a badge for every profile an app encounters?
Yeah, maybe.
In that case would be nice to have a standard for publishing lists of people as bloom filters, such that they are interoperable.
Login to reply
Replies (2)
Yeah, that is still my dream. One way to save a bloom filter that anyone can recode and understand.
I've already though about the bloom filter idea, as well as @hzrd149 and many others.
Imo it's just a "short blanket".
You can use bloom filters to do basic filtering. E.g. hide this event because its author is not allowed, but you can only do it *after* you downloaded the event.
So, where it is useful?
Only where you can't control/specify the authors in the REQ beforehand. This includes:
- filtering spam from DMs
- filtering spam from replies under a post
- filtering spam from notifications
not for search, not for reccomendations
What's better for filtering imo is bulk ranking, which with RankProfiles takes few ms and allows to rank 1000 pubkeys in a single request.
(Oh and btw it's free for up to 100 request/day per user, which means a total of 100k per user).
Instead of a simple 0 or 1, in or out, you get a score between 0 and 1, you can use the reputation in more interesting ways.
e.g. for replies, you could compute a score which is
score = pagerank(author) * zapped amount(from people I follow idk)
and then filtering using the threshold T
score < T
This also has the benefits of not having to worry about expirations, because yes reputations change all the time, precisely ~18k times a day with the current scale of nostr. You just request the moment the user clicks on the event to see the replies.