it's improving already; I constantly work on making that better what we need is a forcing function to break clients from the complacent position of "just use these three relays and it'll be fine"
what would that take?
Maybe choose the clients you want to see implement it and give each of them a cut of the bounty for doing it… Let everyone follow suit after that! It’s only the beginning. Bounties work well when you can split them with a team like how I’m doing with GitNestr. Just a thought! 💭
It’s may be bigfed than NIP-65 one day… but NIP-65 is the first iteration of this spirit / outbox model that could at least get clients prepared for the style of rapidly switching between connections. Good strategy may be to read from the clients you write to first (read from the relays you’re currently writing to), then if there’s no response for the note hash you requested — query the NIP-65 note & connect to a new relay to retrieve the missing note. This way it avoids the attack vectors @jb55 is concerned about by making it the primary model, while providing a back-up means of discovering missing notes & getting NIP-65 integrated sooner than later. Thoughts? nostr:note1ypm4g4vzhkyf6umdj2nklqxlvs4jyv3f55th5kzk2k8ac23633hsmm5wvv
bigger* lol
In a nutshell, this makes clients use NIP-65 as a backup mechanism for when notes are missing… if we totally rely on NIP-65 right out the gate, it might be difficult/glitchy/clients are apprehensive to implement. If we start it out as a backup mechanism then maybe it can gradually switch to the primary discovery mechanism over time.
I don’t understand the rationale behind forcing one to use multiple relays.
The idea as I understand it is one part decentralization/censorship resistance so if one relay takes action against you don't disappear, and one part failover so if one relay goes down you can still post to the other relays you are connected to.
TY… I was entertaining various scenarios, but didn’t think of this .. I thought it was the whole point of Nostr?