I’m ok for now.. I’ll stick to these 2 relays and see what happens. I queried more than 250 relays last week and I found my notes being broadcasted as part of a pollination effect in Nostr so one way or the other I’ll be fine
Discussion
There are certainly a lot of relays aggregating events from others.
I’ve found that once we get outside the top 3-5 relays it’s very high % duplicates.
#[3] has been rocking only nostr.wine/filter since we made it pretty successfully. Of course not what I’d recommend to everyone, but cool that it works.
I used to have a lot more paid relays but started slowly deleting them as they were slowing me down.
Please do let me know if you have any issues or suggestions. We have lots of ideas but are mostly waiting for NIP-42 (client auth).
Cool .. for now it feels good .. and I hope I can now use Nostr on mobile data :)… as before it was killing me
Yes! Big benefit to be had here. Lot less duplicates being downloaded and less event sending.
Client caching is of course another big step that’s coming eventually.
Hey one other thing… why do we need to add “another relay” for filter instead of being just Nostr.wine relay with eventually some commands in the end that can put “filter=true”, broadcast=true”?
We decided to keep them separate as they scale very differently.
Nostr.wine has regional mirror relays that stream events to each other so the databases are local and extremely fast.
Filter is at least 10x bigger than nostr.wine in terms of db size and uses considerably more resources. It’s harder for us to scale them in the same way so we kept them completely separate.