Ironically, I think we are building a tech that enhances out-of-band human-to-human interaction.
Discussion
I agree, the more we pull people out of the traditional “cloud” the better. Humans are designed to communicate with humans. It’s time to flip the internet right side up again. Have you put much thought into a distributed trust registry for usernames that an owner of a domain can offer registry without risking users from losing their name to domain on the http level? Frost would be interesting on a presentation card to prove control of the username with a key on the physical card. I am also wondering if distributed git and blossom can help us verify distributed code in server client schema negotiations. Maybe like smart contracts between client components and servers.
I am grokking my way through this, experimenting trying to figure out what really matters. A human-readable name bound to a cryptographic identifier is super important. The best, but not optimal solution so far is NIP-05.
Yes the http method in NIP-05 is flawed by ICANN and traditional DNS.
DNS mapping is important also for orthogonal checks https://dnsrecords.io/did.mfoster.io.
I was thinking yesterday that maybe a distributed Nostr DNS server could be developed one that performs checksums on Git relays https://gitworkshop.dev/danconwaydev.com/ngit-relay for code bindings. This would allow for distributed HTTP servers. However, it still doesn't solve the ICANN registry issue.
It seems like there needs to be a smart contract-based registry, where domain owners can lock in their domains to guarantee automatic renewal. Otherwise, NIP-05 rug-pulling could become a serious concern.
Cool. FWIW, I am a co-author on this https://datatracker.ietf.org/doc/html/draft-carter-high-assurance-dids-with-dns-07 draft-carter-high-assurance-dids-with-dns-07
Very nice, what are your thoughts as far as utilizing OP_RETURN for a registry fee and forever keeping state changes on a domain/DNS mapping level?
I have to get my head back into this and think deeply about it. Right now I see the npub as the ultimately resolvable address. NIP-05 does the job with a provider you trust. Pragmatically, this is the solution in the near term. I like the idea of being able to resolve with a BTC OP_RETURN transaction but haven’t put much thought into it yet.
I have thought deeply about it and have some ideas. 💡⚡️
Awesome! Keen to hear some more!
First off here are the resources from the ICANN for blockchain integration including payments.
https://www.icann.org/en/system/files/files/octo-039-17oct24-en.pdf
I’ve built #nostr #safebox to be independent of the web app and nip-05 provider. The npub of the safebox is its address and numerous lightning address and nip-05 providers can resolve to the same safebox instance.
I’d like to try it out. I like the concept of using Web NFC and NDEF. What size cards are you using?
I have been digging around in IS0 7816, ISO 14443, and Java Card.
https://gnupg.org/ftp/specs/OpenPGP-smart-card-application-3.4.1.pdf
NTAG215. 504 bytes. Only works with Chrome/Android Web NFC for now.
I tried this size and my CASHU tokens were too big? How are you writing the claims to the card?
Yeah, I use a completely different approach for #nostr #safebox. I replicate what’s done by the card networks by generated an encrypted secret on the card. The token on the nfc card gets submitted along with the payment request, decrypted and sent along to a NWC server to execute the payment instruction.
Do you have an Open Git repository for this specifically? I am going to try it.