How can we better define a "Nostr application"? 🤔 From basic usage to full ecosystem integration 🌐, the purest Nostr applications are not only users of the protocol but also drivers of the decentralized ecosystem 🚀🔗.check out the article，written by hodlbod (npub1jlr…ynqn)

quoting naddr1qq…x25y

There was a slight dust up recently over a website someone runs removing a listing for an app someone built based on entirely arbitrary criteria. I’m not to going to attempt to speak for either wounded party, but I would like to share my own personal definition for what constitutes a “nostr app” in an effort to help clarify what might be an otherwise confusing and opaque purity test.

In this post, I will be committing the “no true Scotsman” fallacy, in which I start with the most liberal definition I can come up with, and gradually refine it until all that is left is the purest, gleamingest, most imaginary and unattainable nostr app imaginable. As I write this, I wonder if anything built yet will actually qualify. In any case, here we go.

It uses nostr

The lowest bar for what a “nostr app” might be is an app (“application” - i.e. software, not necessarily a native app of any kind) that has some nostr-specific code in it, but which doesn’t take any advantage of what makes nostr distinctive as a protocol.

Examples might include a scraper of some kind which fulfills its charter by fetching data from relays (regardless of whether it validates or retains signatures). Another might be a regular web 2.0 app which provides an option to “log in with nostr” by requesting and storing the user’s public key.

In either case, the fact that nostr is involved is entirely neutral. A scraper can scrape html, pdfs, jsonl, whatever data source - nostr relays are just another target. Likewise, a user’s key in this scenario is treated merely as an opaque identifier, with no appreciation for the super powers it brings along.

In most cases, this kind of app only exists as a marketing ploy, or less cynically, because it wants to get in on the hype of being a “nostr app”, without the developer quite understanding what that means, or having the budget to execute properly on the claim.

It leverages nostr

Some of you might be wondering, “isn’t ‘leverage’ a synonym for ‘use’?” And you would be right, but for one connotative difference. It’s possible to “use” something improperly, but by definition leverage gives you a mechanical advantage that you wouldn’t otherwise have. This is the second category of “nostr app”.

This kind of app gets some benefit out of the nostr protocol and network, but in an entirely selfish fashion. The intention of this kind of app is not to augment the nostr network, but to augment its own UX by borrowing some nifty thing from the protocol without really contributing anything back.

Some examples might include:

• Using nostr signers to encrypt or sign data, and then store that data on a proprietary server.
• Using nostr relays as a kind of low-code backend, but using proprietary event payloads.
• Using nostr event kinds to represent data (why), but not leveraging the trustlessness that buys you.

An application in this category might even communicate to its users via nostr DMs - but this doesn’t make it a “nostr app” any more than a website that emails you hot deals on herbal supplements is an “email app”. These apps are purely parasitic on the nostr ecosystem.

In the long-term, that’s not necessarily a bad thing. Email’s ubiquity is self-reinforcing. But in the short term, this kind of “nostr app” can actually do damage to nostr’s reputation by over-promising and under-delivering.

It complements nostr

Next up, we have apps that get some benefit out of nostr as above, but give back by providing a unique value proposition to nostr users as nostr users. This is a bit of a fine distinction, but for me this category is for apps which focus on solving problems that nostr isn’t good at solving, leaving the nostr integration in a secondary or supporting role.

One example of this kind of app was Mutiny (RIP), which not only allowed users to sign in with nostr, but also pulled those users’ social graphs so that users could send money to people they knew and trusted. Mutiny was doing a great job of leveraging nostr, as well as providing value to users with nostr identities - but it was still primarily a bitcoin wallet, not a “nostr app” in the purest sense.

Other examples are things like Nostr Nests and Zap.stream, whose core value proposition is streaming video or audio content. Both make great use of nostr identities, data formats, and relays, but they’re primarily streaming apps. A good litmus test for things like this is: if you got rid of nostr, would it be the same product (even if inferior in certain ways)?

A similar category is infrastructure providers that benefit nostr by their existence (and may in fact be targeted explicitly at nostr users), but do things in a centralized, old-web way; for example: media hosts, DNS registrars, hosting providers, and CDNs.

To be clear here, I’m not casting aspersions (I don’t even know what those are, or where to buy them). All the apps mentioned above use nostr to great effect, and are a real benefit to nostr users. But they are not True Scotsmen.

It embodies nostr

Ok, here we go. This is the crème de la crème, the top du top, the meilleur du meilleur, the bee’s knees. The purest, holiest, most chaste category of nostr app out there. The apps which are, indeed, nostr indigitate.

This category of nostr app (see, no quotes this time) can be defined by the converse of the previous category. If nostr was removed from this type of application, would it be impossible to create the same product?

To tease this apart a bit, apps that leverage the technical aspects of nostr are dependent on nostr the protocol, while apps that benefit nostr exclusively via network effect are integrated into nostr the network. An app that does both things is working in symbiosis with nostr as a whole.

An app that embraces both nostr’s protocol and its network becomes an organic extension of every other nostr app out there, multiplying both its competitive moat and its contribution to the ecosystem:

• In contrast to apps that only borrow from nostr on the technical level but continue to operate in their own silos, an application integrated into the nostr network comes pre-packaged with existing users, and is able to provide more value to those users because of other nostr products. On nostr, it’s a good thing to advertise your competitors.
• In contrast to apps that only market themselves to nostr users without building out a deep integration on the protocol level, a deeply integrated app becomes an asset to every other nostr app by becoming an organic extension of them through interoperability. This results in increased traffic to the app as other developers and users refer people to it instead of solving their problem on their own. This is the “micro-apps” utopia we’ve all been waiting for.

Credible exit doesn’t matter if there aren’t alternative services. Interoperability is pointless if other applications don’t offer something your app doesn’t. Marketing to nostr users doesn’t matter if you don’t augment their agency as nostr users.

If I had to choose a single NIP that represents the mindset behind this kind of app, it would be NIP 89 A.K.A. “Recommended Application Handlers”, which states:

Nostr’s discoverability and transparent event interaction is one of its most interesting/novel mechanics. This NIP provides a simple way for clients to discover applications that handle events of a specific kind to ensure smooth cross-client and cross-kind interactions.

These handlers are the glue that holds nostr apps together. A single event, signed by the developer of an application (or by the application’s own account) tells anyone who wants to know 1. what event kinds the app supports, 2. how to link to the app (if it’s a client), and (if the pubkey also publishes a kind 10002), 3. which relays the app prefers.

As a sidenote, NIP 89 is currently focused more on clients, leaving DVMs, relays, signers, etc somewhat out in the cold. Updating 89 to include tailored listings for each kind of supporting app would be a huge improvement to the protocol. This, plus a good front end for navigating these listings (sorry nostrapp.link, close but no cigar) would obviate the evil centralized websites that curate apps based on arbitrary criteria.

Examples of this kind of app obviously include many kind 1 clients, as well as clients that attempt to bring the benefits of the nostr protocol and network to new use cases - whether long form content, video, image posts, music, emojis, recipes, project management, or any other “content type”.

To drill down into one example, let’s think for a moment about forms. What’s so great about a forms app that is built on nostr? Well,

• There is a spec for forms and responses, which means that…
• Multiple clients can implement the same data format, allowing for credible exit and user choice, even of…
• Other products not focused on forms, which can still view, respond to, or embed forms, and which can send their users via NIP 89 to a client that does…
• Cryptographically sign forms and responses, which means they are self-authenticating and can be sent to…
• Multiple relays, which reduces the amount of trust necessary to be confident results haven’t been deliberately “lost”.

Show me a forms product that does all of those things, and isn’t built on nostr. You can’t, because it doesn’t exist. Meanwhile, there are plenty of image hosts with APIs, streaming services, and bitcoin wallets which have basically the same levels of censorship resistance, interoperability, and network effect as if they weren’t built on nostr.

It supports nostr

Notice I haven’t said anything about whether relays, signers, blossom servers, software libraries, DVMs, and the accumulated addenda of the nostr ecosystem are nostr apps. Well, they are (usually).

This is the category of nostr app that gets none of the credit for doing all of the work. There’s no question that they qualify as beautiful nostrcorns, because their value propositions are entirely meaningless outside of the context of nostr. Who needs a signer if you don’t have a cryptographic identity you need to protect? DVMs are literally impossible to use without relays. How are you going to find the blossom server that will serve a given hash if you don’t know which servers the publishing user has selected to store their content?

In addition to being entirely contextualized by nostr architecture, this type of nostr app is valuable because it does things “the nostr way”. By that I mean that they don’t simply try to replicate existing internet functionality into a nostr context; instead, they create entirely new ways of putting the basic building blocks of the internet back together.

A great example of this is how Nostr Connect, Nostr Wallet Connect, and DVMs all use relays as brokers, which allows service providers to avoid having to accept incoming network connections. This opens up really interesting possibilities all on its own.

So while I might hesitate to call many of these things “apps”, they are certainly “nostr”.

Appendix: it smells like a NINO

So, let’s say you’ve created an app, but when you show it to people they politely smile, nod, and call it a NINO (Nostr In Name Only). What’s a hacker to do? Well, here’s your handy-dandy guide on how to wash that NINO stench off and Become a Nostr.

You app might be a NINO if:

• There’s no NIP for your data format (or you’re abusing NIP 78, 32, etc by inventing a sub-protocol inside an existing event kind)
• There’s a NIP, but no one knows about it because it’s in a text file on your hard drive (or buried in your project’s repository)
• Your NIP imposes an incompatible/centralized/legacy web paradigm onto nostr
• Your NIP relies on trusted third (or first) parties
• There’s only one implementation of your NIP (yours)
• Your core value proposition doesn’t depend on relays, events, or nostr identities
• One or more relay urls are hard-coded into the source code
• Your app depends on a specific relay implementation to work (ahem, relay29)
• You don’t validate event signatures
• You don’t publish events to relays you don’t control
• You don’t read events from relays you don’t control
• You use legacy web services to solve problems, rather than nostr-native solutions
• You use nostr-native solutions, but you’ve hardcoded their pubkeys or URLs into your app
• You don’t use NIP 89 to discover clients and services
• You haven’t published a NIP 89 listing for your app
• You don’t leverage your users’ web of trust for filtering out spam
• You don’t respect your users’ mute lists
• You try to “own” your users’ data

Now let me just re-iterate - it’s ok to be a NINO. We need NINOs, because nostr can’t (and shouldn’t) tackle every problem. You just need to decide whether your app, as a NINO, is actually contributing to the nostr ecosystem, or whether you’re just using buzzwords to whitewash a legacy web software product.

If you’re in the former camp, great! If you’re in the latter, what are you waiting for? Only you can fix your NINO problem. And there are lots of ways to do this, depending on your own unique situation:

• Drop nostr support if it’s not doing anyone any good. If you want to build a normal company and make some money, that’s perfectly fine.
• Build out your nostr integration - start taking advantage of webs of trust, self-authenticating data, event handlers, etc.
• Work around the problem. Think you need a special relay feature for your app to work? Guess again. Consider encryption, AUTH, DVMs, or better data formats.
• Think your idea is a good one? Talk to other devs or open a PR to the nips repo. No one can adopt your NIP if they don’t know about it.
• Keep going. It can sometimes be hard to distinguish a research project from a NINO. New ideas have to be built out before they can be fully appreciated.
• Listen to advice. Nostr developers are friendly and happy to help. If you’re not sure why you’re getting traction, ask!

I sincerely hope this article is useful for all of you out there in NINO land. Maybe this made you feel better about not passing the totally optional nostr app purity test. Or maybe it gave you some actionable next steps towards making a great NINON (Nostr In Not Only Name) app. In either case, GM and PV.