The Spec Change That Rewrites Discovery

If you’ve ever tried to highlight a passage from a physical book and share it on Nostr, you already know the problem. There was no way to say where it came from. The old NIP-84 spec gave you exactly two options: a and e tags for Nostr events, or an r tag for URLs. A printed book doesn’t have a URL. A podcast episode doesn’t have a URL. An academic paper with a DOI doesn’t need one.

That changed on September 1st, 2026, when PR #2454 was merged into the NIPs repository. One file, six lines changed, and suddenly the reference section of NIP-84 looks completely different.

What Actually Changed

The new spec replaces the old two-sentence definition with a three-item list. Here’s what it looks like in practice: a and/or e tags for Nostr events, i tags for structured sources per NIP-73, and r tags for everything else, which now can contain a URL or plain text.

That third bullet is the quiet bomb. The r tag is no longer the URL tag. It’s the fallback. The pull request describes the situation that prompted the change: highlights published with a non-URL source, which clients that assumed a valid URL failed to interpret. Reading r as a URL was never safe in practice, and this change stops implementations from being wrong to keep parsing it that way.

The i Tag Brings Structured Identity

The real addition is the i tag. NIP-73 is the external content ID specification, and it gives i tags a fixed vocabulary for identifiers that exist outside Nostr. We’re talking isbn: for books, doi: for papers, isan: for movies, geo: for geohashes, iso3166: for countries, podcast:guid: and its variants, plus blockchain transaction and address forms and a normalized URL form under the web kind.

Before this change, a highlight from a book had no way to say so. The only non-Nostr slot was r, defined as a URL, and a printed book doesn’t have one. Pointing i at NIP-73 gives that highlight an identifier other clients can query on. Every event carrying ["i", "isbn:9780123456789"] becomes findable as a group. That’s the whole point of an id registry: structured, queryable, interoperable.

What Got Lost in the Diff

Nothing is free. The same edit removed a recommendation that had ridden along with the old definition. The old spec said clients generating these events should do a best effort of cleaning URLs from trackers or obvious non-useful information from the query string. That was the only tracker-stripping guidance in NIP-84, and it’s gone. Nothing in the diff moved it elsewhere. Clients that strip tracking parameters from highlight sources are now doing so on their own judgement rather than on spec guidance.

I think that’s a mistake, personally. Tracker stripping was a small privacy win that cost nothing to keep. But the spec authors made a call: the r tag is now a catch-all, and parsing it as anything specific is unsafe. If you want structured data, use i. If you want privacy hygiene, that’s a client concern now.

The NIP-67 Auth Hint You Might Have Missed

While everyone was arguing about highlights, NIP-67 quietly gained a third hint value. Pull request #2371, opened by fiatjaf on June 6th and merged on September 1st, adds "auth" to the EOSE hint array. Twelve lines added, sixteen removed across two files.

Why it matters? Before this change, an unauthenticated subscription that returned a partial view of a relay’s data ended with the same EOSE as one that returned everything. The client couldn’t tell the difference between “that’s all there is” and “that’s all you’re allowed to see without authenticating.” The new hint fixes that. An EOSE carrying "auth" tells the client that more stored events are waiting behind NIP-42 authentication, and the relay must have sent the challenge before saying so.

The normative part is the ordering requirement. Relays MUST send an AUTH message containing a challenge before the EOSE that carries the "auth" hint. A relay that sent the hint without a challenge would be telling a client to do something it has no way to do.

The Client Nobody’s Talking About

Ditto pushed a bug-fix release this week that’s worth noting for one specific reason. Zaps that carry a comment now pay instead of getting cancelled. Sending Monero from the send dialog works again. Restoring a wallet that’s already there quietly loads it instead of dead-ending on an error. Push notifications also arrive for longer posts that used to slip through.

Summary

This week in Nostr was defined by specification hygiene, not hype. NIP-84 now supports structured external identifiers via i tags and NIP-73, turning highlights into queryable, interoperable objects. NIP-67 gained an auth hint so clients can finally tell the difference between “no more data” and “no more data for you.” Ditto shipped wallet and zap fixes that make the client usable for actual transactions. The quiet weeks are the ones that build the foundation for the loud ones.