What’s the end product going to look like? What do you mean by private browser storage data? Why would users need it?
Discussion
Take a look at the beta version over here: https://autobtc.ai nostr:npub1lzmk2evgs4hryjg5hnv3h6cj7fl3qa6nqnxazs9udap3krgr9rpq2w2q9x
Right now, private data, like a rune to connect to a CLN node (along with some other user preferences) is stored in the browser's local storage. But I've got my eye on expanding it to a multi-rune/macaroons data storage system. It'd be killer if users could log in and out from different browsers, and their client could securely pull this data from a dedicated "Nostr-vault". Any thoughts?
So, when I'm talking about a "client", I'm mainly referring to AutoBTC.ai at present. But down the line, we might see other clients cropping up. These potential clients could be designed to request permissions for reading specific values from that secure vault.
If there's no existing solution for this, I might just put forth a NIP to address it.
I need to think about it for a moment. In the meantime, #[4] may have some inputs as he was working on a nostr vault if I remember correctly
didn't read this thread, but are you referring to nsecBunker, nostr:npub1ujsax5qggxkmvu6gwht9c30p0w2df56akngj3hfg3j3cr7daejgq2nnzxc ?
I recorded this poor-man-demo video this morning:
https://pablof7z.com/images/nsec.mov
after publishing this note:
nostr:note1hvys0eq2c9jwrz6sqwvqznmzwaa2hnsf4lg4rfq49ftxzrtwgnesxzqur0
That's really neat! I just want to clarify a few things - it seems like the nsecBunkerClient has to stay online and listens out for "note signature requests", right? And then, it approves these requests based on a certain set of rules? Where are these rules stored? Do you have plans to evolve it for more complex rule sets? (for example, "a specific npub is authorized to post on my behalf for the next hour only and a max of 5 notes")
However, I think what I'm searching for is slightly different. I'm envisioning something like a private vault (think Amazon's style, but implemented on nostr relays). My application would then ask the extension for read/write permissions for a specific key in this encrypted vault. After a user logs in with nostr, the app could ask for access to some of the user's private data, pending the user's approval.
Down the line, this could be integrated with nsecBunkerClient. In this scenario, you could allow another npub access to your private vault. The client would manage the decryption and encryption for that user, following a set of specified rules.
no, the nsecBunker Admin UI you see in this video (where I click "always allow") is just for administrating the nsecBunker.
nsecbunkerd runs in the same model as a lightning node does; 24/7 available, running as a background daemon and guarding access to your keys.
you can establish any complex HSM-type policy (allow this npub to do X and Y under condition Z, where condition Z can be time based or anything else)
that vault you describe sounds very much like the kind of stuff nsecBunker supports
Fascinating! is the code publicly available?
My concern is it's aimed more towards power-users with dedicated hardware running the nsecbunker daemon.
I've been envisioning something simpler to kick things off: a "Vault data" event kind ({vault_key -> encrypted_data}), which can be stored on public relays. Apps could then pull all npub's vault keys and request continuous read/write permissions for specific keys through an extension.
This approach eliminates the reliance on the browser's local storage as the "long-term" memory for personal data, as everything can be restored from the vault.
It's a basic idea in need of more thought
But then the relays need to implement the signing? That’d basically make the relay act as an nsecBunker (which I’ve contemplated and might end up doing, creating a very special kind of relay which I really dig)
From my viewpoint, the relay doesn't need to implement signing or undergo any changes. To put it into perspective with my current situation, user's browser is storing private node data, say, a CLN rune. Whenever a user switches a browser or clears the local storage, they're required to re-enter the data.
The workaround I've considered involves my app generating a "vault-store" event. The user's extension would then encrypt it, sign it, and broadcast it to the relays.
Following this, when the user logs back in via nostr, my app could request the extension to decrypt the value and re-store it in the browser's local storage.
What do you think?
Additionally, this approach simplifies sharing user's private data across various apps, while maintaining ongoing user consent.
So more like a self DM?
Definitely, that was my first idea. But I'm pondering if there's a method that fits this scenario better. Instead of providing an app access to all decrypted dms, how about granting access only to particular necessary (unencrypted) keys? It'd also be a more precise and secure way to share private data across apps.
just do a passphrase on the key; I'll do that on Highlighter too at some point
nostr:npub1ek88duljevwf8mqquvjtarjlwjpzn8zjllymgtvdd4eyjqne0r0qxetvsn
try this out on highlighter.com/my
it already does exactly that
wow nsecBunker is coming along very well!