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