Week in Review: Nine Pull Requests Merged Into nostr-protocol/nips

NIP-59: a new ephemeral gift wrap kind for real-time messages

PR #2245 adds kind:21059, an ephemeral counterpart to the existing kind:1059 gift wrap. It has the same structure as kind:1059, but follows the ephemeral event semantics defined in NIP-01, meaning relays MUST NOT store it. NIP-59 now spells out the intended split: kind:1059 is for persisted, asynchronous messaging, such as NIP-17 conversations that need offline delivery, while kind:21059 is for real-time contexts, such as live chat or gaming, where only currently connected recipients matter. This does not change how NIP-17 direct messages work today; it adds a second, non-persisted gift wrap kind for use cases that don't need message history.

NIP-17: gift-wrapped DMs get a deletion and edit section

PR #2260 adds a "Delete and Edit" section to NIP-17. It states that, in addition to the deletion behaviour already specified in NIP-59, where a gift wrap can be deleted by its p-tagged recipient, clients MAY let a user delete a message by wrapping a kind:5 delete event inside a kind:1059 gift wrap and sending it to the recipient as part of the conversation. Clients SHOULD then remove the deleted message from the conversation, or mark it as deleted. The same section also allows implementing message editing as a delete followed by a new event published with the same timestamp. This is new guidance layered on top of the existing gift wrap format, not a change to the encryption itself.

NIP-01: relays must treat extra path segments as the same endpoint

PR #2307 adds one sentence to NIP-01: "Relays MUST only accept connections to a single endpoint when additional path segments do not influence its behavior." The PR's description points out that a relay URL such as wss://relay.example/<random-string> was, on most running relays, functionally identical to wss://relay.example/, an ambiguity that made relay identity and deduplication harder for clients to reason about.

NIP-29: audio and video live spaces for groups

PR #2238 adds a section to NIP-29 letting a group advertise a LiveKit-powered voice and video room through a livekit tag on the group announcement event, alongside a new supported_kinds tag that lists which event kinds the group accepts (an empty list means it supports no kinds at all, only the AV room). Clients request a join token from a relay's /.well-known/nip29/livekit/<group-id> endpoint using a NIP-98 authorization event, and relays may publish who is currently in the room through a new kind:39004 participants event.

NIP-71: multiple audio tracks per video

PR #2255 extends the imeta tag conventions in NIP-71 so a single video can list several audio tracks as separate imeta tags, each carrying an l property for its language and an ov property flagging the original-language track. It also adds a waveform property, a short space-separated list of amplitude values, so clients can render a waveform for an audio track.

NIP-78: a normal, non-addressable application-specific kind

PR #2292 adds kind:78 to NIP-78 as a normal event, alongside the existing addressable kind:30078. The distinction matters for apps that need to store and query several events of the same type: an addressable kind keeps only the latest event per d tag, while a normal kind keeps all of them. The PR also adds the new kind to the NIPs README's event kind table.

NIP-85: reworded description of kind:10040

PR #2304 rewords a single paragraph of NIP-85. It changes language describing kind:10040 as a list of "trusted service providers" to describe it instead as the user's preferred source per result, and clarifies that a service provider may use multiple keys and relays, including a key issued per user when results are personalized to that user.

C7: chat views restricted to kind 9

PR #2310 adds one line to the C7 convention: clients that render a "chat view" as an ordered stream of events MUST only fetch kind:9 events, to avoid losing context across different implementations. Other content types can still be referenced inside a kind:9 message by quoting them, per NIP-18.

NIP-F4: a new draft NIP for podcasts

PR #1093 is the largest change of the day by a wide margin, adding a full draft specification of more than a hundred new lines. It introduces NIP-F4, a draft, optional NIP defining how podcast shows and episodes are published to and read from Nostr relays, structured to fit into existing podcast player workflows. Under NIP-F4, each podcast is its own Nostr keypair, letting it combine a podcasting presence with an ordinary kind:0/kind:1 profile. Show-level information, such as title, cover image, description, and website, is published as a replaceable kind:10154 event that can also credit hosts, co-hosts, and editors by pubkey. Individual episodes are separate kind:54 events published directly by the podcast's own key, each carrying a title, description, and one or more audio tags pointing to the episode's media file. Because anyone could otherwise falsely claim to be a podcast's author, NIP-F4 adds a kind:10064 event through which a podcast's real authors publish their own list of the podcasts they author, so a claimed authorship can be checked against that counter-claim rather than trusted on its face. The PR also updates NIP-51 to add a kind:10054 "Favorite podcasts" list, letting any user publicly note which podcasts they follow using p tags for podcast pubkeys and url tags for RSS/XML feed URLs, and adds the new event kinds to the NIPs README's kind table.

A batch, not a coordinated release

Beyond the two direct message changes, there is no shared thread connecting these nine pull requests. They touch unrelated parts of the protocol, from relay connection handling to group video, application storage, and podcast distribution, and simply cleared review within the same roughly ninety minute window on 28 May. It was a batch, not a themed release, even though the day's largest change by far, the new podcast NIP, landed in the same window as eight much smaller ones.