Yeah, this is not a good solution. I think that bounty is incentivising more bad/partial solutions.
Discussion
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 ?