Damus
Mazin
Recent notes
Introducing Purgatory - our new spam evaluation engine for filter.nostr.wine. The newest addition to our nostr event data pipeline. Here is a flowchart that npub1qlkwmzmrhzpuak7c2g9akvcrh7wzkd7zc7fpefw9najwpau662nqealf5y npub1qlkwmzmrhzpuak7c2g9akvcrh7wzkd7zc7fpefw9najwpau662nqealf5y made to illustrate how it all works: https://i.nostr.build/61SaCp4c3Ns5TjZu.png
I assume you have received several good explanations by now, but in case you haven’t I wrote this almost 2 years ago: How do we check “follower count” on nostr? 1. Your client sends a request to all your connected relays asking for contact lists that follow you 2. Relays answer back with the events requested 3. The client aggregates the event total, de-duplicates, and displays the count Each relay has a set limit on how many stored events it will return per request. For some relays it’s 500, others 1000, some as high as 5000. Let’s say for simplicity that all your public relays you query use 500 as their limit. If you ask 10 relays for your followers the max possible answer you can get is 5000. In reality you won’t ever get 5000 unique responses, you’ll likely get something closer to the same 500 from each relays you query. That won’t change if you have 20,000 followers or 100,000 or if you query 100 relays instead of 10. You may get back a “different” 500-5000 each time, but you’ll still cap out at 5000 (non-unique) because that is the most events your client will receive. Primal, nostr.band, and other aggregators that store counts in their own DB will always show different numbers than clients reading directly from relays. Generally speaking, neither number is correct! note1rg39c6hwy29eucrztq7hupd7gtvqjtfeansgsqresh9dx9jqt8gsklyq75
Randomly assigning relays to new users without any reliability or performance metrics will not end well. Primal has the benefit of their caching service to mask the problem but those users will suffer on other apps that don’t support it.