Plebeian Market

Apps25 min readNostr marketplace

Plebeian Market

Plebeian Market is a serious attempt to make open Bitcoin commerce feel ordinary: publish a product as a Nostr event, let people discover it from more than one client, settle in sats and keep the seller's market closer to the seller than to a platform.

The market is the smallest part of the story

The official site greets you with a plain promise: buy and sell stuff with sats, powered by Nostr. That sentence is useful because it is small. It keeps the first mental picture simple. You browse products, you start selling, you price things, you expect payment in Bitcoin. If you only look at that surface, Plebeian Market feels like a Bitcoin-native flea market with cleaner branding.

That storefront logic also changes what you inspect before trusting it. You are not only checking whether the page can display a product. You are checking whether a seller identity survives across relays, whether listing edits are signed by the same key, whether a buyer can understand shipping and payment terms before sending sats, and whether a dispute would leave enough evidence to reason about what happened. Plebeian Market is interesting precisely because it pushes those details into Nostr-shaped records instead of hiding them behind a platform account.

But the interesting part starts one layer lower. Most online marketplaces own the room you trade in. They own the merchant account, the customer relationship, the storefront ranking, the review system, the checkout data and the archive of what happened. You can build a good business there, but you are renting gravity. Plebeian Market is trying to move those market facts into Nostr events: signed listings, seller-owned identity, relays as the place where market state can live, and direct payment paths that do not require the app to custody the money.

That changes what you should ask while reading the page. Do not ask only whether it has pretty product cards. Ask what survives when the website changes. A product listing published as NIP-99 kind 30402 can be understood outside one interface. A collection event can group products without asking a central platform to bless the shelf. A shipping option can become a reusable event. An order message can be encrypted between buyer and seller instead of becoming a public receipt of someone's home address. That is the promise, and it is also the burden. Once you build commerce on open events, every lazy shortcut becomes visible.

Plebeian Market therefore belongs in the App Hub as a marketplace, but that label is too thin. It is closer to a working argument about how peer-to-peer commerce should feel when the shop, the account and the audience are not welded to one company. You still need a usable product. You still need trust. You still need shipping, support and refunds. Nostr does not make those problems vanish. It makes them easier to inspect.

From old Plebeian to the NIP-99 version

The project has a real before-and-after. The older public codebase, PlebeianApp/plebeian-market-old, is archived. GitHub describes it as the old version of a Bitcoin-native self-sovereign marketplace. It was created on 2022-06-02, written mainly in Svelte, licensed GPL-3.0 and still shows a healthy old footprint: 88 stars, 19 forks, topics such as auctions, Bitcoin, ecommerce, Lightning Network, marketplace, Nostr, self-hosted and web5. It was pushed last on 2024-03-30, then the living work moved elsewhere.

The current home for development is PlebeianApp/market. GitHub describes that repo as "The circular economic community builder". At the time of this check, the API showed a TypeScript project created on 2025-03-08, GPL-3.0 licensed, not archived, with topics for Bitcoin, ecash, Lightning and Nostr. It had 8 stars, 7 forks and 118 open issues and pull requests combined; the GitHub web view split that public workload into 93 issues and 25 pull requests. The repo had been pushed on 2026-06-06. That matters more than the star count. This is not a dead listing scraped into a directory. It is a young, noisy, moving app with a lot of open work.

The public story also says why the change matters. A Plebeian Market long-form post rendered through Damus announced that the site had moved fully to NIP-99 and away from legacy NIP-15. The post frames the move as interoperability: stalls and listings should be visible to clients that speak the same standard, instead of being locked into one marketplace interface. NIP-99 itself is marked as a draft optional NIP, but its core idea is straightforward: kind:30402 is an addressable event for classified listings, flexible enough for products, services, work, rentals, free giveaways and other things offered by an author.

This is the key editorial line for Plebeian Market: it is not simply using Nostr because Nostr is fashionable. Its product model depends on one of Nostr's most practical superpowers, addressable events. A seller can publish a listing under their key. The listing can carry title, summary, price, status, location and image metadata. The author key is not a decorative account handle; it is the origin of the listing. The market becomes less like a database row and more like a signed object that other clients can point at.

What actually happens when you sell there

The seller side is where Plebeian Market gets ambitious. The launch coverage from No Bullshit Bitcoin in January 2025 described it as the first instance of the Plebeian app, aimed at goods and services for Bitcoin and Nostr communities. The same report listed the practical seller story: add products, create stalls, sell goods or services for sats, support auctions, customize the design, connect payment methods and dedicate portions of sales to communities. That last part is why the current repo keeps using the phrase circular economic community builder. Plebeian is not only asking, "Can you sell a mug?" It is asking whether the seller can route value back into the people and projects around the sale.

The codebase backs that up. The route tree exposes dashboard paths for products, collections, migration tools, shipping options, sales, messages, app settings, blacklists, featured items, team settings, vanity URLs and payment preferences. That is not a brochure. Those are the surfaces a real merchant needs once the first listing works. You create a product. You group products into collections. You set shipping methods. You manage orders. You receive messages. You handle the less glamorous edges where commerce usually breaks.

The product event starts with NIP-99 kind 30402. Plebeian's own marketplace specification then layers more commerce shape around it. Product collections use kind 30405. Shipping options use kind 30406. Product reviews are sketched as kind 31555, following a trusted-assertion style. Merchant preferences can advertise a payment_preference such as manual | ecash | lud16. The important detail is not the numbers by themselves. The important detail is that each number marks a thing a marketplace normally hides in its private database.

If you sell there, you are not merely filling a product form. You are publishing a small set of market facts that can travel better than a centralized SKU. The product can carry price, images, stock, type, visibility, summary, specifications, location, geohash, tags, collection references and shipping references. Plebeian can render those facts in its own interface, but the stronger idea is that another client can read the same facts and build a different shop window. That is the Nostr move.

The buyer side of the counter

Buyers usually do not care about event kinds. They care whether they can understand what is being sold, choose a shipping method, pay without drama and talk to the seller if something goes wrong. Plebeian's current code is wrestling with exactly that sequence. There is a checkout route, product pages, collection pages, profile pages, search pages, cart components, payment dialogs, order detail components, invoice tracking, private order details, delivery address displays, pickup address displays and tracking information displays.

The order flow is where the app becomes most Nostr-specific. Plebeian's Gamma marketplace document describes order communication through private message flows. The current order code uses kind 16 for order processing. Type 1 is order creation, type 2 is a payment request, type 3 is a status update, and type 4 is a shipping update. Kind 17 is used for payment receipts or proofs. In plain text: kind 16 carries the order conversation, and kind 17 carries payment evidence. That gives the buyer and seller a timeline: order placed, payment requested, payment proved, status changed, shipping updated, delivery completed or cancelled.

Now notice the privacy edge. Commerce needs address data. A marketplace can pretend that is boring until it accidentally publishes it. Plebeian's repo includes a PIIExposureModal that warns about personal information exposure in post-purchase shipping communication, lists events containing PII, offers deletion steps and tells users to resend shipping details through encrypted direct messages. That is a bracingly honest artifact to find in a young app. It tells you two things at once: the team has faced a real privacy class of bug, and the app is building UI around the remedy rather than hiding the problem in release fog.

The private order code goes further. src/lib/orders/privateOrderMessage.ts creates private order details around kind 16, order IDs, product references, shipping references and address fields. Instead of leaving that sensitive data as plain public market noise, it wraps details through the project's NIP-59 helper. That helper uses NIP-44 encryption, seal kind 13 and gift wrap kind 1059. In normal language: the order needs enough structure to be useful, but the buyer's private details should not become free public metadata for every relay and crawler.

Payments, shipping and the V4V idea

Plebeian Market speaks Bitcoin first. The UI code exposes Lightning and on-chain Bitcoin payment methods, with Lightning described as instant and low-fee and on-chain Bitcoin as the blockchain settlement path. The dependency list also tells you where the project is looking: @getalby/lightning-tools, light-bolt11-decoder, @nostr-dev-kit/wallet, @cashu/cashu-ts, coco-cashu-core and coco-cashu-indexeddb all sit in the current package. Cashu is not just a word in a blog post; the libraries are in the stack, even if not every payment path is equally visible to a casual buyer yet.

The app settings and startup scripts show an infrastructure view of payments and media. Startup publishes an app handler event kind 31990, extended settings around kind 30078, a relay list event kind 10002, a ban list kind 10000, and admin/editor role lists kind 30000. Put another way, kind 31990 tells clients what the app handles, kind 30078 stores application-specific settings, kind 10000 carries bans, and kind 30000 carries roles. It also advertises app support for product events, collection events and shipping events. Default settings point at https://blossom.plebeian.market and https://nip96.plebeian.market for media/file handling. The separate Blossom helper lists additional servers, including Primal, Blossom Band and f7z Blossom. A shop cannot sell well if images and files are brittle, so this belongs in the core story.

Shipping deserves its own respect. Many marketplace demos look good because they never ask where the physical object is going. Plebeian's shipping code does ask. Shipping options can carry country, region, service type, carrier, duration, pickup location, geohash, weight and dimension constraints, and price rules. In the UI, a shipping selector loads a seller's shipping events, displays available methods and lets the cart attach a shipping reference to a product. The Damus migration post even warns sellers that migrated products can become view-only if shipping options are missing. That is the kind of mundane sentence that proves the app is touching real commerce.

The V4V layer is the most characterful part of Plebeian. Value-for-value splits let a seller choose recipients and weights for a share of proceeds, using zap-style tags in the project's settings model. The Damus post is careful that this is optional: a seller can keep all sats or route part of the flow back to developers, artists, local communities, schools, farms or people they want to support. That is not necessary for a marketplace to function. It is necessary for Plebeian's deeper identity. The app is trying to make a market feel like a network of people, not only a row of products.

The stack under the counter

The current Plebeian codebase is a modern web app, not a small static experiment. package.json names the project plebeian.market, version 0.1.0, private, module-based and built around Bun. The README says it was created with bun init in Bun v1.2.4. Development runs through bun install, bun dev, bun start, bun run startup and local relay setup with nak serve on ws://localhost:10547. First run can redirect to /setup, and the first user who completes setup becomes administrator unless startup seeding already created defaults.

The front end uses React 19, TanStack React Query, TanStack Router, TanStack Form, TanStack Store and TanStack Table. TanStack Router is configured for file-based routes in src/routes with route tree generation through tsr watch and intent prefetching. The Nostr side uses @nostr-dev-kit/ndk, @nostr-dev-kit/wallet, @nostr-dev-kit/wot, @nostr-dev-kit/blossom and nostr-tools. The UI stack includes Radix primitives, lucide-react, QR scanning, MapLibre GL, Zod and Playwright tests.

Login is not an afterthought. The visible auth components support browser extensions, private key login and bunker URLs for NIP-46 remote signing. The BunkerConnect component validates bunker:// URLs, checks for relay and secret parameters, accepts QR scans and names nsec.app and Amber as examples. That is the right direction for a commerce app. If money, orders and private shipping information are involved, your signing flow cannot be casual. A Nostr marketplace has to help a normal seller do the safer thing without asking them to become a protocol engineer.

The test surface also tells a story. The repo includes Playwright E2E scenarios for auth, app settings, buyer purchase, cart, checkout, collections, marketplace behavior, order lifecycle, order messaging, payments, PII exposure remediation, product pages, products, shipping options, shipping edge cases and V4V product creation. This does not prove the app is finished. It proves the team knows the dangerous paths. In a marketplace, the dangerous paths are not exotic. They are checkout, private data, payment confirmation, inventory, shipping and seller-buyer disagreement.

Who is visible behind it

The cleanest answer is the public project trail: PlebeianApp is the GitHub organization, PlebeianApp/market is the current repo, and the public Nostr-facing identity appears as Plebeian Market. The January 2025 launch coverage says the Plebeian app had been through years of development and pivots before settling on Nostr for this proof of concept. That article says the team thanked Mohammad, Schlaus Kwab, Gzuuus, Zazawowow, BitcoinBekka and Bitko for work on the project, and pointed inquiries toward Chiefmonkey or the project Telegram group. The later Damus migration post is signed by Bekka and the Plebeian Team.

I would not turn that into a founder myth. Public Nostr projects are often fluid: people contribute code, test flows, seed products, write posts, run relays, file issues, design screens, migrate shops and do unpaid support in chat. What we can say with confidence is that Plebeian Market is built by a visible PlebeianApp project group around open GPL-3.0 code, public Nostr posts, GitHub issues and a live site at plebeian.market. That is enough to treat it as a real app. It is not enough to pretend every role is settled forever.

The launch narrative also explains the social target. Plebeian is aimed squarely at Bitcoin and Nostr communities: independent merchants, creators, builders, local producers, service providers and people who want sats to move through communities without a platform tollbooth in the middle. If you are selling mass-market inventory and need conventional buyer protection, card disputes, tax exports and warehouse integrations tomorrow morning, you should read this as early open-commerce infrastructure, not as a Shopify replacement. If you are a Nostr-native maker who wants a shop that speaks your keys, the app is much closer to home.

What can go wrong, and why that matters

The first risk is ordinary marketplace risk: the seller may not ship, the buyer may misunderstand, the package may vanish, the product may be misrepresented, and nobody can make a decentralized protocol behave like a customer support department. Plebeian can structure listings, messages, payments and statuses. It cannot eliminate judgment. For first use, buy something small, check the seller's public reputation, read the shipping option, and prefer a path where communication is clear before money moves.

The second risk is privacy. Nostr events are durable in a way web users often underestimate. If you publish an address in the wrong place, deletion can become messy because relays and mirrors may already have seen it. Plebeian's own PII remediation UI is a reason to take the app seriously and a reason to be careful with it. When a checkout asks for personal details, your question is not only "Does the form submit?" Your question is "Where does this data go, who can read it, and can the seller still fulfill the order without making private data public?"

The third risk is standards drift. NIP-99 is flexible, and flexibility is both the gift and the headache. Plebeian's Gamma marketplace document tries to define richer commerce around collections, shipping, reviews, payment preferences and order flows. Other clients may implement only the simple listing part. That is fine as long as everyone is honest about what interoperability means. A product can appear elsewhere, but a full checkout with shipping, V4V splits and private order state may still work best inside the app that understands Plebeian's richer model.

So how should you read Plebeian before you trust it? Start with the official site, then open the GitHub repo. Check whether recent commits and issues line up with the feature you plan to use. Look at the seller's Nostr identity. Make sure shipping is configured. Use a sane signer, ideally an extension or remote signer instead of pasting a private key into random pages. Treat Lightning, on-chain and any ecash path as different risk shapes. And remember the beautiful part: if Plebeian's model works, the sale is no longer trapped inside a company account. It becomes part of a signed, portable market layer that other Nostr tools can learn to read.

That is why this app earns a long article. It is messy in the way real work is messy. It has old code and new code, launch excitement and migration chores, open issues and ambitious specs, privacy scars and a better privacy direction. Plebeian Market is one of the places where Nostr stops being a timeline and starts becoming economic plumbing. You may not want to run your whole shop on it yet. But if you care about a web where independent people can trade without giving the market itself to a platform, this is a page worth opening slowly.

Sources worth opening

Start here if you want to verify the project trail yourself. The article above leans on public pages, the active codebase, the archived old codebase and the Nostr specifications Plebeian is building around.

• Plebeian Market official site
• NostrApps listing for Plebeian Market
• PlebeianApp/market active GitHub repository
• Plebeian Market README
• Plebeian Market package.json
• Plebeian Market app settings and architecture spec
• Plebeian Market Gamma marketplace spec
• PlebeianApp/plebeian-market-old archived repository
• No Bullshit Bitcoin launch coverage, 24 Jan 2025
• Plebeian Market NIP-99 migration post rendered by Damus
• Stacker News discussion of GPL-3.0 and NIP-99 code release
• NIP-99 classified listings
• NIP-15 marketplace notes for historical context
• NIP-17 private direct messages
• NIP-44 encrypted payloads
• NIP-59 gift wrap
• NIP-57 zaps
• NIP-78 application-specific data
• NIP-89 recommended application handlers
• Plebeian private order message code
• Plebeian NIP-59 helper code
• Plebeian Blossom upload helper
• Plebeian startup script for app settings, roles and relays
• Plebeian product event generator
• Plebeian order event generator
• Plebeian shipping event generator
• Plebeian order flow and shipping process notes