NIP-59: Add ephemeral gift wrap event kind (21059)

[ContextVM-org]

Adds support for ephemeral gift wraps (kind:21059) following the same semantics as regular gift wraps (kind:1059) but with ephemeral event semantics per NIP-01. This allows apps to use one or the other based on their requirements.

[vitorpamplona]

Is this a performance bottleneck? I usually just do regular wraps with a 3 minute expiration tag when I need this (our push notifications are like that).

[ContextVM-org]

Expiration tags are more expensive in relays than ephemeral events. The idea behind this is to provide another building block for gift wrapping. The change is quite straightforward and follows the same semantics as regular gift wraps

[vitorpamplona]

Expiration tags are more expensive in relays than ephemeral events.

I agree, but not by much. Modern relay design won't even store events that have nearby expiration dates. They just keep them in memory. That's why I asked if this is a performance problem.

I am not against this proposal. I just want to make sure we don't have an existing way around it that works for you.

[ContextVM-org]

From my perspective, the interesting aspect of this is not about performance. It's about having a clear mental model and enabling new capabilities. Temporary and ephemeral events are distinct concepts and may serve different purposes. It's true that an event with a very short expiration might behave similarly to an ephemeral event in practice, but if the goal is to have clear semantics about persistence expectations, then this addition makes sense.

We are already using this concept in ContextVM, as we use gift wraps for encryption. There is no need for asynchronous operations, and the events inside the wraps are ephemeral. This justifies our use of the concept of ephemeral gift wraps for us. We thought this could also be an interesting building block for other applications.

[vitorpamplona]

That makes more sense. So the use case is actually for ephemeral inner events. hum....

[ContextVM-org]

No, the use case is for ephemeral gift wraps; it is not more than that. It is just 1059 for regular gift wraps and 21059 for ephemeral gift wraps. It is pretty simple and straightforward, the semantics are the same; inner events doesnt need to change. I used the example of CVM because that was what motivated us to use 21059 for ephemeral gift wraps.

[staab]

I'm fine with this (although I agree that expiration tags would be cheaper and relays can optimize them into ephemeral events if expiration is < 1 minute in the future or something), as long as we're clear which type of wrap is used for a given rumor event kind. I don't want to be missing DMs because someone decided to send them as ephemerals (both because they wouldn't be stored and because my client wouldn't be asking for the kind). Would you mind auditing the nips and seeing if there's anywhere we just say "wrap" without specifying the kind?

[ContextVM-org]

Just pushed a commit clarifying the use cases and expectations for both wrap kinds. After auditing the existing NIPs that reference gift wraps, I found that the concern about missing DMs is largely addressed by how current implementations already specify kind numbers explicitly. NIP‑17, which is the primary consumer of gift wraps for messaging, consistently uses kind:1059 throughout its specification, including in subscription filters and relay queries. NIP‑45 and NIP‑46 also explicitly reference kind:1059 in their implementations.

The only ambiguous reference was in NIP‑EE, which uses the term “gift‑wrapped” without specifying a kind. That NIP is already ambiguous since it has become the Marmot protocol and its spec lives outside the NIPs repo.

So the audit revealed that existing clients and protocols already treat kind:1059 as the specific kind for persistent messaging, meaning they won’t accidentally miss messages sent as ephemerals because those clients aren’t yet subscribing to kind:21059.

[staab]

Great, thanks for doing that. This looks good to me.

[vitorpamplona]

No, the use case is for ephemeral gift wraps; it is not more than that. It is just 1059 for regular gift wraps and 21059 for ephemeral gift wraps. It is pretty simple and straightforward, the semantics are the same; inner events doesnt need to change. I used the example of CVM because that was what motivated us to use 21059 for ephemeral gift wraps.

Sure, but I don't care about hypothetical use cases that may someday exist. The key to this PR is that you have ephemeral events inside a Wrap, and it doesn't make sense to keep wraps saved with ephemeral events inside. That's the important part.

Once we have somebody else doing ephemeral wraps with regular events, we can then expand what this event kind is for.

[ContextVM-org]

Well, it seems wavlake is already working on using them. Apart from that, Nostr nips are full of ambiguities to allow hypothetical use cases that may someday exist.
wavlake/monorepo#1039

[vitorpamplona]

Yep, we made this mistake before lots of times and made things way more complicated than what they needed to be for implementers.