NIP-05: Is it Time to Say Goodbye to the Blue/Purple Check?

NIP-05 addresses are everywhere. Many clients show them under every message with a blue or purple check. Some clients don't show the address but just show the check. I'll make the case that NIP-05 addresses have their place but we are using them wrong. They are good for identity sharing but wore than useless for verification.

NIP-05 is a Verification Anti-Feature

At face value, a valid NIP-05 address verifies that:

1. the account was created by the identity they are claiming to represent.
2. the account hasn't been compromised and is still operated by this identity.

This is underpinned by the widespread usage of a blue or purple check mark connected to the address. An equivalence is created with the once hallowed blue check, back in the glory days of the other bird app.

NIP-05 fails so badly at both of these types of verification that it gives a false impression of identity verification. This makes it an anti-feature. It's worse than useless for verification.

The vast majority of accounts use one of over a dozen NIP-05 verification-as-a-service domains. This includes enough public figures for it not to raise an eyebrow, even for a keen observer, to see a public figure they don't follow to use a service like this.

Even if these services have robust procedures to prevent a scammer assuming someone else's identity, another one could be setup.

Do you think Lyn Alden's NIP-05 address is:

• [email protected] or;
• [email protected]

One of these is her actual NIP-05 and the other is an unregistered domain name that a scammer (or NVK) could register and use today.

If the account has been compromised the attacker would change the NIP-05 to use one of the above services as soon as the account owner updated the npub reference hosted on the domain.

All the while users are presented with a comforting blue or purple check which they interpret as confirming the account is run by the identity they are claiming to represent.

Even is we halted these services, scammers could still register a domain name that could conceivably belong to the account and use that instead eg. LynAldenFinance.com and we'd face the same problem.

NIP-05 is for Meat-Space Identity Sharing

NIP-05 is a useful tool but we have got its value and the UX all wrong.

You should use it in a phone call, podcast or face to face conversation:

"You can find me on nostr by searching for [email protected] in your favorite nostr client."

Or in response to a question like "How do I follow fiatjaf?" you could say:

"Search for fiatjaf.com in your nostr client."

In an online conversation it is still best to say:

"Search for npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 in your client".

I'm not sure we are at the stage where sharing a link to "

" is going to consistently work. Also, I'm not convinced linking to the npub on a specific web client is the right UX either.

NIP-05 User Interface Recommendations

Here's some actions clients could take to address this:

1. Clients should phase out displaying NIP-05 addresses on any feeds.
2. Clients should stop associating NIP-05 with a check of any colour. Its time to say goodbye to check altogether. The blue check has been dragged through the mud and the expectation on nostr that it relates to NIP-05 would be hard to shift?
3. Clients should only display it on a detailed profile view and only if the associated npub appears correctly in the nostr.json.
4. Clients should stop displaying it to other users as invalid if they cannot connect to, or find a nostr.json on, the domain. In this case the address should not be displayed at all. In my experience, it is almost always invalid for this reason.
5. Clients should treat an account with a NIP-05 which points to a different npub as suspicious and take action to either not display posts, or display posts with a warning. Currently there is a 'boy who cried wolf' problem with invalid NIP-05 addresses.

Conclusions

Yes, its time to say goodbye to the blue/purple check as it fails to provide the verification it seems to promise.

This is the first of short series of posts on Nostr Identity Display, Verification and Recovery. These thoughts have have emerged whilst designing Nostr Authorisation Groups, as part of wider work on GitHub Alternative on Nostr. See Key Challenges for a GitHub Alternative on Nostr naddr1qqyxxdmyvsmrqdn9qywhwumn8ghj7mn0wd68yttsw43zuam9d3kx7unyv4ezumn9wspzpgqgmmc409hm4xsdd74sf68a2uyf9pwel4g9mfdg8l5244t6x4jdqvzqqqr4guzzjrgj