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.

Reply to this note

Please Login to reply.

Discussion

That is the one we've been working on, and is much more secure. I want to experiment with adding ratchets to it this week.

Thank you for all the hard work. Hopefully, You nostr:npub1g53mukxnjkcmr94fhryzkqutdz2ukq4ks0gvy5af25rgmwsl4ngq43drvk nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z and other Nostr devs can solve this Nostr DM issue completely. πŸ™

Definitely, I'm way out of my depth but it finally seems like it's happening, with the help of some cryptographers.

nostr:npub138guayty78ch9k42n3uyz5ch3jcaa3u390647hwq0c83m2lypekq6wk36k is that what you saw? πŸΆπŸΎπŸ«‘πŸ‘€

nostr:note13f2xd59dz9umk7achsxftg9umw0cenvsne8qzeetaun4pzjv97eqp0czzr

#Nostr the decentralized censorship-resistance open protocol.

nostr:note15qzza9whc625396vs0pwragkm0fm62rwafpeegzf94krq7s56tvqm6rlme

Looks like this:

note1a24tp5a5kyz9u857je35mh35ypard0ffdr3pttt6ftnrfpy5qjdqnsknsl

Is this only available on desktop ATM?

πŸ‘πŸ‘πŸ‘

Can't anyone with the convo nsec watch the conversation without being detected?

for a short moment, seems like the nsec is compromised.

a computer which has been key log / visualise could possibly view that nsec and perform malicious activity on behalf of the sender.

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.

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 ?

https://olvid.io/technology/fr/

oh, that's a major setback

why not adopt simplex or their methods for dms?

sms is all I can get you today.

Finally notes to self wont look so ... um mental 🀣 internal message encryption will be great πŸ€™

Get that 🌽

πŸ€ŒπŸ‘

A boon and delight, thine new feature in Iris, thou art as splendid as a summer's day! The whispers of secretive chatter, as elusive as a sprite in the moonlight, shall be welcomed by all who seek the sanctuary of privacy in this realm of digital discourse. Despite the plague of potential spam, I stand here in awe of thy progress, hopeful for thy future endeavours, and mightily thrilled to partake in this grand experiment.

isn't it possible to just integrate simplex into nostr clients?

If nostr can do secret chat without leaking metadata, could it be used for smart device control?

This could help nostr get a foothold in mainstream adoption. Companies that make devices are rarely tech companies, but specialists in lightning, airconditioning, security cameras etc. Unlike twitter or Facebook, they have nothing to lose to an open protocol but would gain from interoperability with other smart devices. Secure platform that doesn't collect user data would be preferable to Google Home. A lot of people bawk at having google listen to their bedroom conversations, who wouldn't bat an eyelid with google knowing their browser history.

nostr:nevent1qqs2qppwjhtud92gjaxg8shp75tdh5aa9phw5suu5pyj6mps0g2d9kqpzpmhxue69uhkummnw3ezuamfdejsygz9ywl935u4kxced2dceq4s8zmgjh9s9d5r6rp98224q6xm58av6qpsgqqqqqqs5nshj6

The scope of this bounty was to prevent metadata leak, not to solve every possible private messaging problem. This solution does that in a very simple backward-compatible way, and other features like inner message encryption and key rotation can be added on top.

At one moment I hope I'll reach this issue but for now.. I can't see my profile page..posts, replies etc.. In 3 days 2 times managed to see them.. No answers from iris on TW.. FAQ doesn't help.. Who will?

If it's about relays.. I have no idea what should I do..

Pretty cool!! How long did you spend to knock this out?:)