nips
nips copied to clipboard
nostr-protocol
NIP-122: Request For Events
For direct requests?
On Sun, Jun 23, 2024 at 5:33 PM, Vitor Pamplona @.***(mailto:On Sun, Jun 23, 2024 at 5:33 PM, Vitor Pamplona < wrote:
Nice!
You should allow a tags as well.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>
Yep, you can ask using e tags and/or a tags for the newest version of a replaceable.
If this becomes widely implemented, I could see someone posting an ephemeral public request for missing events, and then thousands of clients all responding with those events flooding the relay they are communicating with.
I'm not sure by what mechanism that can be avoided.
If this becomes widely implemented, I could see someone posting an ephemeral public request for missing events, and then thousands of clients all responding with those events flooding the relay they are communicating with.
I'm not sure by what mechanism that can be avoided.
Clients can respond to a sample of the incoming requests, rate limit, have quotas for this function or data caps, require PoW, respond only from their Web of Trust.
There's plenty of solutions to mitigate that scenario.
If this becomes widely implemented, I could see someone posting an ephemeral public request for missing events, and then thousands of clients all responding with those events flooding the relay they are communicating with.
I'm not sure by what mechanism that can be avoided.
Relays also mitigate the effect by not forwarding if the event ID is stored.
It might also be a hint to the relay or to a relay service to find those events because your users want them.
There could be services that just connect to relays and re-broadcast events from other relays based on these requests.
Interesting approach. Could maybe also eventually be extended to respond with wrapped events if events are not accepted (maybe too old or other reason).
