Design Question(s) re: NIP04Event, DirectMessageEvent, CheckoutEvent

[avlo]

@tcheeric hi, eric. do i understand correctly that:

1. a DirectMessageEvent (and any/all of its subclasses) implies both sender (pubkey) and receiver (pubkey) are required?
2. is there any DirectMessageEvent context whereby either sender/receiver is not required?

i also noticed that you've removed deprecation warning from NIP04Event.java, was that intentional? you'll recall that NIP-04 docs have it listed as Warning unrecommended: deprecated in favor of NIP-17

i'll be submitting updates to nj develop branch shortly.

[tcheeric]

Hi Nick,

This is correct. Sender and recipients are required. The server is always the one signing the event. I'm the validation, I ensure there's a p-tag (recipient)

I cannot really think of a scenario where either sender/recipient is not required. There will always be a sender, the note signer, and, I believe, you need the recipient pubkey to encrypt the message

You are correct with the deprecation. It was intentional, and the reason is that, although nip04 is not recommended anymore, it's still used in other nips for encryption. I believe 15, 60/61 etc. I felt that maybe it was too premature to deprecate it, and removed it.

[avlo]

gotcha, understood and sounds good, thanks for the info.

unrelated- SC will be undergoing architectural changes/experimentation that may not be compatible with nj variants after current nostr-java develop/nj-0.7_upgrade branch (revision 4bc30cceb90b48772cdf7bedbe08b30d68973ae5), so i've created an SC branch nj_0.7_upgrade-compatible (revision 63139d3ca7fce157f8671dce1cd34b885a6e05af) as a most recent working SC version for you to checkout/pull into your SC fork if useful/helpful to you. i'll be available for advisement, but otherwise any (breaking) changes made after above nj/sc snapshots will likely not receive correlated/immediate attention.

[tcheeric]

Ok, this is noted. Thanks Nick.