Interesting. How do you ensure that other people can't claim the same name you already claimed? Ie. how do you ensure you have a global state?
Have you considered coming to SEC-07?
Still need to do a bunch more work on this, but I said I'd show magic by today, showcasing the latest state of DNN, and here it is:
https://files.catbox.moe/84bw6j.mp4
https://files.catbox.moe/h49osf.mp4
What was done:
- Massive visual and UX overhaul.
- Updated the name/ID encoder (now shows fewer words most of the time, so even more human readable/memorable).
- Grabbing relevant events from other relays.
- Implemented the Awareness system (if there's a domain that's problematic, the node can mark it and not server it. Others can choose to do it).
- Updated the 6200 connection event to include a more complex support of connecting to servers (including delegating connection data to a server without risking your nostr nsec).
- Remove signer nostr connect.
- Optimization (the dashboard isn't slow/sluggish anymore)
- Fixed a bunch of bugs.
What was done (extra):
- Tested support of DNN on a nostr client and worked (on jumble.social fork).
- Tested support of DNN on a browser (lightweight one for now) to not only retrieve a website, but also verifying SSL/TLS certificate that's self-signed (no need to co-sign with the Certificate Authority).
To do:
- Double-check on re-org scenario.
- Node peer discovery, connectivity, auto self-discovery, and management as well as handling edge cases of conflicting data.
- Double-checking on TLS functionality working on the browser to the intended server.
- Detailed documentation of the project (a lot more than currently available, and on the node itself, including documentation on implementation on nostr clients and browsers, and down the line Operating Systems / specifically Linux distros).
- Set up pages for n0.0/n0 and b1m.0/b1m/b1000000.0/b1000000 to be nostr pages showcasing posts by different maintainers of different versions of DNN nodes and Bitcoin nodes (to solve the issue bitcoin has with which to best promote and use the market-decided node version. I don't want to have that mess with DNN, and on the way giving that solution to Bitcoin as well).
- Implementing the second part of DNN ID registration in PWANS (At which point this would be the tool to use to get IDs easily and manage them).
- Plan and develop and implement what I'm calling "username and email version 2" and implement it in PWANS alongside the jumble.social fork.
- Update the jumble.social fork to auto-discover a user's (with a DNN ID) relay list to have users finally establish proper connection with each other and significantly decrease the chance of missing communications (solves that problem on nostr).
- keep testing, improving, and fixing, until I'm satisfied with everything and have the DNN repo public for use and/or review the code and push PRs to fix it / contributors come and see the mess to fix and improve things bit by bit x3 (if that doesn't happen, I'll just hire one or two people to review the code and see where issues are and improve things, when funds become available), so that people can start running their own DNN nodes and expand the network / its decentralization.
I hope I didn't forget anything else to mention.
Now that my self-imposed obligation of sharing this today is done, and even though I want to continue, I want to relax and so I'll spend just one day, tomorrow, not working on any of my projects or others' (aside from normal work), because it's needed x3
Discussion
Each new DNN ID is generated based on when their policy valid Bitcoin transaction is created, and its order position in the block.
A policy valid Bitcoin transaction is one where it's a self-transfer and the transaction fee is set at a minimum of 5 vBytes.
For example, I did that for myself using my Bitcoin derived address from my nostr address (this is also an important point) and got the numbers n4.8 and b922664.8 (n as in nostr/DNN, b as in bitcoin).
The first number in each is the entry of where the transaction took place, and the second number is its position within them, in the context of policy validity (self transfer, minimum fee, order based on amount).
From that it's already unique and will always be so.
From there, the encoder transforms that number based ID to a human-readable and memorable one. That n4.8 turned into nABCeAbsurd.
n = DNN/nostr prefix
abc = batch of blocks of an upper limit if 15,600 policy valid transactions per block
e = block position within a batch
(future numbers) = cycle of 78,000 blocks
absurd = bip39 mapping to the policy valid transaction position within a block ordered by highest paying fee rate
So, with that number based ID and its encoder results, IDs will always be unique (and all are already created technically, just born yet. This is infinitely scalable, where I simulated results from 10k and a 100k years later and it still gave human-readable and memorable IDs). No collision.
So the IDs exist, and you get what you get in the end based on timing and fee rate. I'd imagine most people won't try to time to acquire a ID as other people would bump them up or down in position, they'll just do a self transfer and they get what they get. My name is still freakoverse, but my ID is nABCeAbsurd, and my I can have whatever website name, and however many, under that ID/TLD.
Regarding SEC, I'd love to (wanted to go there for a while), but most likely I'm unable to (though there would be someone there where he might do what he did last time, which is do a quick stream to everyone there of projects from people that aren't there).
That sounds really promising! It makes sense that Bitcoin would be the anchor for a global naming system, because Bitcoin is the closest approximation to a truly global database that we have.
Have you heard of the spaces protocol? I managed to set up the DHT client on my computer, but haven't tried securing and/or resolving a name yet. Would be interested in your thoughts...
https://spacesprotocol.org/paper/
https://docs.spacesprotocol.org/getting-started/fabric-dht
https://github.com/spacesprotocol/sips/blob/main/sip-0002.mediawiki
https://github.com/spacesprotocol/fabric
Unfortunately soveng is in person only, but it would be incredible if your able to join. The 7th cohort is all about networking, so your project would fit in perfectly..
It seems like the similarity between Spaces and DNN ends at 'both use bitcoin' (more specifically, both use bitcoin txid, but even there it differs).
Based on my understanding, at least on a surface level, Spaces has scarce names, must go through a bidding process to get a new name, and that process results in burning bitcoin (at scale, this isn't healthy for bitcoin in my opinion), and said process might result in requiring the user to pay (burn) a high number to get a single desired name/id/domain.
##Spaces:
Pros:
-uses bitcoin
-name transfer
-decentralized website
-equal to dns human readability
Cons:
-burning bitcoin
-relies on 'op_return' (putting spam in bitcoin, and spam here means anything that is not transaction data)
-similar bad ux as dns in terms of acquiring a name (or worse? requires consensus permission? i might be wrong on that 'requires consensus permission' bit)
-potentially very expensive
-scarce names (might not be a pro depending on who you ask, but for the end average user, and for scalability, it's a con)
-(not technical con:) brand tied (.spaces, .bitcoin)
Neutral:
-Can be updated to do what DNN is doing to circumvent IANA/IPs
##On DNN's side:
Pros:
-uses bitcoin
-decentralized websites (infinite)
-cheap
-doesn't burn bitcoin (but circulates it in a neutral sense)
-doesn't put any data on bitcoin (zero / no spam) / no reliance on 'op_return' or anything else, just the txid self-transfer
-no permission
-easy UX (self transfer btc, one click publishing of nostr events (4 button clicks at the moment, but will make it a one-click process soon), and done. Two actions. Well, three assuming you don't have funds on your bitcoin derived nostr address)
-no name scarcity (have whatever name you want, the ID/TLD part is a 'you get what you get')
-Brand-agnostic ('nabceabsurd' is just a simple structure)
Neutral:
-human-readable and memorable, but not as equal to the level of dns.
Cons:
-no transfer (though in most cases, 99%, there isn't a need to do it)
---
Aside from that, I think I'd have a much easier time with adoption, and faster, from developer adoption on nostr and on bitcoin (it's infra is bitcoin+nostr, and bitcoin and nostr sides are merging more and more over time, as well as how easy it is/would-be to implement dnn support on existing nostr signers apps or extensions), to user adoption through short to long term strategies. There's also an assumption of Tollgate's future potential growth/success that utilizes nostr, so DNN's growth path is intertwined with Tollgate as well.
---
So far, I see Spaces as a market of names to have fun in (and with usefulness in terms of identification and/or rendering sites), but not as the non-hostile slow/invisible infrastructure takeover of ICANN-DNS&IANA which DNN is going for. Though that's my opinion so far from what I looked into, and of course you're asking me who is the person behind DNN in this 'DNN vs Spaces' comparison x3 but who knows, maybe Space will be the dominant network in the future (hopefully no though, not out of malice but out of those cons i mentioned) and DNN won't be, which is fine, but I'd want to continue developing and pushing DNN to be that 'new internet' (hopefully along with Tollgate, it's awesome =3) as I took decisions for it to be simple, easy, infinitely scalable within bounds, cheap, not worry about names, and bring in a host of secondary benefit solutions.
Thanks for the patient explanation nostr:nprofile1qqsre6jgq6c7r2vzn5cdtju20qq36sn3cer5avc4x8kfru5pzrlr7sqpzpmhxue69uhhxmmvda3k7tnwdshsvcu4cn. Getting a sense of the tradeoffs helps a bit, but I must admit that I still need to give it more thought before I fully grock your system. What do you mean by "no name scarcity"? Can others claim the same name that I have already claimed? I guess the cost of doing a Bitcoin transaction is what rate limits my ability to claim as many names as I want right?
A pleasure =3
To further elaborate on what I meant by "no name scarcity", let's look at Space to help deliver what I mean.
You have name.space on the Spaces protocol, where "name" is unique and "space" is the protocol TLD (like .com) let's say.
On DNN, we have name.nABCeAbsurd, where the unique part of this is the TLD/ID (in this example, it's nABCeAbsurd, which is what I got when I did a bitcoin self-transfer. Another's might be nJHDcAbility, for example, or nMDKa12Zoo many years later), and "name" can be whatever you want, even if it's the same as someone else. The unique part is the TLD/ID, not the name.
Aah, so the name is human readable, but the TLD is a large random string - ie. the entropy that makes it secure. That makes sense. Does this mean I need to check the large random string like checking an npub to make sure I'm being redirected to the right IP address?
Are you familiar with zookos triangle?
When trying to understand new systems, I like to try to place them on that triangle to reason about the tradeoffs...
It seems to me like DNN has the same set of tradeoffs as noDNS, but DNN has a global state thanks to Bitcoin. Where does DNN store the IP address that a name resolves to? Does it use nostr for this? Apologies if you already explained this..