CraysShopstr
Shopstr is not a catalog card with a Bitcoin button pasted on top. It is one of the clearest attempts to make Nostr carry the messy parts of real commerce: listings, seller identity, order messages, wallet flows, reviews, relay choice and the uncomfortable question of who you trust when nobody can freeze the market for you.
Commerce without a platform account
Shopstr starts from a simple frustration: people can talk about Bitcoin all day, but the ordinary act of buying a physical thing from another person still tends to fall back into centralized accounts, frozen balances, seller bans, payment processors and marketplace fees. The live Shopstr landing page now frames the product as a place to sell, get paid in Bitcoin and avoid bans, fees and middlemen. That is a strong claim, but it is also the right doorway into the product. Shopstr is trying to make the store account less important than the keys, events and payment tools underneath it.
Because Shopstr makes the store portable, you should read the product less like a checkout page and more like a public trade workflow. The important questions are whether the listing event is understandable outside the website, whether the seller profile is tied to a stable public key, whether private order messages stay private enough for the goods involved, and whether the chosen payment path gives both sides a useful audit trail. A decentralized market does not remove judgment. It moves judgment closer to the buyer, seller and software they choose.
The important distinction is this: Shopstr is not just a web page at shopstr.market or a marketplace view at shopstr.store. Those are the interfaces. The deeper product is a set of conventions for making a listing, a seller, a message thread, a review and a payment readable outside one company's private database. If you only look at the storefront, it resembles a small online market. If you inspect the code and NIPs, it becomes a test case for whether Nostr can carry real commercial state.
The public story has become more polished since the first launch. A 2023 No Bullshit Bitcoin note described Shopstr as a decentralized classifieds marketplace on Nostr using Lightning and Cashu, then listed the early support set as NIP-04, NIP-07, NIP-09 and NIP-99. The later Devpost profile gives a fuller origin: the idea grew out of wanting a direct Bitcoin commerce app, work at Replit hackathons, calvadev bringing TommySatoshi and eric onboard, and a run through Nostrasia, PlebLab and Sovereign Engineering circles. The current GitHub README is tighter: "A global, permissionless Nostr marketplace for Bitcoin commerce." The product moved from proof-of-concept classifieds to a more complete marketplace stack.
That evolution matters because commerce is not a cute demo category. A photo app can be delightful with a small user base. A marketplace must answer harder questions: who is the seller, what exactly is being sold, what happens if the buyer never receives the item, where does the message live, what does the wallet sign, which relays carry the listing, and whether a review can be checked later by a different client. Shopstr is interesting because it exposes those questions instead of pretending that "decentralized" magically solves them.
The listing is a signed object
The center of Shopstr is the listing event. In the current codebase, the product posting path creates a Nostr event with kind 30402, the kind used by NIP-99 classified listings. That is a big architectural choice. Instead of treating a product as a row that only Shopstr understands, the product becomes a signed object with tags and content that can move through relays. A Nostr-aware client does not need Shopstr's permission to discover or display the event if it understands the convention.
Shopstr also publishes handler metadata around those listings. The helper code creates kind 31990 and 31989 events so other Nostr clients can learn that Shopstr can handle kind 30402 listings and open routes like a marketplace or listing page. That sounds like plumbing, but it is the kind of plumbing that makes app choice real. A buyer can see a listing in one context and open it in another. A seller is not merely uploading into an isolated store; they are signing a piece of commerce data into the Nostr network.
There is another layer: shop profiles. Shopstr uses kind 30019 for seller shop profiles, separate from ordinary profile metadata. That lets a seller have a commercial face with store details rather than trying to cram a shop into a social bio. The database schema in the repo caches profile events, product events and shop profile events, which is a useful reminder that "built on Nostr" does not mean "no implementation infrastructure." The signed event is portable; the hosted app still uses indexing, caching and server routes to make the experience fast enough for humans.
Images and media are part of the same story. The README lists NIP-B7 Blossom Media support, and Umbrel's app listing notes a previous Shopstr update that added Blossom media support for uploads with metadata stripping. This is exactly the kind of detail that separates a real commerce app from a directory entry. Sellers need product images. Images need hosting. Hosting creates privacy, permanence and moderation questions. Shopstr's direction is to keep the marketplace data aligned with open Nostr conventions while giving sellers a usable product creation flow.
Orders move through messages
A marketplace becomes real when somebody tries to buy something. Shopstr's order path is not just a button that says "message seller." The helper code builds structured order messages with fields for amount, payment, status, tracking, carrier, estimated arrival, contact, address, pickup details, items, variants and donation amount. Those are wrapped into Nostr messaging flows rather than stored as ordinary marketplace tickets controlled by a central marketplace operator.
The current implementation leans on NIP-17-style private direct messages with NIP-44 encryption and kind 1059 gift wrapping. The code constructs a message seal, wraps it with a random public key and tags the recipient. This is newer and more careful than the older NIP-04-style encrypted DM story often seen in early Nostr apps. It still does not mean every useful fact disappears. A commerce message can carry shipping and order metadata. The intended recipient should be the only one reading content, but relays, timing, payment rails and application behavior can still leak patterns. Shopstr is better read as privacy-aware, not magically invisible.
The app also caches gift-wrapped message events and tracks failed relay publishes for retry. That is another important detail. In a pure slogan version of Nostr commerce, everything simply goes to relays and works. In a real checkout, failed relay writes matter. If an order message fails to publish, the buyer and seller may disagree about what happened. Shopstr's code acknowledges that by saving and retrying, which improves reliability while also adding another implementation surface to audit.
For a reader, the practical lesson is simple: treat Shopstr messages as order infrastructure, not casual chat. Do not send sensitive shipping or contact data casually. Use a fresh commerce key when appropriate. Read the relay list and understand where messages may be routed. If you are buying something expensive, ask the seller for additional verification outside the bare listing card. Nostr gives you cryptographic identity, but the human identity and fulfillment trail still need work.
The money path
Shopstr's money story has three main pieces: Lightning, Cashu and Nostr Wallet Connect. The live site says buyers pay with Bitcoin through Lightning or Cashu and that the platform does not hold funds. The code backs up the seriousness of that direction: it depends on Cashu tooling, Alby libraries, the Alby SDK and nostr-tools, and it contains payment components for Cashu, NWC and Lightning-style flows.
Cashu is especially important to Shopstr's identity. The Devpost write-up says the team selected Cashu because of its privacy-preserving nature and ease of use, and the current app has a built-in Cashu wallet context, mint handling, proof recovery and token redemption logic. The database schema includes wallet event kinds 7375, 7376, 17375 and 37375, tying the app into the NIP-60 Cashu wallet world. That does not make Cashu risk-free. A Cashu user must care which mint issued the ecash, whether proofs are backed, how recovery works and what happens if a mint fails. Privacy improves in some ways, but trust moves to the mint and wallet implementation.
Nostr Wallet Connect adds a different path. Shopstr uses the Alby SDK's NostrWebLNProvider to talk to a wallet through a NWC string. The appeal is obvious: a buyer can authorize a wallet connection rather than pasting invoices and tokens by hand. The risk is also obvious: NWC permissions, budgets and connection strings are security boundaries. If you connect a wallet to a marketplace, use a wallet setup where a bad or buggy web session cannot drain more than you meant to spend.
Shopstr also has a platform-support mechanism that is easy to miss. The checkout code includes a seller-configurable Shopstr donation rate, with a fallback visible in code. The public site says there are no mandatory platform fees and that sellers can optionally set a donation rate. That is a cleaner model than hidden marketplace take rates, but it still deserves transparency during checkout. A buyer should be able to see what goes to the seller, what goes to any optional support amount, and which payment rail is carrying each piece.
Sellers, storefronts and the operator trail
Shopstr is unusually traceable for a small Nostr commerce project. The README lists authors calvadev, thomasyeung687 and ericspaghetti, each with an npub. The Devpost page names calvadev and describes how TommySatoshi and eric joined. The contact page points people to the official Nostr account @shopstrmarkets and the GitHub repository for issues and feature requests. The Umbrel App Store listing credits calvadev as developer and submitter for the umbrelOS app. This is not a faceless "Nostr marketplace" with no public trail.
The GitHub repository matters more than the marketing. As checked on June 7, 2026, shopstr-eng/shopstr is GPL-3.0 licensed, TypeScript-heavy, created on April 15, 2023, and active with a latest commit on June 6, 2026. GitHub showed 97 stars, 69 forks, open issues and no formal releases. The package metadata shows a modern Next.js app with React 19, Next 16, nostr-tools, Cashu libraries, Alby SDK pieces, Dexie, Postgres, QR code handling, PWA support and testing scripts. That is not proof of safety, but it is enough surface for a serious reader to audit.
The app has also moved toward self-hosting and local deployment. Umbrel lists Shopstr as an app compatible with umbrelOS and says it can be self-hosted, including Tor access for privacy-oriented users. That matters because a Nostr marketplace that can only be accessed through one hosted domain still depends heavily on that domain. Self-hosting does not make scams disappear, but it makes the interface less fragile and gives operators a way to run their own view of the market.
The company language is a little more formal now. The public landing page carries a 2025 Shopstr Markets Inc. footer, while the contact page still emphasizes open-source communication through Nostr and GitHub rather than a central office. The honest read is that Shopstr is both an open-source protocol-facing product and an operated web experience. Those two facts can coexist. The important thing is not to collapse them into a myth. The data model leans Nostr. The user experience still depends on maintainers, domains, code quality, caches, APIs and defaults.
Search, reputation and web-of-trust
Search and trust are the places where marketplace ideology meets product pain. Shopstr can publish listings to relays, but buyers need to find the right listings, filter junk and decide whether a seller is worth paying. The current marketplace UI includes category, location and search filtering. The code also has web-of-trust filtering behavior tied to logged-in users and follow graphs. That is a very Nostr-native idea: instead of assuming a central platform's algorithmic trust score, let your graph influence what looks credible.
Reviews are the other major piece. Shopstr publishes review events with kind 31555 and the README lists NIP-85 Reviews. The product's own terms say the review system helps accountability, while also making clear that Shopstr cannot enforce dispute resolutions or provide refunds. That is the right level of humility. A review can make reputation more portable. It cannot guarantee shipment, authenticate a luxury item, stop a throwaway key from misbehaving or replace escrow for high-value transactions.
There is also reporting. The helper code creates kind 1984 report events for reported users or listings, and the README lists NIP-56 Reporting. In a centralized marketplace, reports can lead to takedowns. In Nostr, reports are signals that clients, relays and users may choose to act on. That is more flexible and more politically honest, but it also means the burden shifts to relay operators, app filters and buyers. If you want a marketplace where a central support desk reverses a scam, Shopstr is not promising that. It is offering a market where the evidence can travel.
For Crays readers, this is the most important product lesson. Shopstr is not just "commerce with sats." It is a live example of reputation becoming a portable layer: seller keys, shop profiles, product events, reviews, reports, relay lists and wallet behavior all become part of the trust picture. That is powerful. It is also cognitively expensive. The app can make the surface easier, but it cannot remove the need to think.
What decentralization does not solve
Shopstr's own Terms of Service are unusually useful reading because they say the quiet part clearly. The platform does not take custody of funds, products or communications and does not act as an intermediary between buyers and sellers. Users choose relays and therefore influence what content they see. Users are responsible for private keys, wallets, seller verification, irreversible transactions and local compliance. Shopstr says it cannot guarantee product quality, reverse blockchain transactions, remove listings from relays or intervene in buyer-seller disputes.
That is not a weakness in the article; it is the reality of the product. Traditional marketplaces are annoying because they can freeze you, take a large fee and demand identification. They are also useful because they can mediate, refund, delist, insure and pressure sellers. Shopstr removes or weakens the middle layer. In exchange, buyers and sellers get more control and more responsibility. If you are selling a low-risk physical item to someone in your Nostr graph, that trade-off can be attractive. If you are buying an expensive item from a fresh key with no external proof, the same trade-off should make you slow down.
Privacy is also more nuanced than the landing page can fully explain. Shopstr's privacy policy says the platform minimizes collection, does not collect KYC or analytics, and stores local keys and preferences in the browser when relevant. It also says Nostr data is distributed across selected relays and that Bitcoin, Lightning and Cashu each have their own privacy models. The codebase, however, contains Postgres-backed caches, API routes and MCP-related scaffolding. That does not automatically contradict the protocol design, but it does mean the hosted implementation should be audited like software, not trusted as a slogan.
The legal edge is equally real. The terms prohibit illegal goods and services, counterfeit items, stolen property and other prohibited listings, while acknowledging that Shopstr may not have the technical ability to prevent every listing from existing on relays. That is the Nostr moderation problem arriving in commerce form. A user, a relay, a client and a jurisdiction may all draw different lines. A marketplace app can provide defaults and reports. It cannot make the whole network behave like a single shop with one policy team.
How to test Shopstr carefully
The best first test is not to buy something expensive. Open Shopstr, browse the marketplace, inspect a few seller profiles, read the listing detail and look for seller history that exists beyond the card. If you are a Nostr user, try to understand which relays are involved and whether the listing appears from another Nostr context that understands NIP-99. A marketplace event that only feels alive inside one interface is less convincing than one you can follow through the network.
If you are a seller, create a low-risk test listing first. Use a dedicated Nostr commerce key or a signer setup you are comfortable exposing to a web commerce workflow. Check whether your shop profile, product images, pricing, shipping details and contact path survive reloads and appear as expected. Then delete or edit the listing and see what actually happens on relays. Event deletion requests exist, but relays may retain data. This is not Shopify with a centralized delete button.
If you are a buyer, test the payment path with a tiny amount. If you use Cashu, know the mint. If you use NWC, set a spending budget and do not connect a wallet with more authority than the purchase requires. If you use Lightning, remember that successful payment does not mean fulfilled order. Ask the seller questions before payment when shipping or product authenticity matters. Save the relevant event IDs, message thread and payment proof in case you need to reconstruct the story later.
If you are evaluating Shopstr for a venue, creator community or FoundUPS-style commerce experiment, read the code paths rather than only the landing page. Look at NIP-99 listings, kind 30019 shop profiles, NIP-17 messages, Cashu wallet support, NWC payment permissions, review events, reporting, relay configuration and the Terms. Then decide whether the risks match the goods being sold. Shopstr is strongest when the buyer and seller benefit from open identity, direct Bitcoin settlement and portable marketplace evidence. It is weakest when the transaction needs formal escrow, regulated compliance or centralized customer support.
The fair verdict is that Shopstr is one of the more substantial Nostr commerce apps because it has a real product, a public codebase, a visible maintainer trail, current development, wallet work and a clear NIP map. The caution is that its ambition lands in the hardest category of all: money between strangers. That is exactly why it belongs in the Crays Nostr Hub. It shows what Nostr can do when the stakes stop being posts and start being goods, orders and sats.
Sources worth opening
Start with the live product, then read the repository and the standards beside it. Shopstr is transparent enough that you can check most claims yourself.
- Shopstr official landing page
- Shopstr live marketplace
- Shopstr about page
- Shopstr contact page
- Shopstr FAQ
- Shopstr Terms of Service
- Shopstr Privacy Policy
- shopstr-eng/shopstr GitHub repository
- Shopstr README and supported NIPs
- Shopstr package metadata
- Shopstr database schema
- Shopstr about page source
- Shopstr terms source
- Shopstr privacy source
- Shopstr Nostr helper functions
- Shopstr sign-in modal
- Shopstr Nostr context provider
- Shopstr cart payment component
- Shopstr marketplace UI source
- Shopstr MCP create-order API
- Shopstr on NostrApps
- Shopstr Devpost project page
- Shopstr on Umbrel App Store
- No Bullshit Bitcoin: Shopstr announcement
- NIP-99 Classified Listings
- NIP-17 Private Direct Messages
- NIP-44 Versioned Encryption
- NIP-47 Nostr Wallet Connect
- NIP-60 Cashu Wallet
- NIP-85 Reviews
- NIP-89 Recommended Application Handlers
- NIP-B7 Blossom Media
- Cashu project site
