“Blind signatures cannot prevent or discourage the unauthorized lending of certificates. This drawback by itself renders the blinding technique useless for the majority of certificate applications”
Re-reading Brands book on certificates. Came across this statement above. This is the superpower for ecash.
Pug in the sun.
As part of the 80km canoe trip, the boys had to portage through Ottawa downtown. You can see Parliament in the background.
NPUBs could replace IBANs (International Bank Account Numbers) for cross-border payment.
Got it! Something like nostr:nprofile1qqsg2aharxl7dy7t5mc2acemssnnxscxs3hvvxm9uttpwgy7rsppq3spr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp046dlwk, where it's possible to claim a username paying a fee (5k if I remember) would be nice in terms of UX. Also, thanks for the sats. :)
Thx. Still lots of experimentation to do.
Thx. I notice your nip05 is not verified with Amethyst. I had a similar problem and after a couple of days of troubleshooting I discovered that I had a trailing slash after nostr.json/ and nginx treated it as a redirect so nip05 failed. Hopefully you can fix.
nostr:npub1q6mcr8tlr3l4gus3sfnw6772s7zae6hqncmw5wj27ejud5wcxf7q0nx7d5 I'm really digging the Pay-to-Npub flow using nostr:npub10penj5dqgdw6yez25hd7vgcvcp3ys3qn9fh7yyl9j9cte37a8pcq7jycdm, but I was wandering... How can we get a nice username like npub@openbalance.app or trbouma@openbalance.app? Count me in if you are looking for beta testers for the username flow. ;)
I do have the ability to create custom handles, I just haven’t yet implemented the UI for it. As for P2NPUB, it’s meant for a generic pass through. I do have a bunch of nostr integration underneath the hood, I am still thinking the best way to leverage/expose.
Another thing that #nostr does is that it decouples the concept of a ‘certificate’.
Shortly after the invention of asymmetric cryptography, the ‘certificate’ was invented which was basically a signed public key with some metadata. This gave rise to that very powerful industry, PKI, where they made you believe that you needed them as an ‘issuer’ to be trusted.
Well, #nostr breaks that all apart, because the ‘certificate’ become part of the network, where every event (especially kind 0), becomes its certificate. If you need to graft of extra trust you can do so with nip05, and other yet to be specified trust schemes where an event (certificate) can be countersigned by another party or cross-validated against another source.
So in a nutshell, what does #nostr do? It breaks apart our current notion of a certificate and makes it part of the network as relayed events that are signed and uncensorable.
TBH, I haven’t thought it through completely. The question, I believe is specifying the validity period or state of a prior npub with something like “expired”. The problem is that the prior npub, if compromised, could specify a bogus n+1 pub. I think this is an open timestamp-like problem.
Yeah, that the idea. The trick is the ordering of npubs so that (n+1) npub can announce that (n) npub is no longer valid. Similarly, someone can determine which events were valid and at which point they are invalid. Likely will require an open timestamp.
Not sure. We could do something similar to hkd with xpub, but I think the way to go is to publish events that point to the next valid npub. The trick is absolute ordering, so that if the original npub is compromised it can’t trick you to a bogus new npub.
I was playing around with tbd which is jack Dorsey's project: https://developer.tbd.website/projects/ssi/
I am not sure where that is going TBH (pardon the pun). The leadership is too opinionated for my liking.
I am pretty sure there is a simple model underneath it all. Just haven’t figure it out yet. I think it’s something like generating a new npub, publish a kind xxxx event that this is the next npub.
Yeah, there is no commercial incentive. This needs to be considered as public or sovereign infrastructure.