Replying to Avatar Lamp

nostr:npub1x3azxuysp5vmfer4vgs4jn5tmfcx4ew8sh0qnev7gczljxsr7jwqa3g4el does it really use that much bandwidth just pushing text around? most bandwidth usage is media but nostr doesnt serve that.

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.

Reply to this note

Please Login to reply.

Discussion

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).

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.

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

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)

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

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

I know, that's what bostr is about.