Is it correct the interpretation that NIP-59 allows the sending of encrypted gift wrap to groups (NIP-29)?

[WesleyBatista]

Context is an application that allows the exchange of messages that only members of a closed and private group can read.

While I noticed that implementation of NIP-29 is not widely accepted/incorporated by relays, I was considering to build an application that abides as much as possible to this NIP, e.g the part mentioning that every message sent to a group should have the h tag set.

Concerning the message encryption part of this application, I skipped NIP-04 in favor of NIP-17 as recommended, which relies on NIP-44 and NIP-59. The later one, has the following statement I'd like to highlight:

nips/59.md

Lines 58 to 62 in a59ce89

	## 3. Gift Wrap Event Kind
	A `gift wrap` event is a `kind:1059` event that wraps any other event. `tags` SHOULD include any information
	needed to route the event to its intended recipient, including the recipient's `p` tag or [NIP-13](13.md) proof of work.

It's noticeable that examples available focus on the use of p tag to exemplify a Recipient. However, considering the actual definition of NIP-59 and in light of NIP-29, I wonder if the h tag could be set instead of a p one, perhaps along with the NIP-13 to fight spam.

Adding more context...

This comes after some experimentation with the examples from nostr_sdk python package, where I spotted the limitation in the gift_wrap function definition, found not accepting any tags to be set.

I was about to create an issue there, suggesting to replace the receiver_pubkey with tags where the client should "include any information needed to route the event to its intended recipient", but I thought that asking the community first around the interpretation would give more basis for an issue and possibly pr there.

[staab]

PoW definitely makes sense. But since gift wraps have to be possible to decrypt, addressing the gift wrap to something other than a p tag means you need some other mechanism for figuring out which key to use to decrypt. I'm not sure if nip 29 has something like that, but NIP 87 (#875) uses key sharing to accomplish that.