Replying to Avatar Tim Bouma

I am now %100 certain that I can build a permissionless, decentralized credential presentation and verification system.

In the example below, the only unencrypted channel is the visual invocation and acquisition of a #nauth presented as a QR code. Once acquired, the rest of the communication, including the request for, and presentation of a credential is done via negotiated encrypted channels.

The end user web apps (the UX front end of #safebox) only communicate to their own user; they do not directly communicate with one another. Actually, each app has no clue, nor cares where the other app is running. All inter-app communication is done in real-time using gift-wrapped encrypted messages.

It's the #nostr protocol that enables this. IMHO, the killer-app for #nostr is rather a killer-capability for every app tha wishes to securely communicate with any other app, so long as they have a #npub, and a pool of available relays.

nostr:nevent1qqsvpyjh26w8muqfe7fdr2smvt5takr4ctuvt8v6dxrwl0a4rnd3engpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygqxk7qe6lcu0a28yyvzvmkhhj58shww4cy7xm4r5jhkvhrdrkpj0spsgqqqqqqsp6s8lz

43
43d140f6... 8mo ago

The auth_relais tag might bring some form of centralization (if all of those relays are shut down or censored, the nauth key gets worthless, if I understand it. Maybe there needs to be some form of auth relay determination automatism (but it might be that this is over my head...)

Reply to this note

Please Login to reply.

Discussion

Avatar
Tim Bouma 8mo ago

I’ve built into the protocol so that either party can propose and negotiate which relays to use. If you don’t like the relays proposed, you don’t continue. Maybe not perfect, but the best way to counter any centralization threat is to give equal power to initiator and responder, and the right to exit at any time.