Nostr Web Client

https://www.youtube.com/watch?v=tldTGhcVWX8

Here’s a video demo of “Incognito Direct Messages” - showing a forked version of Hamstr that can send private NIP-04 DMs where no metadata is leaked to the public (no more inbox peeking).

#[0] #[1] and myself developed this as part of the Nostr Hackathon organised by Hard Yaka, Universal Names and #[2].

The main idea was developed by Anton and #[3] (developer of Hamstr.to). The essential idea is to create new disposable identities for each conversation you create, you exchange these identities with your peer secretly, and then the entire conversation takes place away from your public identity. It’s very simple, it works, there are some weaknesses (you have to trust relays), but it’s a step in the right direction.

Reply to this note

Please Login to reply.

Discussion

Bartholomew Joyce⚡️🇫🇷 2y ago

If you want to dig into the code (beware it’s *hackathon* code):

https://github.com/antonleviathan/hamstr

Anton and I are trying to formalise our work into a standard NIP. Here’s what we’ve got so far. If you want to chime in and help formalise it, please do! Issues and pull requests welcome:

https://github.com/bartjoyce/private-dms-nip

Once the NIP is formalised we’ll also build a standard helper library for web clients:

https://github.com/bartjoyce/nostr-incognito/

We’re very serious about getting this out into clients

anton 2y ago

Thanks for including us in your post :) we have a few things to show now: #[3]

anton 2y ago

#[4]

elsat 2y ago

#[6] #[7] #[8] #[9] what do you think?

Bartholomew Joyce⚡️🇫🇷 2y ago

#[6] if you’re a fan of the idea I’d be more than happy to make a pull request to Damus with an implementation of it. Can be opt-in, like a long press on the send button gives you an option to upgrade your DM to an incognito DM

Sirius 2y ago

Iris doesn't accept DMs from unconnected public keys, so someone in your network would need to follow it first, which makes it a bit less anonymous.

anton 2y ago

Would you be open to changing that if there’s some consensus on using the private dm approach we proposed?

Bartholomew Joyce⚡️🇫🇷 2y ago

Is this filtering happening on the client level? If so could the client accept DMs from unconnected pubkeys provided they contain a signed invite from someone in your network?

Sirius 2y ago

Yes, it could. Shouldn't be too much extra work on the CPU if relays take care of spam prevention.

Bartholomew Joyce⚡️🇫🇷 2y ago

Like Vitor suggested, it could help for the wrapped DMs to use a different kind so the relays are able to treat them differently from regular DMs, and optimise accordingly.

Vitor Pamplona 2y ago

Sounds cool. It's not perfect, but an improvement.

But I wonder if this should be a different event kind from regular DMs.

#[0]

Bartholomew Joyce⚡️🇫🇷 2y ago

Yep, I agree that a new kind would be better for wrapped DMs, allows relays to recognise them

Sirius 2y ago

You could deterministically generate the outer key from your private key and the recipient's public key, so it will be the same every time, even if your devices are not in sync.

Sirius 2y ago

Actually, if you used hash(ECDH + your public key), both of you could calculate the outer key even without the invitation message.

Sirius 2y ago

Or you could just use the ECDH as outer key. Less subscriptions. And if you want plausible deniability ("the other guy sent it") you could skip signing the inner message.

Bartholomew Joyce⚡️🇫🇷 2y ago

Yes, we considered this, but to derive keys from your private key would require direct access to your key which isn’t supported through window.nostr and would require support from signing devices. Not impossible but a little harder.

And further more, if you never send invites it’ll be harder for clients to find open conversations. You’ll have to query a bunch of keys of people you follow to find conversations. So each variant comes with its own set of compromises

Sirius 2y ago

Fair enough. I hope ECDH can be added to window.nostr at some point. You could still send invites, but it would also allow you to operate in stealth mode if you want.

Bartholomew Joyce⚡️🇫🇷 2y ago

Agreed. Would open up a lot of options. Our temporary solution is to generate a new private key that we encrypt and store in a replaceable event, which permits us to derive any keys we want. It helps on the author side, but for recipients we still can’t derive their keys, so still need some sort of invite

Bartholomew Joyce⚡️🇫🇷 2y ago

There’s an existing protocol called XMTP that seems to use the same kind of system of sending an invitation to generate keys secretly. It’s in the alt-coin space and appears to be completely centralised for the moment, but we can certainly borrow some ideas from them https://xmtp.org/docs/dev-concepts/invitation-and-message-encryption

signal_and_rage 2y ago

#[2]