#

relay

(52 articles)

Day 5: Monetization & Lightning Native Payments — Where the Sats Actually Flow

# Day 5: Monetization & Lightning Native Payments — Where the Sats Actually Flow Everyone talks about Nostr's protocol. Almost nobody talks about the money flowing through it. That's the real story. I've spent four days mapping how Nostr works: the relay layer, identity, clients, UX gaps. But here's the question that actually matters if you're building a business — where does the revenue come from? The answer is Lightning. Not as a gimmick. As the native payment layer woven into the protocol itself. Nostr is the only social protocol in the world where money moves at the same speed as messages. That's not a feature. That's a moat. Yesterday I dissected the client layer — the apps where users stick or bounce. If you missed it, catch up here: https://iris.to/note1pmdc2g66lhpfp40469aa7083vunf4k2vaucxwnn0f7k2afffzyjqe452wp Today I'm looking at the money. Who's earning. How. And where the gaps are. --- ## The 12-Day Roadmap This article is Day 5 of my deep-dive into Nostr before I place a single business bet. 1. ✅ Protocol Architecture & How It Works 2. ✅ Identity & Verification 3. ✅ Relays & Data Availability 4. ✅ Clients & UX Patterns 5. 🔄 **Monetization & Lightning Native Payments** ← Today 6. NIPs, Tags & Discovery 7. Market Research & Opportunity Mapping 8. Competitive Analysis & Positioning 9. Business Model Selection 10. MVP & First Revenue 11. Automation, Scale & Systems 12. Community, Growth & Iteration --- ## Zaps: The Killer Feature Nobody Else Has A zap is a Lightning payment attached to a Nostr event. That's the whole idea. Someone reads your note, decides it was worth something, and sends you sats — instantly, cheaply, without a platform taking a cut. NIP-57 defines the mechanics. When a zap is paid, the Lightning wallet creates a public Zap Receipt (kind 9735) on the relays. This receipt is immutable. It provides auditable, decentralized proof that value changed hands. On Nostr, your tips are on-chain in the social graph itself. The volume is real. Peak daily zap volume hit **41 million sats** — approximately $9,252 at the time. Individual creators earn thousands of sats per post. Some power users have sent and received hundreds of thousands of sats purely through organic engagement. Compare this to Twitter tips. Or Patreon. Or YouTube's 45% revenue cut. On Nostr, the payment goes from payer to creator in one hop. No platform fee. No withdrawal minimum. No KYC gatekeeping your audience's money. The wallet is the platform. The psychology is different too. A zap is social proof and payment rolled into one. When someone zaps your note, every client that displays it reinforces your credibility. It's not just money — it's reputation capital you can spend. --- ## Commerce on Nostr: Beyond Tips Zaps are attention payments. But Nostr's commerce layer goes deeper. **Shopstr** is the standout. It's a Bitcoin-native marketplace built entirely on Nostr. No accounts. No permissions. Your listings live on relays and cannot be taken down. Buyers pay with Lightning or Cashu. Sellers keep 100% of revenue — no platform fee, no Stripe middleman, no chargeback risk. This is structural disruption. Amazon takes 15%. Etsy takes 6.5% plus listing fees. Shopify charges monthly plus transaction fees. Shopstr charges zero at the protocol layer because there is no platform. Under the hood, commerce events use **NIP-15** (structured marketplace stalls and products) and **NIP-99** (flexible classified listings for goods, services, jobs, rentals). NIP-99 is winning because it's simpler — closer to a long-form content event with price tags attached. The spec is young but functional, and marketplace clients are already building on it. The directory at **nostrmarket.org** tracks the ecosystem. It's still early — mostly Bitcoin-focused products, digital goods, and community services. But the infrastructure is live. The protocol supports it. The only missing ingredient is mass adoption. --- ## Cashu: Private Payments on a Public Protocol Not everyone wants their purchasing history visible on relays. Enter **Cashu**. Cashu is a Chaumian ecash protocol that runs on top of Bitcoin and Lightning. It works by issuing bearer tokens backed by Bitcoin held in Lightning Network mints. You trade sats for tokens. You trade tokens for goods. The mint knows the balance but not who spent what. On Nostr, Cashu enables instant, private micropayments. Users tip without exposing their Lightning node. Buyers purchase without publishing a transaction trail to every relay. Zeus wallet already integrates Cashu, and more clients are adding support. For entrepreneurs, this matters because privacy expands addressable market. Mainstream users don't want their coffee purchases in a public social graph. Cashu gives Nostr commerce the privacy layer it needs to scale beyond the Bitcoin hardcore. --- ## Paid Relays: The Infrastructure Play Here's the uncomfortable math: **95% of Nostr relays cannot cover their operating costs** as of early 2026. That's not sustainable. The solution is paid relay subscriptions via Lightning. Users pay a small monthly fee — some as low as **12,000 sats** — for access to a high-quality relay. In exchange, they get better uptime, faster propagation, spam filtering, and higher storage limits. This creates a proper market. Relay operators compete on price, performance, and policy. Some specialize: archival relays for long-form content, real-time relays for chat, geographic relays for local latency. Others go premium: guaranteed delivery, custom domain hosting, priority support. The OpenSats advancements blog documented a 43% cost reduction in relay hosting through optimization. That trend continues. As costs drop and demand rises, paid relays will become the default for serious users and businesses. The business model here is pure infrastructure: host a relay, charge for access, optimize costs, scale. It's unglamorous until you realize that every Nostr business depends on relays. Being the AWS of relay infrastructure is a massive opportunity. --- ## Streaming + Zaps: The Attention Economy in Real Time **Zap.stream** does something Twitter Spaces and Twitch can't replicate: livestreaming where viewers pay the streamer directly, in real time, without platform cuts. NIP-53 defines the live event structure. Streamers broadcast. Viewers watch and chat. And when someone drops 1,000 sats, it appears instantly in the stream — visible to everyone, verified on the Lightning network, immortalized as a Zap Receipt on the relays. This isn't a tipping jar. It's an attention auction. Viewers compete for the streamer's acknowledgement. The streamer earns while performing. No Super Chat revenue share. No affiliate percentage. Just direct value-for-attention exchange at protocol speed. The market for this is niche today. But the model is proven elsewhere. When Nostr scales beyond 21,000 users, the first successful livestreamers here will have infrastructure advantages that centralized platforms can't match. --- ## Client Monetization: Where the Money Meets the User Clients are where payments happen. And clients need revenue too. **Zap commissions** are the cleanest model. The client takes a small percentage — typically 1-5% — of zaps that route through its interface. It's opt-in, Lightning-native, and aligns incentives perfectly: the client earns when creators earn. **Premium subscriptions** offer advanced features: analytics dashboards showing which posts earned the most sats, scheduled publishing, multi-account management, custom relay configurations. Think "LinkedIn Premium" but denominated in sats. **Embedded wallet interchange.** Clients that integrate Lightning wallets earn fees on every transaction. Alby, Zeus, and Minibits all partner with clients for this. The social app becomes a financial interface. **White-label deployments.** A brand wants a Nostr client with its colors, its relay defaults, its embedded wallet. They'll pay setup plus monthly maintenance. This is already happening in Bitcoin communities and expands to any niche that values censorship-resistant communication. The direction is clear: free core, paid power. The client that cracks monetization without annoying users captures serious value — and right now, nobody has clearly won. --- ## Business Models That Actually Work on Nostr Today After five days of research, here's my shortlist of monetization categories with real traction: | Model | Status | Barrier | |---|---|---| | **Zap-powered content** | Live and scaling | Audience building | | **Marketplace selling** | Functional, early | Product-market fit | | **Paid relay hosting** | Growing rapidly | Infrastructure cost | | **Livestream tipping** | Niche but proven | User acquisition | | **Premium client features** | Early experiments | UX design | | **Cashu private payments** | Technical, growing | Wallet integration | | **White-label clients** | B2B inbound exists | Engineering capacity | | **Commerce tooling/plugins** | Underserved | NIP-99 maturity | The common thread: every model is Lightning-native, peer-to-peer, and protocol-level. There are no ad networks. No platform fees. No middlemen. The money flows from user to user, and the protocol makes it possible. --- ## What This Means for You If you're building on Nostr, the monetization layer is both easier and harder than Web2. Easier because the payment rails are built in. You don't need Stripe. You don't need a merchant account. You don't need to integrate a third-party tipping widget. Lightning is the protocol. Your keys are your wallet. Your content is your storefront. Harder because there is no platform to bootstrap you. No algorithm to surface your content. No ad network to buy reach. You earn exactly what the network values you at, in real time, in public. That requires either genuine value creation or genuine community building. There are no shortcuts. The businesses that will win are the ones that own the full stack: content + audience + payments + delivery. On Nostr, that's not a platform play. It's a protocol-native operation where every layer reinforces the others. Day 6 will cover NIPs, Tags & Discovery — the mechanics of how content gets found in a protocol with no central index. Because monetization is meaningless if nobody sees your work. --- Want to explore ways to make money on Nostr and watch the execution live? Follow me and come on the journey 👇 #nostr #buildinginpublic #learnnostr #monetization #lightning #bitcoin #zaps #commerce #cashu #venturex #payments #startup #relay

Day 3: Relays & Data Availability — The Real Estate of Nostr

# Day 3: Relays & Data Availability — The Real Estate of Nostr Yesterday I broke down identity and verification on Nostr—why your keypair is your passport, how NIP-05 gives you a human-readable name, and why zaps are the only reputation signal that matters in a world without follower counts. If you missed it, catch up here: https://iris.to/note12gprtp97wy7ypqns84sds0nm9dmwxr26ya9axpatgnas904y7lvqln4m3w Today I want to talk about the layer nobody sees but everyone depends on: **relays**. Because on Nostr, data availability is your problem. Not the protocol's. Not a support desk's. Yours. And if you're serious about building a business here, that matters more than any client feature. --- ## The 12-Day Roadmap This article is Day 3 of my deep-dive into Nostr before I place a single business bet. 1. ✅ Protocol Architecture & How It Works 2. ✅ Identity & Verification 3. 🔄 **Relays & Data Availability** ← Today 4. Clients & UX Patterns 5. Monetization & Lightning Native Payments 6. NIPs, Tags & Discovery 7. Market Research & Opportunity Mapping 8. Competitive Analysis & Positioning 9. Business Model Selection 10. MVP & First Revenue 11. Automation, Scale & Systems 12. Community, Growth & Iteration --- ## What Relays Actually Are Forget everything you know about servers. Nostr relays are intentionally dumb. They accept events. They store them. They forward them to anyone who asks. That's it. No algorithm. No ranking. No shadowbanning. No content moderation at the protocol level. A relay doesn't care if you're a bot, a brand, or a billion-dollar fund. If the signature is valid and the relay's policy allows it, the event gets stored. That simplicity is Nostr's superpower—and its weakness. Because relays don't talk to each other. There is no "Nostr cloud" that guarantees your post exists everywhere. Your event only lives on the relays you publish to and the relays your readers follow. If those relays go offline, your history vanishes. Not deleted by a moderator. Just... gone. Data availability is your infrastructure decision. Treat it like rent. Because it is. --- ## How Relays Work: The Outbox and Gossip Models Right now, most clients ask a handful of hardcoded relays for everything. That's fine when Nostr is small. But it doesn't scale—and it centralizes load on the same free relays that are already struggling. Enter the **Outbox Model** (formerly called the Gossip Model), proposed by Mike Dilger. Here's the idea in one sentence: your client publishes your relay preferences to the network, and other clients check those preferences before they look for your content. That metadata lives in a **NIP-65** event—a replaceable list of relays you read from and write to. When someone wants your posts, their client doesn't spam every relay on the planet. It goes to the ones you said matter. The result? You can run a tiny relay for yourself and still be found. You don't need to park your data on a megarelay run by strangers. You just need to tell the network where you live. That changes the economics. If people actually use NIP-65, relay power fragments. Small, specialized relays become viable. And that creates room for businesses. --- ## Free Relays Are Drowning Let me give you numbers, not hype. According to data from early 2024, **20% of Nostr relays are down more than 40% of the time**. Bandwidth costs are killing hobby operators. **95% of free relays cannot cover their costs.** This isn't a temporary problem. This is structural. Running a relay means storage, bandwidth, CPU, and DDoS protection. Someone has to pay for it. And goodwill doesn't scale. Meanwhile, users over-replicate like crazy because they're scared of losing data. **Half of all posts on Nostr end up on 14 or more relays. A quarter land on 49 or more.** That's not redundancy. That's chaos. And it makes the cost problem worse, because every redundant copy chews more bandwidth. One-time payment models for relays have already failed. Relay costs are recurring—storage grows, bandwidth is monthly, attacks don't schedule appointments. If the business model doesn't match the cost curve, the relay dies. So free relays aren't free. They're subsidized by volunteers who will eventually stop. If your business depends on them, you're building on quicksand. --- ## The Rise of Paid Relays The fix is obvious: pay for the pipe. Paid relay models are emerging fast. Here are the ones I'm tracking: **Lightning-native subscriptions.** The Nostream relay implementation has plug-and-play Lightning support. Users pay a monthly fee in sats. Content gets published. Spam disappears because it costs money to post. **Pay-per-note models.** Some relays charge a small Lightning fee for every event. Cheap enough for humans, expensive enough to drown bots. **Nosflare and serverless relays.** This one excites me. Nosflare deploys a Nostr relay on Cloudflare's edge network. No server maintenance. Global distribution. One-time setup fee of 21,420 sats and practically zero ongoing overhead. Relay hosting costs have already dropped—from roughly 21,000 sats per month to around 12,000 sats per month—thanks to efficiency improvements funded by the ecosystem. That's real progress. But it's still a bill. And bills need revenue models. Paid relays aren't just a backup plan. They're a business model with three entry points: operator, aggregator, and tooling. --- ## Where the Money Lives: Relay Opportunities I don't write these articles for fun. I write them to find edges. Here are the relay-layer opportunities I'm cataloguing. **1. Niche paid relays** Think "relay for Brazilian Bitcoiners" or "relay for AI agent traffic only." Small communities with shared interests will pay for a well-moderated, high-uptime relay that serves their content fast. Generalist relays compete on price. Specialist relays compete on trust. **2. Relay-as-a-Service** Creators, brands, and startups don't want to run infrastructure. They want a white-label relay with their domain, their rules, and a dashboard. Charge a monthly subscription in sats or fiat. Handle uptime, backups, and scaling for them. **3. Discovery and indexing relays** Not every relay needs to store everything. A discovery relay could index events across the network and serve query results without holding the full firehose. It's the search engine layer Nostr doesn't have yet. Build it before everyone else does. **4. Nosflare deployment services** Most people can't click through Cloudflare Workers and D1 setup. Deploy Nosflare instances for clients, charge a setup fee, and upsell monitoring. Infrastructure consulting is boring until it prints sats. **5. Relay health and redundancy tools** If data availability is the user's problem, sell them the solution. A service that monitors your relays, warns you before they go dark, and auto-replicates your events to backups? That's insurance. People pay for insurance. --- ## What This Means for You If you're building on Nostr, you need a relay strategy. Not a relay preference. A strategy. That means: - Keep a NIP-65 list updated so people can find you. - Diversify across at least one reliable free relay, one paid relay, and (if you're serious) a relay you control. - Budget for it. Relays are digital real estate. Location matters. - Watch the Outbox Model adoption. When clients fully support it, the relay market fragments. Fragmentation creates niches. Niches are where small businesses win. Nostr is still a frontier town. The roads aren't paved. The maps aren't drawn. But the people selling picks and shovels to the miners usually do better than the miners. Relays are the picks and shovels. --- ## Building in Public I'm not keeping a notebook under my desk. Every insight, failure, and bet gets shared here on Nostr in real time. If you want to see how this roadmap turns into actual revenue, the journey is public. Day 4 will cover Clients & UX Patterns—how users actually experience Nostr, where the friction lives, and what that means for anyone building a product here. --- Want to explore ways to make money on Nostr and watch the execution live? Follow me and come on the journey 👇 #nostr #buildinginpublic #learnnostr #ai #entrepreneurship #n8n #bitcoin #lightning #startup #venturex #relay #dataavailability

Run Your Own Nostr Relay on Your Android Phone

You don't need a server. You don't need to pay for hosting. Your Android phone is enough to run a personal Nostr relay, accessible from anywhere, over Tor, for free. This guide covers: 1. Installing apps via **Zap Store** 2. Setting up **Citrine** as your relay 3. Exposing it over Tor with **Orbot** 4. Connecting from desktop browsers using **Tor + FoxyProxy** --- ## Step 1: Get Zap Store [Zap Store](https://zapstore.dev) is a Nostr-native app store. Apps are published by their creators directly on Nostr, so you can follow the developer, see their other work, and zap them to support development, all without ads or shady monetization. Discovery can take some getting used to, but there are genuinely useful apps there that you won't find pushed by algorithm or paid placement. If someone you follow builds an app, you can find it on Zap Store and follow their work directly. Install Zap Store first. We'll use it to install the other apps in this guide. --- ## Step 2: Install and Configure Citrine **Citrine** is a Nostr relay that runs locally on your Android phone. It's made by the same developer as **Amber** (the popular Nostr signer app), which is a good trust signal. Install it from Zap Store (or Play Store). Once installed, you have a few options for how permissive your relay is: ### Option A: Personal relay only Only store events from your pubkey or events that mention you. Your relay stays small and relevant to you only. Good default for most people. ### Option B: Open relay with auto-cleanup Allow anyone to publish events to your relay, but run automatic cleanup so old events get deleted. You can configure it to never delete your own events while cleaning up everything else. ### Option C: No filtering Accept and keep everything. Generous, but be aware: your relay is open to spam and your storage will fill up over time. Pick what fits your use case. After configuring, Citrine will start listening on a local port (default: `4869`). Note this port number — you'll need it in the next step. --- ## Step 3: Expose Your Relay Over Tor with Orbot Your relay is running, but it's only accessible locally on your phone. To reach it from other devices and networks, you'll use **Orbot** to create a Tor hidden service (`.onion` address). Install Orbot from Zap Store or Play Store. ### Create a hidden service 1. Open Orbot 2. Go to settings and find **Hidden Services** (or "Tor Hidden Services") 3. Add a new hidden service pointed at the port Citrine is using (e.g. `4869`) 4. Orbot will generate a `.onion` address. Save this, it's your relay address ### Whitelist Citrine in Orbot In Orbot's app list, enable Tor **only for Citrine**. This routes Citrine's traffic through Tor but leaves all your other apps unaffected. ### Set Orbot as Always-On VPN Go to **Android Settings → Network → VPN**, find Orbot, and enable **Always-on VPN**. This makes Orbot start automatically when your phone boots, keeping your relay reachable without manual intervention. > Do not enable the "Block connections without VPN" / kill switch option. Since > only Citrine is whitelisted, enabling it would cut internet access for all > your other apps. Your relay is now live. The `.onion` address works over mobile data, Wi-Fi, any network, no port forwarding, no static IP needed. --- ## Step 4: Add Your Relay to Your Nostr Clients Your `.onion` relay address looks like: `ws://youraddress.onion` Add it to your relay list in your Nostr client. Most mobile Nostr apps (Yakihonne, Amethyst, etc.) have built-in Tor support and will connect to `.onion` relays automatically once you add the address. --- ## Step 5: Connect from Desktop Most mobile apps work out of the box, but desktop browsers can't resolve `.onion` addresses natively. Fix this with Tor + FoxyProxy. ### Install Tor You need Tor running locally. Install it however you prefer. On macOS and Linux, Homebrew is the easiest way: ```bash brew install tor brew services start tor ``` Homebrew itself can be installed from [brew.sh](https://brew.sh). Once running, Tor listens on `localhost:9050` (SOCKS5). ### Install FoxyProxy Install the **FoxyProxy** extension for Firefox or Chromium-based browsers. ### Configure FoxyProxy 1. Click the FoxyProxy icon → **Options** 2. Go to **Proxies** → **Add** 3. Fill in: - **Title:** Onion Resolver (or anything you like) - **Type:** SOCKS5 - **Hostname:** `127.0.0.1` - **Port:** `9050` 4. Scroll down to **Proxy by Patterns** → **Add Pattern** - **Title:** onion - **Pattern:** `*.onion` 5. Save 6. Back in FoxyProxy popup, switch mode to **Proxy by Patterns** Now your browser will route only `.onion` addresses through Tor, leaving all normal traffic unchanged. The goal here is connectivity, not anonymity. You're just making `.onion` addresses resolvable. Open your web-based Nostr client (e.g. Yakihonne web, Primal) and add your relay. It will connect. --- ## You're Done You now have a personal Nostr relay running on your phone, reachable from anywhere in the world. No server, no fees, no central point of failure. Your data lives on your device.

Data Model for a Neo4j Nostr Relay

# Background Nostr: Notes and Other Stuff Transmitted by Relays \[1] is an open source protocol for censorship-resistant social media. Users maintain public key - private key pairs and use the Schnorr signature standard for digital signatures and encodings. Content is stored in objects called *events* (a.k.a. *notes*) which are signed and broadcast to *relays* which act as the backend servers for Nostr. Relays transmit events with users, with clients, and with each other via websockets following the protocol specified in NIP-01 (Nostr Implementation Possibility-01: Basic Protocol) \[2]. Most Nostr relays store events using relational databases or key-value databases such as LMDB. However, as of Nov 2025, no native graph database nostr relays have been built. This is unfortunate, given the performance advantages of native graph databases in social graph analysis. This prompts us at NosFabrica to construct a fully NIP-01 compliant, native graph database nostr relay based on neo4j. This document provides an overview of a proposed *data model* \[3] for a *neo4j nostr relay*. The primary function of this data model is to provide support for NIP-01. However, it also provides support for Follow Lists (NIP-02), Mute Lists (NIP-51), Reports (NIP-56), Replies (NIP-10), Reactions (NIP-25), Reposts (NIP-18), Comments (NIP-22), and Trusted Assertions (NIP-85) \[4]. # Data Model ## Node labels * NostrUser, NostrEvent, NostrEventTag, NostrRelay (NIP-01) * NostrUserWotMetricsCard (NIP-85: Trusted Assertions)) ## Relationship types * AUTHORS, HAS\_TAG, REFERENCES, SUGGESTED\_RELAY (NIP-01) * FOLLOWS (NIP-02), MUTES (NIP-51), REPORTS (NIP-56) * IS\_A\_REPLY\_TO (NIP-10) * IS\_A\_REACTION\_TO (NIP-25) * IS\_A\_REPOST\_OF (NIP-18) * IS\_A\_COMMENT\_ON (NIP-22) ## Properties See graph below. ## Graph ![](https://i.nostr.build/sbVvsTTjFKAt6anB.png) ## Cypher Cypher code for the above graph. CREATE (:NostrUser)<-\[:FOLLOWS {timestamp: ""}]-(n11:NostrUser {pubkey: ""})-\[:AUTHORS]->(:NostrEvent {id: "\<id>", kind: "\<kind>", sig: "\<sig>", content: "\<content>", created\_at: "\<unix\_time>"})-\[:HAS\_TAG]->(n4:NostrEventTag {tag\_name: "\<p, e, a, d, ...>", tag\_value: "\<pubkey, id, naddr, etc>", relay\_url: "\<url>", `<other_optional_keys>`: ""})-\[:REFERENCES]->(:NostrEvent)-\[:SUGGESTED\_RELAY]->(:NostrRelay {url: "\<url>"}), (:NostrUser)<-\[:REPORTS {timestamp: "", report\_type: ""}]-(n11)-\[:MUTES {timestamp: ""}]->(:NostrUser), (n11)-\[:WOT\_METRICS\_CARD]->(:NostrUserWotMetricsCard {customer\_id: "", hops: "", influence: "", average: "", input: "", confidence: "", personalizedPageRank: "", verifiedFollowerCount: "", verifiedMuterCount: "", verifiedReporterCount: "", followerInput: "", muterInput: "", reporterInput: ""}), (:NostrEvent {kind: 1})-\[:IS\_A\_REPLY\_TO {marker: "\<reply vs root>"}]->(:NostrEvent {kind: 1}), (:NostrEvent {kind: 7})-\[:IS\_A\_REACTION\_TO]->(:NostrEvent), (:NostrEvent {kind: 6})-\[:IS\_A\_REPOST\_OF]->(:NostrEvent {kind: 1}), (:NostrEvent {kind: 16})-\[:IS\_A\_REPOST\_OF]->(:NostrEvent), (:NostrEvent {kind: 1111})-\[:IS\_A\_COMMENT\_ON]->(:NostrEvent), (n4)-\[:REFERENCES]->(:NostrUser) ## Data Volume Statistics from [nostr.band](http://nostr.band) \[5] indicate: * \~ 15 thousand daily users * \~ 1.2 million profiles with a bio and contact list * \~ 300 thousand users in the extended Follows network * \~ 25 thousand daily updates of contact lists (kind 3 events) * \~ 500 thousand new events published per day * \~ 600 million total events published as of Nov 2025 ## References \[1] <https://github.com/nostr-protocol/nostr> \[2] <https://github.com/nostr-protocol/nips/blob/master/01.md> \[3]  <https://neo4j.com/docs/getting-started/data-modeling/tutorial-data-modeling/> \[4] <https://nostrhub.io/naddr1qvzqqqrcvypzq3svyhng9ld8sv44950j957j9vchdktj7cxumsep9mvvjthc2pjuqyt8wumn8ghj7un9d3shjtnswf5k6ctv9ehx2aqqzf68yatnw3jkgttpwdek2un5d9hkuuctys9zn> \[5] <https://stats.nostr.band>

PPQ Deep Research Report: The Nostr Ecosystem and Future Disruptions

## Table of Contents 1. [Introduction](#introduction) 2. [Overview of the Nostr Ecosystem](#overview) 3. [Current Use Cases and Quantitative Metrics](#use-cases) - [User Adoption Metrics](#user-adoption) - [Network Resilience and Decentralization](#network-resilience) 4. [Operational Challenges and Scalability](#challenges) - [Replication Overhead and Bandwidth Issues](#replication-overhead) - [Relay Downtime and Financial Sustainability](#relay-downtime) 5. [Market Disruption and Sentiment](#disruption) - [Disrupting Twitter and Centralized Social Platforms](#twitter-disruption) - [Impact on Decentralized Social Media and Censorship Resistance](#decentralized-social-media) 6. [Future Trends and 5-Year Outlook](#future-outlook) - [Innovative Protocol Developments](#protocol-innovations) - [Quantitative Forecasting and Diffusion Modeling](#forecasting) - [Networking and Integration with Emerging Technologies](#networking-integration) 7. [Conclusions and Strategic Recommendations](#conclusions) --- ## 1. Introduction <a name="introduction"></a> The Nostr ecosystem has emerged as a powerful decentralized alternative to traditional social media networks, particularly as a potential disruptor of Twitter and other centralized—and even existing decentralized—social media platforms. Developed using a protocol based on cryptographic key pairs and a multi-relay system, Nostr is unique in its provision of censorship resistance and user sovereignty. In this report, we provide a detailed analysis of the current state, scalability challenges, and market disruption potential of Nostr, followed by speculative insights on its trajectory over the next five years. --- ## 2. Overview of the Nostr Ecosystem <a name="overview"></a> Launched in 2022, Nostr (Notes and Other Stuff Transmitted by Relays) has rapidly gained traction as an open and decentralized social network. Some of the core features include: - **Decentralized Communication:** Relying on independent relays across multiple countries and autonomous systems, Nostr offers an architecture that ensures posts are not stored on a single centralized server. - **Censorship Resistance:** With cryptographic authentication and a decentralized relay structure, content censorship becomes significantly more difficult than in traditional networks. - **User Sovereignty:** Empowering users with cryptographic key pairs allows for enhanced privacy and data ownership. - **Wide Geographic Distribution:** The ecosystem spreads over 44 countries and 151 autonomous systems, underscoring its global reach. Notable endorsements from figures such as Jack Dorsey, Edward Snowden, Vitalik Buterin, and Sen. Cynthia Lummis have bolstered its reputation as an experimental yet promising alternative to centralized social platforms. --- ## 3. Current Use Cases and Quantitative Metrics <a name="use-cases"></a> ### User Adoption Metrics <a name="user-adoption"></a> - **User Base:** In just two years, the Nostr network has attracted over 4 million users, a significant figure given its nascent stage and decentralized nature. - **Content Generation:** With over 60 million posts, the volume of content mirrors the rapid adoption and active usage seen in more centralized models. - **Post Replication:** Empirical measurements indicate that there are 17.8 million text notes among these posts, replicated on an average of 34.6 relays per post. This level of replication underlines robust resilience and availability even if significant portions of the network experience downtime. ### Network Resilience and Decentralization <a name="network-resilience"></a> - **Global Distribution:** Nostr’s decentralized network ensures high availability with >90% post accessibility even under simulated network failures (e.g., removal of key relays or autonomous systems). - **Robustness:** The dispersion across 712 relays illustrates that decentralization is not only a design choice but also a working reality, which contributes to the network’s reliability. --- ## 4. Operational Challenges and Scalability <a name="challenges"></a> While the Nostr ecosystem demonstrates significant promise, it faces noteworthy operational challenges. ### Replication Overhead and Bandwidth Issues <a name="replication-overhead"></a> - **Excessive Redundancy:** Detailed studies have shown that nearly 98.2% of retrieval traffic is redundant. In practice, this equates to an estimated 144 TiB of unnecessary bandwidth consumption. - **Optimization Proposals:** To mitigate these inefficiencies, there's a proposal to limit post replications from 34.6 relays to between 10 and 20 relays per post. This could reduce redundant data copies by between 380 million to 480 million instances, potentially lowering operational costs and improving bandwidth utilization. - **Scaling Concerns:** With a projected network load of 10 million events per day (or approximately 2 TB annually), the throughput requirement of ~115 TPS is putting a strain on the current architecture. This has led to debates on whether solutions like the current outbox mechanism are sufficient or if further fundamental redesigns and emergent moderation systems are needed. ### Relay Downtime and Financial Sustainability <a name="relay-downtime"></a> - **Relay Stability:** Data indicates roughly 20% of relays suffer from significant downtime (exceeding 40% operational time), and 132 relays have been classified as 'dead'. This is a concern for maintaining network integrity. - **Economic Model Challenges:** With 95% of free-to-use relays unable to cover operational costs due to minimal zap-based income, there is an urgent need for innovative monetization or community funding models to ensure long-term sustainability. --- ## 5. Market Disruption and Sentiment <a name="disruption"></a> Nostr is positioned as both a disruptor to traditional centralized social platforms—most notably Twitter—and a catalyst for change within decentralized social media. ### Disrupting Twitter and Centralized Platforms <a name="twitter-disruption"></a> - **User Shift:** While Twitter remains the most well-known platform, the high-profile endorsements and robust user base of Nostr indicate that there is both market intrigue and a gradual shift among early adopters. Disruption here is measured not only in user numbers but also in the paradigm shift towards decentralized content distribution. - **Market Penetration:** Current metrics (4 million users, 60 million posts) suggest that Nostr is challenging Twitter's centralized model insofar as it appeals to users prioritizing censorship resistance, data sovereignty, and resiliency against centralized failures. However, mainstream adoption on par with Twitter is still not realized, and there remains a gap in user experience and feature richness. ### Impact on Decentralized Social Media and Censorship Resistance <a name="decentralized-social-media"></a> - **Complementary Integrations:** As decentralized social media ecosystems continue to mature, integration between Nostr and other censorship-resistant platforms is increasingly likely. This can include interoperability protocols, shared identity management systems, and cross-platform content replication. - **Comparative Advantage:** Nostr's network design offers unique advantages over other decentralized social media, particularly in its straightforward, relay-based communication protocol. This positions Nostr to potentially serve as an underpinning technology for a broader decoherent ecosystem of social networks. - **Sentiment Toward Scalability Innovations:** Discussions around scaling Nostr often focus on the balance between ensuring redundancy (for resilience) and reducing overhead (for efficiency). The sentiment is one of cautious optimism: while outbox solutions offer a stopgap, many experts advocate for more fundamental architectural redesigns in the long-term. --- ## 6. Future Trends and 5-Year Outlook <a name="future-outlook"></a> Looking forward, the evolution of Nostr will likely be shaped by several interrelated trends and emerging technical innovations. ### Innovative Protocol Developments <a name="protocol-innovations"></a> - **Decentralized Identity and Reputation Mechanisms:** The next phase may see the introduction of distributed reputation systems and rating mechanisms that aid in spam management and improve trustworthiness without compromising decentralization. - **Optimistic Replication and Selective Mirroring:** Innovations such as selective content mirroring and event pruning will be key in managing bandwidth and storage demands while remaining true to the decentralized philosophy. ### Quantitative Forecasting and Diffusion Modeling <a name="forecasting"></a> - **Forecast Models:** By integrating modified Bass diffusion models and learning curve effects, predictions suggest that Nostr can potentially spur significant market disruption within five years. Recent studies indicate that forecasting models in disruptive technology fields have reached accuracies of up to 82% for demand projections. - **Hybrid Quantitative Techniques:** Leveraging methods like LDA2Vec and patent citation network analysis, combined with multi-criteria decision-making models (as seen in extended UTAUT approaches), will be crucial for accurately estimating future adoption and cost efficiencies. - **Metrics to Monitor:** Future research should focus on user growth rates, relay uptime percentages, cost reductions achieved through replication optimizations, and overall sentiment analysis using advanced deep learning architectures that overcome traditional pitfalls (e.g., sarcasm and multipolarity in text data). ### Networking and Integration with Emerging Technologies <a name="networking-integration"></a> - **Integration with Other Decentralized Platforms:** One promising avenue is exploring cross-platform interoperability with other decentralized and blockchain-based social networks, which could lead to a more cohesive ecosystem. This would not only enhance user experience but also enable shared security and moderation frameworks. - **Next-Generation Relays:** The deployment of relays that are more resilient through redundancy optimization and financial sustainability models (perhaps incorporating micro-transaction revenue models or community-driven funding) is another critical area. Such improvements could mitigate the issues of relay downtime and excessive network overhead. - **Contrarian Approaches:** A contrarian perspective suggests that instead of building on current frameworks, a radical overhaul of the network architecture might be considered, potentially by leveraging novel distributed ledger technologies or leveraging a hybrid centralized-decentralized model during the transition phase to ensure smoother scaling. --- ## 7. Conclusions and Strategic Recommendations <a name="conclusions"></a> The Nostr ecosystem represents a significant stride toward decentralized, censorship-resistant social media. While its current market adoption and technical design offer a robust alternative to centralized platforms like Twitter, several challenges must be addressed for sustained growth and disruption: 1. **Optimization of Data Replication:** Reducing redundant data transfers without compromising resilience is essential. Limiting the replication factor and exploring optimistic retrieval mechanisms could provide a balance between availability and efficiency. 2. **Relay Stability and Sustainability:** With nearly 20% of relays experiencing significant downtime, innovative financial and technical models (such as micro-payments and community funding) should be deployed to enhance the operational reliability of network nodes. 3. **Enhanced Moderation and Reputation Systems:** Emerging strategies for decentralized content moderation and reputation management could reduce spam and improve content quality while preserving the open nature of the network. 4. **Interoperability with Other Decentralized Platforms:** Fostering integration with other emerging systems could accelerate market disruption across the broader spectrum of social media. 5. **Future-Proofing Through Quantitative Forecasting:** Continual adoption of cutting-edge forecasting models and machine learning techniques to measure sentiment and track network metrics is imperative for proactive evolution. 6. **Exploring Contrarian Innovations:** In addition to incremental changes, it is important not to discount radically new architectures that may emerge from ongoing research in distributed systems and blockchain technologies. ### Final Outlook In the coming five years, Nostr has the potential to disrupt not only Twitter but also the broader landscape of both centralized and decentralized social media. Although the current architecture presents significant scaling challenges, proactive investments in replication optimization, relay stability, and cross-platform integration will likely propel the network into a more mature phase of adoption. The ecosystem will benefit from a dual approach that combines both evolutionary improvements and revolutionary changes, ensuring that it remains robust while meeting the demands of a growing, globally distributed user base. --- ## Appendices ### Appendix A: Data and Metrics Summary - **User Base:** ~4 million - **Post Volume:** >60 million posts - **Average Relay Replication:** ~34.6 replicas per post - **Geographical Distribution:** 44 countries, 151 autonomous systems - **Bandwidth Waste:** ~144 TiB due to redundancy - **Network Load:** 10 million events/day (~2TB/year) - **Throughput Requirement:** ~115 TPS ### Appendix B: Key Technical Proposals - **Replication Control:** Limit copies to 10–20 relays for optimal efficiency. - **Selective Mirroring:** Implement event pruning and selective content mirroring. - **Decentralized Reputation Systems:** Develop distributed rating mechanisms to enhance distributed moderation. ### Appendix C: Forecasting and Quantitative Methods - **Diffusion Modeling:** Modified Bass models with multi-market dynamics. - **Hybrid Quantitative Techniques:** Integration of machine learning (CNN-LSTM, LDA2Vec) with multi‐criteria decision models. --- ## Recommendations for Further Research - Investigate the comparative performance of alternative replication strategies in decentralized networks. - Explore funding models that can sustain relay operations without compromising neutrality or decentralization. - Conduct long-term sentiment analysis using advanced neural architectures to understand evolving user attitudes. - Evaluate the prospective benefits of radical design overhauls versus incremental enhancements in ensuring network scalability. --- *This report is intended for expert analysts and researchers in decentralized network systems and social media disruption. It synthesizes current empirical findings with speculative insights to inform future strategies and academic inquiry.* ## Sources - https://www.voltage.cloud/blog/exploring-6-use-cases-of-nostr-beyond-messaging - https://arxiv.org/abs/2402.05709 - https://arxiv.org/html/2402.05709v1 - https://papers.ssrn.com/sol3/Delivery.cfm/5146515.pdf?abstractid=5146515&mirid=1 - https://matchnode.com/blog-and-podcasts/mastering-paid-social-media-advertising-a-comprehensive-guide/ - https://blockworks.co/news/jack-dorsey-app-to-disrupt-twitter - https://www.securities.io/nostr-a-better-twitter/ - https://medium.com/@jasminedevv/battle-of-the-decentralized-twitter-alternatives-c9f51114614a - https://www.murrayrudd.pro/nostrs-relay-revolution-scaling-decentralized-networks-for-growth/ - https://github.com/nostr-protocol/nips/issues/75 - https://news.ycombinator.com/item?id=42758579 - https://www.toptal.com/deep-learning/4-sentiment-analysis-accuracy-traps - https://www.researchgate.net/publication/3076742_Forecasting_the_Market_Diffusion_of_Disruptive_and_Discontinuous_Innovation - https://www.globenewswire.com/news-release/2025/03/17/3043701/0/en/United-States-Online-Household-Furniture-Market-Report-2025-2029-Analysis-of-Price-Sensitivity-Lifecycle-Customer-Purchase-Basket-Adoption-Rates-and-Purchase-Criteria.html - https://northeast.newschannelnebraska.com/story/52583550/laser-welding-market-growth-industrial-adoption-rate - https://www.sciencedirect.com/science/article/am/pii/S2405896323014453 - https://www.marketsandmarkets.com/Market-Reports/industry-5-market-35376359.html

Onion Service Nostr Clients list

This is a list of nostr clients exposed as onion services. The list is currently actively maintained on [GitHub](https://github.com/0xtrr/onion-service-nostr-clients). Contributions are always appreciated! | Client name | Onion URL | Source code URL | Admin | Description | | --- | --- | --- | --- | --- | | Snort | http://agzj5a4be3kgp6yurijk4q7pm2yh4a5nphdg4zozk365yirf7ahuctyd.onion | https://git.v0l.io/Kieran/snort | [operator](nostr:nprofile1qyvhwumn8ghj7un9d3shjtnndehhyapwwdhkx6tpdshszxnhwden5te0wpuhyctdd9jzuenfv96x5ctx9e3k7mf0qqsx8lnrrrw9skpulctgzruxm5y7rzlaw64tcf9qpqww9pt0xvzsfmg9umdvr) | N/A | | moStard | http://sifbugd5nwdq77plmidkug4y57zuqwqio3zlyreizrhejhp6bohfwkad.onion/ | https://github.com/rafael-xmr/nostrudel/tree/mostard | [operator](nostr:nprofile1qyv8wumn8ghj7un9d3shjtnddaehgctjvshx7un89uq36amnwvaz7tmzdaehgu3wvf5hgcm0d9h8g7r0ddhjucm0d5hsqgy8wvyzw6l9pn5m47n7tcm5un7t7h5ctx3pjx8nfwh06qq8g6max5zadtyx) | minimalist monero friendly nostrudel fork | | Nostrudel | http://oxtrnmb4wsb77rmk64q3jfr55fo33luwmsyaoovicyhzgrulleiojsad.onion/ | https://github.com/hzrd149/nostrudel | [operator](nostrnpub1ktt8phjnkfmfrsxrgqpztdjuxk3x6psf80xyray0l3c7pyrln49qhkyhz0) | Runs latest tagged docker image | | Nostrudel Next | http://oxtrnnumsflm7hmvb3xqphed2eqpbrt4seflgmdsjnpgc3ejd6iycuyd.onion/ | https://github.com/hzrd149/nostrudel | [operator](nostr:npub1ktt8phjnkfmfrsxrgqpztdjuxk3x6psf80xyray0l3c7pyrln49qhkyhz0) | Runs latest "next" tagged docker image | | Nsite | http://q457mvdt5smqj726m4lsqxxdyx7r3v7gufzt46zbkop6mkghpnr7z3qd.onion/ | https://github.com/hzrd149/nsite-ts | [operator](nostr:nprofile1qqszv6q4uryjzr06xfxxew34wwc5hmjfmfpqn229d72gfegsdn2q3fgpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsxx2q3a) | Runs nsite. You can read more about nsite [here](https://github.com/lez/nsite). | | Shopstr | http://6fkdn756yryd5wurkq7ifnexupnfwj6sotbtby2xhj5baythl4cyf2id.onion/ | https://github.com/shopstr-eng/shopstr-hidden-service | [operator](nostr:nprofile1qqsdxm5qs0a8kdk6aejxew9nlx074g7cnedrjeggws0sq03p4s9khmqpz9mhxue69uhkummnw3ezuamfdejj7qgwwaehxw309ahx7uewd3hkctcpzemhxue69uhksctkv4hzucmpd3mxztnyv4mz747p6g5) | Runs the latest `serverless` branch build of Shopstr. |