The Nostr and Bitcoin communities have plenty of overlap as outlined in this great post. Maybe Nostr should adopt the Bitcoin Naming System? First class integration of Bitcoin names, like satoshi.btc, would be a huge opportunity for BNS, Nostr, and Bitcoin.
Nostr already has a naming convention called NIP-5. These names are already strong from an open source and decentralization perspective. Would BNS be any better? Compared to NIP-5 BNS names offer:
Global state
Onchain verifiability (hard to spoof or forge)
Flexibility to update npub or name anytime
BTC names are just kinda awesome. A great way to signal support for Bitcoin.
How can we make this a reality? There are a couple paths forward:
We can use .btc names within the NIP-5 standard. The names would be a bit funky, for example @[email protected]. But the upside is that it follows the standard and would resolve on all Nostr clients today. Should be pretty fast and easy.
We could also provide a new standard that resolves BNS names directly. As a proof of concept we would probably need to create a new client, or fork one, to resolve and display standard BNS names as expected. Definitely a better “name product” or “name UX” but probably a slower road to adoption.
My opinion is we should probably try both.
What else is needed?
We need a way to easily update zone files. I don’t know of any app today that makes it really simple to add the npub record. Would also be nice to have an API that returns the npub for any given BNS name. We’re working on both of these ATM so happy to contribute our efforts on these goals.
Does BNS(x?) need enhancement to support “@” symbols in name registrations?
We need a way to easily update zone files. I don’t know of any app today that makes it really simple to add the npub record. … We’re working on both of these ATM so happy to contribute our efforts on these goals
Regardless of nostr, it seems like this is a need in the Stacks community: a well-functioning and easy way to update / manage one’s profile.json and zonefile? That’s something you’re working on? (Would love to see a preview / designs!)
Thanks for kicking off this thread @jeffd. I wrote up my proposed approach and started a thread specifically related to that approach here: Bringing BNS Names to Nostr
My proposed spec, which I’m calling NIP-69 (ha!) and a preliminary client implementation in a fork of my favorite Nostr client, Damus and frequently asked questions are linked there.
Yes! The lack of globally unique names is a major usability issue in Nostr in my opinion. I sat down with Nostrovia today, (the Nostr podcast) and I couldn’t even ask listens to follow me on Nostr because
I don’t know my public key
no one wants to listen to read out a nonsensical string on a podcast.
Another major issue is the challenge clients have in implementing autocomplete when the people you’re following don’t have unique names. The current “@'ing” people process in a Nostr note (at least on Damus) is something like this:
Start writing note and realize you want to @ someone.
Go find the profile of the person you want to @ and then copy the npub from that into you clipboard
Go back to writing the note and past in the @ npub
I’d also add
privacy - your nostr client only sends requests to one location to look up names instead of to every random website of every kind: 0 nostr event (Nostr profile info) your client processes. Motivated users can even run this entire stack - bitcoin, stacks, BNS api - locally (on an umbrel node, etc) so the process can be totally private.
speed - making requests to many sites to verify nip-05 means opening lots of new DNS lookup and TLS connections to sites located potentially anywhere. This is resource and time intensive. A client would do all of their BNS lookups from one (possibly self-hosted local) site so only one DNS look up and potentially TLS connection is needed.
no…the @ isn’t part of the name, think of it as a protocol scheme like “https://” or syntax marker or markdown. The convention is that when it is at the beginning of string, it tells the app that it should treat the string after the @ as a username. When @ occurs in the middle of a string that string is intended to be an “internet identifier” as defined in RFC5322.
YES! I used a fork of renewbns.com running locally that lets me arbitrarily update zone files. I was adding this functionality to something else but I couldn’t get update-name working with @aulneau.id 's micro-stacks. The update-transaction would succeed but there’d be no zone file. The Renewbns fork used stacks.js which worked perfectly.
Initially, I was going to say, “while this would work, it doesn’t really contribute much to making Nostr a better experience. or their community - it feels more like helping ourselves than making Nostr better. While helping ourselves is also fine, I really want Nostr to be awesome too.”
On second thought, I think this NIP-05 would encourage all of the people that have .btc names as their Twitter names to join and start using Nostr. While not a direct contribution to making the protocol better, it would be a strong contribution to Nostr community…especially given the overlap of people, interests and value.
I don’t see why the NIP-05 approach also couldn’t be done at the same time!
@larry , I’m curious on what you think the general reaction would be to a more BNS-native Nostr experience? Have you talked with many nostr people about how on-chain names can improve the experience, and do they seem open to it?