NIP-15 - Replaced NIP-04 (deprecated) with NIP-17: Private Direct Messages

[amunrarara]

Replaced NIP-04 (deprecated) with NIP-17: Private Direct Messages

Cheers,
Any opposition to an outright update of this protocol to replace the use of NIP-04 (deprecated) with NIP-17: Private Direct Messages?

[vitorpamplona]

Since we are changing, how about instead of using the same DM kind, we go for a new special kind for the JSONs that can be transferred on NIP-15? You could use the same NIP-17 mechanism and double-wrap a new kind with the usual seal and wrap. In that way, the users will never see the raw json in the chats of clients that don't support NIP-15.

[vitorpamplona]

Actually, does NIP-15 requires the new extreme privacy for DMs? You might not need the whole thing. You could just GiftWrap the new kind directly (so, no Seals... one less event to sign and decrypt).

[amunrarara]

Since we are changing, how about instead of using the same DM kind, we go for a new special kind for the JSONs that can be transferred on NIP-15? You could use the same NIP-17 mechanism and double-wrap a new kind with the usual seal and wrap. In that way, the users will never see the raw json in the chats of clients that don't support NIP-15.

You're totally right; these events have no use outside of NIP-15 enabled clients. It would be great to have each of these events sent with their own kind, instead.

Checkout Events

• customer order (event)
• merchant request payment (event)
• merchant verify payment/shipped (event)

Currently, the events above generate JSON that is placed in the content field of a NIP-04 / kind 4 Encrypted Direct Message, sent between customer and merchant.

Actually, does NIP-15 requires the new extreme privacy for DMs?
That would mean the difference between encrypting the rumor, or not encrypting the rumor? Did I understand that correctly?

Having the rumor encrypted could be a good addition to the protocol, I'd think; I'm sure there's a large percentage of transactions that the participants would prefer to have as hyper-private as possible. I personally wouldn't like anyone to have possible knowledge of my participation in a transaction, unless I want them to have that knowledge; a good argument for using extreme privacy with the new kinds.

Customer Support

I still believe these messages could / should be sent via NIP-17, since they're a bit more conversational in nature; though likely related to a specific product, stall, or transaction, it might be nice to continue communications on other non-NIP-15 clients.

Whaddya think, @vitorpamplona? Awesome thinkin' here, thanks for jumping on the PR. Congrats BTW on the OpenSats LTS grant!!

[vitorpamplona]

Customer Support

Yes, customer support should just be regular DMs :)

Checkout Events

Understood.

My proposal would be to create a new kind (or 3 new kinds, up to you) for all NIP-15 checkout messages. That kind will have today's JSONs as plain text (unencrypted) inside the .content of that event kind. Then you can embed that signed event inside a regular NIP-17 DM with #1078

This allows you to "quote" the checkout event inside a regular DM. You could say something like:

Hi Vitor, 

Thank you for the order! Here's your invoice: 
nembed10v3xjepz8g3rwvmpx4skxef3vvun2er9xgenjetpxv6n2cfhxs6kzcnxv9nx2efn89jrgerrx
ccnxvpcx9sn2cenv33nydf3x5uxxwfn8q6nvv3svs3zcgnsw43xketeygazycnrvs6rwvf4vd3nxdrx8
yuxgcm9xa3r2vnxv3jxze33vsurydn9x43k2vpjxcengdeevgmk2vf3xpsn2cnyxd3nxdec8y6rsdnrv
yuzytpzvdex2ct5v4j97c

And here are your payment options: 
nevent1qqst8w0xhjf9ehy98tmgcmk7zaj6p4lxjwjf8z08s9trzmjg4yzdywcpzemhxue69uhhv6t5d
aezumn0wd68yvfwvdhk6qgawaehxw309ahx7um5wgkhqatz9emk2mrvdaexgetj9ehx2aqpz3mhxue69
uhhyetvv9ujumn0wd68ytnzvupzp78lz8r60568sd2a8dx3wnj6gume02gxaf92vx4fk67qv5kpagt65
gxsjx

Make sure to use a NIP-15 client to be able to see it. 

Let me know if you have any questions. 

The receiving client will receive a DM and if it supports NIP-15, it unpacks the inner event and displays that. Since the inner event is signed but unencrypted, the user can forward that nostr link to the finance dept for payment and to accounting for their logs. In this way, both users and shops can keep a signed nostr event for their records that is not encrypted to a particular pubkey while only transmitting superprivate gift-wrapped DMs back and forth.

[amunrarara]

Ah I see your logic, that is an excellent solution @vitorpamplona

I'll update the PR with these recommendations shortly!

[amunrarara]

@vitorpamplona Alright, finished an edit that includes the new kinds. Want to give it a review?

I'll pull-and-squash the commits before I reopen the PR again, FYI.

[vitorpamplona]

You don't want to use #1078 to embed the event instead of just pasting a JSON in the message? Then it would be easier for clients to find which parts of the message to render (just look for nembed1..)

That would replace all JSONs inside the .content.

[amunrarara]

You don't want to use #1078 to embed the event instead of just pasting a JSON in the message?

Ah, you're totally right @vitorpamplona, I'll update the spec to include #1078