Hi. Thanks for sending me that proposal. The way nostr works, that proposal wouldn’t make much difference; the vast amount of data consumption comes from downloading the same events over and over from multiplier relays.

While there are a lot of low-hanging fruit optimizations left in client development (all stuff I have in #[4]​ ‘s roadmap) there are even more harder optimizations with significant impact to be done here.

Nostr is still very early and the optimizations have yet broadly not been explored.

And yeah, like it’s been said on this thread, in the interim, a proxy approach like I did while I was in Thailand turns the nostr usage to exactly the same model as a Twitter where it’s as efficient as possible (no data duplicates, no local signature verification). The proxy work still needs to be formalized as I never got to write that NIP.