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

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!

Reply to this note

Please Login to reply.

Discussion

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.