Nostr Web Client

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 nostr:npub149p5act9a5qm9p47elp8w8h3wpwn2d7s2xecw2ygnrxqp4wgsklq9g722q 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

ManiMe 1y ago

nostr:npub1xdtducdnjerex88gkg2qk2atsdlqsyxqaag4h05jmcpyspqt30wscmntxy nostr:npub149p5act9a5qm9p47elp8w8h3wpwn2d7s2xecw2ygnrxqp4wgsklq9g722q

Thanks to you both for making this nostr-login proof of concept. Local nsec bunker storage is gonna be a game changer.

Trying to integrate your module into my onboarding client. I have a few issues you may consider:

- I’m not a fan of outright obliterating NIP07 login buttons. Especially while we’re all still testing and getting bunker infra set up… some people will still want to sign in via extension. So I won’t call ‘init’, but instead instantiate one of the included components.

- not really a fan of “branding” the login form (as separate from the hosting app). Y’all do deserve credit but this is just too noisy (a theme switcher on the modal …?) and smells like phishing.

- would like to see a “form only” component that I could use right on the signup page, without all that modal stuff.

- my only option then is to instantiate the modal component and try to restyle it. But it cannot be styled. Using svelte, I haven’t found a way to inject CSS overrides to make it “less modaly” …

- I feel like I’m being given a black box of canned functionality and “that’s all you get” … from an opensats funded project.

Reply to this note

Please Login to reply.

Discussion

PABLOF7z 1y ago

Which opensats funded project are you referring to?

brugeman 1y ago

Init will not override nip07 extension, so if someone has it they will keep using it as usual.

brugeman 1y ago

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?

brugeman 1y ago

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

ManiMe 1y ago

Thanks.

I’m still a bit foggy on the how various nip46 implementations work. (I imaging a lot of nostr users and nostr devs still are…tbh… given the recent “awareness” that original nsecbunker has access to read nsecs) Given this, I’m trying to wrap my head around the code your developed with `noauth`, `noauthd`, and `nostr-login`…

In the end, what’s important to me as a client dev is:

- what are minimum tools I need to implement “local storage” nip46 signin and signup form for my users?

- how do i host a “local storage” nsec bunker at my client domain? (if my new signups are gonna get a nip05 name out of it… I’d rather it be from my onboarding client domain… with integrated key management tools right there … cause first client “should be able to be” the only client a new user needs.)

brugeman 1y ago

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.

ManiMe 1y ago

These are awesome tools!

My only concern with running either (nostr-login or nostr-ignition) is the lack of customizability. Thanks for offering. Because nostr-login supports “local naec storage”, I’ll use this.

Yes please. I’d like to:

- add a “form only” component for nip46 signup (or signin) without the modal, modal header, or modal footer content.

- run users through my own onboarding, and give them my own nip05 without needing to host nsec.app myself. (Without breaking “oauth” style nip05 signin flow for my new users in other clients?)

ManiMe 1y ago

P.S. I will prolly want to host nsec.app at my own domain in the future… or provide some affordance for new users to manage their keys from within the onboarding experience.

brugeman 1y ago

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.