Replies (43)
Oooow :eyes:
Great work bro
Could I provably run code in something like that generates an nsec that I never see?
Yes, generate_test_key is an example of exactly that.
Noted ✍️
Has potential that option!!
To onboard small-ish content creators.
1) create nsec that I don't see
2) publish their stuff + a #communikey around it
3) show them the interactions + zaps
4) hand over*
*eeds a part in the code that you run inside the enclave that lets the onboarded creator export the nsec and proveably tell him this is the first time this happens
Wait, do they need to?
If they can export the nsec, see it its the first that happens, then we don't need a third party, no?
If it's not the first time, well they should ask questions, lol.
So you create an nsec for Taylor Swift and start reposting her insta pics on nostr, those get zapped, eventually you tell her about those sats and invite to take over the nsec. Is that the set up? Wouldn't you want to prove to enclave, somehow, that it's her? Otherwise someone could front-run her?
Also Taylor Swift can sue you out existence for that, lol. Any creator can.
Wait wait wait, I'd have credentials for accessing the enclave, right?
The point is to pass on those credentials and not the nsec.
Also, if the service provider tries to rug us than we can still see that someone already exported the nsec.
I said small-ish creators.
Not mind-controlled slaves acting on the world stage.
Ah got it, you pass the bunker url to creator, and they try to export and that only succeeds once. Sounds good!
Yup :Check:
If I made a noob error in that logic, tell me por favor :prayinghands:
If not, I can use this!
For example, I have no idea if the service can just swap out the whole enclave for another or something.
But even if that's possible, they gain nothing except a bad rep.
Sounds fine, will see what I can do. One issue at this point is that if enclave is restarted, all the state is gone, so storage of long term assets is a challenge, especially while it's not yet production ready. But we will solve that, so eventually your idea is gonna work.
If the code is well written, enclave operator can only turn it off, not mess with it in any other way.
Ow damn, yeah didn't think of that, of course.
Yeah, no stress. Def don't need this tomorrow :winkwithtongue:
That's a non-starter for any creator of any size. You'd need an explicit contract with them first allowing you to use their image in this way. If not even a tiny creator could sue you for a lot and win.
I much skeptical about enclaves
Super solution.
Nice work 👏
Why?
Interesting.
Dont think can exist a provable inaccesible remote secret, and past iteration like intel SGX has been praised as a solution until they repeatedly demostrated to be broken.
A secret that is containerized in isolated processes on someone else machine is no more a secret, even if that "solution" brings an enanchement over non-isolated cloud data secrecy, its still a non-solution.
Nothing to prove here, if you trust AWS virtualization infrastructure, then use it, otherwise ignore. There is always some root of trust.
Maybe I am missing something, but with a tool like Amber on a device that only I control, I am sure only I can use those keys, accept requests and sign, but with this enclave thing, which is "online" and you "connect" to it using a frontend (I guess), how does this work? Is the frontend part of nsec.app running client/browser side? How can I be sure only "my device" (as long as I don't delete website data/cookies of nsec.app ?) can access those keys? How does this differ from Amber?
Amber works great for apps on the same device. Cross device it has same issues as nsec.app - Amber is killed by mobile OS and can't process requests reliably.
This enclaved signer can accept your nsec and process requests to it. You still retain your nsec and can control the signer with it, that's what nsec.app does. Your local key just can't be always-online.
Does it make sense?
Mmhh I get what you say about the drawbacks of an in device signer like Amber (even though I think it depends on the usage one has with a nostr client), but I don't really understand the "you still retain your nsec and can control the signer with it", but probably it's just because I didn't fully understand the overall logic flow.
Really interesting option for custodial providers:
brugeman
Store your nsec in a secure enclave!
We've spent a big part of 2024 trying to make a reliable non-custodial signer with nsec.app. It hasn't worked out perfectly - remote access to keys stored on a mobile device is still unreliable, especially on iOS.
That's why we got very interested in AWS Nitro Enclaves - h/t
@Marks and MapleAI team for inspiration!
The idea is to have an open-source custodial signer and deploy it in an isolated environment that provides attestation for the deployed code. Anyone would be able to reproduce the code build and verify that the signer is running the correct code in a safe environment.
So here it is:
GitHub
GitHub - nostrband/noauth-enclaved: A safe Nostr nip46 signer to be deployed on AWS Nitro Enclave
A safe Nostr nip46 signer to be deployed on AWS Nitro Enclave - nostrband/noauth-enclaved
Each instance of a signer deployed in an enclave announces itself on Nostr. We added some Nostr to attestation provided by AWS - the report is linked to pubkeys of a person building the code image, and a person running it. This way you can choose a signer based on your own preferences.
It's already integrated into nsec.app, go to Settings => Secure enclave and try to upload your keys to the server. The signer API is described in README.
DO NOT deploy your real keys just yet - it's running in a production environment, but the code hasn't been well audited yet. First we need some community members to review the code and reproduce the code image.
The signer can also be used to generate throwaway keys for automated testing of nip46 implementations, check out "generate_test_key" method.
Looking forward to your feedback!
(Signed by my nsec from the enclave)
It sounds like you solved delegation on Noster. Which means brands and content, creation teams get more easily, join the movement. First delegation solution I’ve heard of and I’ve asked at several Nostr meetups! Congrats
Thanks for the link, good read!
The creators that care about their IP are :110percent: the wrong ones to onboard.
The things we can do when we can trust computers...
What if the signing device was a smartphone app, which communicated with the browser over local WiFi, like WhatsApp Web used to work?
That's what Amber should be able to do, web apps can talk to it - though not sure how good it works in practice.
Also mobile apps are turned off by OS at will, especially on iOS, we haven't been able to make that work reliably, so giving up on that path.
I'm ok with keeping it in the front while I'm working on my computer.
All Nostriches should ban iOS until they accept apps that by default allow zapping notes.
Is Amber on Google Play?
idk about Amber,
@greenart7c3Amber should work fine if kept alive on mobile while using the desktop.
Its not on Google play, its on zapstore and F-Droid.
I tried for some months creating a Dev account for Google but the SMS verification worked only after 3 months, when it worked they changed my LLC name and rejected me from the KYC step so I gave up trying
I always upload the aabs to the github repo so if anyone else has a Dev account they can upload it to the play store
Can you post an update on the status of this?
