Tragedy of the commons comes to mind when I read these kinds of misdirected comments.
Relays are finite resources. The better question is why your specific algorithm needs that many. From that we can then have a conversation.
Tragedy of the commons comes to mind when I read these kinds of misdirected comments.
Relays are finite resources. The better question is why your specific algorithm needs that many. From that we can then have a conversation.
What's the difference in costs from 10 to 30 filters per sub?
Why not 300 filters?
Just because I don't think that is needed. 10 is just way to low for today's use cases.
The way the conversation should go is:
- I, Victor, have a particular use case for having more than 10 filters
- I find out relays have limits, let me contact relay devs to get those limits increased
- Relay devs hear you out and increase your limits
Instead we get this useless conversation and nobody is winning 🥇
I am not sure that works. First because I don't know which relays our users are trying to access. It's all one by one, after a lot of debug time. Quite impractical these days.
And second, relays are seeing that Amethyst hitting their rate limits all the time. So they already have that information. They shouldn't need me going there and make the life of their users better.
Btw, relays are getting hit no matter what. The app will send 10 filters, then the next 10, then the next 10 as soon as each receives an EOSE... So i don't think people are saving any costs by limiting to 10... It just takes longer to get everything.
“Costs savings” is the wrong assumption here