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)
Thread collapsed
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.
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.
Thread collapsed
Thread collapsed
try this out on highlighter.com/my
it already does exactly that
https://pablof7z.com/images/2023-05-31.mov
I think my current browser doesn’t like Highlight. Will change browser and see
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed