NIP-89: Recommended Application Handlers
Nostr keeps inventing event kinds faster than every client can understand
A strength of Nostr is that new event kinds can appear without asking a central platform for permission. The cost is discoverability. A client may encounter a chess game, classified listing, video event, zap goal or wiki page and have no idea which app can open it well.
NIP-89 creates a recommendation and handler-discovery layer. Apps can publish handler information. Users can recommend which apps handle a given kind. A client that sees an unfamiliar object can ask the network where to send the user.
That is a product-layer standard, not core relay plumbing. It helps the long tail of Nostr apps feel connected.
Kind 31989 recommends; kind 31990 describes
Recommendation events use kind 31989. The d tag is the supported event kind, and a tags point to handler information events, optionally scoped to platforms such as web, iOS or Android.
Handler information events use kind 31990. They can carry app metadata, one or more k tags for supported event kinds and URL templates for NIP-19 entities. A web handler might publish a URL with a bech32 placeholder, which the client replaces with an naddr, nevent or nprofile.
Recent edits connect web handlers to NIP-5A-style site manifests through latest and next tags, making app discovery more deployment-aware.
App handlers became more serious as Nostr apps diversified
NIP-89 entered the repo in 2023 and saw early compatibility work from Jon Staab and Asai Toshiya. In June 2026, hzrd149 connected handler descriptors to aggregate hashes and site snapshots through PR #2287, tying the NIP to the newer nsite deployment story.
The file history is a reminder that NIP-89 is not only about opening a link. It is about helping users move between specialized Nostr applications without each client becoming a monolith.
The more event kinds Nostr gains, the more important this routing layer becomes.
Recommendations needs to respect platform and user preference
A client needs to not blindly open the first handler it finds. It needs to consider the user's platform, installed apps, web fallback, who recommended the handler and whether the handler actually declares the event kind.
Apps publishing handler information needs to keep URL templates current and support the NIP-19 entity forms they advertise. Broken handler URLs are worse than no handler because they teach users not to trust cross-app routing.
NIP-89 works well when the user feels in control: open in this app now, remember my choice later, or inspect other handlers.
Handler discovery can become app spam
If any app can claim support for any kind, clients need reputation, user preference and sanity checks. A malicious handler can phish keys, misrender data or trap users in a bad app.
The NIP is strongest when recommendations come from trusted users and handler descriptors are treated as claims to verify through product behavior.
Read NIP-89 in the wild
NIP-89 lets people recommend application handlers for event types. That helps Nostr avoid one super-app by letting specialized tools open specialized objects.
Handler choice can also become quiet capture. Show who recommends the handler, let users override it and avoid turning recommendations into an app-store funnel.
What changes when you actually use it
For you, NIP-89: Recommended Application Handlers is felt when a specialized experience still remains portable. Games, forums, handlers, static sites and local transports become useful only when another client can understand the same object. The source terms kind 31989, kind 31990, kind 0, kind 1, kind 31337, draft are the difference between an open feature and a private app convention.
What changes for builders and operators
For builders, NIP-89: Recommended Application Handlers needs cross-client proof. Create an object in one product, open it in another, then test what survives without special server knowledge. That is where an app-specific idea becomes a real Nostr surface.
What the official file makes concrete
The official file is organized around Rationale, Parties involved, Events, Recommendation event, Handler information, Client tag, User flow, Example. Inspect kind 31989, kind 31990, kind 0, kind 1, kind 31337, draft, kind:31989, kind:31990 because these are the pieces most likely to surface as product behavior. Read it beside NIP-01, NIP-19, NIP-31 before treating it as isolated.
NIP-89: Recommended Application Handlers earns trust when a second client can understand the same object without a private handshake.
Where it breaks
The failure mode in NIP-89: Recommended Application Handlers is private interoperability. The event exists on Nostr, but only the original app knows how to use it. Test a second interface and a second relay before calling the feature portable.
Where this appears outside the markdown
In the ecosystem, NIP-89: Recommended Application Handlers is where Nostr stops being only a feed and becomes a surface for specialized products: forums, games, static sites, handlers, local transport or application state. The standard matters only when another client can open the same object without calling the first app for private instructions.
The nearby-standard trap
The nearby-standard trap in NIP-89: Recommended Application Handlers is mistaking novelty for interoperability. A clever app-specific event is not a standard until another client can use it. Read NIP-01, NIP-19, NIP-31 to see whether the feature has a path out of its first product.
Language that keeps the feature honest
Good product copy for NIP-89: Recommended Application Handlers names portability. It tells you whether another client can open the object, whether a relay or app-specific convention is required, and what might fail when you leave the original product.
What this page does not promise
NIP-89: Recommended Application Handlers does not make a niche feature portable just because it uses Nostr events. Portability begins when another client can parse the object, recover the context and show a useful experience without a private API. Read NIP-01, NIP-19, NIP-31 and look for second-client evidence before treating the format as settled.
Read it as a field test
Start NIP-89: Recommended Application Handlers with interoperability. If kind 31989, kind 31990, kind 0, kind 1, kind 31337, draft cannot travel into another useful interface, the feature is still mostly an app convention. Read NIP-01, NIP-19, NIP-31 and look for public examples before assuming a specialized NIP has become a stable product surface.
Where the standard earns trust
The source links give you places to test the interpretation in public: PR #2287, NIP-19 entities, Amethyst release note. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-89 source is the anchor for exact wording, and NIP-89 commit history shows how that wording moved over time. The strongest secondary clues here are PR #2287, NIP-19 entities, Amethyst release note. Treat this evidence chain as part of the article, not as footnotes. A NIP page becomes useful when you can move from claim to source to working behavior without guessing.
Keep the chain visible for NIP-89: Recommended Application Handlers: first the human promise, then kind 31989, kind 31990, kind 0, kind 1, kind 31337, draft, then the implementation record, then the real-world failure case. That order keeps NIP-89 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Can a second app open the object and make it useful, or does the first product still carry the real meaning?
- Which part is standardized in
kind 31989,kind 31990,kind 0,kind 1, and which part remains a convention, server policy or UI choice? - What happens when the app, relay, local transport or handler that created the object is gone?
What to verify before you rely on it
- Find
kind 31989,kind 31990,kind 0,kind 1,kind 31337in the official file and check where the UI exposes the same concept. - Read NIP-01, NIP-19, NIP-31 as context before treating NIP-89 as a complete product story.
- Open at least one implementation, mirror, pull request or library source from the source links before trusting that the idea is mature.
- Test the unhappy path: missing relays, stale metadata, invalid signatures, blocked events, expired state, revoked permissions or unavailable media.
- Write the user-facing copy in plain language. If a standard changes authority, privacy, money, moderation or recovery, say that before the click.
Direct sources
Use these sources for NIP-89: Recommended Application Handlers in that order: Official NIP-89 source for the current wording; NIP-89 commit history for the change record; PR #2287, NIP-19 entities, Amethyst release note for public context. The article gives you the consequence in plain language, but the source trail is where exact fields, status notes, unresolved debates and implementation proof stay checkable.
