In nostr.json, each pubkey has their own relay list. Take a look at mine: https://mikedilger.com/.well-known/nostr.json
In saying this though, I'm not suggesting that NIP-05 ought to be how we find people's relays if we already know them by pubkey. If we know them by pubkey, we should get a pubkey-signed document, which NIP-05 is not.
wow i cant believe it is not signed, thats a real oversight, nostr needs to resist centralization
Well, it is a statement by the domain, not by the nostr keys. The domain is saying "Yes, this person at this domain goes by that nostr key". The relays are just in there as hints,.
yes it is a statement by the domain and so are all the events statements by relays, signing is fundemental to nostr, it allows trust inspite of any distribution methods
But domains don't have nostr keys to sign with. The relays part could be signed,yes, but the prevailing opinion was that we don't want to rely on DNS and would rather have such information elsewhere.
um the user would sign the thing stored at the domain? aka just another event
Yes, that’s what #[5] did with his NIP-65 spec for a signed message with relays, but there’s nothing yet about putting that signed message on the nip-05 verification / identity server or in a DHT where you could look it up without knowing at least one relay for that npub.
#[8] 's standard i think now is you implement then nip
so we need dht on relays and maybe clients?
i start to think we could host more on the nip5 providers, maybe relays should start doing both, then hash chains and repos and nostr is feeling more like bluesky
the nostr way seems to be explore many possibilities and come to what works, i cant disagree with the progress this way
I’m personally fine with DNS, I mean relays rely on dns for example. But I don’t like the idea that something as important as what relays you’re using isn’t signed by you.
We could host the 10002 message signed as part of the webfinger file that nip-05 uses, or put them in a DHT.
It feels like DHT’s are less fragile and dependent on a service provider.
