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… 🖼️
