.

We're launching an platform for unique digital assets, it's not a fancy dapp or nothin, just uses Next.js and a MongoDB. I think our users are fine with this, but a number of users have requested not to use email auth. The thing is, we'd still like to communicate with them, and we were hoping Nostr could be a viable alternative as both a sort of email address alternative, and also as a way to generate passwords specific to each site using your Nostr key. We intend to build this into the BitMask extension, along with NIP-07 authentication, though ideally other browser extension adopt this also, and maybe even mobile clients with Nostr-enabled webviews.

.

The server will have a private key which will serve as its means to authenticate, and also to communicate with users via encrypted DMs.

A shared secret could be generated using ECDH derived from the website's NIP-05 public key and a private key available only to the user.

The 32-byte hex-encoded public key could then be provided as the username, and the shared secret would be used as the password within the Basic Authorization header.

When the server sees this on the request header, it computes an ECDH shared secret using the user's provided public key as the username, which should match the shared secret provided as the password. This then does not need to be persisted within a database, which helps against hacks, is entirely serverless, and also obviates the entire business model used by Silicon Valley tech startups like Auth0 and Okta.

A convention would be that "admin" would be the username used by websites, though perhaps this could be specified through some other way, either via meta tags, or a dictionary of popular administrative usernames could be utilized, though that might result in unexpected behavior in some cases, such as a user registering as "admin" or "webmaster" and if they wind up in the NIP-05 JSON somehow, that could result in mistaken identity. But this is a relatively contrived scenario. Perhaps instead, a character like "@" could be used to indicate the webmaster username, and so first the key "@" is looked up, and let's say the value is "admin", and then the key for the NIP-05 username "admin" is used as the canonical site key.

This same information could also be used to end-to-end encrypt data at-rest in a way that is relatively opaque to cloud hosts, especially if using something like object storage from a different cloud provider.

In case the private key on this centralized server is ever compromised, its NIP-05 identifier could be updated once it's secured again, and users will authenticate for their old data using new passwords generated from the new NIP-05. This will then update all communications. Perhaps in Nostr email clients, they could request the NIP-05 id to validate the sender.

Also, I'm unsure if ECDH can be done using the x-only public keys used by Nostr as defined in NIP-01. If this is the case, when the server goes to validate a shared secret password, both a lower and upper s value will need to be generated, and shared secrets created from both. If one matches, the password is considered valid.

Browser extensions that support NIP-07 could also support this NIP to authenticate with sites that have a NIP-05 identifier available.

Additionally, to reduce the number of calls, perhaps a meta tag could be embedded within the HTML page, such as this: <meta name="nostr-nip-05" content="admin:deadbeefdeadbeefdeadbeefdeadbeef">

Continue reading at github