Oddbean new post about | logout
 Thanks for asking. 
I wouldn’t worry. What’s the harm?

Profile keys have no value upon first creation. Their value grows only over time, as a user creates content with them. 

State briefly and unambiguously the importance of key privacy. “Do not share with friends. Do not copy and paste into browsers. Lost is lost.” And then let people loose their keys. 

Give great experiences, and they will come back.  
 Good point. Although I think that works best for clients where people can directly get active. Nosta is about setting up your basic profile and then using other clients to fill that profile up further. So the user needs to have the key to sign in elsewhere. 

TBH, I have not quite figured out how to make that really smooth. Installing a browser extension during profile setup seems like a good step forward. It's in a way more complex to set up, but at least the private keys follow along to other clients and users just need to confirm pop-ups. Maybe Nosta needs a minimal browser extension companion for key handling? 
 Is nosta open source? I would like to make a fork that implements email/password instead of keys 
 Yep, here you go: https://github.com/gbks/nosta-me

How come you prefer email & pass for this? 
 Bunker on the backend?

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

Marry this with NIP-41 for when the user is ready to off board and we’ve achieved a very interesting compromise 
 Sign me up!! Wd love to help with user flow and front end to make a winning onboarding experience!! 
 because it's a flow people are much more familiar with than keys and we can use NIP-46 to delay the introduction of keys 
 Sounds more complicated, TBH. So a user signs up with email & pass and can use Nosta to set up their profile. Then they want to use Snort, how do they log in?

I am not sure it is easier to explain this stuff further down the road to users. My guess is they will just stick with email & pass if it's convenient. 
 They authorize Snort just like they use most OAuth flows (“do you allow this app to connect to your nostr account?”) 
 And that would happen by email? I guess I have to see it. Looking forward to what magic you'll come up with. 
 No, on an nosta.me popup just like when you use an oauth flow 😅 
 I proposed this to @hodlbod a few days ago (via DM). Wasn’t sure if I was way out the window, being a nostr noob myself. But this may be the future for nostr, and (I think) we are both keen on seeing (something similar to) this built out in coracle (and other clients).
—-

I slept on this (as I do) and assembled some pieces in my dream. 

Right now bunker has two parts : “bunker-host” and “bunker-admin”, where the former is what stores encrypted keys and the latter is the admin UI for putting keys into storage and managing their shared npubs. 

Last night I dreamed of a slightly different architecture, one that plays better with relays and clients. 

Seeing as (right now) any bunker-admin instance can manage any bunker-host, it seems to fit that clients could have a bunker-admin embedded into them. But as it stands, bunker-admin (for multiple key storage) is tied to an npub, for which a user must ALREADY have the nsec (plugged into a browser extension). This is NOT the bunker-admin that would be embedded into a client.

Anybody (including an already “trusted” relay operator) can spin up an instance of bunker-host, and use any bunker-admin to manage the keys stored there. (If I understand this right) these keys are E2E encrypted (by password) as soon as the user submits one from the browser. This means that the bunker-host has no access to the actual key data. It’s “warm” storage. So we improve this flow for integration by relay operators, and BAM new users get a “nostr name”, online notes storage, and a “warm” place to hide their private key at the “home relay” of their choosing. (As long as they have their private key in “cold storage”, they are free to “move” their home to another relay.) 

But the clients have a major role to facilitate this. The clients’ role (beyond helping users to “discover” home relays) is to provide a consistent (across clients) UX for the creation of nostr names and keys. This would be a “lighter” instance of bunker-admin for end users only (let’s call this bunker-my-admin) that would ALSO plug into the bunker-host (at a chosen domain). 

The bunker-my-admin provides for choosing a username and a password, and INFORMING the end user of their keys and how they are stored. It also facilitates end users to log into any client with said username@Nostr Gang.domain and password (and to look up the FIRST suggested relay in their well-known/nostr.json if @Nostr Gang.domain is not a bunker-host)

This (mostly) uses nsecbunker “out of the box”. The only thing further to develop (aside from bunker bug fixes and existing feature requests) would be an API for a bunker-my-admin to connect to a bunker-host (via U+P or as new user) at a given domain and a client implementation of a bunker-my-admin UI. 

Am I off my rocker?
Thanks for reading. 
 
 TBH, I have a hard time visualizing this. I also have a hard time figuring nsecBunker in the first place, so that's not surprising. A little over my head...