-
@ bf03bdf6:faacdbbd
2025-06-01 20:39:28
I don't see anything to be happy for, not until they release the source code of the app to actually see whether the encryption in end to end and on devicr, which we know will never happen.
-
@ bf03bdf6:faacdbbd
2025-05-17 07:52:02
Curious how grapheneos will tackle these features.
-
@ bf03bdf6:faacdbbd
2025-05-12 06:52:14
Wait, do you mean a multi-hop vpn, or actually multiple vpns/tunnels used at the same time (maybe you can decide which app uses which or based on AllowedIP like in wireguard)?
-
@ bf03bdf6:faacdbbd
2025-05-02 08:39:08
What about totalsportek.pro ?
-
@ bf03bdf6:faacdbbd
2025-04-11 20:19:53
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.
-
@ bf03bdf6:faacdbbd
2025-04-11 19:45:42
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?
-
@ bf03bdf6:faacdbbd
2025-04-06 07:36:10
Will it be a NIP-60 wallet (tokens over nostr) or a "standard" one where everythingins only on the phone?
-
@ bf03bdf6:faacdbbd
2025-04-02 14:42:00
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.
-
@ bf03bdf6:faacdbbd
2025-03-31 19:59:31
#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.
-
@ bf03bdf6:faacdbbd
2025-03-23 15:48:02
You mean the `next/minor` and `next/major` branches and then build the image yourself?
-
@ bf03bdf6:faacdbbd
2025-03-23 10:54:58
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.
-
@ bf03bdf6:faacdbbd
2025-03-20 21:14:48
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.
-
@ bf03bdf6:faacdbbd
2025-03-14 19:50:32
You gotta diversify: a bit of bitcoins, a bit of sats and a bit of digital gold
-
@ bf03bdf6:faacdbbd
2025-03-13 19:31:58
https://haven.ciori.net/8616600ba38489e2d470fbc28005f2827c7fd85b69e71eeaa434f3328309b1d3.jpg
-
@ bf03bdf6:faacdbbd
2025-03-07 18:26:40
Where do you get the "improved with RL" ones? HunngingFace?
-
@ bf03bdf6:faacdbbd
2025-03-03 17:50:41
Hey nostr:nprofile1qqsd79ejwuvz7v246danxqs3hgw7f2q4qrqz6x27je8er0nhfmykwzqc9djpe what kind of model is Maple using and what are the actual request limits for the starter account?
-
@ bf03bdf6:faacdbbd
2025-02-23 13:11:11
#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).
-
@ bf03bdf6:faacdbbd
2025-02-22 11:08:59
How can they be so cheap? Are they reliable?
-
@ bf03bdf6:faacdbbd
2025-02-20 18:46:12
Thanks, will look into it 👀
-
@ bf03bdf6:faacdbbd
2025-02-20 18:17:31
nostr:npub12rv5lskctqxxs2c8rf2zlzc7xx3qpvzs3w4etgemauy9thegr43sf485vg nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft #cashu Is it possible to create a cashu mint that only accept whitelisted users based on nostr pubkeys?
-
@ bf03bdf6:faacdbbd
2025-02-12 19:16:14
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.
-
@ bf03bdf6:faacdbbd
2025-01-13 08:42:23
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?
-
@ bf03bdf6:faacdbbd
2025-01-05 15:12:49
Test upload
https://haven.ciori.net/872bc96594465c882617a229fb6349ef0638ed500c18b840904e67dbabd70ca5.jpg
-
@ bf03bdf6:faacdbbd
2025-01-04 12:30:38
#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?