I decoupled the names event from the connection records (like dns records for when you update your domain) in DNN so you don't have to update two places at the same time (not sure why I decided that in the past...).
DNN node peer discovery is working (two nodes on two different hosts), but there's a design flaw with it that I'm fixing.
After that, I need to make sure that the DNN daemon is working after that decoupling change, along with the forked Min browser, double-check on delegation if it still works along with ssl/tls self signatures, clean up docs, then I'd release the DNN node code (so that people can see the horror, but it's working! x3).
I want to also see if I can package it for umbrel/start9/cloudron, but I'll pause that for temporarily.
Then I can start poking nostr clients on their thoughts about it, and see if they'd implement it into their clients, then start talking with browser projects/devs for the same purpose, then linux distros, etc.
During which, I'd start working on that Discord alt.
Funnily enough, this made me realize how amazing DNN is, not DNN itself but the idea behind it: Cleanly, harmlessly, and effeciently anchoring nostr identity to Bitcoin that results in unlimited application/usecase possibilities.
At first I was amazed "holy shit is the ICANN-DNS problem solved?", and in the past two days I've realized "holy mega-shit this extends beyond solving ICANN-DNS". DNN is just the first application/usecase/solution in this system.
This also means, to a degree, there's no need for a lot of alt blockchains to exist, so this isn't a threat to Bitcoin, this is actually a potential threat to a large number of alt blockchains...
But I'll only be focusing on DNN for now and make that the best that it can be and try my best to have high adoption with it so that people don't need to worry about ICANN-DNS (and SSL/TLS) anymore. Others could figure out other services with this now discovered system, which... let's call it 'Cross-Protocol Anchoring'.
A process that connects a key from an identity protocol (e.g., a npub in Nostr) to a key in an anchor protocol (e.g., a Bitcoin address) to produce a verifiable connection record within the anchor protocol. This connection record can then be used as a deterministic reference point to tie application-specific data under the identity protocol, without modifying the anchor protocol itself or adding any new data to it.
This probably needs a document or whitepaper or something to be written for it. Hopefully I'll remember and find the time to do that x3
View quoted note →
btw, i haven't mentioned this before, but DNN isn't reliant on DNN nodes to work (and that's pretty cool!), but it does rely on it to lessen the load on users/nostr-clients/browsers/OSs, as well as provide a similar quality of service and reliability of traditional DNS and services like Mullvad/Cloudflare for content moderation and saftey.
Having a DNN node network/system also provides many other benefits, aside from reliability, so that's another reason for its existance and value for people to run one up.
If you're wondering how it isn't reliant on a node to work:
naboutgateb > translates to block 6744 at position 2 > queries bitcoin nodes to find the specific transactions ID after applying rules > queries multiple nostr relays to find an event published with this TXID > finds it then the npub that published it to derive a bitcoin address from it > if the derived address matches the input/out of the bitcoin transaction then it's verified that this npub is the owner > print: ☑ for ID verification /or/ start fetching domain records /or/ start fetching metadata
This all would be done client-side/browser-side/OS-side without a DNN node, unreliabily, but with a node it handles all of the middle part and highly reliable.
Had an interesting discussion with another person about bloat/spam on bitcoin, we were pretty much on the same page, aside from my DNS solution with DNN.
Even though DNN doesn't add anything to Bitcoin (no op_return data, no exploitation of witness data / taproot, zero), no writes, where it only reads from Bitcoin as users do a simple self-transfer (bitcoin address A sends to the send bitcoin address A), I could not comprehend the presented issue of:
'There's now an incentive for people to do self transfers, and at scale this would result in bloat in bitcoin not for its intended purpose of sending money from A to B.' (paraphrasing)
I couldn't comprehend the presented or perceived issue because:
1. It is sending A to B ('B' being 'A' itself)
2. It doesn't add anything, no bloat
3. Even if a full block or blocks were about these self-transfers, they are legit and clean (no non-transactional data / zero)
The gentleman I was discussing it with see DNN as a bigger threat than Ordinals, which came to me as a surprise considering I myself am against it, and don't mind also if op_return was zero, and that's why I made the DNN the way it is now.
My best attempt at coming to an understanding is that because the reason/incentive isn't about sending money from A to B just so that B can have the money, then this shouldn't be socially pushed to become mainstream because if it catches on and many people start doing self-transfers, it'll bloat bitcoin blocks with these self-transfer type of transactions. But even then, my thought was "So... because the reason/incentive for sending a transaction isn't for sending someone money or utxo consolidation, then it's a bad utxo, even though it's no different from any other clean utxo, if not cleaner in comparison to many other utxo because no op_return rule + input=output, as in as legit/greenlight of a bitcoin transaction as it can be".
I was wished upon that I'd stop doing DNN because of this perceived threat that's supposedly bigger than ordinals and op_return (combined?), but wtihout coming to understanding how this is that big of a threat, if a threat at all, I probably won't...
...not out of being malicious, as I'm simply solving the ID and DNS problem with it, as effeciently as possible, and as cost-effective and cleanly cleanly as possible, and the most simplest with the highest security possible, and there's no one backing me, and I won't be getting anything out of this aside from using it like everyone else, so there's no conflict of interest or ulterior motive (not saying anyone is saying that, just trying to deliver a point, which is...), so since I can't see or understand the problem, then I can't even agree or disagree if it is a problem or not to then decide if i'd continue making DNN or not, as a result i'd continue making it.
From my point of view after thinking about it, the pushback isn't a protocol purity resistance (resistance against op_return/junk, witness exploitation, etc, which is a legit pushback and I resist it as well), but rather a hyper purestic ideological that extends/overeaches outside of bitcoin.
Going back to what Satoshi mentioned about this topic, where one or more people asked about adding a DNS solution into Bitcoin, the idea was rejected and suggested that a DNS solution should be on a different chain, so that no non-bitcoin/transactional data is added to Bitcoin, and as a result namecoin and others like it were born, however, the discovery with DNN is that it follows that exact logical reasoning: nothing is added to Bitcoin (no spam/junk/bloat), and DNN only observse it (observes only clean transactions).
If there was such a thing like a 'Satoshi Test', then DNN passes it with flying colors.
When I think about my opinions on Bitcoin in regards to what should be done with it or what shouldn't be done with it, the line is clear: don't add unrelated things to it (op_return, witness exploit, ordinals, etc), don't overreach (prevent people from doing a normal utxo because of a disagreement on the why, which is more dangerous as that would add subjectivity to objective system).
However, I might have gotten something wrong or am fully delusional, so if you have thoughts, feel free to share it.
The people you like and/or respect and/or admire might make wrong decisions, have bad opinons or stances, or even do something bad, and it doesn't mean that you have to agree with them, follow what they have done, or defend them, and it's not wrong to point it out, and it also doesn't mean that you have to cut them off or stop liking/respecting/admiring them.
Focus on the topic, do what you think is right with it, unaffected by the people around the topic, be it friends/family/etc and how it may affect them, and carry on.
Reitirating, be it friend or foe, god or the devil, take what's useful to from all to help you reach what you'd think is right and cast away all other elements unrelated to the topic (the idea, the problem, the solution, etc).
DENOS
A PC nostr signer, DNN ID manager, payment system
- Available for Linux, Windows, Apple (Annoying to use on Mac because I won't have an apple dev account anytime soon. Tested Linux deb/pkg(friend)/appimage but not rpm or flatpak)
- Generate a 24 word seed and get nostr keypairs (or import 24 words / nsec)
- Three flows to login (bunker (nip-46), username/password (custom nip-upv2, local (custom nip-pc55))
- Different options to handle signings for each event and clients (approve/reject, auto approve/reject kind, auto approve/reject everything from client)
- On signing into the same client without cached history of the previous login, asks if you want to replace the previous connection (with saved policies toggle) or create a new one (or cancel)
- For the username/password flow, it would detect if someone that knows your password has attempted to login with it while the signer is offline (might be you / false alarm, but you'd be notified regardless)
- Bitcoin wallet derived from your npub (so not from your seed / no expectation of HD style wallet)
- eCash (nutzap specifically is what's mainly used, tokens encrypted to receiver's npub, that's how i see ecash on nostr, always)
Here's the source code (Download for your OS in the releases page. For Windows use the .msi installer):
GitHub
GitHub - Freakoverse/DENOS
Contribute to Freakoverse/DENOS development by creating an account on GitHub.
And if you want to test out the two other login flows (username/password and local/nip55-butOnPC), you can use:
Jumble
A user-friendly Nostr client for exploring relay feeds
Future:
- Nostr Silent Payments (custom nip-nsp)
- Be able to receive more than just bitcoin natively (Any secp256k1 can be supported)
- Bitcoin multisig (based on seed, not npub) with nostr comms flow to make this shit easier x3
- Point-of-Sale system for merchants to do e-commerce with traditional payment methods over nostr (custom nip-dpos, for the DEGA project / any e-commorce project)
