Secure DM

[arthurfranca]

Read here

[staab]

This seems fine, but again, similar to NIP 101. I'd also like to see zaps as an alternative to PoW. That wouldn't help relays since they can't verify zaps, but recipients could fetch zaps, validate them, then fetch the envelopes that the zaps tagged. This is preferable to PoW for me because the work expended is durable rather than disposable. It also allows for senders to bid or receivers to set different thresholds for message requests.

[arthurfranca]

@staab Can't open issue there at the NIP-101 repo nor there is a PR to comment on.

@water783 if you ever read this, I think NIP-101 is more complex because:

• It uses 5 event kinds per session. I think "reject" and "close" are things one doesn't want to reveal. "Update" isn't needed when one can just start a new session (in our case where we don't need the other party's alias). Here we use just 2 event kinds (kind:1044 and 1045 rumors).
• If I got it correctly, both users need to get online once before anyone can start sending DMs (because the sender doesn't know the receiver's alias pubkey to add it to the DM gift-wrap's p tag?). Here our DM gift wrap uses no p tag at all.
• It has custom expiration (and update interval). Here we simply use a convention fixed on a three weeks expiration window.
• It needs to set a relay. Here we just use NIP-65.

[arthurfranca]

@staab zaps aren't an alternative to PoW cause of the relay part you mentioned. Zaps could be used in addition to PoW though.

I admit that atm I'm a bit lazy to open NIP-57 and figure out how to stuff it in here xD

[arthurfranca]

Furthermore, you could get forward secrecy if you did in fact generate keys and exchange them. Why not strive for forward secrecy? https://github.com/nostr-protocol/nips/pull/945#issuecomment-1881932884

@mikedilger could you review these lines? New sessions would not be able to decrypt previous DMs after discarding previous session's privkey (it's chars are used as salt for decrypting the old DMs).

[mattn]

Just a question, if the session-key for A & B to another one, and if it also add C's pubkey to the p tag. it can become private group chat?

[arthurfranca]

@mattn edit: Short answer: no. #875 seems to be a good private group chat spec.

I'm not sure if you want to add p tags to kind:1044 rumor (Chat Session Request) or to kind:14 (DM) or elsewhere.

Either way, we would need some type of chat room identifier to add to the kind:10043 list like in place of "<pubkey-A>" from the ["s", "<pubkey-A>", "<session-privkey-A>", "1704525400", "1"] example. And maybe replace s with another tag name like gs (as in "g"roup "s"ession)

edit: Also the kind:1059 DM events would have to change like generating and encrypting one to each chat member OR using the session keypair to encrypt the same event just once to be read by all members (but whoever has the session key would be able to read the DM).

[arthurfranca]

Added new device usage detection to help identify unauthorized privkey access.

In my mind the flow works but it may have a flaw I may be missing.

The idea is simple: a hacker with my privkey won't be able to read my messages nor talk to someone until it reveals his device id (called LID - any random string local to the client/device) to the other chat participant (peer).

Then the peer will broadcast the hacker's LID (using a LID Tracker Event) so that I can compare it with my own LID. If it is different than mine and I hadn't used a new device recently, someone else accessed my account.