Nostr Web Client

Most bandwidth is from downloading notes from numbers of relays. So say each 10 relays are being requested to return last 100 events to a client.

That itself including duplicate event is already totalling 100*10 = 1000 events being received by client. Compression still proved ineffective on handling this kind of buffers as some nostr clients still tend to be intensive when requesting events to nostr relays.

If nostr client still keeps requesting for another 100 events to these 10 relays, You already know what happen next.

Lamp 1y ago

nostr:npub1x3azxuysp5vmfer4vgs4jn5tmfcx4ew8sh0qnev7gczljxsr7jwqa3g4el do you have any numbers from a real test?

Reply to this note

Please Login to reply.

Discussion

Yonle 1y ago

You could tell by looking at the bandwidth usage (This is in Amethyst client. Was intensive on requesting events)

This is just a normal scrolling through global timeline and after looking at hell thread post (4 minutes test).

Valentino Giudice 1y ago

Do you think this is actually the way it has to be, or may it just be due to clients being rather inefficient an unwise on what to fetch and when to fetch it?

Because in principle fetching text, even seemingly a lot, shouldn't be much worse than fetching all the shit you'll have using some common mainstream platforms.

Yonle 1y ago

Well. That's the way it has to be. Because that's how nostr currently works.

Yonle 1y ago

And it's also depending on client. At some part, it's being inefficient due to how it works (As amethyst tend to check whenever the event actually exists)

Valentino Giudice 1y ago

More generally, some clients may fetch way more events than they actually need to, or fetch them at the wrong time.

All in 🥥🌴 1y ago

Some people run a proxy connected to multiple nodes to save bandwidth

Valentino Giudice 1y ago

I know, that's what bostr is about.