Nostr Web Client

I too am interested in this. I basically avoid nostr when I'm not on WiFi. I don't have unlimited data and it blows my data plan out of the water after about 5 min when I accidentally use it on a mobile network.

I think there are some settings that can help with this though like, having a different app/profile with just one relay, turning off media loading. Turning off all extra stuff like nip05, and possibly pfps.

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

having a local relay and imageproxy like a little local deployment of nostrudel, that i use here, would probably help a lot, especially the imageproxy, though the app should be keeping a cache of images (ya know, cache management isn't that hard but mosta y'all never did serious systems programming, and i only just got the excuse to build a cache)

second thing that would help would be a new field in filters that lets you send a bloom filter of all the event IDs you don't want to be sent in a request

i've filed this as an issue/enhancement request on nip-01 and i'd appreciate it if more people would recognise what a massive boost it would make to mobile users

Reply to this note

Please Login to reply.

Discussion

calle 1y ago 💬 2

Can you talk more about the bloom filter? How do you get a list of event IDs you don't want to see in the first place?

ben 1y ago 💬 1

probably from the local relay. but passing a bloom filter up seems like a solution looking for a problem. send up event ids. too many? use since/until. too big? use better encoding. still too much? write a for loop.

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

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

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.

ben 1y ago 💬 1

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

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 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

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

ones that match the filter, in the local cache

#nostrudel has already started to move in this direction with the local cache relay, use the same query format for in-app data and then you can first check that, and then construct a bloom filter from the IDs that match, and add that to the filter before you send that filter out