Verification on Nostr

[Aspie96]

There is something I have been thinking about.
Nostr doesn't have a verification system (NIP-05 is not a verification system, it's meant for shorthands).

However, I think some kind of simple verification system that is compatible with how Nostr is supposed to work is possible.

My idea is simple: any account can act as a verifier. Any user can decide what verifiers to trust.
When X is verified by Y, Y publishes a new event specifying that X was verified and with what username ("name" property). Y updates its verification list: each entry contains the ID of a verification event and the pubkey of the verifier.
The client checks the verification list of X. If there is a verifier the user trusts, the client pulls that verification event and displays the verification to the user.

[fiatjaf]

This could work. Or we can use the badges system that is already supported in many places. But regardless of that we don't have anyone that is willing to perform such verification processes right now, and I don't see why anyone would want to do that at least in the short term.

[fiatjaf]

(And if someone shows up I'll assume it's a scam anyway because it makes no sense.)

[vitorpamplona]

Follow list is a lighter form of verification everybody already does.

It's how migrations with #1056 work.

[Aspie96]

Or we can use the badges system that is already supported in many places.

This would require standardizing the "verification" value for the d tag.
I'm not against this.
My idea to include the username in the verification event, however, is so that the verification is invalidated if the username is changed.
I think it would make sense to keep this as a separate event kind, although I do see the overlap with the functioning of badges.

I don't see why anyone would want to do that at least in the short term.

I suppose for the same reasons people do everything else they do in the Nostr ecosystem.
Why would one provide NIP-05 identifiers, as many providers do (including at no charge)?

Follow list is a lighter form of verification everybody already does.

Following serves a different purpose: to, presumably, follow accounts that you think are interesting.
Verifiers, collectively, could verify a larger amount of accounts than most would be interested in following, or even just fetching. The list of accounts followed by a user is fetched as a whole. The client also needs to continue fetching even after the first response (because it can be updated).

Currently many clients display NIP-05 identities as verification.
I think this is a bad idea. Some providers wrote an article about it, but it's unfortunately not available at the moment: https://hedgedoc.semisol.dev/ciXY6QE-Tx6CQZowDwcK4A?both#
I think having a "standard" way to handle verification could help to discourage this practice.

There wouldn't be a specified global meaning to a verification, since any user can trust whatever verifiers they want and any verifier can verify anyone they want.
However, I think the verifiers that would work best in practice are those who verify accounts that (on whatever grounds they deem appropriate) appear to be neither spammers nor impostors.

Veification events may also include an expiry date (also not present in badges), if the verifier wants to reconfirm the verification (by replacing the event) after a certain time.

The interaction between the user and the verifier is outside the scope of this and may happen outside of Nostr.

[alexgleason]

NIP-05 of a _ name actually does verify that you own the domain, in most cases.

Follow lists are useful, eg:

[Aspie96]

Yes, and anyone can own a domain. Spammers own domains. Impostors own domains.
The fact that someone owns some domain is pretty meaningless.
Plus, domains comes at a cost, they rely on the centralized DNS systems (yes, relays do to, but any user would need to deal with the oligopoly individually to get verified) and they require talking to servers unknown to the user (which is a matter of client design and configuration).

[alexgleason]

Yes but do you think jack@cash.app is an impostor?

I understand what you're saying, but understand what I'm saying.

[Aspie96]

That is possibly the best known account on Nostr. I was thinking about mere mortals.

The current policy that many client have is displaying a "verification" check besides the name of any user that has a NIP-05 identifier.
It's a bad policy. Having a NIP-05 identifier means nothing besides the fact that you have a NIP-05 identifier. It's useful, but only to have something more mnemonic than a pubkey. It's not a verification, it's merely a shorthand.

Conversely, if a user chooses to trust a verifier and that verifier confirm the user is to be "trusted" (by whatever policy they have), it makes sense for the user to trust verified accounts.
NIP-05 can't do this because, besides the other problems I mentioned, each account can only have one NIP-05. So either the client trusts all providers as verifiers by default (which is in no way better than just trusting every user directly) or only trusts those selected by the user. But trusting only those selected by the user wouldn't work because each account can only have one provider.

[jivanpal]

Let's make sure that we learn from past mistakes, and don't reinvent a wheel that is more useless than useful:

• https://en.wikipedia.org/wiki/Web_of_trust#Problems

• https://medium.com/@bblfish/what-are-the-failings-of-pgp-web-of-trust-958e1f62e5b7

[jivanpal]

Let me clarify that my concern is not one of loss of keys, but one of the utility of a web of trust (which is indeed exactly what you're proposing, albeit with the suggestion that clients only look at the web within 2 degrees of separation from themselves). The main issue with a web of trust is not a technical one, but a social one: users of the feature must be competent enough to only sign keys that they have actually verified, and/or only trust verifications from users that they know will only sign keys that they have actually verified. As soon as users start signing keys that they haven't actually verified, or trusting such blind verifications, the utility of the system goes completely out of the window.

We have already seen this happen with PGP en masse with regard to keys used to sign software packages and email messages, since the vast majority of users do not have the technical competence/awareness to know what the consequences of signing another key are, and simply blindly follow instructions telling them to sign other people's keys without them having any legitimate reason to do so. My expectation is that such senseless signing/verification would simply happen again to the same extent, if not a greater one, on Nostr.

PGP implementations have mostly worked around / solved this nowadays by using centralised keyservers that verify PGP key UIDs (e.g. email addresses) before publicising keys that are uploaded to them. These include services like https://keys.openpgp.org/ and Keybase's cross-platform proofs system. Of course, such systems rely on a person's identity on one or more other platforms (e.g. email, Reddit, Twitter, etc.) being known, but this is largely not an issue. Indeed, Nostr already uses domain names / internet IDs for identification via NIP-5, which I see as being good enough as is.

[Aspie96]

Ok, thank you a lot for clarifying!

users of the feature must be competent enough to only sign keys that they have actually verified, and/or only trust verifications from users that they know will only sign keys that they have actually verified

Indeed this is true of all verification systems, even centralized ones. For example, Twitter (back when the blue tick was meant to be a verification, not just something you could buy) did verify fake scam accounts (for example, I recall personally seeing spam accounts impersonating Vitalik Buterin being verified, which is of course detrimental to users regardless of what you think about the person).

It's perfectly reasonable not to want to trust any verifier at all. What often happens on centralized platforms, however, is that users trust one specific verifier (the platform) which may or may not o a good job at it. My idea is to put control back in the hands of the user.

I think a reasonable implementation of my idea would absolutely not expect most users, or even half, or even 10% of all users to be verifiers. A good client wouldn't suggest that you should start verifying accounts.
Instead, specific initiatives, with specific accounts, could have the purpose of verifying users that wish to be verified. Everyone else would choose a list of verifiers to trust (or none at all). From a technical prospective, every account could be a user and a verifier, but what I was imagining (and what I should have explained more clearly than I have) is not a situation in which everyone verifies others.

Many users may feel they don't need this feature at all: neither to be verified nor to verify others. That's fine. But I think enough users would want this to justify it. Consider the following:

• Some Nostr-related projects may benefit from having a batch of users they consider to be (likely) real. These wouldn't be part of Nostr per se, but rather use it and (hopefully) contribute back to its ecosystems. Consider scientific research, spam detectors, search engines that need a starting point of real users or posts. There are many kinds of analysis of interactions in the Nostr ecosystem that would benefit from having even an imperfect (but sufficiently large) batch of users which are likely real. Those working on these would have the technical skills required to fully understand how the verification system works. Learning more about Nostr, having it be analyzed and talked about, would help us and Nostr may have a lot of potential in this area.
• Currently NIP-05 is (incorrectly) promoted as a feature for verification. This has effectively all of the disadvantages you mention and none of the advantages I mentioned, but it does suggest users would want such a feature.
• For some it would likely be a vanity thing.
• Currently users don't have the responsibility of choosing what verifiers to trust, but they do have the more "direct" responsibility of choosing what accounts to trust. This raises similar issues for incompetent users.

internet IDs for identification via NIP-5, which I see as being good enough as is.

Internet IDs only verify that the user paid for a domain. Scammers pay for domains. Scammers own domains. Scammers are absolutely willing to pay if that gets them what they want. They buy domain, they buy personal data, they pay for ads. Someone having paid something is about the worst metric I can think of for whether they are a scammer or not.

At least one large NIP-05 "verifier" (the same one I use, which also happens to be the one Snowden, a rather prominent account, uses) agrees with me that NIP-05 isn't a verification and it doesn't seem to be alone (although I can't "verify" this anymore, because the article is no longer available).
Even if you believe NIP-05 should be a verification system, it's fair to say NIP-05 providers (at least one) are giving an ID to unverified users, who will then have the nice "tick" besides their profile name. And what clients do is trust all "verifiers". Anyone can buy a domain, specifically start giving an ID to scammers and most clients would start showing those accounts as "verified" without giving any choice at all to the user.

[jivanpal]

Internet IDs only verify that the user paid for a domain.

Let me also clarify that I don't see internet IDs themselves as an immediate form of verification. Rather, they are simply human-friendly aliases for public keys. The reason they exist is that they are easier to remember, and if you already know about someone you wish to follow via an identifier such as their website's domain name or their email address, then it stands to reason that they will also have a corresponding NIP-5 alias (or rather, if someone with such an alias exists, then that someone is the person you wish to follow).

I completely agree that it doesn't make sense to show a verified checkmark if and only if an account has a NIP-5 alias, and I can't fathom what the developers of client apps that do this are/were thinking.

I generally agree with everything else that you've said, and feel comfortable that you have a good understanding of what constitutes verification and what the potential pitfalls are of such a system. With that in mind, I still feel like having verifications as a native feature of Nostr will lead to network bloat. I think it all ultimately depends on how well the social aspects of such a system are handled; it's all well and good to propose that most users don't publish verifications, but it's another thing to actually put the system out there and see how it gets used in practice, and I think that the world's past experience with PGP perfectly demonstrates what we can expect to happen of any similar such system at scale.

[vitorpamplona]

I completely agree that it doesn't make sense to show a verified checkmark if and only if an account has a NIP-5 alias, and I can't fathom what the developers of client apps that do this are/were thinking.

This sounds like a complaint you need to raise with that particular client. NIP-05 doesn't even use the word verification.

[Aspie96]

With that in mind, I still feel like having verifications as a native feature of Nostr will lead to network bloat.

Why network bloat, more than other Nostr features?

I think it all ultimately depends on how well the social aspects of such a system are handled; it's all well and good to propose that most users don't publish verifications,

I don't think random users publishing verifications would be the issue, on its own. It would however, pave the way for the actual (potential) issue: users trusting verifications from everyone they follow.
There is a risk that users would handle this wrong. However, at a minimum, I expect that developers, researchers and the like that wish to use this kind of information for the purposes I exemplified, would understand the issue at hand perfectly well, and surely much better than most other Nostr users (in all likelihood, myself included).
This is a feature which, I think, would be useful to many skilled users. I think it's consistent with Nostr philosophy to trust that users don't mess up their Nostring, for which they remain responsible (consider the task itself of holding one's private key, or understanding that the private messaging activity is actually public, except for the content of messages). I don't think we should not have it because some could misuse it.

but it's another thing to actually put the system out there and see how it gets used in practice, and I think that the world's past experience with PGP perfectly demonstrates what we can expect to happen of any similar such system at scale.

I don't think the lesson from it has to be "don't do it", I think it can be "do it differently".
I think a good description of a potential NIP wouldn't suggest that clients ever suggest users to verify anyone else. Indeed, I don't even think clients need to implement a feature to verify other users at all, that just needs to be defined at the protocol level.
Even at the protocol level, I don't think there should be a defined way to ask for a verification.

This sounds like a complaint you need to raise with that particular client. NIP-05 doesn't even use the word verification.

Yes, I 100% agree with this.

But I did need to respond to the idea that NIP-05 is a form of verification. Since many users seem to believe it, and since it was brought up by others too in this repo.
I was not suggesting that NIP-05 is a "bad" form of verification (it just isn't one) or that NIP-05 providers are doing something wrong by giving an ID to unverified users (they are not, IDs are just handles).

To be clear, I am not against NIP-05.