Oddbean

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?

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.

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.