Nostr Web Client

RFC on a new custodial signer I'm building. Highlights:

- Designed to be used with a single app rather than following the user around.

- Has email-based registration/reset workflows.

- Provides a signer/relay combo, reducing nip46 latency.

- Encourages users to "eject", which sends them an email with their ncryptsec, and deletes their account from the database.

The goal is to limit incentives for attackers to steal keys. The keys are only used for a single application, only keys for that application are stored, and the application eagerly deletes keys from the database. Keys are encrypted at rest.

Here's a demo video:

https://coracle-media.us-southeast-1.linodeobjects.com/burrow-demo-20241202.mov

And the source code:

https://github.com/coracle-social/burrow

Reply to this note

Please Login to reply.

Discussion

Derek Ross 1y ago

this login process will onboard the next wave of users. guarantee it.

nostr:note10t864g34kmn7e7l2708xq0k5t9glu7mktkeyxyvf35gxv4cmyfes7gts0r

ben 1y ago

what is a ncryptsec?

kidwarp 1y ago

Encrypted nsec?

calvadev⚡️ 1y ago

Yes.

ben 1y ago

where?

https://github.com/nostr-protocol/nips/blob/master/19.md

kidwarp 1y ago

It’s probably in another nip

ben 1y ago

thanks for wasting my time

kidwarp 1y ago

You’re welcome for being an asshat

daniele 1y ago

A way to encrypt one's nsec (private key) with a personalized password to make storage/use more secure.

ben 1y ago

symmetric encrypted nsec, cool! does that use nip-44? is there a nip? I can’t seem to find it.

hodlbod 1y ago

See NIP 49

ben 1y ago

Charlie Crown 10mo ago

I understand the storage part. But what’s you recommended standard? Should people save their ncryptsec to a password manager? How can I decrypt it without the help of any app?

I’m a bit confused as to how to use this properly. Any help is greatly appreciated.

daniele 1y ago

An interesting approach to gently transition from the current pattern to Nostr.

But it greatly reduces Nostr's “one key, multiple platforms” advantage during the first exploratory sessions, since the user cannot easily test other applications without running the exit procedure. Or worse, start creating multiple accounts to overcome this problem, and he cannot merge them later, of course. I think a lot depends on which application the user starts with.

Note: after ejecting the login procedure should remeber the old emails (hashing them), so:

A) It's able to point the user to the new login procedure that uses the ncryptsec;

B) Refuses a new registration with the same email, avoiding confusion for the user with more accounts;

DanConwayDev 1y ago

Thanks nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn for exploring new paradigms for nostr login and key management. I've been working on the login / signup / export experience for ngit and its really hard because because no simple solutions have emerged with acceptable trade-offs.

DanConwayDev 1y ago

I wouldn't treat an ncryptsec as secure as a lot of people will use weak passwords. Instead of sending it via email why not copy it to the clipboard or show a QR code? Also you could wait until the user has confirmed they successfully logged in elsewhere before deleting the nsec.

DanConwayDev 1y ago

I'm really uncomfortable with custodial key management solutions like this for nostr but I can see why its attractive.

An alternative approach could be to store the key on device and approve a new login from a new device running Flottila by sending the nsec eg via DMs with an ephemeral key. I suppose that's not much different UX than showing a QR code or copying to the clipboard like I suggested.

hodlbod 1y ago

I wouldn't send via DM, but I do want seamless multi-device login for flotilla, which reliance on an existing session makes difficult

hodlbod 1y ago

Burrow requires passwords to be at least 12 characters. Sending via email is a form of 2FA, since you need access to the password, and to the email account. That is at the expense of exposing the key to email servers, which you're right, isn't ideal.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

couldn't it just be a HTTP GET?

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

oh never mind i was thinking the "set" side not the "recover" side or ? i'm not sure i understand

DanConwayDev 1y ago

I do appricate the resonance with login flows the user might be familiar with but character length doesn't always equate to good entropy.

hodlbod 1y ago

That's true. But I think it's a well enough understood problem that it is the user's responsibility at this point. Are there user-friendly ways of ensuring high-entropy passwords though? The "at least one number" policies are both obnoxious and ineffective.

DanConwayDev 1y ago

The average person's understanding of password strength in the context of a system where the password can be changed later to protect the account. I'm not aware of any user friendly ways. Generate a random 4 word combo for the user that they will probably forget?

hodlbod 1y ago

That's a good call, encrypting an nsec is a very different thing. Hmmmm

daniele 1y ago

The main problem is that you ask for a password to create the account, I would avoid that and simply use a login via email using a temporary token with a very long session.

When the nsec must be exported, just create a password with some random words to have a good entropy, ask the user to repeat/write it down, and send the email with the ncryptsec.

hodlbod 1y ago

But I need a password on signup anyway in order to authenticate with the server. Having two passwords seems unnecessarily confusing. Otherwise I like the idea.

daniele 1y ago

Why do you need one password to authenticate with the server? A token sent via email with a 10 minutes expiration is fine. The signup can require only the email and validate the account at the first login (step that usually is necessary anyway).

hodlbod 1y ago

I was thinking to authenticate further sessions, but you're right, you could do the email login every time, that's fairly familiar.

daniele 1y ago

And the average user has just one device, max two, and don't has any tool to aggressively clear cookies (= sessions), so the need to redo the login should be quite rare.

DanConwayDev 1y ago

> "Designed to be used with a single app rather than following the user around."

This undermines main the value proposition of nostr. Perhaps pressing into that vision is counter productive for nostr?

hodlbod 1y ago

Definitely a trade off, but I think it depends: nostr:nostr:nevent1qvzqqqqqqypzp978pfzrv6n9xhq5tvenl9e74pklmskh4xw6vxxyp3j8qkke3cezqy88wumn8ghj7mn0wvhxcmmv9uq3camnwvaz7tmgdajxccn0vshxxmmjv93kcefww3hk7mrn9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcpr9mhxue69uhnyvtfv3jkzuewdehhxarjxyhxxmmd9uq3jamnwvaz7tmzwgh8qatjwpkx2un9d3shjtnrdakj7qpq8hhr9lmvgsf8ttd32hmxph2am7canlmjehy9fn809dahulvjuv0s6puhgl

brugeman 1y ago

Which flow have you settled on for now?

hodlbod 1y ago

Good points. I think you're right that it strongly depends on the application. Only apps that could be considered platforms in their own right (e.g. flotilla, primal) should probably do this, since the exploratory dimension isn't part of that app's value prop (even if they are a bridge to the wider network). Maybe this could be solved by making the original app a bunker? "Log in with flotilla". But this would probably only increase the lock-in to the original bunker, which is the opposite of my goal.

daniele 1y ago

Yes, I also was thinking about this kind of platforms, or super apps, that can offer different tools (social networks, chats, DMs, video, etc).

I agree on the lock-in risk.

brugeman 1y ago

Thanks for exploring this space!

So basically when I "log in" your client will generate local keypair and pass it's pubkey into your bunker and it will accept it if the password is right and hopefully will only give permissions that your client uses - so if local keypair leaks at least hacker won't sign kinds other than ones flotilla uses. Is that sort of correct?

Why not send the ncryptsec immediately after signup to make sure user has the copy even if flotilla goes down?

Do you store keys as ncryptsec and if server is restarted all users have to re-login and key is only decrypted if user supplies the password? This would sound better than storing all nsecs encrypted with a single server-side key, right?

So compared to storing keys locally in the browser the benefit is that a) it works across devices, b) user can't lose the key. Seems like a good alternative to localstorage nsec - in both cases user kind of trusts that app won't mess with my key after I "export" it. Anything I'm missing?

nsec.app has an "import key" flow where you redirect to nsec.app with a nostrconnect string and nsec, nsec.app imports the nsec and connects the app using the nostrconnect string, so app can receive the nip46 connect ack and switch to pure nip46, all smoothly for the user. I have this implemented in nostr-login - user can create local keys and then export to nsec.app and their session is auto-switched to nip46. Would you use something like this if we standardize the flow?

We could also standardize the API of your bunker so that nostr-login could work with your bunker as a replacement for localstorage key flow.

Looks interesting overall!

hodlbod 1y ago

> So basically when I "log in" your client will generate local keypair and pass it's pubkey into your bunker and it will accept it if the password is right and hopefully will only give permissions that your client uses - so if local keypair leaks at least hacker won't sign kinds other than ones flotilla uses. Is that sort of correct?

The key is generated by and stored on the server, it never exists on the client. Other than the login flow, it's a normal NIP 46 nostrconnect flow. Probably a good idea to build permissions into the bunker, right now it signs anything.

> Why not send the ncryptsec immediately after signup to make sure user has the copy even if flotilla goes down?

Just UX friction, I don't want users to have to think about keys at all when they're getting started. Maybe I could do this after a week or something? Not sure.

> Do you store keys as ncryptsec and if server is restarted all users have to re-login and key is only decrypted if user supplies the password? This would sound better than storing all nsecs encrypted with a single server-side key, right?

I considered this, and might still do it. It would definitely improve security. Building a re-authorization flow would also allow me to expire bunker sessions instead of let them live in perpetuity.

> We could also standardize the API of your bunker so that nostr-login could work with your bunker as a replacement for localstorage key flow.

Good idea, do you think we should shove it into nip46 or just let it be a separate thing?

brugeman 1y ago

> The key is generated by and stored on the server, it never exists on the client.

I said 'local keypair' in nip46 terms - the nip46-client keypair that will talk to remote-signer-pubkey. Anyway, you answered my question.

> Good idea, do you think we should shove it into nip46 or just let it be a separate thing?

Separate - the signup/login here seem only tangentially-relevant to nip46, and are HTTP endpoints (I guess?), not rpc-over-relays.

fiatjaf 1y ago

If you are using NIP-46 already why not allow the user to use those credentials in other apps?

hodlbod 1y ago

Introducing friction reduces lock-in. I want to encourage people to take custody of their keys. Not being able to sign in to the rest of nostr (especially when flotilla constantly links out to coracle) might be able to accomplish that.

hodlbod 1y ago

> Introducing friction reduces lock-in

Ironically, because normally it's the opposite. The single-app approach widens the top of the funnel (onboarding to flotilla) while narrowing the middle of the funnel (onboarding to other nostr apps). Depending on the relative sizes of those bottlenecks, this can be a win or a loss.

fiatjaf 1y ago

I would think it's definitely a loss, no question about it.

But since you seem to think the opposite I'll give it more thought.

fiatjaf 1y ago

It looks like you're trying to not store people's keys forever, which I understand.

But even if you're not going to do it I think it could be a nice model to have a generic custodial bunker that could be used anywhere, and then after 1, 2, 3 months it would start sending emails to the person like you mentioned, and after 6 months maybe send them their keys and delete them locally.

brugeman 1y ago

I agree, Flotilla could gradually teach people about remote signing, i.e. using Flotilla's affiliated apps (Coracle) - "Now try to login to Coracle using this bunker-url etc". And then users would probably try to login to other apps. And then after a while you could explain that users should migrate to non-custodial signer so you could reduce risks for the user and yourself.

I wonder though whether we're shooting ourselves in the foot by trying to make the learning curve less steep... Instead of teaching users once "here is how you use Nostr - get a proper signer app and put keys there", we create these longer multi-step long-lasting flows which might create more confusion in the end. Still not clear to me where the balance is.

fiatjaf 1y ago

I think we will never know and there are millions of people out there and each will deal better with a different experience. Anyone who thinks they know what is the "best normie UX" is just delusional. The only thing we can do is try multiple approaches and do our possible best in each one of them.

atyh 1y ago

“Anyone who thinks they know what is the "best normie UX" is just delusional. The only thing we can do is try multiple approaches and do our possible best in each one of them.”

oh my gosh, thank you.

daniele 1y ago

I like this planned exit, but the bunker should work everywhere.