The issue I have with this approach is that anyone with the shared link can see the conversation, past and future. People can share the link with coworkers or with the NSA and no one will ever know they are watching.
Iris now supports secret chats that don't leak metadata, implementing the https://hrfbounties.org/ bounty #3. It works also for group messaging.
It's a quick & dirty solution, but works. A shared nostr account is created for the secret chat / group. Its nsec can be shared via link, qr code or invite message from a single-use anonymous account.
Users can then communicate using the shared account's messages-to-self. Iris signs the inner messages with your own key, but the arrangement could be used for anonymous group messaging as well.
I'll also add inner message encryption at some point, so you can ensure that only certain group participants can read the message.
This arrangement doesn't introduce any new event kinds and works also in clients that haven't implemented a special UX for it. You can just log in with the nsec and message yourself.
I had to disable the Iris social graph filter to let invites through, so now Iris DMs are open to spam again, but I'll try to figure out a better solution.
As always, the UX needs a lot of attention, but I believe here's an MVP.
Screenshots:
Alice wants to message Bob:
Alice sends a secret chat invite to Bob:
Bob automatically follows the invite from Alice. They can now message each other in the secret chat:
Here's how the invite looks in another client. I will add an "nostr:ninvite" URI in addition to the nsec.
Discussion
And since users love to paste these links on trusted platforms (Google drive, sms, etc) it's really difficult to see if the group is still secret.
When inner message encryption is added, group secret leak would only expose metadata. On top of that, you can add key rotation which fixes the issue.
Then you are just doing gift wraps, but in a more complicated way. There is no need to have an invite.
Doesn't gift wrap DM reveal the recipient in metadata?
If you are not using aliases, yes. But you can always use another key to receive wraps. The concept separates transmission needs from identity. That's why it is so powerful. Right now I am testing using 5 random keys for each contact in my list. They can send private DMs, private likes, private zaps, and reports in any of those 5 keys randomly.
Yeah, this is not a good solution. I think that bounty is incentivising more bad/partial solutions.
There's no protocol that protects against a malicious participant that shares the keys, that's like trying to protect against someone who can video record the phone while its being used or something.
The link sharing can be improved but I think this part is making reasonable trade offs and could be modified to prevent mistakes users might make without much trouble.
I think its too easy to id what npubs are group chats, and subsequently who the participants are with taps on the relays.
> There's no protocol that protects against a malicious participant that shares the keys.
Correct, but that is not the point. The point is that a secret-based channel can be the target of multiple social attacks that play on people's lack of cryptographic knowledge on top of the usual secret managing mistakes people already do on a regular basis.
In this case, I am willing to bet that people will create a "My Chatgroups" Google Doc with all the active links to their most important chats. And if they need to share information that was discussed in the chat, they will share the link and enable other people to see everything without the other participant's approval.
The design is particularly bad for activists that don't or can't trust their counterparty from exposing them.
> The link sharing can be improved but I think this part is making reasonable trade offs and could be modified to prevent mistakes users might make without much trouble.
There are other solutions that don't need link sharing trade-offs: https://github.com/nostr-protocol/nips/pull/686
> I think its too easy to id what npubs are group chats, and subsequently who the participants are with taps on the relays.
Agree.
I think we more or less agree, but the properties here differ and there's room for more than one solution. For example - What you linked seems good but can't work for large groups at first glance (it also suffers from much more severe comms patterns analysis attacks).
Modifying the invite link to ping a coordinator for the final channel info (I.e. accept the invite) is easy to do and would eliminate the threat you outline. There might be other options like adding a password.
I don't object to the analysis so much as dismissing the entire approach as unsound. I'm advocating for constructive collaboration. (And I've got no dog in this fight, I'd love to work on this but I'm too busy with my other projects right now).
I agree with the multiple approaches. And, yes a large group will need a different protocol. But there are so many possible solutions that it's hard to settle for a secret-based approach. At least, I have not seen a good protocol yet. Especially when the group is indeed large: it just takes 1 person out of 10,000 people to not make it private.
And share a temporary code like you do to create a secret chat with solution like Olvid ?
oh, that's a major setback