Nostr-login in the wild!
nostr:nevent1qqswvexw6dp0f7tqqe63wvpj2qswnq9lhy8zrjhpm7r57gme4rhf9vqpp4mhxue69uhkummn9ekx7mqzyzvmk4v3eygkvq8cg5g86v0ekk0z7lr7pxsllqpwsncag0d92l9xgqcyqqqqqqg4jp6c6
Check this out
nostr:nevent1qqsyfmy0hqpzgghm2yf4vqwgzj6lu8pkm4zuk2pshqfd2rg7hy27zggpr4mhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet5qgsrx4k7vxeev3unrn5ty9qt9w4cxlsgzrqw752mh6fduqjgqs9chhgrqsqqqqqp4l4w45
There are already nostr-login, nostr-ignition and some other lib cooked by fiatjaf to simplify adoption for apps, should be pretty straightforward from now on.
To import keys click add account then advanced then import. Do the same on another device.
You can setup cloud sync for your key in settings - set a password and your key is encrypted with password and stored on our server, then on another device you can login with that password and your key is fetched from server and decrypted.
Nsec.app doesn't use nsecbunker (server-side nip46 server). It stores your keys in browser and runs nip46 server in a service worker, it's server only wakes the worker up when needed.
You could host your own version of nsec.app. But doing that just to sync your keys through your own server isn't worth it - sync is e2e encrypted with your password, you don't gain much from self hosting.
If your app already works with key storage extensions (nip-07, window.nostr) then you can use nostr-login library - two lines of code and all your calls to window.nostr are proxied to nip46 remote signing, with a pretty UI showing up for users to login/signup.
Can you please elaborate? Why do you need a new relay to try nostr-login and how could you leak your keys? The whole point of nostr-login is to not have access to your keys, but to have restricted remote access to them.
Yeah so OAuth-like sign-up process works like this:
- client checks bunker.com/.well-known/nostr.json?name=_ to find the bunker relay and bunker pubkey (one from BUNKER_NSEC)
- client sends nip46 create_account request to the bunker (not the user - no user yet)
- bunker replies with auth_url and a popup shows up with bunker website where account is created
- create_account returns the new user's pubkey and can then do normal nip46 calls to that user
More info here: https://github.com/kind-0/nsecbunkerd/blob/master/OAUTH-LIKE-FLOW.md
So you don't set BUNKER_NSEC to "your own keys", you generate new ones - these are just keys used to talk to the bunker server when users request account creation.
So nostr tools has the nip46 now? Nice!
Have you taken a look at nsec.app ?
Sorry for inadvertently competing with you, I started nostr-login a while ago before learning about nostr-ignition
There is an announcement, it runs nip46 server in browser service worker, and uses a custom server to wake the sw up when needed. No extensions, works on mobile.
nostr:nevent1qqsyfmy0hqpzgghm2yf4vqwgzj6lu8pkm4zuk2pshqfd2rg7hy27zggpr4mhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet5qgsrx4k7vxeev3unrn5ty9qt9w4cxlsgzrqw752mh6fduqjgqs9chhgrqsqqqqqp4l4w45
Thanks for trying it!
Nsec.app does talk to a backend - to subscribe and get woken-up when there are pending nip46 calls on a relay. But nsec doesn't leave the device unless "Cloud sync" is enabled. I think I will make the "enter password - get your keys synched" the default flow, advanced users could disable it.
The OAuth flow isn't working well from a new device/browser, that hasn't been handled yet. For now you'd have to log in (through cloud sync) or import key into that other browser manually before connecting to new apps there.
It is confusing, because the app looks like a normal web app that's supposed to work across devices and show the same data, but underneath it's not (yet) like that, because it's non-custodial. But that's all fixable and on the roadmap.
Yeah, user journey is hard, especially given that existing nostr users have very different demands compared to noobs that could join through Oauth and have no preconception of how it could/should work.
I am not talking about a built in relay in lume, lume.nu advertises itself as nsecbunker.
But it principle, if relay is accessible to both client and bunker then nip46 would work.
Oauth flow is focused around nip05 names, those require a domain name, that's trickier
Users see nsec.app in a popup, after it's all done (login/signup) the popup closes and user is back at your client app. At least that's how it should work unless there are bugs.
Would you be interested in using nostr-login library in your apps? People with extensions would continue to use them, others would be able to use this new OAuth-like flow.
With noauth repo you'd do npm install; npm run build; and have the app in build folder. But you'd need to tweat .env variables before building:
REACT_APP_WEB_PUSH_PUBKEY= web push public key, npm install web-push then web-push generate-vapid-keys --json (more at https://github.com/web-push-libs/web-push)
REACT_APP_NOAUTHD_URL= address of the noauthd server
REACT_APP_DOMAIN= domain name of your bunker (i.e. nsec.app)
REACT_APP_RELAY= relay that you'll use, can use wss://relay.nsec.app - don't use public general-purpose relays, you'll hit rate limits very fast
There is also a noauthd repo with server-side, tweak .env:
PUSH_PUBKEY= web push public key, same as above
PUSH_SECRET= web push private key that you generated above
ORIGIN= address of the server itself, like http://localhost:8000
DATABASE_URL="file:./prod.db"
BUNKER_NSEC= nsec of the bunker (needed for create_account methods)
BUNKER_RELAY="wss://relay.nsec.app" - same as above
BUNKER_DOMAIN="nsec.app" - same as above
BUNKER_ORIGIN= where noauth is hosted
Then run npx prisma migrate deploy to init db, and then run
node -r dotenv/config src/index.js dotenv_config_path=.env
The nsec is stored in an encrypted form with keys generated at the browser, it's a light protection from someone just peeking at the localstore. But if they're smart enough to debug js then they would find the decrypted nsec somewhere inside js variables (same w/ extensions btw).
It is possible to add some pin/password to confirm on every use, although it would mean you can't set 'Don't ask again' checkbox - you'd literally have to confirm (almost) every use of the key. Do you think we need such advanced mode?
Well with formstr you could encrypt forms w/ user's nsec store locally? It pushes the problem to nsec storage, at least it's one problem to solve, not scattered across apps.
Introducing nsec.app and nostr-login!
I've shown the prototype of https://nsec.app in December, and it's essentially an nsecbunker in your browser. It is non-custodial - your keys are stored locally in the browser, and apps can get access to your keys using NIP46. We've now turned that prototype into a real thing, and I invite you to try it. Shoutout to @nielliesmons for the designs!
Now how do we help Nostr apps adopt NIP46 for remote key access?
That's where nostr-login library comes in. If your app uses NIP07 to talk to a browser extension, then with just two lines of code you can make it talk over NIP46.
Both of these tools support the new OAuth-like flow proposed by Pablo. Below you can watch a demo of how nostr-login (added to my fork of Snort) works with Nsec.app (or would work with any other nsecbunker).
What this all means is that people could join Nostr on the web, without installing extensions or mobile apps, with their keys stored non-custodially in the Nsec.app, and then could log in to other Nostr apps without copying their private keys.
Demo: https://void.cat/d/JSWwYMTtbWxTDTLpe132Kr.mp4
Links:
Snort+nostr-login: https://snort.nostrapps.org
nsec app: https://github.com/nostrband/noauth
nsec app server: https://github.com/nostrband/noauthd
nostr-login: https://github.com/nostrband/nostr-login
We are looking into using WebAuthn. I haven't fully grasped what's possible there yet, but some integration with your existing devices (like auth with your biometrics on the phone) is definitely coming.
I commented under that PR, I believe it's now broken on next.nostrudel.ninja.
Also, I'm trying to use Nostr-address login on Nostrudel, I enter artur@nsec.app - connect button is disabled, what am I doing wrong?
This project has nothing to do with opensats.
Re your other points I agree that we should provide much more customization. Which design elements you would like to exclude? Header?
We could provide just functions that accept username and handle the rest, then you could implement your own forms as you wish. These isn't much login in them aside from checking nip05
To implement nip46 sign in simplest thing is nostr-login or nostr-ignition. Couple lines of code and your app can be signed into.
If you want to give new users your own nip05 you don't have to run the full nsec.app service - I can fire onAuth event on sign up and you can run users through your own onboarding and give them your own nip05.
If you do want to host your own version of nsec.app I will have some instructions in readme soon.
Nostr ignition seems to be functionally the same, both are a way to access keys using nip46. It's more customizable atm from what I read in their docs, although I am not sure how ready it is.
Thanks for your feedback I will get back to you when we have more customization options and onAuth event fired for you to run your own onboarding.
Oddbean new post about login | logout
Notes by brugeman | export