Replying to Avatar ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ

clients have to have a model of a relay in them, some are more explicit in this than others. #nostrudel lets you literally run a relay on localhost:4869, which i have done extensively with my relay, and from this i saw just how chatty this whole thing is, unnecessarily

i've already come up with a way to reduce the traffic aside from this addition (and yes, a bloom filter is less bandwidth but maybe just having an extra "not these" field in the filter would work too, arguable) - that is, and i'm going to add this to my relay, it keeps track of events it sent out recently to clients, and not send them twice in some time window

also, you really haven't actually seen how much times this data gets requested by clients, i can tell
Avatar
ben 1y ago 💬 1

I connect to the nostr network through a proxy relay that I wrote and operate, so I’m aware.

I’m also cautious of premature optimization, particularly when solutions are advocated very matter of fact.

I agree bloom filters would help reduce data tx, but it feels like a spoiler on a honda civic.

Reply to this note

Please Login to reply.

Discussion

Avatar
ben 1y ago 💬 1

with that said, I encourage you to explore and implement it! all iteration is good iteration.

Avatar
ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

yeah, i'm not implementing it

i've figured out that i can have the relay track what events it sends out and not send them out every time they match a filter

within some time window that seems reasonable, somewhere between 5 and 30 minutes i figure

doesn't have to be bloom filters, that is just a compact representation of a list of 32 byte, ie 64 character event IDs that you can represent as 1 bit, pretty much, with a low rate of false positives in the bloom filter

if you got 500 results and have them cached, then that's more than most relays are ever going to send, and that's - hypothetical 500 results already known, 16kb of data in your hypothetical filter that is intended to reduce bandwidth