Only been playing with it for a few hours but I love the security/privacy implications. And how I can route most of the qubes through whonix, and create a qube for apps that don’t want work with tor so route it through normal networking. I also love that I can spin up a qube to just test out some shit and then wipe it when I’m done. My next project is to install start9 onto a qube and play around with it.
I treat all “security questions” as additional passwords and use my password manager to generate the answers. So, I grew up on “JdiJ63$>ge)sne” street.
nostr:npub1f6ugxyxkknket3kkdgu4k0fu74vmshawermkj8d06sz6jts9t4kslazcka thank you for recommending Qubes OS. SO cool!
Depends entirely on two questions: By whom? And for what reason?
The translations in damus are a great resource, maybe we could put them in some format that everyone on nostr could use nostr:npub1yaul8k059377u9lsu67de7y637w4jtgeuwcmh5n7788l6xnlnrgs3tvjmf ?
Are your translations in standard .po files? A good model for this would be how the #Drupal open source project does it.
Check out https://localize.drupal.org
Not a direct comparison because different apps, but you’re right, everybody could benefit.
nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft I bought an nsecBunker (1-hour trial) and the screen seems stuck on “Deploying Bunker…”. It’s been showing that for over 10 minutes. Should it take that long?
Thank you SO much for this explanation!
I want to start up a private relay and I’ve been really concerned about the “best” way to implement E2EE DMs.
Looking forward to reading the next DM NIP that implements this.
Gotcha. But that can already be done with NIP-04. How does NIP-44 improve on that? Just better encryption that does not increase the chance of nsec leakage?
For #1, how do relays “not leak those events to anyone outside of authorized recipients” if the recipient npub is itself encrypted or otherwise obfuscated?
Please correct me if I’m misunderstanding. Key distribution was necessary because in other implementations (except NIP-04), users don’t post the message using their actual npub. Clients had to generate an alternate key pair to encrypt the message, so it looked like the message was posted by some random npub. Therefore it wasn’t compatible with private relays because the relay didn’t have that npub on file.
I’m hoping that this NIP solves that problem so that encrypted DMs can be sent to private relays which use an allow-list of npubs that have permission to post.
If that’s not the case for this NIP, my next question is: how do private relays support it?
NIP44, the new audited encryption procedure by nostr:npub10jcnehsxwrjepupvh602pl83up0dh3wv3fqfwv062smygqvpeuwsk03kag to fully replace NIP-04 has been merged!
The NIP04 is now officially dead.
GM.
The NIP says: “Every nostr user has their own public key, which solves key distribution problems present in other solutions.”
Does this mean that it will work with private relays that have an allow-list of npubs that are permitted to post?
I couldn’t find a websocket data flow diagram for #nostr client/relay communication so I drew one up. Comments/suggestions/constructive-criticism welcome!
nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 
#49ers player 16 is Joe Montana! MVP! #thecasine
Woohoo! #49ers win again! Still top of the conference.
#49ers player number 23 is Christian McCaffrey! 105 106 107 #thecasine
#49ers player number 57 is Dre Greenlaw! 098 #thecasine
I won!! #devilblock #thecasine
Verifying my Nostr Nests identity: S8pjOxavtr49NnA_SK7ALEXd5IaxxJRxwPrPYbg89jU