Correct. The use of the main key as receiver makes it country party trustless. If the receive uses a separate key to receive, he just needs to leak that key to expose the sender.
Is that true? I was hoping the link between the keys remained offline. The secrecy would only break if the attacker got the main key and the backup key.
Click and hold the zap button
Disappearing is for your outgoing messages only. Just don't send the Gift wrap to yourself and you won't be able to recover your messages.
There might be a way to do it, but every time I assemble an alternative to the pubkey, it breaks some of the privacy guarantees or the need to trust the counter party :(
It's clear the receiver got something encrypted. It might not be a message (it could be a private zap) and it might not be from the day.
Amethyst's new DM model will allow users to backup their outgoing DMs to a separate Nostr pubkey. If somebody gets access to the main key, they won't be able to find or even count your outgoing messages.
That will create a new class of micro apps to manage DM backup and recovery.
To recover DMs, the backup client re-signs all past messages to a new key your main client just created. If you have two or three clients, you can use 2-3 DM keys. The backup client can keep forwarding your own backed-up DMs to 2-3 other keys so that all clients can sync and see the same messages.
There are lots of interesting features of this model. The most important one is that when re-signing, the date/time of the original message doesn't need to be shown. The backup client re-signs everything as of today.
The public doesn't know these are DMs and doesn't even know if the public date is relevant or not.
Want to know more? Here: https://github.com/vitorpamplona/nips/blob/sealed-dms/24.md
Another cool feature of this system is that you don't need to trust the counter party or the group you are talking with. They cannot expose your messages without significantly exposing themselves (leaking their main account's private key).
In many other proposals, all an unsatisfied person has to do is to expose the conversation's shared secret and boom, everyone can see and verify your messages. And they can leak that secret anonymously, without any damage to themselves.
why does no one talk about nip 101 and what nostr:npub1tm99pgz2lth724jeld6gzz6zv48zy6xp4n9xu5uqrwvx9km54qaqkkxn72 has done with npub aliases? also i think iris desktop is using. seems promising to me, but no chatter
Because ideas with aliases and other shared key protocols require you to trust the counterparty you are talking with. They can leak all your conversation at any point without leaking their private key. There were many proposals, but they all require some level of trust in the counterparty or in a private relay operator, for instance.
This one does not. You can talk to your worse enemy and they won't be able to expose you unless they expose themselves as well (leak their main account's private keys).
There is no key exchange. The protocol sends an encrypted message from a new random key per message to the pub key of the person.
You can count how many "encrypted things" a user is receiving, but you won't know where they are coming from, if they are real or not, if the date is correct or not.
1. You are going to need to design something as complicated as this on the new protocol if you want to provide the same privacy guarantees at the same comfort level (device syncing, etc)
2. Designing a protocol just for private messages is WORSE than doing private messages inside a system that can transfer anything privately. The anonymity set of the new protocol is just worse.
3. The other protocol doesn't exist. This one does :)
Amethyst's new DM model will allow users to backup their outgoing DMs to a separate Nostr pubkey. If somebody gets access to the main key, they won't be able to find or even count your outgoing messages.
That will create a new class of micro apps to manage DM backup and recovery.
To recover DMs, the backup client re-signs all past messages to a new key your main client just created. If you have two or three clients, you can use 2-3 DM keys. The backup client can keep forwarding your own backed-up DMs to 2-3 other keys so that all clients can sync and see the same messages.
There are lots of interesting features of this model. The most important one is that when re-signing, the date/time of the original message doesn't need to be shown. The backup client re-signs everything as of today.
The public doesn't know these are DMs and doesn't even know if the public date is relevant or not.
Want to know more? Here: https://github.com/vitorpamplona/nips/blob/sealed-dms/24.md
Finished, I just haven't had the time to implement
You can. I am not sure if listr.lol or highlighter have interfaces for this yet, though
nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z if I put more than one @user in a zap reroute what happens? Seems to allow it?
It will just take the first one. We need to finish the zap split process :(
probably some caching issue. Once you click in the list, the issues disappear.
https://listr.lol is severely underrated.
GM.
nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z is it feasible to have optional settings for BH etched to notes?
For what? :)
nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z why is there a button in Amethyst to speak the poster's name aloud? I would get it if you had voice to text for everything, but why just the name?
To help people memorize a name when talking to folks in other languages. Instead of translating a name from Chinese or Arabic, you can just hear how they sound.
The emoji pallet is per account. You can set a different reaction set for each account which also requires you to reconfigure them in each account.