Subnostr

IMHO the fact that nostr identities use self-created and self-managed keypairs is not a flaw, nostr does not need a way to bind keys to names, nor does it need identity provider services.

If you want to bind a key to a name, use a petname. That idea was there from the start (afaik). What is a name anyways other than a way for you to remember who that key represents?

The whole business of binding keys to other sorts of identifiers was always murky to me. Why are these other sorts of identifiers important? Who are they important to? Are the centralized? Do they promote centralization? Why should I trust some 3rd party with this binding?

Back at Sun Microsystems IT, I made a proposal I was (and still am) very proud of, but it wasn't accepted and probably wasn't really well understood either. The proposal was to send new recruits a javacard with a Sun PKI keypair pre-generated on the card, along with a serial port smartcard reader (this was pre USB). They would fill out their job applications under a session authenticated by (or else digitally signed by) the keys on that card. Everything the company knew about the person happened through those keys. In this way, the problem of authenticating people before giving them a keypair disappeared. The problem of binding some knowledge about them to a keypair was solved, because all that knowledge was acquired in the first place through that keypair.

I have no idea who fiatjaf really is. I don't know his real name. No third party bound some identifying information about him to his keypair and shared it with me in certificate form. And yet I have a good idea who he is and how much I trust him and in which regards. "By their fruits shall you know them" - Matthew 7:16

Nostr has other issues. How to roll over a keypair. How to export/import private keys without risking their exposure. IMHO these are much better issues to have than ... oh shit Thawte/StartCom/Comodo/DigiNotar/TurkTrust/NICCA/CNNIC/WoSign/LetsEncrypt/Symantec/StartCom/GoDaddy/Certinomis fucked up and aren't trustworthy.

hodlbod 2y ago

What you say is true for identities native to nostr. But impersonation is a real issue for people who have a reputation outside the system (we've seen this problem crop up multiple times this week). I don't know if that can be solved by binding names, because you can always create a similar name (phishers do this all the time).

A checkmark is the right idiom, but what that indicates is not that the name is bound to the account, but that the account represents the user's idea of what that name represents. The best solution I've been able to find is to show a check mark on an account when a user is following that person. Self-authenticating, so of limited utility, but at least it's something.

Reply to this note

Please Login to reply.

Discussion

Mike Dilger ☑️ 2y ago

This is where i think petnames work well. If you petname the real McCoy, and your client shows your petname in a special font or color, you can have it say "(the real) Jack" and not be fooled by other "Jack"s. (I keep meaning to add this to gossip, it is a small and easy change, but I keep diving deep into the hard stuff first).

Of course initially this doesn't help if you don't know which keypair is the real Jack. That probably has to be discovered out of band though (e.g. professing your keypair on Twitter).

Maybe 1984-aware clients could flag as "possible impostor" any account that other people have reported as being such.

hodlbod 2y ago

Actually, that's a good point, nip 32 or 1984s might be the best way to do this. Petnames might be a really underrated feature of the protocol too, if more people used custom names you could show "name (most popular petname)" or something.

StephanGuy 2y ago

report real and fake ids? report works really well on amethyst