Oddbean new post about | logout
 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...