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.
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 nostr:nprofile1qyvhwumn8ghj7urjv4kkjatd9ec8y6tdv9kzumn9wshszxmhwden5te0deex2mrp0yhxxttnw3jkcmrpwghxuet59uq35amnwvaz7tmjv4kxz7fwdehhxarjvd5x2cmt9ekk2tcpzdmhxue69uhhqatjwpkx2urpvuhx2ue0qythwumn8ghj7un9d3shjtnwdaehgu3wvfskuep0qqsgafy9ye4j9p2x8vfmlq6equtpcg4m8ks7v545g0d3f7wwueeq5scudj64l 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: https://github.com/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)
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?
Will it be a NIP-60 wallet (tokens over nostr) or a "standard" one where everythingins only on the phone?
I didn't really understand what you said about cashu.me, as far as I remember, NWC is a different thing than cashu tokens on relays (NIP-60 wallet).
And I am not sure #nutstash is a NIP-60 wallet either.
#asknostr #cashu #wallet
Is there a standalone cashu wallet app compatible with NUT-60 and NUT-61? So no wallet feature inside another app (sorry olas and the likes), I mean a proper wallet only app, think of it as cashu.me but you login with nostr and tokens follow you around.
You mean the `next/minor` and `next/major` branches and then build the image yourself?
Is there the possibility to try out the alpha releases? At least for more skilled people that won't ask support if something is not working as expected.
nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 Kind of a strange question as I don't really know how clients usually handle this kind of stuff, but let's say I want to build a relay that needs to process different Kinds requests in different manners, for example in the cashu world there are kinds that only the owner should retrieve and others that possibly anyone could ask for.
Now as I understand with #khatru based relays I don't see any problem when I need to check a new "write" event request, as it will only have one kind, but for "read" actions (I am referring to the `relay.RejectFilter` function) you have the input `filter` variable that contains the list of Kinds requested by the client, so it could be multiple kinds. In this last case, what is the best practice to handle this type of logic? Should I assume to expect only one kind from the client request and then process them "individually"? Should a relay process them in particular ways as I could get a filter with both a "private" (example: 17375) and a "public" (example: 10019) kind in the list?
Maybe the last two kinds are not a really good example as a wallet client will probably never ask them both on the same request, but you get the point. I hope I made my doubt clear.
You gotta diversify: a bit of bitcoins, a bit of sats and a bit of digital gold
Hey nostr:nprofile1qqsd79ejwuvz7v246danxqs3hgw7f2q4qrqz6x27je8er0nhfmykwzqc9djpe what kind of model is Maple using and what are the actual request limits for the starter account?
#lnd #cln
What is the state of the art on running a Bitcoin Lightning Node in an Enterprise/Production level environment? I am talking about the LN logic on replicated/distributed containers (for Kubernetes or multiple machines) and external Database Backends (like PostgreSQL and MySQL).
nostr:npub12rv5lskctqxxs2c8rf2zlzc7xx3qpvzs3w4etgemauy9thegr43sf485vg nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft #cashu Is it possible to create a cashu mint that only accept whitelisted users based on nostr pubkeys?
Today is the day: Obscura VPN is NOW AVAILABLE!
Obscura is the first VPN that:
- CAN'T log your activity by design
- Outsmarts network filters
We believe Obscura sets the standard for a new generation of VPNs, and hope you’ll check it out!
đź”— https://obscura.net/
----
Contrary to popular belief, traditional VPNs (even “no-log” ones) can track you – they see both who you are and what you do, just like your ISP.
Your ISP is no better. Since 2017, they've been able to legally sell your sensitive data.
Obscura is different – we never see your decrypted internet packets in the first place.
It’s simply impossible for us to log your internet activity, even if we were compelled to, or if our servers were compromised.
We achieve this by using a fully-independent exit hop run by @mullvadvpn. Ensuring that our servers never see your traffic, and the exit hop never sees your identity.
In fact, you can check your connected server’s public key against those listed on Mullvad’s server page!
But that’s not all…
You may have had the frustrating experience of trying to use your VPN on a restrictive WiFi: in an airport, a hotel, or certain jurisdictions.
Other VPNs will often fail to connect, as their off-the-shelf protocol is easily detected and blocked.
With Obscura, we built our own custom stealth protocol that is much harder to block.
Our protocol blends in with regular internet traffic using the same technology that powers HTTP/3 – QUIC – making it much harder for censors or network filters to detect or block.
To celebrate our launch, Obscura is just $6/month.
Our team has put in the hours to make this all a seamless experience, and I hope you’ll take Obscura for a spin.
đź”— https://obscura.net/
Thanks for reading, and I’ll see you on the free and open internet. 🏄
P.S. For those looking for an exploration of our technical choices, here's our blog post! https://obscura.net/blog/bootstrapping-trust/
What if the "instances" of obscura and mullvad you are trying to connect to are both hosted on the same datacenter provider? Aren't they able to connect the dots of your traffic? Honest question here, not trying to brag.
Hi Ken, I always found these facts interesting, but it's difficult to make other people understand or make them change their stance on these, do you have any book you recommend that describes/summarizes all these false myths in nutrition and that also explains them in simple terms as to why they are wrong?
#cashu #nostr nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 nostr:npub12rv5lskctqxxs2c8rf2zlzc7xx3qpvzs3w4etgemauy9thegr43sf485vg nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft
My understanding is that a cashu wallet needs direct access to the seed (NUT-13) to be able to work, so there is no way to have a flow similar to NIP-46 of Nostr where the privkey/nsec is never accessed directly from the client, right? Is this something that would need to be added/implemented, or is it technically impossible for some reason?
#cashu #wallet nostr:npub12rv5lskctqxxs2c8rf2zlzc7xx3qpvzs3w4etgemauy9thegr43sf485vg
Are there some docs and/or articles/videos to understand the flow of operations that a cashu wallet needs to do to send and receive cashu tokens? I wanted to try out the Rust cdk library, but it gets confusing quickly when I see terms like "quotes" and "proofs" and I don't really understand what should be done and in what order. So, is there a ELI5 like content somewhere?
I have to say that the https://cashubtc.github.io/nuts/ is of great help, but wanted to know whether something simplier exists
#cashu #wallet nostr:npub12rv5lskctqxxs2c8rf2zlzc7xx3qpvzs3w4etgemauy9thegr43sf485vg
Are there some docs and/or articles/videos to understand the flow of operations that a cashu wallet needs to do to send and receive cashu tokens? I wanted to try out the Rust cdk library, but it gets confusing quickly when I see terms like "quotes" and "proofs" and I don't really understand what should be done and in what order. So, is there a ELI5 like content somewhere?