pull down to refresh

DNN: Decentralized Naming Network
767 sats \ 6 comments \ @freakoverseOG 24 Oct nostr
(I wasn't sure where to make this post, if it should be posted on here/nostr or on bitcoin, but decided here).
DNN, a Bitcoin-anchored naming system for nostr and the web.
  • Doesn't bloat Bitcoin (no data added to it).
  • Not a blockchain / there's no shitcoin.
  • Permissionless.
  • Censorship-resistant.
  • Scalable.
  • Cheap / no recurring payment.
  • Have whatever name you want and change it whenever you want.
  • Human-readable & human-memorable ID/address/true-name.
  • A lot of secondary-effect solutions and benefits that come out of this.
I essentially examined the issues of past attempts to eliminate reliance on ICANN and noticed their problems, and collected others' criticisms of them, which led me to develop this approach.
Here's a presentation of the idea: https://video.nostr.build/ce76b435f360425f24ec98faeb037527bc33af90e453511c67b8ca813f62b14c.mp4
Aside from that, you can read up on the README file and other files (NIP-DN and node policy) from the repo found on this slave site: https://icannot.xyz/
Would like to hear people's thoughts on it.
If this turns out to be a proper solution, then I'd continue developing it, assuming I'd have funds for it, or if devs come along to help develop it.
write
preview
related posts
0 sats \ 1 reply \ @ursuscamp 19h
If I am understanding this correctly, it is similar to a “phone number” or human-readable bitcoin transaction ID that also has associated metadata? Interesting idea if that’s true.
So the Bitcoin event is connected to the Nostr event because the Nostr events public key is encoded as a bitcoin address right? In essence, while this “adds no burden to bitcoin” in a practical sense it requires multiple transactions for a name since no one uses their Nostr pub key as a bitcoin address. So it would involve:
  1. a transaction to send bitcoin to the address for their Nostr pub key
  2. a second transaction to send bitcoin from the key to itself as the “marker” transaction
  3. a third transaction to send their remaining bitcoin not spent in fees back to their actual main wallet (optional but likely to occur)
When I was originally working on Nomen I also considered using a scheme that involved using a Nostr pub key as a bitcoin address/pub key as well, but I kept hitting this same wall. I ended deciding it was both less costly to Bitcoin and overall less tiresome to the user to just allow them to use any Bitcoin transaction from any address with just an attached OP_RETURN as the anchor. This is actually even easier now since core v30 relaxed op return restrictions, giving more room to create a sane protocol (I originally made some discouraging mistakes in Nomen due to having to work within the 83 byte limit).
reply
0 sats \ 0 replies \ @freakoverseOG OP 14h
Happy you checked it out =3
I understand that concern, or rather, it’s more of a practical consideration than a true problem. To acquire a DNN name/ID, a user would typically need at least two transactions: one to fund the Nostr address, and another to perform the transaction that anchors the name/ID. A third transaction could be used to return remaining funds.
On one hand, it is a practical issue, more so on that third transaction if it happened, for the user, but beneficial for miners, of course, since they'd get more fees x3. However, I'd counter the general presented practical issue with 3 points:
  1. cost efficiency: even with multiple transactions, acquiring a name/ID on this protocol is, in most cases, cheaper than ICANN.
  2. retention and future use: a user who funds a nostr address to acquire a name might leave their small balance there, either to acquire another name later, using the same address or another nostr address.
  3. social and transactional utility: that funded nostr address can serve practical purposes, such as sending funds to other nostr users (or other bitcoin addresses by other people), giving the address social or transactional value beyond just name acquisition.
What I'd summarize from all of these points is, yes, there's a bit of a practical overhead, but it wouldn't dissuade the user from using this protocol, especially considering its counter-benefits and general various primary and secondary-effect benefits.
Side note: This is also making me think of a 'nostr-first' approach of a wallet wallet, where a wallet can be developed/released, where it would, from its seed, generate multiple nostr addresses and from it their corresponding bitcoin addresses. With altered UX tweaks, this would result in having a user use their wallet (new wallet based on this setup/scheme of course) for their normal bitcoin transactions/saving, but also can be used for nostr purposes as well (with careful UX planning as to avoid, or rather decrease the chances of, privacy and ID matching). Just an interesting thought I had while writing this reply =3
reply
0 sats \ 1 reply \ @supratic 25 Oct
What are the alternatives you have found not satisfying your expectations that push you to build this solution?
reply
0 sats \ 0 replies \ @freakoverseOG OP 25 Oct
Most of them require running a separate blockchain that is not the most secure in comparison to Bitcoin, and most of them seem to be centralized (or at least not as decentralized), and having to deal with a currency that is not as solid as Bitcoin, and for those that have used Bitcoin, they're adding non-transactionary data and bloating bitcoin with said data where aside from being limited by their sizes, there might be a future that these loop-holes get removed.
So I basically looked at all their problems (from what I knew and from what people have mentioned), and thought, "Can there be something that doesn't have any of those issues?" and came up with this solution with those points mentioned in the OP.
From my pov, it seems like this solves all those issues, scales well, and is secured (without bloating/adding junk to Bitcoin), etc.
reply
0 sats \ 1 reply \ @k00b 25 Oct
Interesting scheme. I was curious how it was both "anchored in the bitcoin" and not putting data on-chain which is laid out in (4):
  1. Publish a kind:61600 event with your desired name.
  2. Publish a kind:62600 event with connection data.
  3. Publish a kind:63600 event with metadata.
  4. Publish a kind:60600 event, referencing the above and including a Bitcoin self-transfer as proof.
This inversion of offchain referencing onchain rather than the reverse is not something I've seen before.
I was also curious how one can "Have whatever name you want and change it whenever you want" and it appears that that's only true if your name carries metadata about how to verify the name:
alice.n50.5 alice.b1000050.5
This can be shortened to another encoding I guess:
To improve human readability and memorability and make referencing DNN names easier, DNN supports an extra encoded format that compresses the block number and transaction position into a compact alphanumeric string.
The above example becomes:
alice.agd-abandon alice.ytj-abandon-zoo
Which is objectively more human friendly even if it's unsatisfying.
Overall I feel like I'm not able to "Have whatever name I want" but it's an interesting scheme.
reply
21 sats \ 0 replies \ @freakoverseOG OP 25 Oct
I'm basically differentiating between an "ID" and a "name", where "alice.n50.5" can be "bob.n50.5" where the change happens in nostr event kind:61600
reply