That's one of the reasons I created a caching server for NostrGram.co. It caches all the events from the top 100 relays (by user counts) and reads from the caching server to only send a single event stream. Writes still get broadcasted to all configured write relays, but that's a tiny fraction of the bandwidth of reads.
Discussion
hmm centralization, nostr has really ignored the big networking problem
It is more central, that's true, but an important distinction is that NostrGram's database isn't the *only* place where this data is stored. It's on all the relays, too. So there's decentralized redundancy. Clients can verify the signature of the events coming from NostrGram to verify that nothing is being modified (don't trust, verify).
if the app can only pull from one server its quite a dependency
It *currently* only reads from the caching server, but it's on my roadmap to support reads from other relays that aren't cached (or to skip using the caching server altogether). We need some NIPs to make reading from multiple relays more efficient though. This is currently being discussed.
i remember #[4] mentioning something on this
Yes, his idea for querying relays to see if they have the event ids but not get back *all* the data and then only querying specific relays for the needed ids is a really good one. That alone would take care of a lot of the redundant event issues that eat up mobile data.
seems an obvious idea like many things, relays do seem lacking, question is maybe skip them and work on p2p given the effort going into holepunch
I have no doubt p2p is coming to Nostr. There's no reason not to create a p2p messaging system on the protocol. It won't be the only way it's used though. People will always want a social media platform to communicate on. Better a hybrid relay/client system with choice than a centralized walled-garden like the current Big Tech social sites imo.
certainly nostr has diverse dev paths thats the beauty of what is happening, p2p is not proven either but has always seemed possible, i think p2p being added as a module, another relay option etc is likely what will happen
Amazing!
I guess I wouldn’t worry about centralization too much yet? This level of caching sounds more costly even then a regular node? Let’s see how it shakes out once usage is high, and it starts to cost to use relays.
#[0]
this is why nostrgram is my favorite client so far. Besides the nice features, the caching makes it really snappy and fast. #[1]
Twitter is fast 2, if u accept a filtered view, how can u be sure that u see not a censored version of ur and ur contracts server list, relays where always a wrong nomer nostr relays are in fact plain servers, the relay function is in the client, by Broadcast over segregated servers.
Speed and convenience will always drive incentives, does it matter what relays goodies are being indexed by a certain client if you're curating your own feed? building direct connections with accounts?
What direct connections, if relays would become mirros of the whole net, what is then the whole net? What direct connections without a common server ( relay) are possible? Sure u could and must run for curating ur own posts anyway a server, but will that reduce bandwide? And can u do that on a mobile? Sure clients will be relays and store ur own posts, but to share them behind NAT on a mobile is only convinient possible with Tor. And then why not use tor socks from the tor browser in first place, pub/key auth is in essence transport independent, why use nostr bulk global servers anyway? To find inital contacts? Then one or two global relays would be enough.