Thread

So every name has to correspond with a bitcoin (self transfer) transaction? That seems limited in scale

Can you elaborate?

From the readme 4. Publish a kind:60600 event, referencing the above and including a Bitcoin self-transfer as proof.

Yes, but what I meant to ask is if you can elaborate on how that limits the solution at scale

Well let's say it catches on and is on track to replace the 350 million or so entries in ICANN. At bitcoin's speed of roughly 7 transactions per second that would take like 1.5 years of this to the exclusion of all other transactions

Ah, ok. DNN doesn't have to replace ICANN, but it can with time assuming people like it. What you said in my eyes is good news actually. In realistic terms, people won't hop on to DNN at the same time, it'll be gradual, slowly but surely people would get a DNN name/ID (if I had to guess when it would have above 50% of the market, it'll probably be 25 to 50 years later). Though let's assume this scenario where every renter of those 350 million domains suddenly wanted to have their name on DNN, then 2 years or less of waiting (heck, 3 years why not), to move the whole of this massive legacy system to a new one, in one go, in that time frame, and then everything is done? That's fantastic and fast actually.

Would be nicer if it could be done with opentimestamp or something

I like the first point

Thnx =3 I'd probably run a geyser campaign since it's Bitcoin focused but don't think sufficient funds will come from it. So basically this won't get developed until I can fund it myself through the success of DEG Mods (which will fund DEGA), or get an investment, or if an interested developer comes along to program it. Aside from that though, thoughts? Concerns? I'm basically seeing peoples reactions to get feedback on it and see if I'm heading in the right direct or not (for me this is a 'holy shit this is it', but basically it needs to be challenged to make sure of that).

I don't have any input right now, sadly, but if I think of anything I'll tell you. As for concerns, I can totally see some entities thinking of this as a threat in the long run, but that is a "minor" issue in my opinion (who cares if they can't really stop it, right?)

oh ya, if this is actually a solution, yes, this becomes a massive risk that needs to but shot down x3 But it's no biggie, assuming this is legit, the idea is now out there, and whatever is done to harm it (assuming it's fully developed / people are using it), resisting against it is a breeze, I'd imagine, since it's more flexible than Bitcoin (but as a result of / thanks to Bitcoin). (I've also accounted for dealing with 'bad/illegal stuff in nodes' that Bitcoin is and/or will be facing, which would be non-destructive to the node network operations (that solution had a secondary-effect of increasing node discovery and connectivey between each other as a bonus), and accounted for the issue of the main development/maintaining team having the benefit of presenting their node releases as the default top option for people to download, which that won't be the cases unless the market does actually like their releases, otherwise another team/node version can replace them as the new top option. I'll also have this second solution for Bitcoin as well, assuming adoption, since it can be shared with it). Unrelated note: I'm replying from https://jumble.social/ , so far to me it seems like the new best web client imo. Super nice.

Yes, nostr:npub17n4cuc4d6y6qh89dekvxrenfkt5s0n49xns00uavjaxpr36c55dq87fyh9 for sure is the best nostr client.

I've modified the NIP-ND, specifically kind:61600 and kind:62600, where it now does what I mentioned previously. This means that after one acquires an ID, they can have multiple names under it that lead to different servers/sites, without needing to register a new ID. Example: - You've managed to acquire the ID nABCPoolDog. - By default, it goes to the first IP, and the first/primary name (found in kind:61600). So "desiredName.nABCPoolDog" leads to the same server as "nABCPoolDog" (note: nothing is case-sensitive). - However, after setup, otherName1.nABCPoolDog leads to a different server/website, otherName2.nABCPoolDog leads to a third different server/website, and so on. It's like you bought a ".com" and you can have whatever domain you want under it. "name1.com", "name2.com", and so on, without requiring an additional Bitcoin transaction. With that change, the protocol is now much more scalable and cheaper than before, without breaking multiple parts of it or changing its core registration/acquisition process. With a single registration/acquisition, you can have however many domains you desire, only restricted by the file size that the DNN node operators allow in their policy. Note: nABCPoolDog as a social identity, like here on nostr, will resolve to itself and/or to the first/primary name only, which is equal to the npub that owns that 'nABCPoolDog'.