Bringing Names to Nostr

I propose that we use names from the Bitcoin Name System (BNS) as globally unique names for Nostr. Let’s call them Nostr Names and the spec NIP-69 because it’s quick and dirty and why not? I’ve written a draft spec and added functionality to a fork of Damus, the beautiful iOS Nostr client by jb55.

What is Nostr?

Nostr is the first decentralized social network that looks like it’s going to work.

Nostr has three things that other upstart social networks do not have, pragmatism, simplicity, and, most importantly, a passionate community of technically-savvy and product-focused users.

Nostr is based on the same public key cryptography as bitcoin and uses a simple client-relay architecture to distribute your notes and hints on which relays to find them to your followers. Users are represented by public keys like npub132w0sg64x08h2klxvytsamgcu63qqmk8d2yv8ltay8nvzwahk6wsyg2j8n (mine!) and you follow someone by following their public key. Posts, or “events” in Nostr-speak are addressed by the hash of their content and signed by the publisher’s private key.

Public keys aren’t human-friendly

When you start to use Nostr you quickly run into the difficulty posed by talking about identity solely by using a public key. Most humans today can’t remember their own npub let alone those of their friends. There are a number of proposals to try make Nostr public keys more human-friendly by giving them names…in fact, the very second "Nostr Implementations Possibilities", NIP-02, suggests using petnames. NIP-05 raises the possibility of using internet identifiers, user@domain - like email addresses - as a way to associate public keys with a name. Some users have even taken to “mining” public keys - repeatedly generating private keys until the associated public key begins with their desired string of characters - to make them appear more human-friendly.

All of these solutions have significant problems. We'll talk about those later.

How do Nostr Names work?

There are four components: a Nostr client, a Bitcoin node, a Stacks node and a BNS name lookup API. The BNS name look up API connects to the Stacks node, the Stacks node connects to the Bitcoin node. These can all be run by the motivated user with no trusted third parties.
Every user who wants a name registers this name in the BNS smart contract. They can do this today through an app like btc.us or programmatically if they're so inclined.
User adds their Nostr account public key to the zone file of the as a TXT record named “underscore” “underscore nostr” and signs and broadcasts a transaction calling the update-name function of the BNS contract.
The hash of the updated zone file is anchored in the Stacks blockchain which is in turn anchored in the Bitcoin blockchain. Zone file is propagated via the atlas gossip protocol between all Stacks nodes.
User adds their BNS name to their Nostr profile in their client which publishes it in a kind: 0 metadata event in the field nip69.
Client performs request to a BNS name lookup API endpoint to retrieve the zone file for the claimed name, extracts the Nostr public key and compares it to the expected public key

For a more detailed walkthrough and technical examples, please see the NIP-69 draft.

This is needed because other solutions are broken:

The problem with only public keys and no names

No one can remember their own public key - difficult to communicate to your friend.
No one can remember their friends’ public keys.
This makes it trivial to spoof someone else.
You can’t verbally communicate your public key to someone else - try asking listeners on the Nostrovia podcast to follow you on Nostr.

The problem with vanity public keys

The human readable part is not unique - If you can generate a vanity npub that starts with a certain human readable prefix anyone else with access to adequate computing power can too.
The unique part is the non-human readable part which is the part no one can remember.
Because vanity npubs are not unique, it is dangerous to rely on them to identify users and opens your followers that rely on them up to attacks by bad actors impersonating you.

The problem with NIP-02 petnames

They don’t help you find people that aren’t friends of your mutual friends
They are confusing to communicate to others: Bob may be bob.larry to me but he’s bob.alice to Alice. To tell someone listening on a podcast to follow bob.larry I could say “follow my friend bob on nostr”…but what if they aren’t already friends with me? You need to both know the petname and the chain of people through which you are related to it to find the person. Not easy.

The problem with NIP-05 internet identifiers

DNS names - even ones you “own” are controlled by the state and a number of other 3rd parties.
Expensive & complicated requirements: DNS name, ssl certificate, web server running on it.
The web server need to permit the store of arbitrary data in the .well-known directory - non trivial if you’re already using the domain for something else.
The expense and skill required to configure one’s own DNS name has led to a number of 3rd party sites offering “verification.” This leads back to the same problem fiatjaf mentioned in the Nostr FAQ with user identities being controlled by 3rd parties.
Bad for privacy - Your client sends request to the domains of each NIP-05 verified account whose events you access even if you don’t follow giving them the opportunity to track you.
The user@domain format implies implies domain controls, owns or has some other hierarchical relationship with user…a relationship that in Nostr doesn’t actually exist.
domain does not provide or own user’s Nostr account…the user generates the private key themselves and has complete ownership of their account

Trying this out

To try this out, you can check out my fork of Damus which you can run on your iPhone, iPad or Mac and then visit my Nostr profile.

Next steps

There are a number of next steps before sending a pull request with NIP-69 to the NIP repo:

Community feedback from the Nostr and BNS communities…especially developers:

Does this approach make sense?
– Is this something you would use as a user?
– Nostr client developers: is this something you’d enable in your clients? How do you feel about the implementation?
– What am I doing wrong? (or right?)

Creating tools to make it easier for BNS name owners to link their Nostr name to their names.
Adding support to Damus for loading suggested relays from a BNS name
Adding support to at least one more client for NIP-69

I’d love your help with any of these!

To learn more about Nostr, NIP-69 and BNS, listen to the Nostrovia podcast I recorded today with gsovereignty that will be released soon. You can also read the original thread on Twitter. For a related discussion of mapping bitcoin addresses to names read my post on standardizing names for bitcoin addresses.

To ask me questions about this or share your thoughts, find me on Nostr npub132w0sg64x08h2klxvytsamgcu63qqmk8d2yv8ltay8nvzwahk6wsyg2j8n, tweet at me @larrysalibra, message me @larry in the Nostr telegram group or join the discussion on the Stacks forum.