No. That’s how you end up with a single huge relay called relay.x.com.
This is the equivalent of bcash.
Bitcoin nodes must jeep state in sync and the limited blocksize is the compromise we make to make that possible. Nostr can’t limit the amount of data it produces.
NIP-65 is important (tho imperfect as I described earlier) but saying “relay syncing is bcash” is overblown FUD. We need relay syncing, especially for paid relays. nostr:npub1dergggklka99wwrs92yz8wdjs952h2ux2ha2ed598ngwu9w7a6fsh9xzpc
Strfry has syncing. I don’t see you calling it Bcash. What’s with all this hate?
Relays use FOREST to retrieve missing notes from other relays — but this functionality can be extended — relays can examine the NIP65 metadata (list of relays) inside a note and contact those relays to retrieve the note content…
This way the user doesn’t have to establish new connections to get the benefits of NIP65.
Still doesn’t solve NIP65’s other problem, but I have a solution for that too. Saying syncing is bcash is idiotic non-sense Pablo.
User checks where the note is stored with NIP65, relay grabs note from other relay (using the same NIP65 list) and delivers it to user.
This removes burden from the client and places it back on the server/relay. If the server/relay doesn’t grab the note for the client, the client can resort to grabbing it how they do today.
STOP THE FUD 🛑🙏
nostr:note1hdwwegfed7hmwvwxnznwefknhxxcn9yxzg56muz7vkta0yn08maq4fxa6q
nostr:note1zmll2uuknztn5f50feevxwxk5hqwmkjd4h82swj97cjthxzf3nlsgydcay
Decentralized GitHub social layer (notes reflecting commits etc) can use NIP65, but the repo itself is stored in relays and must be syncable otherwise it’d be centralized to one relay.
You can’t turn a repo into nostr notes, that’s why we use Merkle DAGs for the repo. See the bigger picture… 🖼️
