DNS based identifier w/o nostr.json

[ghost]

Would writing a new NIP or adding support for TXT record in NIP 5 make sense?

Example

If a client sees an event like this:

{
  "pubkey": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9",
  "kind": 0,
  "content": "{\"name\": \"bob\", \"nip05\": \"[email protected]\"}"
  ...
}

It will perform a DNS query for the TXT record of bob.example.com and get back a response that will contain the string b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9.

[fiatjaf]

See this answer at #29 (comment).

[ghost]

See this answer at #29 (comment).

I am against this on the grounds that it introduces a new way of doing a thing that is already being done, thus violating a some principle that probably has a name but I don't know.

I don't find this argument convincing because we are just verifying if author of an event owns a domain and there can be different ways to do it.

• Most popular way of doing it is creating a TXT record and some users might prefer it.

• It's easier to update a DNS record if you own a domain compared to hosting a json file in a particular format.

• Some users might want to use a domain for nostr identifier but not add any json files for different reasons.

• If TXT records are supported in NIP 5, clients just need to add a few more lines to verify. It should not be a big deal.

If people reaaaally want this they should still do it, but I think it would be better to see clear adoption before adding a NIP since otherwise it would be counterproductive.

This makes sense although it's chicken and egg problem at this point because most of the clients would not use something that has no NIP and you are against the idea.

[fiatjaf]

there can be different ways to do it

That is entirely the point. We must pick one. If you pick two or three or four you're just adding more work to be done by all clients; or creating incompatibility and confusion ("wait? why is my NIP-05 not working?"); or fomenting centralization ("don't use client A, it doesn't support TXT records, let's everybody use client B"). And what do you gain from that? Very very little.

[gkbrk]

Right now we have a one-to-one mapping from a NIP-05 identifier to a pubkey. If there are two methods that can both resolve the same identifier to a pubkey, which one should be considered valid?

I'm assuming we're not throwing away the existing .well-known/nostr.json infra that many people use right now.

[ghost]

Right now we have a one-to-one mapping from a NIP-05 identifier to a pubkey. If there are two methods that can both resolve the same identifier to a pubkey, which one should be considered valid?

Anyone. It depends on the client if they want to support one or both.

[oscarrdg]

And what do you gain from that? Very very little.

We gain simplicity:
The ability to add a NIP-05 alias without requiring any web server, https certificate, etc. and without the maintenance burden all this requires.
Just with a DNS record.

I understand you are precisely trying to achieve simplicity at the protocol level.
I just want to note that simplicity at the UX or systems level are very interesting too.

[mikedilger]

...https certificate...

I appreciate that argument the most so far.

This makes sense although it's chicken and egg problem at this point because most of the clients would not use something that has no NIP and you are against the idea.

Not necessarily chicken and egg. NIPs are supposed to be written/accepted after two clients already implement the thing (so I read). I'm happy to add it to my client after I add the other several dozen critical functions it is still missing, with settings where you can choose one method or both methods. I see the benefit. I see the complexity creep too. So I'm kind of on the fence and this is low priority for me.

[mikedilger]

And btw, the content of the DNS record would have to be the nostr.json file contents as defined in NIP-05, not just a public key. Otherwise I'm completely out because that would push people towards the centralization problem I'm trying desperately to push people away from (the one where they learn public keys without also learning where those people post to).

[oscarrdg]

The centralisation problem I see with NIP-05 aliases is that the majority of users will use external services to set their NIP05 alias, as managing a personal webserver is too much of a burden for the casual user.

Some people are also starting to confuse these aliases with some kind of 'verification', or even an 'account'.
I have seen some proposals to filter out 'users not verified' (referring to users without NIP05 alias) as a solution to prevent spam.
If this path continues, we could end up requiring to use some central services or setting our own server, with all the maintenance costs.

That looks more and more to other federated social protocols than to nostr.

Just my 2 cents.
Thank you.

[mikedilger]

After posting I realized the content of these DNS fields should be the 'nprofile' string for the person, not the nostr.json contents which includes other people.

[oscarrdg]

After posting I realized the content of these DNS fields should be the 'nprofile' string for the person

That would be a nice idea, as the nprofile string contains both the pubkey and relay information.

[ghost]

Related poll and some comments in the thread: https://twitter.com/1440000bytes/status/1612299582884696065