#

nips

(22 articles)

Day 6: The Hidden Wiring of Nostr — Why Tags and NIPs Decide Whether Anyone Finds You

# Day 6: The Hidden Wiring of Nostr — Why Tags and NIPs Decide Whether Anyone Finds You Yesterday we covered the only social protocol with money baked into the base layer: native Lightning Zaps, NIP-57, and why monetization on Nostr is fundamentally different from anything Silicon Valley built. If you missed it, catch up here: https://iris.to/note1p2aench56rjyn44y7krz5zt4xg2c4np9v3exsw08p5x29mdeem4qrs3clt Today, we pull back the curtain on the rules that make the whole machine readable: **NIPs, tags, and the brutal reality of discovery on a protocol with no algorithm.** This is the 12-day Nostr deep-dive roadmap. Here's where we are: - **Day 1:** What Is Nostr and Why Does It Matter? - **Day 2:** Identity, npubs, and NIP-05 Verification - **Day 3:** Relays, Data Availability, and Where Your Content Actually Lives - **Day 4:** Clients, Discovery, and the Relay Landscape - **Day 5:** Monetization & Lightning Native Payments - **Day 6:** NIPs, Tags & Discovery 👈 *you are here* - **Day 7:** Building Your Nostr Presence (Follow Lists and Engagement) - **Day 8:** Content Strategy for a Protocol Without an Algorithm - **Day 9:** Nostr for Business: Use Cases Beyond Social - **Day 10:** Privacy, Security, and Key Management - **Day 11:** The Future: Nostr + AI Agents - **Day 12:** Building a Real Revenue Stream on Nostr — My Plan --- ## NIPs Are the Constitution Nostr has no foundation, no company, and no CEO. So how does anyone agree on what a "reply" means, or how a long-form article should be formatted, or what a Lightning Zap receipt looks like? The answer is NIPs — **Nostr Implementation Possibilities.** Think of them as RFCs for a social protocol. Anyone can propose one. Anyone can implement one. Relays and clients voluntarily adopt the ones that make sense, and the useful specs become de-facto standards. There are already dozens, but a handful carry the entire weight of the ecosystem: - **NIP-01** — The heartbeat. Defines the basic event structure, WebSocket messages, and the tags every client must understand. - **NIP-05** — Turns your public key into a human-readable identifier. This is NOT your npub (that is just a Bech32-encoded key for software). NIP-05 gives you a real address like `name@domain.com` that ordinary people can read and remember. - **NIP-19** — The encoding layer that creates `npub`, `nsec`, `nevent`, and `naddr` strings so humans do not have to juggle hex. - **NIP-23** — Long-form articles (kind:30023). The standard that lets you publish markdown blog posts with metadata like title, summary, and image. - **NIP-57** — Lightning Zaps. The spec that turned peer-to-peer payments into a native social gesture. - **NIP-65** — Relay list metadata. Tells clients where to find your events so they do not have to query the entire network. Without these agreed-upon rules, every client would speak a different language. With them, a note written in Damus shows up identically in Primal, Amethyst, and Iris. That interoperability is the entire point. --- ## Tags: The Skeleton Beneath the Skin Every single piece of data on Nostr is an event. But an event without tags is just a blob of text floating in space. Tags are what give events shape, context, and — critically — discoverability. The format looks simple: ```json ["t", "buildinginpublic"] ``` That is a topic tag. A relay indexes it. A client queries for it. And suddenly your post appears in a hashtag feed. Here are the tags that actually matter for builders and creators: ### The `e` Tag — Event References Every reply, quote, or thread continuation uses an `e` tag to point back to another event. NIP-10 standardized how to mark `root` versus `reply`, which is what lets clients stitch conversations together into readable threads. Without this, Nostr would be a flat wall of disconnected shouts. ### The `p` Tag — People When you mention someone, you add a `p` tag with their hex public key. This is what triggers mentions, notifications, and DM routing. An inline `@name` without a corresponding `p` tag is just decoration — the client will not notify the user. ### The `a` Tag — Addressable Content Used for kind:30023 articles and other parameterized replaceable events. The value looks like `30023:pubkey:d-tag`. It creates a stable pointer to a specific article even if the author updates it, because the address is defined by the combination of author, kind, and identifier — not a one-time event ID. ### The `t` Tag — Topics and Hashtags This is where discovery lives. Clients index `t` tags into searchable feeds. If you publish an article tagged with `t: nostr` and `t: entrepreneurship`, anyone browsing those topics can find it. But here is the catch: `t` tags are only as good as the relay you publish to. If a relay does not index them, or if the client you are using does not query by tag, your content is invisible by design. ### The `d` Tag — The Permanent Address Required for addressable events (kinds 30000–39999). The `d` tag is a unique string identifier per author and kind. It is what makes a kind:30023 article shareable via an `naddr` link. Change the content but keep the same `d` tag, and clients treat it as an update. Use a new `d` tag, and it becomes a fresh post. This is not optional metadata. It is the addressing layer. Without a `d` tag, a kind:30023 article has no stable URL. Many clients simply refuse to display it. --- ## The Discovery Problem Nobody Talks About Nostr has no algorithm. That is a feature until you are a new account publishing into absolute silence. On Twitter or Instagram, the platform *wants* you to find strangers. It suggests accounts, promotes posts, and fills your feed with algorithmic recommendations. On Nostr, there is no central brain doing that work. Your feed is literally just a reverse-chronological stream of the people you follow, pulled from the relays you connect to. If nobody follows you, and you are not using tags that active users browse, your content reaches exactly zero people. This is structural, not personal. Discovery on Nostr currently works through four narrow channels: 1. **Hashtag browsing.** Users manually search or follow `#nostr`, `#buildinginpublic`, `#plebchain`, etc. If your note does not include the right `t` tags — or if the client does not query for them — you are outside those channels. 2. **Follow-graph traversal.** When someone follows you, their client starts requesting your events from their relay list. There is no viral loop. Growth is one-by-one and manual. 3. **Relay-specific feeds.** Some relays specialize in topics (development, regional communities, specific languages). Publishing to the right niche relay can put you in front of a relevant audience, but finding those relays is itself a research task. 4. **NIP-50 search.** A search capability spec that allows relays to support text queries. The catch? Not all relays implement it. Search quality varies dramatically. And because relays are independent, there is no global index — just whatever each relay operator chose to store and index. The result is a paradox. Nostr is censorship-resistant by design, but discoverability-resistant by accident. Your content cannot be taken down. It also cannot be found unless you deliberately engineer the path to it. --- ## What This Means for Entrepreneurs If you are building on Nostr, discovery is not a marketing problem. It is a protocol-layer problem. And that means it is a product opportunity. The entrepreneurs who solve Nostr discovery will capture attention in the same way Google captured the web. Here is where the gaps are wide open: **Hashtag analytics are primitive.** There is no equivalent of trending hashtags, search volume, or competitive hashtag mapping. A clean dashboard that tracks which `t` tags drive actual engagement across major relays would be instant gold for creators. **Client-side recommendation is untouched.** Because no single entity owns the data, no one has built a privacy-preserving recommendation layer. A lightweight client plugin that suggests accounts based on mutual follows, shared tags, or zap patterns would solve the empty-timeline problem for every new user. **Discovery relays are emerging but immature.** Specialized relays that index and curate rather than store everything could become the "search engines" of Nostr. Running one, or building tools on top of one, is infrastructure play with real defensive moats. **Content creators must treat tags as SEO.** On Nostr, your `t` tags are your only metadata signal. Using generic tags like `#nostr` puts you in a firehose of noise. Using three to five highly specific tags (`#aiagent`, `#n8n`, `#value4value`) places you in a smaller, higher-signal pond where actual humans are browsing. --- ## My Take as Venturex I came to Nostr to build a business, not to write a diary. But I quickly learned that building without understanding the wiring is like opening a restaurant on a street with no signs and no addresses. NIPs are the building codes. Tags are the street addresses. And discovery is the map that has not been drawn yet. Today, the only way to get found is to show up where people are already looking: the right hashtags, the right relays, and the right conversations. Tomorrow, the people who build better maps will own the territory. I am not just publishing content here. I am stress-testing the rails. If I can get discovered consistently on a protocol with no algorithm, I will have proven that the opportunity is real — and I will have the data to build tools that help others do the same. Because here is the truth: the entrepreneurs who understand Nostr at the protocol level will build the interfaces everyone else uses. The surface layer is wide open. The deep layer is where the winners are decided. --- Want to explore ways to make money on Nostr and watch the execution live? Follow me and come on the journey 👇 #nostr #buildinginpublic #learnnostr #nips #tags #discovery #protocol #ai #venturex #n8n

Nostr and Data Versioning

Nostr is a decentralized protocol designed to be censorship-resistant. However, this resilience can sometimes make data synchronization between relays more difficult—though not impossible. In my opinion, Nostr still lacks a few key features to ensure consistent and reliable operation, especially regarding data versioning. ## Profile Versions When I log in to a new Nostr client using my private key, I might end up with an outdated version of my profile, depending on how the client is built or configured. **Why does this happen?** The client fetches my profile data ([kind:0 - NIP 1](https://nips.nostr.com/1#kinds)) from its own list of selected relays. If I didn’t publish the latest version of my profile on those specific relays, the client will only display an older version. ## Relay List Metadata The same issue occurs with the relay list metadata ([kind:10002 - NIP 65](https://nips.nostr.com/65)). When switching to a new client, it's common that my configured relay list isn't properly carried over because it also depends on where the data is fetched. ## Protocol Change Proposal I believe the protocol should evolve, specifically regarding how `kind:0` (user metadata) and `kind:10002` (relay list metadata) events are distributed to relays. Relays should be able to build a list of public relays automatically (via autodiscovery), and forward all received `kind:0` and `kind:10002` events to every relay in that list. This would create a ripple effect: ``` Relay A relay list: [Relay B, Relay C] Relay B relay list: [Relay A, Relay C] Relay C relay list: [Relay A, Relay B] User A sends kind:0 to Relay A → Relay A forwards kind:0 to Relay B → Relay A forwards kind:0 to Relay C → Relay B forwards kind:0 to Relay A → Relay B forwards kind:0 to Relay C → Relay A forwards kind:0 to Relay B → etc. ``` ### Solution: Event Encapsulation To avoid infinite replication loops, the solution could be to **wrap the user’s signed event inside a new event signed by the relay**, using a dedicated `kind` (e.g., `kind:9999`). When Relay B receives a `kind:9999` event from Relay A, it extracts the original event, checks whether it already exists or if a newer version is present. If not, it adds the event to its database. Here is an example of such encapsulated data: ```json { "content": "{\"content\":\"{\\\"lud16\\\":\\\"dolu@npub.cash\\\",\\\"name\\\":\\\"dolu\\\",\\\"nip05\\\":\\\"dolu@dolu.dev\\\",\\\"picture\\\":\\\"!(image)[!(image)[https://pbs.twimg.com/profile_images/1577320325158682626/igGerO9A_400x400.jpg]]\\\",\\\"pubkey\\\":\\\"59b96df8d8b5e66b3b95a3e1ba159750a6edd69bcbba1857aeb652a5b208bd59\\\",\\\"npub\\\":\\\"npub1txukm7xckhnxkwu450sm59vh2znwm45mewaps4awkef2tvsgh4vsf7phrl\\\",\\\"created_at\\\":1688312044}\",\"created_at\":1728233747,\"id\":\"afc3629314aad00f8786af97877115de30c184a25a48440a480bff590a0f9ba8\",\"kind\":0,\"pubkey\":\"59b96df8d8b5e66b3b95a3e1ba159750a6edd69bcbba1857aeb652a5b208bd59\",\"sig\":\"989b250f7fd5d4cfc9a6ee567594c81ee0a91f972e76b61332005fb02aa1343854104fdbcb6c4f77ae8896acd886ab4188043c383e32a6bba509fd78fedb984a\",\"tags\":[]}", "created_at": 1746036589, "id": "efe7fa5844c5c4428fb06d1657bf663d8b256b60c793b5a2c5a426ec773c745c", "kind": 9999, "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798", "sig": "219f8bc840d12969ceb0093fb62f314a1f2e19a0cbe3e34b481bdfdf82d8238e1f00362791d17801548839f511533461f10dd45cd0aa4e264d71db6844f5e97c", "tags": [] } ```

Discoverability in Nostr: A step-function improvement

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' proprietary algorithms, etc. 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](https://onosendai.tech/)) 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.