---
# System prepended metadata

title: NIP89 is an app store killer

---

App stores sit at the top of the food chain because they enable us to discover new apps.

Nostr doesn't need an app store to allow us to discover new nostr apps, because NIP89 allows this to happen from within any existing app.

Every nostr client *is* the app store, and you discover new apps by seeing comments etc on events produced by other apps.

### How it works
NIP89 provides two simple building blocks:

- a way for apps to “register” kind applications handlers (e.g. app X supports kind Y using such-and-such URL)
- a way for users to publicly associate kinds with these application handlers throughout their different platforms (e.g. web, vs ios)

A byproduct of this is that anyone can see what applications exist for a given kind and who (from the people they follow) uses which application.

Let's look at Zapstr as an example. It's a music player that lets you publish and listen to music track events (kind 31337).

You can also comment on a track with a note. 

When your followers see that comment event in their twitter style nostr clients, the music track itself is not displayed. So it looks like you are commenting on nothing. Their client doesn’t know what kind 31337 means, how to render it, or how to interact with it.

In our new NIP89 world, the song event itself is no longer displayed as a missing event, but as a short description of the song (thanks to NIP31), and when you tap on the event it will open it in Zapster.

It does this by querying the people you follow for the app that *they* use to open kind 31337 events.

### Why this is awesome
Multiple applications can compete under the same use case. Competition is good.

Different applications may be better suited to different communities. For example let's pretend there's a competitor to Zapster, called Japster, designed specifically for Japanese users. Users in Japan who mostly follow other Japanese nostriches will see that most of the people they follow are using Japster not Zapster.

It also means that Nostr doesn't need an app store because your nostr client *is* the app store.







help us discover new apps

Let’s talk about NIP-31, NIP-89 and how discoverability in Nostr is not only not broken, but it’s a step-function improvement over the status quo of the siloed web.

The captured internet has organically evolved multiple solutions to enable discoverability, which is, the process of discovering new content / tools / people, etc.

These tools sit at the top of the internet food chain: 

Search engines, app stores, social networks algorithms, etc evolved to help us discover new content, tools, 

These individual approaches are multi-billion industries on their own.

How are we, humble nostriches, supposed to compete with these giants and their enormous moats?

We compete by not competing. By playing a different game.
The game

Nostr has a funny design that makes for some very creative implementations.

In Nostr everything is an event. These events can reference other events. Each event has a kind number, which represent what that event is. An event of kind 1 is a short note, what we typically call a tweet. An event of kind 7 is a reaction to another event, such as 🤙ing it. Zaps? Those are kind 9735.

It’s very simple. Painfully simple.

But the fact that these event kinds can mix together in a chaotic soup of events changes the game.
The soup

A few months ago I wrote an application based on Karnage’s designs. Zapstr. It’s a music player where everything you do is… you guessed it, a nostr event. Publishing a song. Listening to a song. Liking it, and of course, zapping it.

But also, you can respond to a song with a short note.

And that’s the first ingredient of this soup.

The moment you find a song you like in this remote corner of the internet and make a comment about it, your followers, can see this comment on any other social application.

Of course, since Zapstr is an application with zero marketing budget, using a kind number I came up with (kind 31337, a wink to the elite hackers out there), your followers don’t know what you’re talking about.

You’re talking to the void.
The void

This is where NIP-31 and NIP-89 come in.

Until these NIPs, you responding to a random song, or to a random anything, your followers will think you’re going insane. You’re responding with something like “Wow, this song moved me to my core”, but you don’t mention what song you’re talking about.

Lana del rey, is that you?

NIP-31 is, like almost anything in nostr, simple as hell.

If you remember the good old alt tag in HTML <img>s that was so important when you were loading images on your 28k modem, you’ll understand NIP-31. This NIP proposes that event kinds that are not widely supported by all clients, include an alt tag explaining, in a human readable format, what the event is about.

alt: "This is a song 'Video Games' by Lana del Rey."

Simple.

But now your followers have context.

Of course, the context is helpful. But insufficient for a full experience.
The full experience

The measuring stick most people will compare our ecosystem with, are superapps.

WeChat. X.com. Etc.

here’s a reason these apps are so popular. It’s not merely that people might crave being governed by a benevolent dictator; the convenience of superapps stands on its own merit.

The appeal of a superapp is the convenience of the seamless integration across use-cases.

Chat with your friends? ✅

Pay your bills? ✅

Get a ride? ✅ How about order some food while you’re riding back home? ✅

The super app is the internet. Why leave? Why create a new account somewhere else? Why go through the hassle of connecting your payment methods, porting your social graph?

It’s all so painful. What’s the upside?

Of couse, if you’ve been paying attention, you feel that Nostr provides many of these properties.

Frictionless transition through all use cases: it’s all just one npub!

Porting your social graph: there is no porting; your social graph already transcends whatever nostr clients you use.

Reconnecting your payment methods: well, we have bitcoin, and wallet connect, and lightning!
Putting it all together

Here the vision of the Nostr I see comes full circle, and why I believe nostr doesn’t only NOT suffer from a discoverability problem, but it’s actually orders of magnitude better than the status quo. We’ve just haven’t fully built it yet.

Nostr allows any developer, with no marketing budget, to create an app, a new app, using a new kind number, on an incredibly niche use case of the internet/nostr, and leverage the liquid nature of how event kinds interoperate to provide organic reach to these new and strange use case of nostr/internet.
The glue

NIP-89 was that one last missing piece to make the experience of transitioning through multiple microapps cohesive. It provides two simple building blocks:

    a way for apps to “register” kind applications handlers (e.g. app X supports kind Y using such-and-such URL)
    a way for users to publicly associate kinds with these application handlers throughout their different platforms (e.g. web, vs ios)

A byproduct of this, is that anyone can query 1) which applications exist for a given kinds, and 2) which one the people they follow use.

Let’s go back to the Zapstr example.

One of your followers sees that song, but clicking on the event yields nothing. Their client doesn’t know what kind 31337 means, how to render, or interact with it.

But, using NIP-89 the client can ask the user’s social graph “hey, what apps do you use for kind 31337?”

All the user experiences is the song opening up in Zapstr, or in any other app that supports kind 31337 as recommended by the people they follow.

    From the people the user follows.

This is key.

This means that multiple applications can compete and win under the same use case in different communities.
A million microapps, one glue

Why do I insist that Nostr is orders-of-magnitude better than the siloed internet and the superapps approach?

Superapps need to appeal to everybody; they have to move carefully, iterate in small steps and remain very conservative. By their very nature, they MUST be bland (which is why all these superapps look very much alike and none of them look like ONOSENDAI)

Whereas in nostr we can experiment with the wildest of ideas and weirdest approaches since no app needs to serve all users. Perhaps a very weird app appeals to only 20 or 50 people, but it can transparently interact with all other apps serving the same event kind.

Long-tails all the way down.

As these microapps enable all types of niche use cases while maintaining interoperability and leveraging discoverability and distribution through nostr, the use cases of nostr begin to blend in and the artificial use-case silos break down.
App Stores need not apply

I believe App Stores are a synthetic solution to a problem that doesn’t exist in Nostr.

App Stores exist due to the internet’s lack of unification in exposing novel use cases to users.

App Stores are necessary because the captured internet lacks a way of unifying different use cases exposing novel use cases and applications to users. The main way of discovering these was through use cases.

But in this world, where within the context of a social client you might see when one of the people you follow posts a new product for sale, or adds a review to a concert, or takes notes about a book they’re reading you can immediately discover these new use cases organically.
WTF happened in 1989?

For decades, we’ve operated within data silos, with each use case as its own isolated entity. The only trancendence of use-cases was the centralizing vertical-integration of a Facebook offering both social media and commerce.

YouTube data isn’t interoperable with Spotify’s. Twitter isn’t interoperable with Amazon, and Airbnb doesn’t inform in any sort of way what happens in reddit.

Every one of these use cases is its own thing, and, to stay relevant, they needed to persuade you to engage, engage, engage. We are all very aware of this and it’s many pitfalls.

We know where that path leads.

But, as we’ve constructed Nostr apps we’ve erected similar use-case walls. Social clients are interoperable with other social clients, but the link to music clients, or to commerce websites, or to airbnb-like websites, etc, is mostly non-existent.

Just like in 1989, bringing down this wall, will unleash a great flurry of innovation and creativity. When Nostr can provide organic, free, non-invasive, discoverability and distribution to any new use case, we’ll see millions of microapps bloom and new entrepreneurs and developers build on Nostr.

Developers, tear down this wall.
