00 — Overview: The Soapbox Stack Operator Manual

One manual answering: can TresPies/DojoGenesis run community ops, company ops, funding, client sites, and publishing on the Soapbox.pub / Nostr stack — and where do we build?

About this manual (build-in-public)

Built and maintained by TresPies Design / DojoGenesis. Researched and written via orchestrated AI agent waves — recon agents → adversarial kill-passes → writer agents → human-operator direction — not a single pass, and not one model.

• Provenance: every chapter carries its own Verified/Amended dates and per-claim confidence tiers; a public correction-log discipline means errors found in our own working documents get logged, not hidden.
• Platform-agnostic by design: nothing here assumes a specific agent or model lane — bring Claude Code, Cursor, Windsurf, OpenCode, DojoGenesis Gateway, or a plain terminal.
• How to adapt: fork the reading order, keep the protocol chapters as reference, swap the worked-example specifics (a firm's niche, a team's hooks) for your own.
• Canonical home: nostr.trespies.dev/manual · agent-readable faces at /manual/llms.txt and /manual/index.json (per-chapter sha256).

Verified: 2026-07-09. Research: 8 parallel agents (chapters 01–06, 08–09), each primary-sourced with numbered citations. Synthesis (this file + ch. 07): main thread, per the amended orchestrator gate (operator-ratified 2026-07-09). One mid-flight adjudication is recorded honestly: Armada was first verdicted nonexistent, then found at the repo level, verified, and corrected (ch. 02) — the product is 26 days old and simply unindexed. Delta pass 2026-07-10 (ch. 05 + ch. 10): NostrHub velocity 866 commits/29 days; no bounty/contest program exists anywhere in the 60-post blog index; new MCP/agent-surface addendum — the "acting NostrHub MCP server" niche is verified empty; ⚠ nostrdeploy.com is DNS-dead (Stacks deploy lane tripwired, affects ch. 04's route too); Stacks 1.0 = the generic template platform, MKStack = one published stack on it.

The four original questions

The stack at a glance

Full portfolio (45+ products incl. Toybox experiments): master map in ch. 01.

Verdicts in brief

How to read this manual

• Operator quick path: this page → 07 — Integration Playbook (runbooks + a worked-example integration blueprint).
• Builder path (v2, added 2026-07-10): 11 — Nostrify → 12 — Building Consumer Apps → 06 — Foundations as reference → 15 — Production before anything ships. Relay decisions: 13; shipping channels: 14.
• Product deep-dives: 01 (company) · 02 (Ditto+Armada) · 03 (Agora) · 04 (Shakespeare) · 05 (NostrHub) · 10 (MKStack — the framework layer and agent contract).
• Protocol layer: 06 — Nostr Foundations — read §1 (keys) before touching your credentials; master NIP table at the end.
• Steering direction (build phase): 08 — i18n → 09 — Visualization → 07 §9 blueprint.

Chapter index

v2 wave (2026-07-10): chapters 11–15 added under the consumer-app builder lens; chapters 01/04/06/10 amended (see each chapter's Amended line). Gap analysis and production audit: maintainers' companion notes (not part of this public chapter set).

v2.1 editorial pass (2026-07-10): generalized for public, platform-agnostic readers; provenance section added.

Source of truth: this repository's notes/manual/ directory, mirrored to the maintainers' internal workspace (internal: OTH-24 manual v1, OTH-25 v2 + hosting, PIP-94 build).

Soapbox.pub — Company Dossier

A grant-and-donation-funded, AGPL-copyleft software studio building the Nostr protocol's social, fundraising, and AI-website-builder layer — founded by Truth Social's former head of engineering.

Verified: 2026-07-09 · Amended: 2026-07-10 (v2 wave) — added the plural AI-team-members section (Dirk Rost, Quilly, Sheila, producer-role culture, cross-ref ch. 12); reclassified HRF funding from recurring grantor to prize/event partner and flagged OpenSats' BTC-denominated treasury as a second-order risk; added a bus-factor finding to Durability & Risk, cross-ref ch. 15.

Confidence: High for company facts, funding sources, licenses, and product inventory (primary-sourced, cross-checked against GitLab/GitHub). Medium for team headcount and exact grant dollar amounts (not publicly itemized). Low for the durability of any single "Toybox" experiment (many are days-to-weeks old with zero external stars).

What Soapbox Is

Soapbox describes itself as an open-source studio building "tools for Freedom Online" — decentralized, ad-free, non-custodial software with no VC and no shareholders [1]. Its ethics pledge states the stakes plainly:

"We would rather shut down than compromise our principles for profit." [3]

That is not rhetorical flourish — it is the operating thesis an operator has to underwrite before building on this stack. Everything below tests whether the thesis is currently backed by cash, commits, and people.

History Timeline

Soapbox has gone through three distinct eras: a Fediverse-frontend company (2019–2022), a Nostr-infrastructure company funded by its founder's Truth Social exit (2023–2024), and — starting mid-2025 — an AI/"vibe-coding" studio. The throughline is Alex Gleason, who founded Soapbox in 2019 as a Mastodon-frontend fork, was hired by Trump Media & Technology Group in January 2022 to adapt that frontend for Truth Social, served as TMTG's Head of Engineering through mid-2023, then resigned to build on Nostr full-time the same month OpenSats funded him to do it [5][6][23].

Confidence: High — dates are primary-sourced from the company's own blog index and GitLab activity timestamps.

Team & Funding

Soapbox is not a solo-founder shop. Its /about page lists 11 named humans plus Gleason (founder/BDFL) across engineering, DevRel, product, and "VibeOps," plus an AI persona ("Quilly 🪶") credited as a team member [15] — see AI Team Members, below, for the fuller and still-growing picture. It has no revenue product: transparency copy states flatly, "We make no income from our users or apps. No ads. No data sales. No venture capital. No shareholders" [4]. It survives entirely on grants and donations, fiscally sponsored by And Other Stuff (AOS) while pursuing 501(c)(3) status, with OpenSats as its one demonstrated recurring grant source [4][23]. (Corrected 2026-07-10 — this line previously also named Human Rights Foundation as a second grant source; see the Funding correction note below the diagram.)

This is not a dormant arrangement. Soapbox's own Open Collective ledger shows an AOS-disbursed W2 payroll run for Software Engineer / DevRel / Marketing roles ($25,977.35) and a conference-travel line for bitcoin++ Nairobi ($6,794.02), both dated July 2026 — the same month this dossier was written [21]. OpenSats has funded Soapbox continuously since its first grant in Q3 2023, with 9 consecutive quarterly public reports through April 2026 and no visible funding gap [4][23][30].

Funding correction (2026-07-10): a same-day audit checked HRF's own 2026 Bitcoin Development Fund grant rounds — 20+ projects per round, names like Snort, Coracle, Zapstore, and Elsat recur — and found no round naming Soapbox, Ditto, or Agora [33]. Soapbox's actual HRF touchpoints are prize/event partner, not grantor: Agora's 25M-sat win at HRF's "AI Hack for Freedom" hackathon (Jan 2026) and the Oslo Freedom Forum as Agora's public-launch venue (Jun 2026). OpenSats continuity is grantee-self-reported — 9 consecutive quarterly transparency reports through April 2026, with no grantor-side (OpenSats-published) 2026 confirmation independently found [4][30]. Net: one demonstrated funding line, self-reported, not the two-funder diversification the diagram previously implied. New second-order risk: OpenSats' own treasury is BTC-denominated, so a Bitcoin bear market mechanically shrinks its USD disbursement capacity — a risk layer beneath ordinary grant-renewal risk. This corrects the diagram above and the "funder concentration" bullet in Durability & Risk, below; it does not change the "alive-and-shipping" verdict (same-day commits and cleared payroll are unaffected facts).

Confidence: High for funding sources and current-month payroll evidence (primary, dated). Medium for total headcount — the payroll line names only 3 roles, so how many of the 12 listed team members are W2 vs. volunteer/contributor is not reconciled in public data.

AI Team Members — Plural and Evolving

At least three named AI personas do Soapbox's own work, each announced separately, with no roster page tying them together [31][32][24] — verify currency before citing any single one as the example:

• Dirk Rost — code review and merge-request approval across Soapbox's projects, giving the team what its own post calls a "bird's-eye view" (cross-project oversight, not one-repo scope): "He runs on open-source infra with a personality defined in plain markdown anyone can read" [31]. The stated payoff is velocity — "so quality scales as fast as we ship" [31].
• Quilly 🪶 — docs, community, and GitLab housekeeping (blog posts, team-page updates, asset management); self-described as "the newest member of Team Soapbox" [32]. Announced late January 2026 — though the post's own byline (Jan 2025) and visible date (Jan 2026) disagree, a small currency flag worth resolving before citing the date hard.
• Sheila — took over Soapbox's own bookkeeping starting 2026-03-06 (History Timeline, above) [24].

"Newest member," in Quilly's own post, implies the roster keeps growing — treat any single AI-team name-check, including this one, as a snapshot that can go stale within months.

This is also where Soapbox's build culture surfaces directly: a "producer role" — a human prompting, directing, and reviewing AI-generated work rather than hand-writing it — runs through both how Soapbox builds itself (the three names above) and how it expects app builders to work this stack. Inferred, synthesis-level: the practical workflow ladder is Shakespeare for ideation → a local agent session (e.g. OpenCode) for deep work → cloning MKStack directly once the app's shape is known. Ch. 12 (new) covers this ladder and the full 19-skill curriculum; treat the ladder itself as this manual's synthesis of the tooling, not a single Soapbox-published claim.

Master Portfolio Map

This table covers every Soapbox product and tool found across soapbox.pub, GitLab, and GitHub — including the 17-item "Toybox" experiments line, which is a real, distinctly-named page (soapbox.pub/toybox), separate from the developer-facing "Toolbox" (soapbox.pub/toolbox) [7][27]. License cells marked "confirmed" were verified by fetching the repo's actual LICENSE file or GitHub license badge; everything else is unverified and should not be assumed.

Confidence: High for status/dates (GitLab activity timestamps are live data). Medium-Low for license on unverified rows — treat as unknown, not as AGPL by default.

Licenses & Ethics Commitments

The verified license pattern is a two-tier copyleft strategy: consumer-facing applications are AGPL-3.0 (network copyleft — if you run a modified version as a service, you must publish your changes), while the underlying framework is MIT (permissive — free to embed without triggering disclosure) [9][11][13][14][16][22]:

The Ethics Pledge commits to: 100% open source for anything public-facing, never selling/trading user data, refusing backdoors or "unjust takedown compliance," and refusing acquisition by anyone who doesn't share the ethics [3]. The November 2025 "Really Open AI" post extends this to AI specifically, defining open AI as open code + open training data + open weights + open access, explicitly invoking the Open Source Initiative's Open Source AI Definition and the FSF's "Four Essential Freedoms" [12].

Confidence: High on the licenses actually checked; Medium on the ethics pledge's enforceability (it is a public commitment, not a legal instrument).

Durability & Risk Assessment for an Operator

Signals of life: same-day GitLab commits across ~10 repos, a 6-year unbroken blog cadence (101 posts, June 2020–July 2026), 3 continuous years of OpenSats funding, and payroll that cleared this month [2][4][8][21]. This is a live, shipping company, not a grant-funded zombie.

Structural risks for an operator building on this stack:

• No recurring revenue anywhere. 100% dependent on grant renewal + donor goodwill; OpenSats grants are typically annual, not perpetual [4][23].
• Funder concentration is actually funder singularity — corrected 2026-07-10. OpenSats is the only demonstrated, self-reported recurring grant line; HRF is a prize/event partner (Agora hackathon win + Oslo launch venue), not a second grantor — the "OpenSats + HRF diversification" framing this bullet previously carried does not hold (see Funding correction, above). One-line dependency reads as more fragile than two, not less; compounding factor: OpenSats' own treasury is BTC-denominated, so its USD disbursement capacity is exposed to Bitcoin price independent of grant-renewal risk [4][20][31][33].
• BDFL governance — Gleason is founder, "BDFL," and the person the Truth Social/Ditto origin story centers on; the "we'd rather shut down than compromise" ethic is principled but explicitly not built for business continuity at all costs [3][6].
• Extreme product sprawl — 45+ named products/experiments, many with zero stars and undocumented purpose (Birdblast, Monorail, Tile Studio) — classic sign of a studio prioritizing breadth over hardening any one surface [8].
• AGPL-3.0 is a real constraint, not just a badge — if you fork and modify Ditto/Shakespeare/Agora/Armada and run the modified version as a network service for clients, you must publish your changes. Using Nostrify or MKStack as a library/scaffold to build separate, independently-licensed client work (as Divine has done) does not carry the same obligation [9][11][22][29].
• Bus-factor is concentrated, measured 2026-07-10 via repo APIs. Gleason authorship: Nostrify 85.2%, mkstack 71.9%, ditto-relay 99.3%, Ditto 47.4%. Ditto is the only repo in the portfolio with real secondary maintainers (Danidfra, marykatefain, derekross) — Nostrify, the framework every other product on this stack compiles against, is 85% one person [34]. See ch. 15 (new) for the per-component exit playbook this feeds.

Fork survivability if Soapbox disappears tomorrow, by tier:

• High — Ditto, Shakespeare: both are explicitly architected for self-host/local-first operation (not an afterthought), AGPL-licensed with real external forks already existing (Ditto: 14 forks) [16][17][9].
• Medium — Agora, Nostrify, MKStack: non-custodial/library-first design survives structurally, but thinner fork/community depth today.
• Low — Armada and anything in Toybox: weeks-old, near-zero external stars/forks; a solo fork today would likely mean you as sole maintainer.

Confidence: Medium — this section synthesizes verified facts into forward-looking judgment; treat the risk framing as informed inference, not fact.

The "Armada" Note

Armada is real, current, and not vaporware: GitLab shows the repo created 2026-06-13 and already at 484 commits, 46 releases, 62 tags by 2026-07-09 — roughly 18 commits/day sustained for 26 days, with commits recorded the same day this was written [18]. It's an end-to-end-encrypted, serverless community-chat app pitched as "Discord without the company," built on a new protocol called Concord plus a NIP-29 relay-based fallback for self-hosters, with a companion self-host backend (armada-relay) and at least one plugin (openclaw-armada) already shipping [14]. It sits on the homepage under "Community Platforms" next to Treasures, Blobbi, and Bookstr [1]. Velocity this high, this early, suggests Armada is Soapbox's current top internal priority — a separate chapter of this manual covers it in depth.

Open Questions

• Exact OpenSats grant dollar amounts — never itemized publicly; only narrative quarterly reports [4][30]. (HRF's Agora hackathon prize is a stated figure — 25M sats, Jan 2026 — but that's a one-time prize to the Agora team, not a Soapbox operating grant; see the Funding correction under Team & Funding, above.)
• MKStack's specific license — two fetch attempts were blocked/unrendered; inferred permissive from third-party ecosystem use (Divine ships its own separate license), not confirmed [28][29].
• Rebased's specific license — not independently verified this session (GitHub org page showed the field blank) [22].
• Whether Soapbox has completed 501(c)(3) conversion or is still solely AOS-fiscally-sponsored as of today [4].
• Reconciling "12 team members listed" against "3 W2 payroll roles disbursed" — volunteer/contributor vs. employee split is unclear [15][21].
• Current Mostr Bridge user count — the only hard figure found was "10k+ unique users, 70% Nostr→Fediverse direction," dated late 2023; no fresher public number was located [26].
• Exact nature/status of several zero-description GitLab repos (Birdblast, Monorail, Tile Studio, NostrHub v1) [8].

Sources

1. soapbox.pub — accessed 2026-07-09 — homepage: mission, product list, ethics summary.
2. soapbox.pub/blog — accessed 2026-07-09 — full 101-post chronological index, June 2020–July 2026.
3. soapbox.pub/ethics — accessed 2026-07-09 — Ethics Pledge verbatim commitments.
4. soapbox.pub/transparency — accessed 2026-07-09 — funding model, funders, quarterly report index (fetched twice for report titles/dates).
5. alexgleason.me/work — surfaced via search 2026-07-09 — Gleason's own work history page.
6. PRNewswire — Truth Social Head of Engineering Leaves for Jack-Dorsey-Backed Alternative, Nostr — accessed 2026-07-09 — Gleason/TMTG/Nostr pivot.
7. soapbox.pub/toolbox — accessed 2026-07-09 — full developer-tools inventory (11 items).
8. gitlab.com/api/v4/groups/soapbox-pub/projects — accessed 2026-07-09 — live repo list with last-activity timestamps, stars.
9. soapbox.pub/ditto — accessed 2026-07-09 — Ditto product page: license, hosting model.
10. soapbox.pub/agora — accessed 2026-07-09 — Agora product page: non-custodial claim, WLC quote.
11. soapbox.pub/shakespeare — accessed 2026-07-09 — Shakespeare product page: AI providers, license, hosting.
12. soapbox.pub/blog/our-stance-on-ai — accessed 2026-07-09 — "Really Open AI" ethics stance.
13. gitlab.com/soapbox-pub/agora LICENSE — accessed 2026-07-09 — AGPL-3.0 confirmed.
14. gitlab.com/soapbox-pub/armada README — accessed 2026-07-09 — Armada/Concord protocol description.
15. soapbox.pub/about — accessed 2026-07-09 — full team roster and mission pillars.
16. github.com/soapbox-pub/ditto — accessed 2026-07-09 — stars, forks, license, tech stack.
17. github.com/soapbox-pub/shakespeare — accessed 2026-07-09 — stars, forks, license, architecture.
18. gitlab.com/soapbox-pub/armada — accessed 2026-07-09 — commit/release/tag counts, creation date.
19. soapbox.pub/blog/soapbox-be-is-now-rebased — accessed 2026-07-09 — Pleroma-fork lineage of Rebased.
20. Web search, Human Rights Foundation grants — accessed 2026-07-09 — hrf.org Bitcoin Development Fund, Agora/hackathon coverage.
21. opencollective.com/soapbox-pub — accessed 2026-07-09 — live financial ledger, July 2026 payroll/travel transactions.
22. github.com/soapbox-pub — accessed 2026-07-09 — org-level repo/license table (confirms Nostrify = MIT).
23. soapbox.pub/blog/soapbox-awarded-grant — accessed 2026-07-09 — OpenSats grant terms, $5M Dorsey fund detail.
24. Web search — accessed 2026-07-09 — Sheila/Clawstr/Chorus/Inkwell descriptions via soapbox.pub/blog/announcing-sheila, soapbox.pub/blog/announcing-clawstr, soapbox.pub/blog/chorus-vibe-coding, soapbox.pub/blog/inkwell-born-in-walmart.
25. soapbox.pub/blog/building-zuka — accessed 2026-07-09 — Zuka description, activist partner quote.
26. Web search, Mostr bridge stats — accessed 2026-07-09 — mostr.pub, fediversereport.com bridging analysis (10k+ unique users / 70% direction figure dated late 2023).
27. soapbox.pub/toybox — accessed 2026-07-09 — full 17-item experimental-apps inventory.
28. gitlab.com/soapbox-pub/mkstack — accessed 2026-07-09 — commit count; license not visible/confirmed.
29. Web search — accessed 2026-07-09 — github.com/divinevideo/divine-web confirms Divine is a separate org/team building on MKStack, not a Soapbox-owned product.
30. soapbox.pub/transparency (report-index pass) — accessed 2026-07-09 — quarterly report titles confirming the "pivot to AI-assisted programming tools" dating (May–July 2025) and unbroken Q3-2023→Q1-2026 report sequence.
31. soapbox.pub/blog/how-soapbox-ships-fast — accessed 2026-07-10 — Dirk Rost's role (code review, MR approval, "bird's-eye view"), open-infra + plain-markdown personality framing.
32. soapbox.pub/blog/meet-quilly — accessed 2026-07-10 — Quilly's role (docs/community/GitLab), "newest member of Team Soapbox" self-description; note byline/date inconsistency (Jan 2025 byline vs. Jan 2026 visible date).
33. HRF Bitcoin Development Fund grant-round announcements (hrf.org/latest and related 2026 posts) — accessed 2026-07-10 — 2026 rounds name Snort, Coracle, Zapstore, Elsat and others; no round found naming Soapbox, Ditto, or Agora, supporting the HRF reclassification to prize/event partner.
34. Maintainers' internal production-secrets-longevity audit note (companion document, not part of this public chapter set), §2 fact 5 — Gleason-authorship percentages (Nostrify 85.2%, mkstack 71.9%, ditto-relay 99.3%, Ditto 47.4%) measured via GitLab/GitHub repo APIs, 2026-07-10; Ditto's secondary maintainers (Danidfra, marykatefain, derekross) named there.

Community & Company Operations — Ditto (public community) + Armada (team ops, early)

Verified: 2026-07-09 — Armada correction pass: 2026-07-09

Two Products, Not One Gap

"Community AND company operations, can it do filesharing" turns out to map onto two separate Soapbox products, not a gap in one:

Ditto (below, unchanged from the first research pass) is the public-facing answer. Armada — added in this correction pass — is the internal-team answer.

The Armada Verdict — Corrected 2026-07-09

The verdict below was wrong in the prior draft. Re-verified this pass by fetching the GitLab repo, its CHANGELOG, a sibling plugin repo, and Soapbox's own product page directly.

Sidebar — Flotilla, in one paragraph: A separate, Discord/Slack-shaped PWA built on "relays as groups" (NIP-29) [6]. Where Ditto is one branded server = one community, Flotilla lets a single relay host many independent group spaces. Not part of Soapbox's stack. Armada (below) is Soapbox's own answer to the same "Discord-shaped internal chat" need — and unlike Flotilla, it's E2E encrypted by default.

What Ditto Is

"Ditto is a Nostr community server. It has a built-in Nostr relay, a web UI, and it implements Mastodon's REST API." [7]

"Ditto is a self-hosted server featuring a community-centered Nostr relay with a built-in UI." [8]

Confidence: High (both quotes are from Soapbox's own blog). Note a real wrinkle: Ditto's current marketing copy pitches a lighter framing — "Deploy it on a $5 VPS, GitHub Pages, or a Raspberry Pi in your closet" [9] — that describes the static React/Vite frontend build [10][11], not the stateful Deno+Postgres backend that actually runs your relay, moderation, and Mastodon API [7][12]. GitHub Pages cannot run a database. Both descriptions are true of different halves of the same repo; see Architecture below.

Capabilities Matrix

Architecture & Self-Hosting

Two independently-corroborated paths reach this same shape:

1. Manual VPS path (third-party, detailed, technical — Linux/macOS only, Windows unsupported): install Deno v1.45.2, PostgreSQL, Nginx, Certbot; create a ditto system user; deno task setup generates .env (domain, DB credentials, media backend choice); provision Postgres; configure Nginx; certbot --nginx for TLS [12].
2. Docker path (community-maintained, not first-party): the arteeh/ditto image + a Postgres container on a shared network. Required env vars: DITTO_NSEC (relay keypair), DATABASE_URL, LOCAL_DOMAIN, PORT (default 6996), optional DITTO_POLICY [22]. Linux amd64 only.

Confidence: Medium-High (both paths are documented, but neither is the current first-party about.ditto.pub guide, which 404'd during verification — official docs appear to be mid-migration between docs.soapbox.pub and about.ditto.pub as of this writing).

Filesharing Verdict

Precise question: can a team use this stack instead of Google Drive/Dropbox?

Bottom line: Ditto can absolutely carry a team's social/community media (photos, video, voice notes, event flyers). It is not a Drive/Dropbox replacement for internal document collaboration — no folders, no permissions, no version history, no office-doc preview, and the 100 MiB ceiling rules out most video-editing or design-asset workflows. The one folder-layer workaround has effectively lapsed — Blossom Drive is deprecated upstream (successor Bouquet manages blobs, not folders; ch. 06) — so the gap stands unbridged. Confidence: High on the CAN/CAN'T calls, Medium on exact size figures (spec-level, not Ditto-instance-verified).

Company-Ops Fit

Pricing & Access

Setup Runbook (as documented)

1. Provision a Linux VPS (Ubuntu recommended) and point a domain's DNS at it [12].
2. Install system packages: git curl unzip nginx postgresql-contrib certbot python3-certbot-nginx [12].
3. Install Deno (pinned version, e.g. v1.45.2) [12].
4. Create a dedicated ditto system user; clone the repo to /opt/ditto, chown to that user [12].
5. Run deno task setup — generates .env with domain, DB credentials, and your media-backend choice (Blossom / S3 / local / IPFS / nostr.build) [12].
6. Provision the Postgres database and user (dittodbuser / dittodb by convention) [12].
7. Copy and edit the Nginx site config with your server_name [12].
8. Run certbot --nginx to obtain and wire up TLS [12].
9. Visit your domain to confirm the Ditto template renders [12].
10. Docker alternative to steps 2-8: run the arteeh/ditto + Postgres compose stack with DITTO_NSEC, DATABASE_URL, LOCAL_DOMAIN set, behind your own reverse proxy [22].
11. Set admin role on your own pubkey, then use the admin dashboard to configure moderation policies, NIP-05 approval flow, and theme [16].

Confidence: Medium — steps 1-9 are a verified third-party walkthrough, not the current first-party guide (which redirected/404'd mid-research); version-pinned details (Deno v1.45.2) may have drifted.

Armada

Verified: 2026-07-09. Repo is 26 days old at time of writing — expect drift; re-check before relying on specifics.

What Armada Is

"Armada is an end-to-end encrypted community chat app built on Nostr." [34]

"Discord without the company. Your keys. Your people." [41]

Discord-shaped: servers, channels, threads, voice, roles, DMs, events/RSVP, emoji reactions, markdown [41]. Unlike Ditto, encryption is the default, not absent — every chat/invite/rekey event is sealed before it touches a relay [34]. Confirmed sibling repos (armada-relay, openclaw-armada) independently corroborate the product and protocol name [36].

The Concord Protocol

"A serverless, end-to-end encrypted community protocol... All control/chat/invite/rekey traffic is gift-wrapped (NIP-59) over generic Nostr relays." [34]

Concord is Soapbox's own protocol — numbered CORD-01 through CORD-07, a sibling spec built on top of Nostr's NIPs, not a NIP itself. It runs on standard public Nostr relays (no special server), using NIP-59 gift-wrapping for every event plus NIP-42 relay auth with per-session derived keys [38].

"Who sent it, which community it belongs to, even the community's name — all sealed." [41]

That metadata-privacy claim is stronger than typical E2EE (which usually still leaks who's-talking-to-whom). It is a DOCUMENTED claim in the README and marketing copy — this pass found no independent security audit confirming it holds up. Whether CORD-06 rekeying gives MLS- or Signal-style forward secrecy is not stated anywhere found — treat as unconfirmed, not as "it's MLS."

A second, non-default path exists: NIP-29 relay-groups for operators who want a self-hosted server instead of the serverless default [34]. Two live implementations already coexist in the codebase — concord-v1/ and concord-v2/ — the protocol has already been rebuilt once in under a month [39].

Architecture

Confidence: High on client/protocol shape (README + landing page agree); High that the NIP-29 self-host path is real but immature (armada-relay = 1 commit, created the same day as this research) [37].

Capabilities Matrix

Filesharing Verdict — Armada

Same precise question as Ditto: can a team use this instead of Google Drive/Dropbox?

Bottom line: narrower than Ditto's filesharing story, but more private where it exists. Armada CAN carry E2E-encrypted image/media drops inside a private team chat today — a genuinely stronger privacy story than Ditto's, since the content itself (not just the transport) is sealed. It is not confirmed to handle arbitrary document types, and there is no evidence at all of folders, permissions, or version history — so it's still not a Drive/Dropbox replacement, for different reasons than Ditto (missing breadth here, vs. Ditto missing E2EE and hitting a hard size cap). Confidence: Medium overall — image-attachment behavior is CHANGELOG-confirmed; everything else in this table is an absence-of-evidence call on 26-day-old software, not a confirmed "no."

How to Try It Today

1. Web: soapbox.pub/armada → "Open Armada" — works in any browser, including mobile Safari/iOS (no native iOS app) [41].
2. Android: native app via Capacitor; configured for Zapstore distribution (zapstore.yaml in-repo) [39][46]; native push bypasses Google services; Bluetooth mesh works fully offline [35][41].
3. Desktop: Electron builds for Linux and Windows (no Mac build found or mentioned) [34][41].
4. Join a community via an invite link — the unlock key rides in the URL fragment, so it never touches a server [41].
5. Self-host (NIP-29 path): marketing copy claims a "complete open-source server stack," but the backing repo (armada-relay) had one commit, created the same day as this research — treat self-hosting as not yet real-world ready [37][41].
6. armada.buzz does not resolve — use soapbox.pub/armada [44].

Maturity Warning

26 days old, ~daily releases, self-described as "Early version (0.x)" on its own landing page [41]. In the 17 days since v0.1.0 (2026-06-22), the protocol has already gone through a v1→v2 rebuild, an encryption-label change reversed days later, and a self-host backend that only started today [35][39][37]. The most recent 25 releases (v0.17.0 → v0.25.3) landed in just five days (2026-07-05 to 2026-07-09) — velocity is accelerating, not settling [40]. At least two named committers (Alex Gleason, Chad Curtis) — a small team, not a solo project, but this pass found no visible external community contributions [40]. Good to pilot and watch closely; do not bet confidential company operations on it without your own review — nothing here has been independently security-audited.

Incumbent Comparison

Confidence: High on Ditto-column facts (cited above); High on Armada being real, Medium-Low on its unaudited/unconfirmed claims (marked throughout); Medium on incumbent pricing (current as of search date, subject to normal SaaS pricing drift) [32].

Integration Points

Open Questions

• Is about.ditto.pub's canonical self-hosting guide currently live at a different path than what redirected/404'd during this research pass? Worth re-checking directly before an actual deployment.
• Whether Ditto's NIP-72 listing in its own reference means it reads and displays NIP-72 community events from other clients (interop) or only that some internal code path touches the kind — not confirmed either way.
• Whether any DM capability exists via a non-listed NIP or a Mastodon-API "direct" visibility mapping — not found in official docs, but not exhaustively ruled out either.
• Whether "Stacks" (getstacks.dev) is a Docker-compose bundler specifically for Ditto, or a broader "AI project template" sharing site unrelated to production deployment — direct fetch only returned a page title, inconclusive.
• Exact current numeric count behind the "27+ content types" marketing claim vs. the "60+ event kinds" reference-doc claim — likely two different countings (curated UI content types vs. raw protocol event kinds) but not reconciled to a single verified number.
• Armada: What are CORD-01 through CORD-04? Only CORD-05 (invites), CORD-06 (rekey/refounding), and CORD-07 (voice broker) were identifiable in sources found this pass.
• Armada: Does CORD-06 rekeying provide forward secrecy comparable to MLS or Signal's double ratchet? Not stated anywhere found — don't assume either way.
• Armada: Are attachment blobs encrypted client-side before reaching the Blossom server (true E2EE at the storage layer), or only the message pointer/metadata? The CHANGELOG's "decrypt and display inline" language implies the former but doesn't say so explicitly.
• Armada: Does the UI actually support non-image file types today? No evidence either way was found.
• Armada: Is armada.buzz a domain Soapbox owns and intends to launch on, or unrelated/parked? Unresolved after three independent failed fetch attempts across two research passes — use soapbox.pub/armada regardless.
• Armada: Is a native iOS app planned, or is web-only a deliberate design choice? Not stated.
• Armada: How real is the "one-command server stack" self-host claim on the landing page, given armada-relay had exactly one commit at time of writing? Worth re-checking in a few weeks.

Sources

1. Star Wars: Armada Fleet Builder — unrelated app, false-lead check. Accessed 2026-07-09.
2. Soapbox Tools — full product/tool list with URLs; no Armada listed. Accessed 2026-07-09.
3. Soapbox Toybox — full experiments list; Armada absent as a project. Accessed 2026-07-09.
4. https://armada.buzz / http://armada.buzz — fetch failed both protocols (SSL WRONG_VERSION_NUMBER). Accessed 2026-07-09.
5. Web search "armada.buzz" — zero Nostr/Soapbox-related results. Accessed 2026-07-09.
6. Flotilla — GitHub — "A nostr relay-based communities PWA modeled after discord." Accessed 2026-07-09.
7. Announcing Ditto — Soapbox Blog — original server architecture (Deno, Postgres, built-in relay, Mastodon REST API). Accessed 2026-07-09.
8. Creating Curated Communities on Nostr with Ditto — community/moderation model. Accessed 2026-07-09.
9. Soapbox Launches Massive Update to Ditto — relaunch marketing copy, "$5 VPS, GitHub Pages, Raspberry Pi." Accessed 2026-07-09.
10. gitlab.com/soapbox-pub/ditto / raw README — React 18 + Vite + TypeScript frontend stack. Accessed 2026-07-09.
11. github.com/soapbox-pub/ditto — README mirror, same frontend-stack description. Accessed 2026-07-09.
12. Setting up your own nostr community with Ditto — freedomweaver.tech — third-party manual VPS self-hosting walkthrough (Deno, Postgres, Nginx, Certbot). Accessed 2026-07-09.
13. Unlocking 50+ Mastodon Apps for Nostr with Ditto — Mastodon-API client compatibility. Accessed 2026-07-09.
14. Web search — Mastodon API access-token/bot-automation mechanics applied to Ditto. Accessed 2026-07-09.
15. Introducing Mostr: a Fediverse Nostr bridge and How to Follow Bluesky Accounts from Nostr — bridge mechanics, Bluesky via Bridgy Fed relay chain, ~15 min+ lag. Accessed 2026-07-09.
16. Ditto 1.3: Explore Nostr — Soapbox Blog — admin tools (username revocation, admin promotion), moderation features. Accessed 2026-07-09.
17. Web search summary of stacker.news/items/863195 discussion — full-text search in Postgres, moderator/admin capabilities (direct fetch returned no content; sourced via search snippet only — lower confidence). Accessed 2026-07-09.
18. Ditto Nostr Reference — about.ditto.pub/reference — official supported-NIPs list and event-kind count. Accessed 2026-07-09.
19. NIP-72 — Moderated Communities — spec definition, kind 34550/4550. Accessed 2026-07-09.
20. Chorus — GitHub (andotherstuff/chorus) and Chorus: An Experiment in Vibe Coding — NIP-72-native community app built with MKStack, distinct from Ditto's model. Accessed 2026-07-09.
21. ditto.pub and web search on its flagship-instance status — free, open enrollment, light moderation. Accessed 2026-07-09.
22. arteeh/ditto — Docker Hub — community-maintained Docker image, env vars, Postgres dependency. Accessed 2026-07-09.
23. Blossom — GitHub (hzrd149/blossom) and NIP-B7 — Blossom media — protocol spec, SHA-256 addressing, mirroring. Accessed 2026-07-09.
24. Blossom Uploader — Nostrify — integration reference. Accessed 2026-07-09.
25. Blossom Drive: Store & Retrieve Data on Public Servers — folder/drive layer on top of Blossom, kind 30563 events. Accessed 2026-07-09.
26. Web search on Blossom spec limits — 100 MiB hard cap, 20 MiB free-tier convention. Accessed 2026-07-09.
27. blossom.nostr.build — example Blossom server, up to 100MB. Accessed 2026-07-09.
28. NIP-96 — HTTP File Storage Integration — marked unrecommended, superseded by Blossom. Accessed 2026-07-09.
29. Web search — Nostr bot / Mastodon API automation patterns (nostrdon bridge example). Accessed 2026-07-09.
30. Web search summary — Ditto's "your identity, content, and connections belong to you" data-portability claim. Accessed 2026-07-09.
31. Ditto 1.3 release notes — staff/role management features. Accessed 2026-07-09.
32. Web search — current Slack, Discord Nitro, Circle.so, Mighty Networks pricing tiers (2026). Accessed 2026-07-09.

Armada correction pass (2026-07-09) — sources 33-46:

1. gitlab.com/soapbox-pub/armada — main repo page: created 2026-06-13, AGPL-3.0, 484 commits, 17 branches, 62 tags, 46 releases. Accessed 2026-07-09.
2. gitlab.com/soapbox-pub/armada/-/raw/main/README.md — verbatim definition of Armada and the Concord protocol, NIP-59 gift-wrap mechanics, NIP-29 self-host alternative, install instructions. Accessed 2026-07-09.
3. gitlab.com/soapbox-pub/armada/-/raw/main/CHANGELOG.md — chronological feature history v0.1.0 (2026-06-22) through v0.25.x (2026-07-09): encrypted image attachments, voice/screen-share, Bluetooth mesh, Concord v2 cutover. Accessed 2026-07-09.
4. gitlab.com/api/v4/groups/soapbox-pub/projects — GitLab group API listing; confirms armada, armada-relay, and openclaw-armada as sibling repos under soapbox-pub. Accessed 2026-07-09.
5. gitlab.com/soapbox-pub/armada-relay — self-hosted backend repo: 1 commit, 1 branch, 0 releases, created 2026-07-09 — key maturity signal for the self-host claim. Accessed 2026-07-09.
6. gitlab.com/soapbox-pub/openclaw-armada/-/raw/main/README.md — confirms Concord protocol spec numbering (CORD-01–07), NIP-59/NIP-42/kind-3313/kind-1059 mechanics, and OpenClaw AI-agent integration. Accessed 2026-07-09.
7. GitLab repository-tree API for soapbox-pub/armada (root + recursive src/) — confirms parallel concord-v1/ and concord-v2/ implementations and BlossomServerListEditor.tsx (media/attachment config UI). Accessed 2026-07-09.
8. GitLab releases API for soapbox-pub/armada — 25 dated releases v0.17.0 through v0.25.3, spanning 2026-07-05 to 2026-07-09; named authors Alex Gleason and Chad Curtis. Accessed 2026-07-09.
9. soapbox.pub/armada — the actual product landing page (not linked from /tools/ or /toybox): tagline, feature list, encryption claims, self-host claim, "Open Armada" CTA. Accessed 2026-07-09.
10. soapbox.pub/blog/ — full blog index (101 posts); confirms /armada exists only as a main-nav link, no dedicated announcement post found. Accessed 2026-07-09.
11. soapbox.pub/tools/ — re-verified this pass; Armada still absent from the product/tools index, consistent with the original chapter's finding and explaining the discovery gap. Accessed 2026-07-09.
12. https://armada.buzz, http://armada.buzz, and a web-archive lookup — re-tested this pass; all three fail (SSL WRONG_VERSION_NUMBER on both protocols; archive fetch could not connect). Confirms this is not Armada's working domain. Accessed 2026-07-09.
13. github.com/openclaw/openclaw and open-claw.bot/docs/channels/nostr — background confirming OpenClaw is an independent open-source AI-agent framework (not a Soapbox product) with an existing Nostr channel plugin pattern. Accessed 2026-07-09.
14. zapstore.dev and github.com/zapstore/zapstore — background on Zapstore, the Nostr-native Android app store Armada's repo is configured for (zapstore.yaml); Armada's own live listing was not independently confirmed. Accessed 2026-07-09.

Agora — Funding Rails

Agora is Soapbox's non-custodial, on-chain-Bitcoin fundraising app for activists — campaigns move wallet-to-wallet with zero platform fee, no KYC, and no approval step.

Verified: 2026-07-09

What It Is

Built by Soapbox (Alex Gleason's company) on Nostr + Bitcoin, Agora started as a hackathon project called Pathos and relaunched as Agora on June 2, 2026 at the Oslo Freedom Forum, announced by the World Liberty Congress (WLC) with Human Rights Foundation (HRF) backing. It lives at agora.spot (web) and on ZapStore (Android), with source at gitlab.com/soapbox-pub/agora.

"Agora never holds funds. Donations move wallet-to-wallet on Bitcoin." [1]

"Recipients sign up in seconds. No bank. No paperwork. No approval." [1]

The platform describes itself as "the world's first Borderless Micro-Philanthropy Network" [8] — positioned specifically for activists, dissidents, and political prisoners, not general-purpose crowdfunding.

How a Donation Flows

Campaign donations run entirely on-chain — not Lightning. (Lightning appears elsewhere in the broader app for social tipping — see Integration Points.)

Donors pick Public (standard address, visible forever, widest wallet support, fastest) or Silent (BIP-352, unlinkable fresh output, fewer wallets support it, slower, no push notifications) [6]. Creators choose which to accept, or both [7].

Campaign Creation & Eligibility

The gate here is social and reputational, not technical: Agora doesn't vet campaigns, but it also doesn't market itself to small businesses or general nonprofits — a non-activist campaign would be real and fundable, just off-brand and undiscoverable without its own audience.

Fees & Costs

Agora's own cut is genuinely zero — the FAQ instructs donors to "pay the amount plus the network fee" [6], meaning the only unavoidable cost is Bitcoin's own transaction fee, not a Soapbox markup.

Custody, Compliance & Fiat Reality (US Operator Lens)

Custody is real and non-custodial: the receiving address is derived from the recipient's own Nostr secret key, and funds can be exported straight to Sparrow, BlueWallet, Trezor, or Ledger [7]. But "no KYC at Agora" doesn't mean "no KYC anywhere" — it just relocates to both ends of the transaction:

Two general considerations for a US-based 501(c)(3) or small business — not legal advice: (1) the IRS treats crypto as property (Notice 2014-21); issuing a compliant donor receipt requires the donor's identity and fair-market-value at receipt, which Silent Payments structurally prevent and Public payments only partially provide (an address isn't a legal name). (2) Funds sit in BTC, subject to price movement, until someone manually off-ramps them — a $10,000 goal today isn't a fixed $10,000 in the bank the way a GoFundMe balance is.

Self-Host / White-Label

Agora is open source (AGPL-3.0) and built to be redeployed, not just used [4]:

Verdict: technically real, but it's a codebase to fork and operate, not a product to purchase. Realistic for a dev-capable client; not a weekend project for a non-technical one.

Traction & Credibility

Confidence: Medium. The launch itself and WLC/HRF backing are solidly corroborated by an independent wire release; platform-wide traction is not — the one dollar figure available comes from Agora's own marketing page, not an independent scan.

Incumbent Comparison

Confidence: Medium — Agora's own figures are primary-sourced; incumbent fee figures are drawn from secondary aggregation (help-center pages and pricing trackers), not each platform's raw fee schedule fetched directly.

Where Agora structurally loses, regardless of fees: no card/fiat donor checkout (a donor must already own or acquire BTC themselves), no Lightning option for cheap micro-donations, no reward or membership mechanic, five weeks of track record versus GoFundMe's ~15 years, and a brand that reads as off-topic for anything that isn't a human-rights cause.

Integration Points

Open Questions

• Exact Nostr event kind(s) recording the on-chain campaign/donation itself (site says donations are "public... on Nostr" [1] but doesn't name the kind)
• Whether NIP-75 powers campaign goal-tracking, or if it's bespoke
• Mechanism for posting campaign updates to donors (standard Nostr notes vs. a dedicated notification path)
• Any embed/widget capability for third-party sites — none located
• Platform-wide traction (total raised, total live campaigns, total donors) beyond the single featured example
• Whether the claimed Forbes/AP coverage is substantive — could not independently locate either
• Full workings of the org "verification statement" feature (concept confirmed, UI/workflow not)
• No Terms of Service document was located despite being referenced from the FAQ
• No iOS listing found — web and Android/ZapStore only, cause unconfirmed

Sources

1. soapbox.pub/agora — Soapbox, "Agora — GoFundMe Without Borders." Accessed 2026-07-09. Supports: tagline, custody quote, zero-fee claim, payment options, Venezuela campaign figures.
2. soapbox.pub/blog/building-pathos — Soapbox blog, "Building Agora: From Hackathon to Real-World Activism." Accessed 2026-07-09. Supports: Pathos→Agora rename, hackathon origin, 25M-sat prize, 100+ users in 24h.
3. soapbox.pub/blog/agora-connecting-freedom-fighters — Soapbox blog. Accessed 2026-07-09. Supports: launch story, WLC/HRF/Bitcoin Park partnership, Venezuela pilot, 2026 expansion countries.
4. gitlab.com/soapbox-pub/agora — GitLab repository + README. Accessed 2026-07-09. Supports: AGPL-3.0 license, tech stack, self-hosting/Docker instructions, config model, Nostr kinds, Lightning zaps via NWC/WebLN.
5. agora.spot — Live app. Accessed 2026-07-09. Supports: navigation structure, "zero platform fees."
6. agora.spot/help/donors and agora.spot/help — Donor guide + FAQ. Accessed 2026-07-09. Supports: 3-step donation flow, network-fee statement, wallet list, Public vs. Silent explanation.
7. agora.spot/help/activists and agora.spot/verify — Activist guide + verify page. Accessed 2026-07-09. Supports: non-custodial confirmation, wallet export options, permissionless creation, org verification-statement model.
8. agora.spot/safety and agora.spot/about — Safety + about pages. Accessed 2026-07-09. Supports: "Borderless Micro-Philanthropy Network," no-Lightning-for-donations, CSAE policy, own relay + Blossom server.
9. PRNewswire — World Liberty Congress Launches Agora at Oslo Freedom Forum. Accessed 2026-07-09. Supports: June 2, 2026 launch date, López/Fain quotes, launch countries, ZapStore/Android distribution.
10. agora.spot/sponsors — Sponsors page. Accessed 2026-07-09. Supports: partner list, self-reported press coverage.
11. Yahoo Finance — World Liberty Congress Launches Agora (syndicated PRNewswire). Accessed 2026-07-09.
12. HRF — HRF Sponsors AI Hack for Freedom in Austin, TX, Jan. 17-18. Accessed 2026-07-09. Supports: hackathon structure, prize tiers (0.5/0.25/0.1 BTC), dates.
13. NIP-57 — Lightning Zaps. Accessed 2026-07-09. Supports: kind 9734/9735 definitions.
14. NIP-47 — Nostr Wallet Connect. Accessed 2026-07-09. Supports: NWC mechanics.
15. NIP-75 — Zap Goals. Accessed 2026-07-09. Supports: kind 9041, amount/relays tags, goal semantics.
16. GoFundMe Help Center — Requirements to receive funds and Learn about GoFundMe fees. Accessed 2026-07-09. Supports: GoFundMe fee rates, ID/bank/country requirements.
17. Geyser Guide — Geyser Fees and How on-chain contributions work. Accessed 2026-07-09. Supports: Geyser fee tiers, Boltz-Exchange non-custodial swap, no-KYC-for-creators.
18. Kickstarter, Patreon, and Open Collective fee figures — aggregated via web search of secondary pricing-comparison sources (not each platform's own pricing page fetched directly). Accessed 2026-07-09. Confidence: Medium; treat as directionally accurate, not verbatim-verified.

Shakespeare — AI Website/App Builder on Nostr

A browser-only, open-source AI coding environment that chats you into a React app, stores the code on your machine (not Soapbox's servers), and deploys it to a free subdomain or anywhere else you point it — priced by the AI token, not the seat.

Verified: 2026-07-09 · Amended: 2026-07-10 (v2 wave) — flagged the BYOK claim UNRESOLVED (a live re-fetch of the announcement post shows no BYOK mechanism mentioned; custody location unknown) without deleting the original claim; added the NostrDeploy.com DNS-tripwire annotation (not previously present in this chapter, unlike ch. 10); flagged Stacks CLI provider-key storage as unknown/unfound.

Confidence: High for architecture, storage, license, and deployment-target facts (multiple primary Soapbox sources agree). Medium for exact current pricing/free-tier durability and for funnel/data-capture mechanics (documented capability exists; where captured data actually lands is not spelled out by Soapbox and is partly inferred from the tool's no-backend architecture). Low for anything competitive (Lovable/Bolt/Webflow/Framer cells are general-knowledge, not independently fetched from those vendors this pass).

What It Is

"Shakespeare is a web interface where you can build websites through conversation with AI assistants." [2]

It is Soapbox's consumer-facing wrapper around MKStack, its Nostr app framework: "bringing the power of MKStack to everyone through natural conversation" [1]. Announced July 10, 2025 and publicly launched July 14, 2025 at a Human Rights Foundation event [2][10], it is not a template picker — it is a full in-browser IDE. Act 2 (Oct 2025) reframed it as "a full-featured development environment, entirely in your browser": code editor, hot-reload preview, in-chat terminal, file uploads [3].

Founder Alex Gleason's framing: "It used to be hard to build websites using decentralized protocols. But Nostr + AI makes this something that anyone can do now." [10] Soapbox runs it "trust-based" rather than subscription-funded, with no outside revenue disclosed [14]. It's a lineage product: Block's Goose agent framework (Jan 2025) → Stacks, a Nostr template platform (May 2025) → the browser-native rebuild that became Shakespeare (Jul 2025), each step shedding a barrier (terminal, Node.js install) [22].

How It Works

Everything — the AI agent loop, the TypeScript compiler, the git client, the file system — runs client-side. There is, per the repo's own README, "no backend (except for a couple microservices in the services/ directory; these are fully configurable within Shakespeare's settings)" [5].

Stack: React PWA frontend, IndexedDB/LightningFS for storage, isomorphic-git for version control, esbuild-wasm to compile TypeScript to a running React app — all in-tab [5]. Generated apps get MKStack's scaffolding: 50+ Nostr NIPs, ShadCN components, and Nostr-native primitives (profiles, DMs, zaps, Cashu wallets) available to the AI on request [6]. Full stack: React, not a generic static-site generator — MKStack is the template; the AI, called "Dork" in the underlying framework, decides what to wire up [9].

Confidence: High — architecture is corroborated across the README, the launch post, and Act 2.

Cost Mechanics — The Free-Mockups Verdict

Yes. You can generate close to unlimited client mockups at near-zero marginal cost — but the mechanism matters, because only one of four paths is genuinely "free" without caveats. The underlying model: Shakespeare doesn't sell AI capacity itself, it brokers access to independent Nostr Service Providers (NSPs) who set their own pricing (pay-per-use, subscription, or free tiers) and settle in USD or Bitcoin [11].

There is no subscription anywhere in this picture — Shakespeare's own comparison page needles v0 for exactly the model you'd otherwise be locked into: "Five monthly free credits, then subscription-based ($20-$100/mo)... No pay-as-you-go option" [16]. Practical read: run free-tier or a cheap BYOK model for the volume mockup pass, reserve Sonnet 4.5 for the deal that's actually going to close.

Confidence: High on the mechanism; Medium on "free forever" — the Gemini Flash tier is described as a current promotion, not a permanent commitment, so verify live before quoting a client $0.

BYOK flag — UNRESOLVED (2026-07-10): the two "BYO API key" rows above could not be re-verified live this pass. Soapbox's own Shakespeare announcement post [2] — one of this table's own citations — was re-fetched and documents only NSP-marketplace payment (USD via Stripe or Bitcoin Lightning) plus the free Gemini Flash NSP; it does not mention a BYOK mechanism at all. Act 2 [3] does document "BYOK providers" as a real feature, so the capability itself is not in doubt — what's unresolved is the custody model: where a pasted API key is stored (browser-local, alongside the IndexedDB/LightningFS project data, versus sent to and held by a Shakespeare-operated server) is not stated in any source fetched. This does not overturn the rows above — they stay — but verify directly in-product (add a BYOK key, then check browser devtools > Application > IndexedDB/localStorage) before trusting a client's API key to it.

Funnel Capability Matrix

This is the section that needs the most caution. "Add a contact form" is a literal documented example prompt [1] — but Shakespeare has no conventional backend or database; Nostr's native data model is public, signed, relay-broadcast events, not a private leads table [5]. A generated form's UI will render; where its submissions land is not specified by Soapbox and depends entirely on what you prompt it to wire up.

Verdict: the awareness layer (site, form UI, scheduling embed) and Bitcoin-native payment are genuinely one-prompt-away. The conversion/data layer for a mainstream (non-Nostr) small-business client — the part that actually makes a "funnel" — needs the same external services most funnels already run (Beehiiv, ManyChat, Cal.com, Stripe), stitched in by prompt rather than provided.

Confidence: Medium — the gap is a structural inference from the architecture, not a Soapbox-stated limitation.

Deployment Paths

Runbook, as documented: build in chat → click deploy → live instantly at a *.shakespeare.wtf subdomain, "no setup required and no configuration headaches" [1]. Act 2's showcased projects confirm the pattern live: mi.shakespeare.wtf, linkbio.shakespeare.wtf [3]. For anything else — "use our built-in, free, deployment service or export your complete project and deploy anywhere you choose" [3] — via ZIP or a git push to GitHub/GitLab/custom, including nostr:// Git URLs for censorship-resistant backup needing no GitHub account [3][5].

The fully decentralized route (content-addressed on Blossom servers, pointer events on Nostr relays, resolvable via nsite:// or gateway domains — the same nsite spec used across the wider Nostr static-hosting ecosystem [27]) is documented for MKStack projects deployed via the Stacks CLI (npm run deploy → Blossom + relays → NostrDeploy.com) [7][9], not spelled out step-by-step for the browser Shakespeare export path specifically — treat as reachable with extra tooling, not a native one-click Shakespeare button.

⚠ Tripwire (2026-07-10), cross-ref ch. 10: nostrdeploy.com does not resolve — a direct DNS check hit ENOTFOUND, which reads as dead-or-broken domain, not a server outage [28]. Both the NostrDeploy.com mention above and in the mermaid diagram are therefore unverifiable and possibly dead; don't promise this decentralized-deploy lane to a client or build a runbook on it until the domain resolves again. Ch. 10 carries the full tripwire detail, including the untested nuance that the underlying Blossom+relay substrate is content-addressed and may still work even if the NostrDeploy.com index/gateway itself is gone. Stacks CLI provider-key storage — unknown, flag before wiring real keys (2026-07-10): ch. 10 documents stacks configure as where the Stacks CLI's model-provider keys (OpenRouter, Routstr, PayPerQ) get set, but where that command actually persists the key (plaintext config file, OS keychain, encrypted store) was not found in this pass — the term is search-drowned by the unrelated "Stacks" blockchain project, which floods generic web results. Before wiring a real client-facing provider key through the Stacks CLI lane, run stacks configure and inspect its output/config file directly rather than assuming a security posture.

Confidence: High for the *.shakespeare.wtf free path and the 8-target export list (corroborated across two independent Soapbox comparison posts [16][17]). Medium for custom-domain mechanics on either path — working examples exist (espy.you) but no published runbook was found.

Code Ownership & Export

Two licenses are in play and they answer different questions:

That second row is the load-bearing fact for an agency workflow: there is no platform to be banned from. Soapbox's contrast: a Replit ban deletes your account and "all Replit App will have been deleted"; Shakespeare's code lives in your browser's IndexedDB from the start, so "prevents account bans" really means "no account to ban" [17]. Export is one click to a ZIP or a full-history git push — no lock-in step exists to remove [3][5].

Confidence: High for the tool's own AGPLv3 status (confirmed on the repo). Medium-High for "no license on generated output" — strongly implied by the architecture and Soapbox's own competitor framing, but never stated as a standalone legal claim.

Limits & Workflow

• Iteration is chat-native, not context-free. Shakespeare's own debugging guide flags "context overload: the conversation has become so long that each prompt is expensive" as the signal to start a fresh chat rather than keep pushing [19].
• Debugging is a 4-step protocol Soapbox documents explicitly: gather evidence → isolate the problem → provide context → test systematically with rollback available, closing with "start with evidence, not assumptions" [19].
• Model choice is the real cost/quality lever, not a plan tier: "If you choose a cheap model, you can expect cheap results" [19][20].
• Version control is built in, framed as "a time machine for your code" — one-click rollback via a three-dot menu, or raw git commands in the in-browser terminal for power users [21].
• Editing an existing (including imported) site is supported — Shakespeare can import external projects, not just greenfield-generate [18].
• No multiplayer/live-collab feature was found anywhere in the primary sources (community, Act 2, or resources pages) — the "Shakespeare Community" is a Nostr-based chat/forum for builders to swap tips, not in-project co-editing [4].

Confidence: High — sourced from Soapbox's own guides, not marketing copy.

Agency Comparison

Where Shakespeare wins: true pay-per-use with no subscription tax, real code ownership with no ban risk, native Bitcoin/Lightning rails, export to 8+ hosts instead of one [16][17]. Where it loses: no visual/drag-and-drop editor, no managed database or one-click Stripe/CRM the way Lovable ships it, no template marketplace, younger track record — plus a client-comfort tax: "log in with a Nostr key" and "your data lives on relays" are unfamiliar to a small-business client used to plain email/password SaaS.

Confidence: Medium — Shakespeare's claims about itself and about v0/Replit are primary-sourced [16][17]; the Lovable/Webflow/Framer cells reflect general market knowledge, not a fresh fetch of those vendors' own pricing/docs this pass.

Integration Points

Confidence: Medium — product relationships are documented; the specific "how to combine these for an agency package" framing is this chapter's synthesis, not a Soapbox-stated playbook.

Open Questions

• Whether the free Gemini Flash NSP is still active today (2026-07-09) and whether it carries a rate limit or usage cap — described in launch copy as a current promotion, not a permanent commitment, and no post after Dec 2025 was found confirming its status [2].
• The exact DNS/runbook steps for attaching a fully custom domain (either to *.shakespeare.wtf or to an nsite/Blossom deployment) — working examples exist (espy.you) but no step-by-step was found [3].
• Whether a contact-form submission can be routed to a private Nostr DM (NIP-17) to the site owner as a semi-native lead-capture path, versus requiring an external HTTP service — plausible given MKStack's NIP coverage, but not demonstrated in any source fetched.
• Whether analytics of any kind (even privacy-respecting/Nostr-native) exists or is roadmapped — zero mentions found across marketing pages, blog, and FAQ listing.
• Current product state beyond the last confirmed changelog entry (Dec 16, 2025, "AI-First Development on Mobile") — seven months of potential unlogged change between then and today; verify live before any client-facing commitment [15].
• Where a BYOK key is actually stored (browser-local vs. Shakespeare-operated server) — see the BYOK flag in Cost Mechanics, above; unresolved as of this pass, inspect in-product before trusting a client's key to it.
• Where the Stacks CLI persists a provider key set via stacks configure — see the Deployment Paths tripwire, above; unresolved, search-drowned by the unrelated Stacks-blockchain project.

Sources

1. Shakespeare — Open Source AI Website Builder — product marketing page: pricing claims, provider list, deployment/export claims. Accessed 2026-07-09.
2. Introducing Shakespeare: AI-Powered Website Builder on Nostr — launch post (2025-07-10): what it is, NSP payment model, free Gemini Flash tier, AGPLv3 license. Accessed 2026-07-09; re-fetched 2026-07-10 — confirms no BYOK mechanism is mentioned in this post (see the BYOK flag in Cost Mechanics).
3. Shakespeare: Act 2 — Build Freely — 2025-10-01 update: local storage (IndexedDB/LightningFS), BYOK providers, git integration incl. nostr://, free deploy service, example live subdomains. Accessed 2026-07-09.
4. Announcing the Shakespeare Community — community structure, channels, no multiplayer/payment features mentioned. Accessed 2026-07-09.
5. gitlab.com/soapbox-pub/shakespeare and raw README — tech stack (React PWA, IndexedDB+LightningFS, isomorphic-git, esbuild-wasm), "no backend" claim, AGPLv3 license. Accessed 2026-07-09.
6. MKStack — AI-Powered Nostr App Framework — 50+ NIPs list incl. payments (NIP-57/60/61/47), React/TypeScript stack, NostrDeploy.com integration. Accessed 2026-07-09.
7. Stacks — AI-First Development Platform — Docker-based template platform, stack.json/agent.json/CONTEXT.md, NostrDeploy.com deploy workflow, Dork AI agent providers. Accessed 2026-07-09.
8. Soapbox Toolbox — full tool inventory used to map integration points (Ditto Relay, Nostrify, NostrHub, Relay Kit, etc.). Accessed 2026-07-09.
9. MKStack: Vibe Coding for Everyone — step-by-step Dork generation pipeline, npm run dev/npm run deploy, cost caution ("this gets expensive"). Accessed 2026-07-09.
10. Shakespeare Launches as Open Source Competitor to AI-site builders — PR Newswire — launch date/venue, Alex Gleason quote. Accessed 2026-07-09.
11. Understanding Nostr Service Providers (NSPs) — NSP payment structure (pay-per-use, subscription, free tiers), how to pick one. Accessed 2026-07-09.
12. ai.shakespeare.diy — OpenAI-compatible API with NIP-98 auth; GLM-4.5 and Claude Sonnet 4.5 per-token pricing. Accessed 2026-07-09.
13. Shakespeare — Product Hunt — maker comments, "Shakespeare only takes a cut if you use our paid NSP" quote, user feedback. Accessed 2026-07-09.
14. Inside Soapbox's push to keep AI open for everyone — TechCabal — Gleason's origin motivation quote, "trust-based" business framing, no revenue/funding disclosed. Accessed 2026-07-09.
15. Soapbox Blog index — full Shakespeare-related post list with dates, used to establish most-recent-confirmed-update timeline (through 2025-12-16). Accessed 2026-07-09.
16. Shakespeare vs. v0 by Vercel — official feature/pricing comparison table (Soapbox's own framing). Accessed 2026-07-09.
17. Shakespeare vs. Replit — official comparison incl. ban/ownership contrast, deployment target list. Accessed 2026-07-09.
18. Shakespeare Resources — FAQ & Guides — guide index (importing projects, editing code, deploying, version control, debugging, prompting) with dates; FAQ question titles (answer text not rendered). Accessed 2026-07-09.
19. Debugging in Shakespeare — 4-step debug protocol, context-overload guidance, cost-effective prompting tips. Accessed 2026-07-09.
20. Which AI Model Should I Use with Shakespeare? — model recommendations by budget, GLM 4.5 vs Claude cost comparison, local-model framing. Accessed 2026-07-09.
21. Using Version Control in Shakespeare — rollback UI, GitHub/GitLab sync workflow, terminal git access, Nostr git backup. Accessed 2026-07-09.
22. The Shakespeare Origin Story — Goose → Stacks → Shakespeare evolution narrative. Accessed 2026-07-09.
23. Ditto — Your Content. Your Vibe. Your Rules. and github.com/soapbox-pub/ditto — Ditto product description, self-host/hosted options. Accessed 2026-07-09.
24. Agora: Connecting Freedom Fighters to Uncensorable International Support — Agora product description, Bitcoin/Lightning support flow. Accessed 2026-07-09.
25. Building Agora: From Hackathon to Real-World Activism — confirms Agora built with MKStack and Shakespeare at an HRF hackathon. Accessed 2026-07-09.
26. gitlab.com/soapbox-pub/nostrhub and NostrHub — protocol/app discovery hub description. Accessed 2026-07-09.
27. Web search summaries on the nsite spec (github.com/lez/nsite, nsite.info) — static-site-on-Nostr mechanics (Blossom storage + relay pointer events); community/protocol-level source, not Soapbox-authored, used only to explain the decentralized deploy path's underlying spec. Accessed 2026-07-09.
28. nostrdeploy.com — direct DNS resolution check: ENOTFOUND, domain does not resolve. Checked 2026-07-10; cross-ref this manual's ch. 10 — MKStack, source [26], which ran the same check the same day.

NostrHub — Soapbox's Developer Hub for NIPs, Apps, and Repos

A Nostr-native site (nostrhub.io) where developers browse and propose protocol specs (NIPs), list apps, host git repos over Nostr, and discuss all three — ranked not by a company or a vote but by a "configurable meritocracy" of experts each visitor picks themselves.

Verified: 2026-07-09 · Delta pass: 2026-07-10 (repo velocity, rating-scale reconfirm, contribution-program check, MCP/agent-surface addendum)

Confidence overview: High for feature inventory, NIP kind numbers, and the login flow (source-code-verified against the live GitLab repo). High for the governance model's mechanics and quotes (primary blog post, fetched directly). Medium for distribution/audience size and cross-tool integration with Shakespeare/Ditto (no hard numbers or explicit docs found — flagged in Open Questions). Low for anything about the DVM marketplace's current (2.0-era) status.

What It Is

"It's not a democracy. It's not a dictatorship. It's a meritocracy you configure yourself." [3]

NostrHub is built by Soapbox (founder Alex Gleason) and has shipped twice. v1 launched June 10, 2025 as "the ultimate resource for Nostr developers" — NIPs, apps, repos, comments [1]. It got overrun by spam [3]. NostrHub 2.0 — a from-scratch rewrite (the GitLab repo was recreated June 11, 2026 [4]) — was announced June 28, 2026, eleven days before this was verified [3]. Everything below describes 2.0 unless marked v1-only.

Framed against its own inspiration: "We started by trying to escape GitHub's oligarchy over the NIPs. We ended up rebuilding the good parts of GitHub itself... on a substrate nobody owns, governed by a meritocracy you control." [3]

Feature Map

Signing In With Your Nostr Credentials

Since you already hold a keypair, this is the load-bearing question. NostrHub's actual login component (AuthDialog.tsx, QuickLoginDialog.tsx — read directly from the GitLab repo [8][9]) offers four paths. Ranked by safety:

No confirmation dialog gates the nsec-paste path beyond a generic warning shown only during new-key generation ("This key is your only way to access your account. If you lose it, you lose the account.") [8] — that warning is about loss, not about the security cost of pasting an existing key into a website. Treat the paste/upload options as absent for your primary identity.

First-login runbook

1. Confirm your existing nsec is already imported into a NIP-07 extension (Alby or nos2x), or have a bunker ready (nsec.app, Amber).
2. Visit nostrhub.io. If the extension is detected, you'll see a "Welcome back" dialog with a single Log in button.
3. Click it — the extension prompts you to approve getPublicKey/signEvent; your key never leaves the extension [9].
4. No extension active? Click "Other ways to log in" → paste your bunker://… URI, or click "Open signer app" to connect a mobile signer via nostrconnect:// [8].
5. Do not use the nsec-paste or file-upload option for your primary key. If you ever need to smoke-test something disposable, use a burner key there instead.

Publishing Workflows

All three content types share one shape — compose, sign, publish to a relay (or GRASP host for repos), NostrHub indexes the event:

(a) Publish/announce a git repo

1. Choose "New repo" or "Mirror from GitHub" (paste a GitHub URL to import history) [3].
2. NostrHub composes a kind 30617 repository-announcement event (name, description, clone URL, relay list, maintainers) and asks your signer to sign it [12].
3. The signed event, plus the repo data, is pushed to a GRASP server — "a relay that doubles as a git host" [3][18].
4. You get a GitHub-style page: issues (kind 1621), PRs (1618/1619), patches (1617), file browser — "except there's no GitHub underneath" [3].
5. "Claiming"/updating = publish a new 30617 (it's replaceable, keyed by its d tag) or a 30618 state event for branch/tag updates [12].

(b) List an app

1. Publish a kind 31990 handler-information event: which event kinds your app supports (k tags), per-platform URLs [13].
2. No submission queue or approval gate — self-announced. NostrHub's directory just indexes 31990/31989 events by kind [3][13].
3. Community attaches ProtonDB-style ratings and comments; ratings are ordinary Nostr events, portable to any client that reads them, not locked to NostrHub [3].

(c) Propose/discuss a NIP (long-form)

1. Write the proposal in Markdown, publish as a kind 30023 long-form article (same event kind NIP-23 defines for blog posts), with title/summary/d tags [16][3].
2. It appears under "custom NIPs" with a comment thread [1][3].
3. Anyone in your configured expert set can attach a NIP-32 label event (kind 1985) approving it [3][17].
4. Enough of your experts' approvals move it toward "official" — for you specifically. There is no single global official flag; ranking is computed per viewer from their own expert list [3].

Governance Model

Confidence: High — this section is built almost entirely from direct quotes in the 2.0 announcement [3].

• Ships with a default expert list: "fiatjaf, hodlbod, Vitor Pamplona, PABLOF7z, jb55, Kieran, mattn, and the rest." [3] Users can add or remove experts from any profile; experts display a shield badge [3].
• Approvals are ordinary NIP-32 label events (kind 1985) attached to a NIP's kind-30023 article [3][17] — not a database flag, not a merge commit.
• History, in the founder's own words: "That first NostrHub got covered in spam. Then ManiMe added web-of-trust scoring to it, which improved the quality, but it was still missing a way for a NIP to become 'official.'" [3]
• Spam control: your combined experts' follow-lists cap the visible community (reported default ~1,000 people, configurable) — "This is what kills the spam that drowned NostrHub 1.0." [3]

vs. github.com/nostr-protocol/nips: the canonical NIPs repo runs on ordinary git-maintainer authority — a small set of people (fiatjaf among them) merge pull requests, and "official" means "merged." NostrHub inverts that: anyone can publish a NIP-shaped event, nothing is ever merged or rejected centrally, and "official" is a number that recomputes per visitor depending on whose approvals they've chosen to weight. It's a discovery/ranking layer next to the git repo, not a replacement governance body for the protocol itself — the canonical spec-acceptance process still runs on GitHub.

Distribution & Discovery Value

Confidence: Medium — no traffic/audience figures were found for nostrhub.io in any source checked; treat the following as qualitative, not a growth metric.

NostrHub sits inside Soapbox's own "Toolbox" page alongside Shakespeare, MKStack, Ditto, and Nostrify [19] — its built-in audience is Soapbox's existing Nostr-developer readership, not a separate acquisition channel. Because every listing is an ordinary Nostr event, discovery is protocol-native in principle: any NIP-89-aware client can in theory surface the same kind 31990 handler event NostrHub indexes [13]. In practice, propagation is not automatic — Zapstore (Android APK store) and nostrapps.com run their own separate catalogs, and this research did not confirm they consume NostrHub's specific events [22]. A repo announced on NostrHub, by contrast, interoperates cleanly with other NIP-34 clients out of the box, because they all read the same kind 30617 event — confirmed by NostrHub's own repo being independently browsable on the competing client gitworkshop.dev [21].

Stack Relations

Operating Model & Self-Hosting

• Repo: gitlab.com/soapbox-pub/nostrhub — public, re-created 2026-06-11 (the 2.0 rewrite), last activity 2026-07-07 [4]. Velocity re-checked 2026-07-10: 866 commits in the 29 days since the rebuild — roughly 30/day sustained, hotter than even Armada's ~18/day (ch. 01) [26]. This is Soapbox's most actively poured foundation right now, not a parked launch.
• License: not declared in the GitLab project's own metadata at time of check (empty license field) [4], despite the README's "open source" framing [5]. Don't assume a specific OSS license without checking again.
• Cost: no pricing or paid tier found on the blog, product page, or repo — free to use.
• Community program: none. The full soapbox.pub blog index (60 posts, checked 2026-07-10) contains no bounty, contest, or call-for-contributions post [27]. Engagement with this ecosystem is artifact-first — you ship events, repos, or skills into it (see the addendum below); there is no formal program to apply to.
• Self-hosting: architecturally plausible — public Vite/React/TypeScript repo, .env.example present (currently just a Plausible-analytics domain toggle) [11] — but no explicit self-hosting guide was found. Inferred, not documented.
• Relay operator: not conclusively identified. NostrHub is a client over whatever relays are configured per-event (each repo's own relays tag; GRASP hosts for git specifically [18]) — no evidence ties it to Soapbox's own Ditto Relay.

Comparison

The gap worth flagging for any agent-tooling/package-distribution use case: NostrHub has no package-registry equivalent. Listing an app publishes metadata (a handler event), not a binary or a build artifact — you still need somewhere else (Shakespeare's own deploy target, a normal host, or Zapstore for Android) to actually distribute the thing.

Integration Points

Addendum (2026-07-10): The Existing MCP / Agent Surface — and the Empty Slot

Delta pass, one day after the chapter's main verification. Confidence: High — each surface below was checked live on 2026-07-10.

The split that matters: everything above reads; nothing acts. Nostrbook serves docs to agents; the skills repos teach agents conventions. No MCP server was found — from Soapbox or anyone else — that performs NostrHub's actual verbs for an agent: publish a kind 31990 handler announcement (NIP-89 app listing), push to a kind 30617 repo (NIP-34), or attach a kind 1985 quality rating (NIP-32). That niche came back empty across every surface checked this pass — Soapbox's repo inventory, the toolbox, the 60-post blog index, and both skills repos [25][26][27][28].

INFERRED, practical read: this is the highest-leverage contribution slot this manual has surfaced. The event kinds are fully documented (this chapter + ch. 06); MKStack already ships a nostr MCP server for building apps (ch. 10) but nothing for publishing into the hub; and the skills repos prove Soapbox welcomes agent-tooling contributions and even name the content-license norm (CC-BY-SA-4.0 — code licensing is murkier, ch. 10). An "acting" NostrHub MCP server would make every flow in Publishing Workflows above scriptable by any MCP-capable agent — and since no bounty or contest program exists to enter (Operating Model above), shipping exactly this kind of artifact is the engagement mechanism.

Open Questions

• Is the DVM marketplace (beta, present in the June 2025 v1 [1]) still live in the June 2026 2.0 rewrite? Not mentioned once in the 2.0 announcement [3]; nostrhub.io is a client-rendered SPA that direct fetches can't confirm either way.
• Exact default "expert" count: one summarized source said "12"; the primary blog quote itself names seven and trails off with "and the rest" [3] — precise number unresolved.
• No OSS license file was confirmed despite repeated "open source" framing in Soapbox's own copy [4][5].
• No hard traffic or registered-developer figures found for nostrhub.io anywhere in this pass.
• Whether Shakespeare or Ditto integrate with NostrHub beyond sharing a Toolbox page — not found.
• NostrHub's own default/hardcoded relay set (beyond per-event relay tags) — not found in accessible config.
• Whether Zapstore's app-listing event kind is the same NIP-89 kind 31990 NostrHub indexes, or a separate proprietary kind — Zapstore's own NIP doc page 404'd during this research; unconfirmed.

Sources

1. soapbox.pub/blog/announcing-nostrhub/ — "NostrHub: NIPs, Apps, and Repos on Nostr," June 10, 2025. Accessed 2026-07-09. Supports: v1 feature set, DVM marketplace (beta), NIP-72 community space.
2. soapbox.pub/tools/nostrhub/ — Product page. Accessed 2026-07-09. Supports: tagline, feature list, profile/reputation framing.
3. soapbox.pub/blog/nostrhub-2 — "NostrHub 2.0: A Meritocracy for Building Nostr Together," Alex Gleason, June 28, 2026. Accessed 2026-07-09. Supports: governance model (all verbatim quotes), Plan Graph, GRASP publishing flow, GitHub comparison, spam history.
4. gitlab.com/soapbox-pub/nostrhub + GitLab API project metadata. Accessed 2026-07-09. Supports: repo creation date (2026-06-11), last activity (2026-07-07), empty license field.
5. gitlab.com/soapbox-pub/nostrhub/-/raw/main/README.md — Accessed 2026-07-09. Supports: "configurable meritocracy" framing, tech stack, "NostrHub doesn't tell you what's true..." quote.
6. GitLab API repository tree, src/components/auth/ listing. Accessed 2026-07-09. Supports: existence of AccountSwitcher.tsx, AuthDialog.tsx, LoginArea.tsx, QuickLoginDialog.tsx.
7. GitLab API repository tree, root and src/ listings. Accessed 2026-07-09. Supports: React/Vite/TypeScript project shape.
8. AuthDialog.tsx source, via GitLab raw API. Accessed 2026-07-09. Supports: nsec paste, bunker URI, key-file upload, new-account generation flow, exact UI copy/warnings.
9. QuickLoginDialog.tsx source, via GitLab raw API. Accessed 2026-07-09. Supports: extension-first "Welcome back" login flow, login.extension().
10. package.json, via GitLab raw API. Accessed 2026-07-09. Supports: project named "mkstack", @nostrify/nostrify, @nostrify/react, nostr-tools, isomorphic-git dependencies.
11. .env.example, via GitLab raw API. Accessed 2026-07-09. Supports: Plausible Analytics config, no default relay found in this file.
12. NIP-34 — git stuff. Accessed 2026-07-09. Supports: kind 30617/30618/1617/1618/1619/1621/1630-1633 definitions, tag structures, clone-URL format.
13. NIP-89 — Recommended Application Handlers. Accessed 2026-07-09. Supports: kind 31989/31990 definitions, k/d/a tags, discovery workflow.
14. NIP-07 — window.nostr capability. Accessed 2026-07-09. Supports: extension signing model, getPublicKey/signEvent.
15. NIP-46 — Nostr Connect / remote signing. Accessed 2026-07-09. Supports: bunker/client roles, bunker:///nostrconnect:// URI formats, kind 24133.
16. NIP-23 — Long-form Content and [nostrhub.io/kind/30023/ search index result]. Accessed 2026-07-09. Supports: kind 30023 definition; NostrHub's use of it for custom NIPs.
17. NIP-32 — Labeling (via search index). Accessed 2026-07-09. Supports: kind 1985, l/L tags, distributed-moderation use case.
18. ngit.dev/grasp/ — "Grasp: Git Repositories Authorized via Signed-Nostr Proofs." Accessed 2026-07-09. Supports: GRASP definition, two-service model (Smart HTTP Git + Nostr relay), implementations (ngit-relay, gitnostr.com).
19. soapbox.pub/toolbox. Accessed 2026-07-09. Supports: full Soapbox tool list, one-line descriptions, Ditto Relay/NostrHub/Nostrbook positioning.
20. gitworkshop.dev and gitworkshop.dev/about (via search index). Accessed 2026-07-09. Supports: gitworkshop.dev's own description as "Decentralized Git," first NIP-34 draft implementation, pairing with ngit.
21. gitworkshop.dev/[email protected]/nostrhub. Accessed 2026-07-09. Supports: NostrHub's own repo is independently browsable via a competing NIP-34 client, confirming cross-client interoperability.
22. zapstore.dev and github.com/zapstore/zapstore (via search index). Accessed 2026-07-09. Supports: Zapstore's separate Android-APK-focused catalog model. Note: zapstore.dev/docs/nips/app/ returned HTTP 404 during this research — exact event-kind overlap with NIP-89 unconfirmed.
23. nostrhub.io — direct fetch. Accessed 2026-07-09. Supports: tagline only ("Build Nostr Together") — site is a client-rendered SPA, body content not retrievable via direct fetch.
24. Search-engine index results for site:nostrhub.io (Google/Bing snippets covering /apps/, /01/, /kind/30023/, /EE). Accessed 2026-07-09. Supports: existence and URL patterns of the browse-by-kind and per-NIP page structure, used because the live SPA could not be fetched directly.
25. nostrbook.dev — direct fetch. Accessed 2026-07-10. Supports: Nostrbook live as a docs site + MCP server for NIP/kind/tag documentation; a read surface only — no publish/act capability found.
26. GitLab API project metadata re-check for soapbox-pub/nostrhub. Accessed 2026-07-10. Supports: 866 commits in the 29 days since the 2026-06-11 recreation.
27. soapbox.pub/blog — full post index, 60 posts. Accessed 2026-07-10. Supports: no bounty, contest, or call-for-contributions program anywhere in the blog's history; no announcement of a NostrHub-acting MCP server.
28. github.com/soapbox-pub/nostr-skills — Accessed 2026-07-10. Supports: Claude/agent skills for Nostr development, CC-BY-SA-4.0, README explicitly inviting community contributions.
29. github.com/soapbox-pub/openclaw-skills — Accessed 2026-07-10. Supports: companion OpenClaw agent-skills repo in the same CC-BY-SA-4.0 skills family.

06 — Nostr Foundations for Operators

This chapter is connective tissue: the protocol-level concepts underneath every Soapbox product a builder will touch — Ditto (community/company ops) [1], Agora (fundraising) [2], Shakespeare (AI-built sites) [3], NostrHub (publishing) [4]. Other chapters cover each product's verdict in depth; this one covers the NIPs (Nostr Implementation Possibilities) those products are built from, so decisions in one tool make sense in the others. Verified live against the nostr-protocol/nips repo on 2026-07-09 — the spec has moved since 2025 training data, notably several deprecations below.

Worked examples throughout this chapter (a company domain, an operator's day-1 checklist, an agent-dispatch pattern) use the maintainers' own setup — trespies.dev, the operator Cruz, the DojoGenesis agent stack — as concrete, real data instead of placeholders. Swap in your own domain, team, and orchestrator wherever you see them.

Amended: 2026-07-10 (v2 wave — NIP-62, NIP-55/17/29/42/77 currency, onchain zaps, signer additions, local-first caching).

1. Identity & Keys for a Company

Confidence: High — verified against NIP-01, NIP-05, NIP-07, NIP-46, NIP-49, NIP-55 source, plus GitHub PR history for key migration.

A Nostr identity is one keypair: a private key (nsec) and a public key (npub) — bech32-encoded, human-readable wrappers around a raw secp256k1 hex key [5][6]. The npub is the identity. There is no username/password, no account database, no "forgot password" flow. Whoever holds the nsec is the account, permanently, on every relay and client at once.

Why this matters more than it sounds like it should: there is no ratified key-rotation mechanism. DOCUMENTED: "there is no native, widely-adopted key rotation or recovery in Nostr. Your public key is your identity, so you cannot update or rotate it while keeping the same account" [7] — a 2023 migration proposal (NIP-41) never merged [8]. If a key leaks, recovery is social: publish a note from the old key pointing followers to a new one, and wait for re-follows. NIP-26 (delegated signing), once floated as a fix, is now deprecated — "unnecessary burden" [5]. Treat nsec loss as identity loss, not a support ticket.

Key custody decision tree

NIP-07 vs NIP-46 — the two signer models

Rationale straight from the spec: "Private keys should be exposed to as few systems - apps, operating systems, devices - as possible as each system adds to the attack surface" [10].

NIP-55 — the third signer standard

NIP-07 and NIP-46 aren't the whole story. NIP-55 standardizes signing through Android's intent system: a client sends a sign request as an Android Intent, the signer app — not the requesting app — shows the approval prompt and returns the signature, so the private key never enters the requesting app's process [46]. Status is draft optional, the same maturity marker most working NIPs in this manual carry, and Amber is the reference implementation [13][46]. Soapbox's own key-management guidance draws the line explicitly: apps should implement NIP-07, NIP-55, and NIP-46 so a site or app can "request signatures... without ever seeing the private key itself" — and never fall back to asking for a raw nsec [47]. Treat that trio as the minimum bar for anything you build that touches Nostr keys.

Two signer tools worth knowing that are newer than most Nostr key-management writeups:

• Soapbox Signer (Chrome/Firefox extension, announced Dec 2025) — NIP-07, multi-identity (switch between several npubs from one extension), per-domain permission grants, both NIP-04 and NIP-44 encryption, and identity export as JSON/CSV for backup or migration [48].
• Divine's Keycast — a managed remote-signer service behind Divine, a Nostr-native short-video app (iOS + Android/Flutter): users create an account or import an nsec once, keys are encrypted server-side, and apps request signing via OAuth-style grants over a NIP-46 bunker URL — the pattern for "feels custodial, isn't underneath" signing [49].

NIP-05 — your name@domain identifier

NIP-05 maps [email protected] to a pubkey via a JSON file at /.well-known/nostr.json [14]:

{
  "names": {
    "cruz": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9"
  },
  "relays": {
    "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9": [
      "wss://relay.example.com",
      "wss://relay2.example.com"
    ]
  }
}

Clients GET https://trespies.dev/.well-known/nostr.json?name=cruz and check the returned pubkey matches your profile's claimed pubkey [14]. Two rules that trip people up: the endpoint must not redirect, and the local-part is restricted to a-z0-9-_. [14]. Critically, this is identification, not verification — NIP-05 "is not intended to verify a user, but only to identify them" [14]; it proves domain control, nothing about the person.

Two paths for @trespies.dev:

• Static file — trespies.dev already exists as a hosted static site; dropping a .well-known/nostr.json there is a no-server, static-hosting-compatible change [14]. This is the practical path for TresPies today.
• Ditto self-service — if community ops move to a self-hosted Ditto instance, Ditto grants NIP-05 self-service under its own domain, with admin approve/deny per request [15]. That's a different domain identity (e.g. @community.trespies.dev) than the static root-domain file — decide which one is canonical before publishing both.

Org-account patterns

[INFERRED from NIP-46 + NIP-05 mechanics — no single spec source covers "how a company does this."] Nostr has no built-in org-account primitive; every event needs exactly one signing key. Two patterns cover most real usage:

Most orgs blend both — a brand account for official posts, personal NIP-05 identities on the same domain for individuals. Pick the brand-account bunker's admin (who can grant/revoke signer access) before anyone posts as @trespies.

Day 1 with your new credentials — checklist

1. Confirm your npub/nsec pair is the one you were issued; do not generate a second one by accident in a different client.
2. Back up nsec offline immediately — encode it as ncryptsec (NIP-49: scrypt-derived key, XChaCha20-Poly1305 encryption) with a strong password [16]; store the password in a password manager and the encrypted string somewhere offline (not in this repo, not in Slack).
3. Install a signer — NIP-07 extension (Alby or nos2x) for daily browser use; if you'll ever touch a second device, set up a NIP-46 bunker (nsec.app) now rather than exporting raw nsec later.
4. Publish your profile — kind 0 event: name, about, picture, and (once a wallet exists — Section 4) a lud16 lightning address.
5. Set up NIP-05 — publish .well-known/nostr.json on trespies.dev per the format above; add the nip05 field to your kind 0.
6. Publish a relay list — kind 10002 (NIP-65), 2-4 write relays + a few read relays (Section 2).
7. First post — a kind 1 note, to confirm the full round-trip: signer signs → event lands on your write relays → visible on njump.me or any client.

2. Relays

Confidence: High — NIP-65, NIP-42, NIP-77 fetched directly; NIndexedDB confirmed against its own source file (2026-07-10); relay ecosystem facts cross-checked across two sources.

A relay is a WebSocket server that stores and forwards events — dumb by design, no protocol-level authority. Clients choose which relays to trust. NIP-65 (Relay List Metadata) lets a user publish a kind 10002 event listing preferred relays, each optionally marked read or write [17].

"When downloading events from a user, clients SHOULD use the write relays of that user." [17]

That's the outbox model: publish to your write relays, look for someone's posts on their write relays, look for mentions of them on their read relays — a directed lookup instead of querying every relay for everything. Spec guidance: keep the list small, 2-4 relays per category [17].

NIP-42 (relay auth) and NIP-77 (sync efficiency)

Two more relay-level mechanics worth knowing before picking a relay mix. NIP-42 is ephemeral challenge-response authentication: the relay sends ["AUTH", <challenge>], the client signs a throwaway kind-22242 event binding that challenge to the relay URL and sends it back [50]. Relays use this to gate access — restrict publishing to a whitelist, limit a private-message subscription to just its participants, or require auth before serving any request at all [50]. It's how a paid relay actually enforces "paid" instead of just asking nicely.

NIP-77 (negentropy) solves a different problem: efficient re-sync. Instead of a client re-downloading everything or diffing by event ID, negentropy does range-based set reconciliation — client and relay exchange compact fingerprints of what they already have and transfer only the gap [51]. The protocol originated in Doug Hoyte's strfry relay before being written up as NIP-77 [52]; independent client-side implementations exist too, e.g. @nostr-dev-kit/sync, which reports 10-100x bandwidth reduction over plain REQ/EVENT sync once both sides are mostly caught up [52]. Caveat that matters operationally: merged into the NIPs repo is not the same as deployed — most relays don't implement NIP-77 yet, so treat it as a bonus when the relay on the other end supports it, not a default to build around.

Local-first caching — NIndexedDB

Everything above is about which server-side relay to trust. There's a client-side complement: NIndexedDB, from @nostrify/indexeddb, is a first-party persistent browser cache that implements the same NStore interface as a relay or any other Nostrify storage — so it drops in as a swap, not a rewrite [60]. It supports the full Nostr filter set (ids, authors, kinds, single-letter tag filters, since/until, limit, and search), resolves supersession correctly (a newer replaceable/addressable event overwrites the old one in the cache, so queries never surface a stale kind-0 profile), and applies NIP-09 deletion requests on write [60]. When IndexedDB itself isn't available — Apple's Lockdown Mode disables it, along with Service Workers and WASM, as part of the exact threat model Lockdown Mode targets [61] — NIndexedDB degrades to a silent no-op (event() does nothing, query() returns empty) instead of throwing, so an app built against it doesn't crash under Lockdown, it just stops caching [60]. The rest of the NStore/NRelay interface family — signer swaps, moderation policies, the other storage backends — is Chapter 11's job; this is the one piece operators need now, because it's the practical answer to "does the app work offline, and does it degrade gracefully when it can't."

Moderation implication: content policy lives at the relay + client layer, not a platform layer (expanded in Section 6). Running your own relay is how TresPies enforces house rules on its own community — but nothing stops content being copied to other relays first. Deletion requests (NIP-09, master table) are, by default, a request — not a guarantee; NIP-62 (Section 6) exists for a stronger, MUST-honor version, but adoption is thin enough that NIP-09's advisory norm is still the safer planning assumption.

3. Event Model & Content Kinds

Confidence: High for kind mechanics (direct NIP fetches); Medium for "which tool uses which" (mix of docs + search-derived, current as of 2026-07-09; adoption claims for NIP-17/NIP-29 refreshed 2026-07-10).

Every Nostr action is the same JSON envelope — id, pubkey, created_at, kind, tags, content, sig [6] — differentiated only by kind. An operator mostly touches these (NIP numbers cited individually below; kind registry per [5]):

NIP-04 vs NIP-17 — currency verdict

NIP-04 is deprecated — "Encrypted Direct Message (superseded by NIP-17)" [5]. NIP-17 wraps a plain (unsigned) message in a seal (kind 13) then a gift wrap (kind 1059), per NIP-59 [22][23]. The privacy gain is real: "Participant identities, each message's real date and time, event kinds… are all hidden from the public" [22] — each gift wrap uses a random one-time key so relays can't correlate messages by sender, and timestamps are randomized per layer to defeat timing analysis [23]. NIP-04 leaked all of that — sender, recipient, and timing were public even though content was encrypted. Any new DM feature should be NIP-17, full stop.

Adoption has moved from "the spec says so" to "the clients actually ship it": Amethyst, Primal, Nostur, Damus, noStrudel, and Coracle all run NIP-17 as their primary DM protocol now, and Amethyst's newer work extends the same gift-wrap machinery to sealed private replies on regular notes, not just 1:1 DMs [54]. Mostro — the P2P Bitcoin/Lightning exchange built on Nostr — made the same move at the protocol level: Mostro Protocol v2 (mostro-core v0.13.0) replaced its old relay-routed order messaging with NIP-44-encrypted, gift-wrapped kind-14 messages bound to a per-trade key, so relays now see only encrypted envelopes instead of order/dispute/settlement metadata [55]. Two different products, same direction of travel.

Watch item, not a recommendation yet — and already more moved-on than expected: a parallel track for group E2EE exists, adapting MLS (Messaging Layer Security, the Signal-Protocol successor standardized as RFC 9420) for Nostr. This is exactly the kind of ground that shifts between verification passes: the original proposal, NIP-EE, is now itself marked unrecommended in the live NIPs repo, superseded by a separate, non-NIP-numbered spec called the Marmot Protocol [56]. Marmot is still experimental but already has real implementations moving — MDK (its Rust reference stack), marmot-ts, and apps including White Noise, Pika, and Vector [57]. Don't build on NIP-EE directly; if group E2EE becomes a real requirement, evaluate Marmot instead, and re-verify its status before committing to it.

NIP-72 vs NIP-29 — currency verdict

Sharper than expected: NIP-72 is now marked unrecommended in the core spec — "unrecommended: try NIP-29 instead" [24]. Steering has moved from moderator-approval (Reddit-style) toward relay-enforced membership (Discord-style), though both still have active client support today (NIP-72: Amethyst, Nostrudel, Satellite; NIP-29: 0xChat, chachi.chat, groups.nip29.com, and Flotilla — partially [21]). NIP-29 itself is still draft optional, the same maturity marker NIP-72 carries [21] — steering intent isn't the same as ratified stability. Ditto does neither exactly — it runs Mastodon-style server/domain moderation (admins, reports, NIP-05 self-service) today, with NIP-29-style groups on its roadmap [15]. Operator read: don't build new tooling against NIP-72; use Ditto's current server-level moderation if it fits, and wait for its NIP-29 groups for Discord-style team space. For a consumer app specifically: NIP-29's implementation list is real but still small and still drafting — not a universal-adoption bet yet, the way NIP-65 or NIP-17 now are.

4. Payments

Confidence: High for NIP-57/47/60/61 mechanics (direct spec fetches) and for kind 8333 onchain zaps (Ditto reference doc fetched directly, 2026-07-10); Medium for wallet-option currency (fast-moving market, verify before funding anything).

Zap flow (NIP-57)

A zap request (kind 9734) is signed by the sender but sent directly to the recipient's LNURL callback — it is not itself published to relays [25]. Once paid, the recipient's Lightning service publishes a zap receipt (kind 9735) to the relays named in the request [25] — that receipt is the public, verifiable "this got paid" record clients render as a zap.

Nostr Wallet Connect (NIP-47)

NWC lets an app pay/check-balance/list-transactions against a wallet without ever holding the wallet's keys — connection is a nostr+walletconnect:// URI (wallet pubkey + per-client secret + relay) [26]. The wallet service runs as an always-on process; the client stores only its own secret and talks to it over relays [26] — this is what lets you connect one Alby Hub wallet to several apps with separate, revocable, spend-limited grants per app.

Cashu / nutzaps (NIP-60 / NIP-61) — status: active, still maturing

Both are live, non-deprecated NIPs [5]. NIP-60 stores an encrypted "wallet in relays" — mint references and unspent ecash proofs as kind 17375/7375/7376/7374 events, so wallet state follows the user across apps [27]. NIP-61 "nutzaps" collapse payment and receipt into one object: a Cashu token locked to the recipient's pubkey (P2PK) is the payment and the proof, no separate receipt needed [28]. Newer and less battle-tested than NIP-57 zaps; promising, not yet default.

Onchain zaps (kind 8333) — a third payment mechanism

As of Ditto 2.12 (shipped, per Soapbox's own post, May 2026) there's a third way to move value on Nostr, alongside Lightning/NIP-57 and Cashu/NWC [58]: onchain zaps — direct on-chain Bitcoin transfers, using kind 8333, defined as "attestation that an on-chain Bitcoin transaction paid a Nostr event or profile" [59]. The mechanism leans on a property of Nostr keys that isn't obvious until pointed out: because both Nostr and Bitcoin use secp256k1, a Nostr public key can double directly as a Bitcoin address — no separate wallet setup for sender or receiver [58]. Ditto layers Silent Payments on top for privacy — deriving a fresh, unlinkable receiving address per payment from a single published key, so on-chain analysis can't trivially cluster a recipient's zaps together [58]. Practical cost, in the team's own words: "It was costing $0.24 to send a transaction. For most of its life the average Nostr transaction was about $0.02" [58] — an onchain zap costs noticeably more than a typical Lightning-based zap, a tradeoff the team argued over before shipping and judged acceptable once you're sending amounts larger than a tip; onchain fees also float with mempool conditions, so treat $0.24 as a snapshot, not a constant. For anyone building rather than just operating: this is the same territory MKStack's onchain-bitcoin skill covers (Chapter 12) — worth knowing it exists before reinventing it.

Practical wallet options (verify before moving real money)

Alby's own guidance signals the direction: they're "phasing out Alby's shared [custodial] wallet" for Alby Hub [31] — self-custody is where the tooling is consolidating in 2026, not custodial web wallets.

Tax reality (flag, not advice)

Sats received for goods/services are ordinary income at fair market value in USD on the date received — for a sole proprietorship, Schedule C, subject to self-employment tax [32]. The $10,000 Form 8300 cash-reporting trigger technically applies to crypto too, though enforcement is currently paused pending final regulations [32]. Not tax advice — get an accountant before treating zaps as real revenue.

5. Files & Media — The Storage Substrate

Confidence: High — Blossom BUD structure and NIP-96 deprecation directly confirmed from source.

NIP-96 vs Blossom — currency verdict

Settled. NIP-96 (HTTP File Storage Integration) carries an explicit deprecation banner: "unrecommended: deprecated in favor of NIP-B7" [33] — NIP-B7 being Blossom, which was folded into the core NIPs index as an active spec [5]. Blossom won. Don't build new file-upload integrations against NIP-96.

How Blossom works

Blossom is an HTTP-endpoint spec for storing blobs addressed by their SHA256 hash, authorized using the uploader's Nostr keypair [34] — same file, same identity everywhere; upload/delete rights ride on Nostr auth, not a platform account. The spec is a stack of BUD (Blossom Upgrade Document) documents:

Mirroring (BUD-04) is what makes this resilient: if a file's home server disappears, any client can pull it from another server in the uploader's published list [34] — same file, same hash, different host. Ditto's product materials describe its media layer as Blossom-integrated [1]; the specific server hostname surfaced in search wasn't independently confirmable this session (install-guide fetch 404'd) — see Open Questions.

nsite — static sites on Blossom

nsite serves a full static website from a Blossom-hosted blob set, with the path-to-file mapping published as Nostr events under the owner's npub — "a static site deployed under your npub, where the raw data is stored on blossom servers, and the mapping from path to sha256 of the content is stored on relays" [35]. Effect: a website with no traditional host — if one gateway blocks it, it resolves through another, because resolution is relay-based, not DNS/server-based [35]. Directly relevant if Shakespeare-built output [3] ever needs a censorship-resistant deployment target beyond a conventional host.

Media metadata in posts (NIP-92)

An imeta tag attaches structured metadata — MIME type, SHA256 hash, dimensions, blurhash, alt text — to a URL inside a kind 1 note's content [36], so clients can render previews and verify integrity before fetching.

File-tool maturity

6. Trust & Safety

Confidence: High — NIP-56, NIP-32, NIP-51, NIP-09, NIP-62 fetched directly; NIP-62's named third-party implementations are REPORTED (search-derived), not all independently confirmed shipped.

Three separate primitives, each doing one job:

• NIP-56 Reporting — kind 1984 events flag a pubkey or note under one of seven categories: nudity, malware, profanity, illegal, spam, impersonation, other [38]. The spec explicitly warns relays against fully-automated moderation on report volume alone — "reports are easily manipulated"; trusted moderator judgment is the intended backstop [38].
• NIP-32 Labeling — kind 1985 events attach a namespaced label (L tag) and value (l tag) to an event, pubkey, relay, or topic [39]. Broader than moderation — also used for content classification and licensing — but it's the primitive a moderation dashboard would consume.
• NIP-51 Mute Lists — kind 10000, a personal list of pubkeys/hashtags/words/threads a user doesn't want to see [40]; can hold private (encrypted) entries alongside public ones.

NIP-09 vs NIP-62 — currency verdict

Reporting, labeling, and muting (above) are signals — they don't remove anything by themselves. Actual deletion is a separate, smaller pair of primitives, and the two are not equivalent:

• NIP-09 (Event Deletion Request) — a client asks relays to drop an event by publishing a kind-5 request naming it. Advisory only: the NIP uses SHOULD language, relays are free to ignore it, and nothing stops a relay that already forwarded the event from having it live on elsewhere. This is the deletion behavior most of the ecosystem has today.
• NIP-62 (Request to Vanish) — a materially stronger primitive, merged into the spec February 19, 2025 [53]. Relays that implement it MUST fully delete every event from the requesting pubkey (not just one named event), MUST ensure deleted events aren't re-broadcast, and — the clause with real teeth — paid or access-restricted relays MUST honor the request regardless of the requester's account status [53]: a relay can't hold data hostage by banning the account first. Requests can be targeted (naming specific relay URLs) or global (["relay", "ALL_RELAYS"], broadcast as widely as possible) [53]. NIP-62 also SHOULDs relays into deleting NIP-59 gift wraps addressed to the pubkey — a vanish request can reach into someone's DMs, not just their public notes [53].

Adoption is thin. NIP-62 is real and legally meaningful wherever "right to be forgotten" regimes apply, but implementation is still early: rust-nostr has shipped it across all three of its storage backends (LMDB, SQLite, in-memory); the nostrcheck-server relay module and the Nestr client both show it as planned/in-progress per project trackers, not confirmed shipped [53]. Ditto's own support wasn't confirmed either way this session — verify directly before promising a user (or a regulator) that "vanish" actually works on your relay. Practical read: NIP-09 is still the safe default assumption for "will this actually disappear"; reach for NIP-62 when a deletion promise needs to be a MUST, not a SHOULD, and confirm relay-by-relay support before relying on it.

Why moderation is relay + client level, not platform level: no central authority can remove content network-wide. A relay operator (Ditto, in TresPies' case) decides what their relay stores, and clients decide what they render — reports and labels are signals those parties act on, not enforcement with teeth beyond one relay's boundary [15]. Practical consequence: you fully control your own relay's front door for events you're willing to purge on request — NIP-62 gives that control real force, NIP-09 gives it a polite ask — but neither can make content vanish once it has propagated to a relay outside your control.

7. Discovery & App Wiring

Confidence: Medium — NIP-89/34 mechanics are High (direct fetch); the DVM ecosystem's current health is a mix of DOCUMENTED spec status and REPORTED community activity.

NIP-89 (Recommended Application Handlers) is Nostr's "open in app" mechanism: apps publish kind 31990 advertising which event kinds they handle; users or contacts publish kind 31989 recommending a handler [41]. Same mechanism DVM marketplaces use for provider discovery (below).

NIP-34 (git over Nostr) replaces GitHub's centralized model with relay-published repo announcements (kind 30617), patches (kind 1617), and issues (kind 1621) [42] — not in the Soapbox stack directly, but a pattern any team could use for censorship-resistant code collaboration.

NIP-05 as lightweight SSO: since a NIP-05 identifier cryptographically ties a domain to a pubkey [14], "Login with Nostr" flows ask a user to sign a challenge event and check it resolves to the claimed name@domain — no password, no OAuth provider. Any app you build (via Shakespeare or otherwise) can use this for low-friction auth.

DVMs (NIP-90) — worked example: the agent-dispatch angle

Currency verdict: the base spec is deprecated. Its own file warns: "this got totally out of control, prefer use-case-specific microstandards" [43], unrecommended throughout. No single named successor — but the pattern moved rather than died: a dedicated nostr-protocol/data-vending-machines repo maintains the kind registry (5000-5999 requests → 6000-6999 results → 7000 status) as narrow per-job "microstandards" [44]. Discovery still runs through NIP-89 — newer projects (e.g. Agentry) auto-discover DVM providers via kind 31990 [45].

Worked example — if you run an agent orchestrator (DojoGenesis Gateway, or any other agent-dispatch stack): DVMs are structurally the same shape as an internal job-dispatch queue (the maintainers' own is dojo_agent_dispatch) — post a job, providers compete, deliver, get paid in sats instead of an internal ledger. Real and live, worth scouting for any orchestrator looking for an open, cross-network job market — but the "unrecommended" base spec plus an informally-governed sister repo means treat it as an early probe, not a dependency.

8. Master NIP Reference Table

The protocol reference card for this manual. Status reflects the live nostr-protocol/nips repo as of 2026-07-09 [5], amended 2026-07-10 with NIP-62, NIP-55, NIP-42, NIP-77, and kind 8333 (onchain zaps) — see the Amended note at the top of the chapter. Individual NIPs are cited in the relevant prose sections above; this table is the consolidated index.

Open Questions

• Whether Agora emits actual NIP-57 zap receipts, or uses a simpler direct wallet-to-wallet Lightning flow with Nostr only for identity/comms — Agora's own materials describe "wallet-to-wallet" Bitcoin movement without confirming zap-event mechanics [2]; verify in the Agora-specific chapter.
• Whether Ditto's media pipeline specifically points at blossom.ditto.pub — this hostname surfaced in preliminary search results but the primary Ditto self-hosting doc 404'd on direct fetch this session; the general claim "Ditto integrates with Blossom" is solid [1], the specific hostname is REPORTED, not independently confirmed.
• Exact reason NIP-06 (mnemonic-seed key derivation) was deprecated — confirmed deprecated in the index [5], but the deprecation-note text itself wasn't fetched; doesn't change the operator recommendation (use NIP-49 ncryptsec for backup) but worth closing out if seed-phrase import ever comes up in a signer's UI.
• Whether Ditto's planned NIP-29 groups feature has shipped by the time an operator would adopt it — roadmap item as of the fetched blog post [15], not yet confirmed live.
• DVM ecosystem health beyond the spec-status question — Agentry and similar discovery projects surfaced in search but weren't independently verified for maturity beyond their own landing page [45]; treat any DVM integration as a probe, not a plan.

Sources

1. Soapbox — Ditto product page, plus Announcing Ditto and Ditto Server Keypair docs — accessed 2026-07-09 — Ditto architecture (relay + web UI + Mastodon API), Blossom integration, self-hosted relay.
2. Soapbox — Agora and Agora: Connecting Freedom Fighters to Uncensorable International Support — accessed 2026-07-09 — Agora product description, non-custodial wallet-to-wallet design, Nostr-as-comms-layer framing.
3. Soapbox — Shakespeare and Announcing Shakespeare — accessed 2026-07-09 — AI website builder on Nostr, NSP model, AGPL license.
4. Soapbox — NostrHub — accessed 2026-07-09 — NIP/app/repo discovery hub description.
5. nostr-protocol/nips README (NIP index + kind registry) — accessed 2026-07-09 — full NIP list, deprecation status, complete event-kind registry.
6. NIP-01: Basic protocol flow description — accessed 2026-07-09 — event structure, key basics, kind 0 definition.
7. Nostr Key Management: Complete Guide — accessed 2026-07-09 — current-practice statement on key rotation absence.
8. NIP-41: simple account migration (unmerged PR #829) — accessed 2026-07-09 — confirms migration proposal never ratified.
9. NIP-07: window.nostr capability for web browsers — accessed 2026-07-09 — extension API, methods.
10. NIP-46: Nostr Remote Signing — accessed 2026-07-09 — bunker/nostrconnect flow, roles, rationale quote.
11. Best Nostr Browser Extensions 2026 — comparison — accessed 2026-07-09 — Alby vs nos2x positioning.
12. nsec.app — accessed 2026-07-09 — non-custodial key storage/remote signer product description.
13. Amber (GitHub) — accessed 2026-07-09 — Android NIP-46 signer, supported client list.
14. NIP-05: Mapping Nostr keys to DNS-based identifiers — accessed 2026-07-09 — exact .well-known/nostr.json format, verification flow, caveats.
15. Creating Curated Communities on Nostr with Ditto — accessed 2026-07-09 — NIP-05 self-service, moderation model, NIP-29 roadmap note.
16. NIP-49: Private Key Encryption (ncryptsec) — accessed 2026-07-09 — password-encrypted key backup spec.
17. NIP-65: Relay List Metadata — accessed 2026-07-09 — outbox model, read/write markers.
18. How to Choose Nostr Relays — accessed 2026-07-09 — relay-mix recommendations, paid relay examples/pricing.
19. Soapbox Toolbox — accessed 2026-07-09 — full Soapbox product inventory, Relay Kit / Stacks descriptions.
20. NIP-53: Live Streaming and Spaces — accessed 2026-07-09 — kind 30311 structure.
21. Comparing Nostr Group Implementations — Nostrbook — accessed 2026-07-09 — plain-English NIP-29 vs NIP-72 comparison, client support lists.
22. NIP-17: Private Direct Messages — accessed 2026-07-09 — gift-wrap DM design, kind 14/15.
23. NIP-59: Gift Wrap — accessed 2026-07-09 — rumor/seal/wrap layering, metadata protection.
24. NIP-72: Moderated Communities — accessed 2026-07-09 — verbatim deprecation notice, original community model.
25. NIP-57: Lightning Zaps — accessed 2026-07-09 — zap request/receipt flow.
26. NIP-47: Nostr Wallet Connect — accessed 2026-07-09 — connection URI, methods, roles.
27. NIP-60: Cashu Wallet — accessed 2026-07-09 — wallet-in-relays architecture, kind numbers.
28. NIP-61: Nutzaps — accessed 2026-07-09 — payment-as-receipt design, kind 9321.
29. Alby Hub — accessed 2026-07-09 — self-custodial wallet product description.
30. The 6 different Lightning backends for Alby Hub — accessed 2026-07-09 — backend options (LDK, LND, Greenlight, Phoenixd, Breez SDK, Cashu mint).
31. Embrace Alby Hub — phasing out Alby's shared wallet — accessed 2026-07-09 — custodial-to-self-custodial market shift, verbatim quote.
32. IRS: Report digital asset income — accessed 2026-07-09 — tax treatment of crypto/digital-asset income, Form 8300 status.
33. NIP-96: HTTP File Storage Integration — accessed 2026-07-09 — verbatim deprecation notice pointing to NIP-B7/Blossom.
34. Blossom protocol README / BUD specs — accessed 2026-07-09 — blob addressing, BUD-01 through BUD-12 overview, mirroring.
35. Nsite.info — Let them eat static — accessed 2026-07-09 — nsite mechanics, Blossom + relay resolution; also source for nsite CLI tooling landscape.
36. NIP-92: Media Attachments Metadata (imeta) — accessed 2026-07-09 — imeta tag fields.
37. blossom-drive (GitHub) — deprecation note pointing to Bouquet — accessed 2026-07-09 — file-manager tool status.
38. NIP-56: Reporting — accessed 2026-07-09 — kind 1984 structure, report categories.
39. NIP-32: Labeling — accessed 2026-07-09 — kind 1985 structure, namespaces, use cases.
40. NIP-51: Lists — accessed 2026-07-09 — mute list and other standard list kinds.
41. NIP-89: Recommended Application Handlers — accessed 2026-07-09 — kind 31989/31990 discovery mechanism.
42. NIP-34: git stuff — accessed 2026-07-09 — repo/patch/issue event kinds.
43. NIP-90: Data Vending Machines — accessed 2026-07-09 — verbatim deprecation notice, original job-marketplace design.
44. nostr-protocol/data-vending-machines (kind registry repo) — accessed 2026-07-09 — successor governance model for DVM kinds.
45. Nostr Agent Network — Agentry — accessed 2026-07-09 — example of DVM provider discovery via NIP-89.

Amendment pack sources (2026-07-10 v2 wave):

1. NIP-55: Android Signer Application — accessed 2026-07-10 — status header (draft optional), Intent/Content Resolver/Web signing methods.
2. Managing Nostr Keys — Soapbox Blog — accessed 2026-07-10 — NIP-07/NIP-55/NIP-46 framing as the three signing standards apps should implement, Amber description.
3. Announcing Soapbox Signer — accessed 2026-07-10 — Dec 7 2025 launch, Chrome/Firefox extension, multi-identity, per-domain permissions, NIP-04/NIP-44, JSON/CSV identity export.
4. Divine — Open Source, Divine (GitHub org), Keycast (GitHub) — accessed 2026-07-10 — Nostr-native short-video app; Keycast as its OAuth-style NIP-46 remote-signer service; iOS App Store + Flutter Android build.
5. NIP-42: Authentication of Clients to Relays — accessed 2026-07-10 — ephemeral kind-22242 challenge-response flow, access-gating use cases.
6. NIP-77: Negentropy Syncing — accessed 2026-07-10 — range-based set reconciliation spec, draft status.
7. @nostr-dev-kit/sync (npm), hoytech/negentropy — accessed 2026-07-10 — negentropy's origin in Doug Hoyte's strfry relay; 10-100x bandwidth-reduction claim; client-side NIP-77 implementation.
8. NIP-62: Request to Vanish, merge PR #1256 — accessed 2026-07-10 — MUST-delete / no-rebroadcast / paid-relay language verbatim; merge date (2025-02-19) confirmed directly via repo commit history; third-party implementation status (rust-nostr, nostrcheck-server, Nestr) cross-checked via search — REPORTED, not all independently confirmed shipped.
9. Amethyst (GitHub) — accessed 2026-07-10 — NIP-17 as primary DM protocol across major clients (Amethyst, Primal, Nostur, Damus, noStrudel, Coracle); gift-wrapped private-note replies — search-derived, current release cycle.
10. Mostro (GitHub) — accessed 2026-07-10 — Mostro Protocol v2 / mostro-core v0.13.0 migration to NIP-44 gift-wrapped kind-14 trade messaging.
11. NIP-EE: E2EE Messaging using MLS — accessed 2026-07-10 — status header (final unrecommended optional), verbatim supersession notice pointing to the Marmot Protocol.
12. Marmot Protocol (GitHub) — accessed 2026-07-10 — NIP-EE's successor; experimental status, named implementations (MDK, marmot-ts, White Noise, Pika, Vector).
13. Onchain Zaps in Ditto — Soapbox Blog — accessed 2026-07-10 — May 2026 post; Ditto 2.12 wallet, Nostr-keys-as-Bitcoin-addresses mechanic, Silent Payments, verbatim $0.24-vs-$0.02 fee quote.
14. Ditto Nostr Reference — accessed 2026-07-10 — kind 8333 definition ("attestation that an on-chain Bitcoin transaction paid a Nostr event or profile").
15. NIndexedDB.ts (soapbox-pub/nostrify) — accessed 2026-07-10 — full source of @nostrify/indexeddb's NStore implementation: filter support, replaceable/addressable supersession, NIP-09 deletion-on-write, IndexedDB-unavailable no-op behavior.
16. About Lockdown Mode — Apple Support — accessed 2026-07-10 — corroborates that Lockdown Mode disables IndexedDB-dependent web functionality, the real-world trigger for NIndexedDB's no-op path.

07 — Integration Playbook: Running (and Modding) the Stack

How TresPies/DojoGenesis actually operates on the Soapbox stack — four runbooks, one integration matrix, the build opportunities, and the TresPies modded-stack blueprint (steering direction, 2026-07-09).

Verified: 2026-07-09. Synthesized in the main thread from chapters 01–06 and 08–09 (each chapter carries its own numbered primary sources; this chapter cites chapters). Facts cross-checked across chapters; two contradictions found and resolved during assembly (Armada existence — ch. 02 corrected; Blossom Drive deprecation — ch. 02 aligned to ch. 06).

0. The operating rule that governs everything: the AGPL boundary

Soapbox apps are AGPL-3.0: a modded, client-facing deployment must publish its modifications (ch. 01). The rule: i18n/viz mods live in the open layer (good citizenship in a grant-funded ecosystem, and it's the build-in-public playbook anyway); client work and IP live in config/content/plugin layers on top, never in the fork; anything that must stay closed gets built on Nostrify (MIT, confirmed). Ch. 10 nuance: the MKStack template ships no license file at all — likely an oversight and boilerplate norms suggest reuse is expected, but get explicit terms from Soapbox before a closed commercial fork — and mkstack-nsp (the AI backend) is AGPLv3, so a self-hosted modified NSP owes its source to its users. Ratified 2026-07-09 — ADR: 0001-mod-layer-rule (the maintainers' companion decision record; not shipped with this public chapter set; internal: PIP-94 phase 1 closed); residual item: ask Soapbox for explicit MKStack-template terms before any closed commercial fork.

1. Decision summary

2. Day 1 with your credentials (do this before anything else)

Ch. 06 §1 has the full version with sources; the sequence:

1. Back up the nsec offline — password-encrypt it as ncryptsec (NIP-49). There is no reset and no ratified key rotation; losing it is identity loss.
2. Install a NIP-07 signer extension (Alby or nos2x) on your main machine. The key never touches websites.
3. Stand up a NIP-46 bunker (nsec.app; Amber on Android) the moment a second device or teammate is involved.
4. Publish your kind-0 profile (name, bio, avatar) from a real client.
5. Claim NIP-05: [email protected] = one static JSON at https://yourdomain.com/.well-known/nostr.json (no redirects allowed). Minutes on existing infra.
6. Pick relays deliberately — 2–4 write relays + a few read (NIP-65 outbox), not twenty.
7. Log into NostrHub with the extension (never the nsec-paste or key-file options it also offers — ch. 05).
8. First publishes: a kind-1 note; then a kind-30023 long-form to test the publishing path.
9. Decide the org-account pattern: brand account (shared via bunker) + personal accounts; document custody (who holds what, where the ncryptsec backups live).
10. Wallet: connect via NWC (NIP-47) for zaps; treat received sats as accounting events from day 1 (ch. 06 §4 flags the tax reality).

3. Runbook A — Community and company ops

Shape: Ditto = the storefront community (public, branded, bridged); Armada = the back office pilot (E2E, internal). They are different products, not versions of one thing (ch. 02).

Filesharing verdict stands: neither is a Drive replacement (no folders/ACLs/versioning; the one folder app, Blossom Drive, is deprecated — Bouquet manages blobs only). Keep Drive; use the stack for community media and E2E chat attachments.

Watch item: Ditto has no native DMs today (NIP-17 absent) and implements neither NIP-72 nor NIP-29 groups (roadmap). For private conversation, Armada is the answer; don't promise DM privacy on Ditto.

4. Runbook B — Funding on Agora

When Agora: BTC-native donor base, censorship-resistance matters, zero platform fees matter, or client is an activist/civic org comfortable with crypto. When not: normie donors (no card checkout), US 501(c)(3) needing tax receipts (anonymous Silent-Payment gifts can't get IRS-compliant receipts — ch. 03), or discovery-dependent campaigns.

1. Campaign creation is permissionless — any Nostr keypair; "featured" is curated (WLC/HRF human-rights positioning).
2. Donations flow wallet-to-wallet on-chain BTC (incl. BIP-352 Silent Payments). Agora never holds funds; $0 platform fee; donor pays network fee.
3. Lightning zaps exist in Agora only as social tipping, a separate rail from campaign donations — don't conflate them in client explanations.
4. Publish campaign updates on Nostr; donations are publicly auditable (blockchain + Nostr) — a transparency feature for community orgs.
5. Off-ramp is manual: raised BTC → exchange (KYC reappears there) → USD; plan the volatility window.
6. Embedding: none. Shakespeare sites link out to the campaign; no widget exists (ch. 03). Zap-goal (NIP-75) integration unconfirmed.
7. White-label: AGPL fork-and-run is feasible (static React/Vite, Docker) for a client's own campaign platform — publishes your mods per §0.

5. Runbook C — Sites, funnels, mockups on Shakespeare

Mockup economics (the agency loop):

Funnel wiring — what's native vs external:

The trap: forms render with one prompt but there is no backend — where submissions land must be explicitly wired to an external service or they land nowhere (ch. 04). Payments are the inverse: Lightning/Cashu is genuinely native (Agora proves it in production); Stripe is the manual add.

Deploy paths: free *.shakespeare.wtf for mockups → export ZIP/git (including nostr:// git URLs) → production on Netlify/Vercel/Cloudflare/Pages, or fully decentralized via nsite + Blossom (Stacks CLI). Custom domains observed live but no documented runbook — budget discovery time. Client caveat: no CMS/visual editor; whoever builds it owns the edits (a retainer surface — position it as such to a client).

6. Runbook D — Publishing on NostrHub 2.0

1. Log in via NIP-07 extension (§2).
2. Repo: create/mirror → signs a kind-30617 announcement → lives on a GRASP host (relay+git) → issues/PRs/browsing on NostrHub; the same repo is clonable via gitworkshop.dev/ngit (interop verified live — ch. 05).
3. App: self-announce a kind-31990 NIP-89 handler event — no submission queue; community ratings accrue.
4. Article/docs: kind-30023 markdown; your chosen experts' NIP-32 approvals drive per-viewer ranking ("configurable meritocracy").
5. Expectations: it is a credibility and discovery layer, not a growth channel — metadata only (no artifact hosting), no auto-propagation to Zapstore/nostrapps (list those separately).

7. Integration matrix

8. Build opportunities

1. DVM-shaped agent dispatch — the data-vending-machine pattern (post job → providers compete → paid in sats) is structurally identical to an internal agent-dispatch queue like dojo_agent_dispatch (ch. 06, worked example) — the maintainers use this shape today. A thin bridge would put any agent orchestrator on an open job market. Scout, not dependency.
2. Ditto bots via Mastodon API — the entire Mastodon bot/tooling ecosystem works against a Ditto instance; cheapest automation surface in the stack.
3. MCP ↔ Nostr bridge — publish/read Nostr events as MCP tools (post, zap, fetch community signals); nothing found in the ecosystem occupying this niche.
4. The bilingual mod layer itself (§9.2) — first-mover OSS contribution with obvious upstream demand: Soapbox's own builder UI has no Spanish (ch. 08).
5. Concord early expertise — protocol is 26 days old (CORD-01–07); early implementers get standing in whatever it becomes.

9. The TresPies modded-stack blueprint (steering direction, 2026-07-09)

What follows is the maintainers' own integration plan, published as a worked example of wiring this stack into a real firm — adapt the shape, swap the specifics (a different niche, a different orchestrator, a different git-mirror target) for your own.

Operator direction, verbatim: "integrate this stack with cutting edge internationalization platforms and visualization platform components then we'll build a Tres Pies stack on the modded version and git anchor it all in Nostr, mirror it to Dojo Genesis Git." (internal: PIP-94). Phase gates below assume §0's mod-layer rule is ratified first.

9.0 AI + orchestration layer (operator-specified 2026-07-09)

Direction, verbatim: "built featuring my dojo orchestration system and the providers of your choice: enterprise or TresPies or windsurf or cursor or whatever or Local: OpenRouter or Dojo Genesis."

The build engine is Dojo orchestration (Gateway agent-dispatch + Claude Code sessions) driving generation against MKStack's AGENTS.md agent contract — 348 lines at the template root, shipping with .mcp.json (Claude Code's own MCP config), opencode.json, and 19 skill files (ch. 10; note NIP.md is a different artifact — the NSP wire protocol in mkstack-nsp). Shakespeare becomes one optional front-end among several, not the required lane. All lanes target the same scaffold:

Rule: no lane lock-in. The scaffold + AGENTS.md contract must build identically from every lane — the zero-lock-in founder veto applied to our own tooling. Ch. 10 confirms it: a raw clone is Claude Code-ready out of the box (AGENTS.md + .mcp.json + skills), local lanes impose no model provider, and only hosted Shakespeare and Stacks/Dork touch a Soapbox-rostered model list. The one unbuilt extension point: a Dojo-Gateway AI_PROVIDER adapter for a self-hosted mkstack-nsp (only OpenAI/OpenRouter adapters exist today — and a self-hosted NSP is AGPLv3, so modified server source must be published).

9.1 i18n integration (from ch. 08)

• Runtime: keep i18next/react-i18next — already proven inside this stack by Agora (16 locales, es at 99.96% parity). Fork Agora's src/i18n.ts pattern into the Ditto/Armada-derived base rather than importing a foreign architecture.
• Automation: layer Lingo.dev (Apache-2.0, CI-native AI-MT with glossary/brand-voice control) for machine passes; TresPies native-Spanish review stays the human gate.
• Gate: port the NS-style symmetric parity check into CI — Agora's existing gate fails only on extra keys, not missing ones; tighten it.
• Nostr layer: no ratified language NIP (Gleason's own NIP-37 closed unmerged; PR #1127 open) — adopt the de facto NIP-32 labels ["L","ISO-639-1"] ["l","es","ISO-639-1"] for bilingual content now.
• Contribution play: Ditto and Armada have literally zero i18n today; Shakespeare's UI has no Spanish. A clean es layer is a visible, welcomed upstream contribution (and marketing).

9.2 Visualization integration (from ch. 09)

• Spec-layer rule: framework-agnostic engines (ECharts, MapLibre GL) bridge the React stack and Svelte house surfaces; framework-bound charts route per surface (Recharts inside Shakespeare/MKStack — it ships in the scaffold; LayerChart/unovis in Svelte dashboards).
• The Atlas pattern (zero-server): ACS/TIGER → Tippecanoe → PMTiles + Parquet on static hosting → MapLibre choropleths + DuckDB-WASM drill-down → bilingual labels via §9.1 hooks. No origin server anywhere; deployable to Pages/R2 or nsite/Blossom.
• Tripwire: PMTiles needs HTTP range requests; Blossom's spec only recommends them — verify per Blossom server or default to Cloudflare R2 (documented Protomaps path).
• Position: no Nostr+census precedent found — an Atlas on this substrate is first-of-kind for the maintainers' §1557/equity-data niche (swap in your own domain — the zero-server pattern doesn't care what the data is).

9.3 Git-anchor + mirror runbook

1. Repo canonical home: GRASP host (relay + git server) with a kind-30617 announcement signed by the TresPies/DojoGenesis key (per repo).
2. Add the GitHub mirror: git remote add github [email protected]:DojoGenesis/<repo>.git — gh auth switch --user DojoGenesis first (existing guard, enforced by hook).
3. Push discipline: anchor push (ngit/GRASP) then mirror push; CI or a post-push hook keeps them in lockstep. nostr:// remotes are already supported by Shakespeare's git export (ch. 04).
4. Issues/PRs: NIP-34 events — workable from NostrHub or gitworkshop.dev interchangeably (verified interop, ch. 05).
5. What stays off the anchor: anything under IP gate or client NDA — Nostr announcements are public and permanent; private repos stay GitHub-only until the maintainers are ready to publish them (their standing practice for moving in-progress internal work into the open).
6. The knowledge layer rides this rail (operator call, 2026-07-09): because the operating model keeps knowledge as markdown in git (manuals, notes, ADRs, the memory system with local autosync), git-over-Nostr IS the internal file layer for knowledge work — anchored, mirrored, versioned. This narrows §1's "keep Drive" verdict to binary/office assets only (client spreadsheets, design files, video); md-native ops need no Drive.

9.4 Sequencing (30/60/90) and tripwires

Tripwires: Armada security audit status (none yet — recheck before widening pilot) · Shakespeare free-tier lapse (promotional, no end date) · Soapbox grant renewals (their existential risk, ch. 01) · Blossom range-request support (per-server) · Concord protocol churn (already v1→v2 in 26 days).

10. Consolidated open questions

Highest-value unknowns across chapters (each chapter lists its own in full): Armada arbitrary-file attachments and audit roadmap (02) · Agora NIP-75 zap-goal use and Forbes/AP coverage verification (03) · Shakespeare custom-domain runbook and free-tier durability (04) · NostrHub DVM-marketplace status in 2.0 and license file (05) · Agora zap-vs-donation edge mechanics (03/06) · whether Soapbox would accept an es upstream contribution PR promptly (08 — ask them directly; they're reachable on their own products).

08 — i18n Integration: Localization Platforms × the Soapbox Stack

Where a modded, bilingual TresPies fork would actually plug in — verified against the real Ditto, Armada, Agora, and Shakespeare/MKStack repos, not just their marketing pages.

The tool landscape and stack-readiness research below (§1, §2, §4, and the comparison table in §5) apply to any team evaluating this stack for localization. §3 and the adoption runbook in §5 are the maintainers' own integration plan for their bilingual fork — a worked example of wiring a parity gate into a real firm; adapt the shape, swap the specifics for your own.

Verified: 2026-07-09

Confidence: High for stack-readiness facts (all four products' actual GitLab repos fetched — package.json, locale files, router code, AGENTS.md — not inferred from docs). High for the Nostr language-tagging verdict (both proposal PRs fetched directly, states confirmed). Medium for the landscape/tool comparison (aggregated from current search results, not independent primary-source fetches of every vendor). Medium-Low for cost figures, which move fast and weren't independently re-verified per vendor.

1. The 2026 Landscape — Legacy TMS vs. AI/Agent-Native

The field has split into two generations: TMSes built for a human-translator queue, and a newer layer built to sit inside a git repo and a CI pipeline with an LLM doing the first pass.

What's genuinely cutting-edge mid-2026: the AI-MT layer, not the runtime library. REPORTED across multiple vendor blogs: the current pattern is glossary + brand-voice-trained LLM + "quality-based routing" that scores each translated segment and only escalates the weak ones to a human editor, rather than a human reviewing every string [6]. Lingo.dev and Crowdin both ship this; inlang's ecosystem (Fink/Sherlock) is compiler-and-editor-native rather than AI-MT-native — it assumes a human or an external MT step fills the message files.

Confidence: Medium — landscape claims are aggregated from current comparison articles and vendor pages, not independently fetched primary text for every row.

2. Stack i18n Readiness — Repo-Verified

Fetched each product's actual GitLab tree, package.json, and (where present) locale files and routing code. This is the load-bearing section — no marketing-page claims below.

Agora is the reference implementation, and it's better than a generic tutorial pattern. Its src/i18n.ts bundles only English eagerly (sync, no flash of untranslated content) and lazy-loads every other locale as its own Vite chunk on selection or detection — REPORTED as saving roughly 2MB off the initial bundle, DOCUMENTED directly in the code's own comments:

"Only English is bundled eagerly. Every other locale is loaded on demand via a dynamic import()" [9]

It also handles RTL languages (ar, fa, ps, +4 more) by flipping document.dir and relying on Tailwind's rtl: variant, and resolves region/script variants (pt-BR→pt, zh-TW/zh-HK→zh-Hant) to the right JSON chunk.

Agora already runs a parity gate — looser than the maintainers' own TresPies standard. Its AGENTS.md (written for AI coding agents working in the repo) states:

"src/test/locales.test.ts fails the build if any locale ships a key that doesn't exist in en.json, but the inverse (a key missing from a non-English locale) is allowed and falls back to English at runtime" [13]

That's an asymmetric gate (blocks drift one direction, tolerates it the other) — looser than the maintainers' existing same-commit EN+ES parity rule. The same file also instructs agents to work the way the maintainers' own workspace already works:

"dispatch the per-language edits to subagents in parallel rather than translating fifteen files sequentially" [13]

Confidence: High — every figure above came from a direct fetch of the file in question, not a changelog or blog post.

3. Integration Architecture for a Modded TresPies Fork

Locale routing on static hosting — three options, one clear default:

Typography/formatting for es: use the web-standard Intl API rather than hand-rolled formatting — Intl.DateTimeFormat('es', …), Intl.NumberFormat('es', …) (decimal comma, currency placement), and Intl.PluralRules('es') for the two-form (singular/plural) Spanish plural system, simpler than languages Agora already handles (Arabic has six plural forms). i18next's ICU/plural plugin and FormatJS both wrap this natively; nothing custom is needed. (Confidence: High — this is stable web-platform behavior, not a Soapbox-specific claim.)

On Shakespeare specifically — can you prompt it to generate a bilingual site? The MKStack scaffold has no i18n opinion baked in (§2), so yes, but the AI has to be told the pattern explicitly rather than reaching for a convention. INFERRED, practical recommendation: paste Agora's src/i18n.ts as a reference into the Shakespeare chat and ask it to replicate the lazy-load + detection pattern with en+es locale files — this reuses a pattern proven inside the same company's own product family rather than inventing one per generated site.

Confidence: Medium — the pipeline and routing recommendations synthesize DOCUMENTED repo evidence with INFERRED architectural judgment; flagged inline above.

4. Nostr-Layer i18n Gaps — No Ratified Standard

Verdict: there is no ratified NIP for natural-language content tagging. Two proposals exist; neither merged.

Even Soapbox's own founder couldn't get a dedicated language tag ratified. The reason it stalled, DOCUMENTED verbatim from the PR thread:

"I think users can't be trusted to specify this tag correctly and all automatic translation tools will already detect the language automatically anyway." [16]

Practical patterns for bilingual posting, given no standard: (a) dual posts — publish separate EN and ES events, each self-labeled via NIP-32's l/L tags, letting language-aware clients filter; (b) inline-both — one event containing both languages in the body, which sidesteps tagging entirely but degrades UX and can't be filtered; (c) per-language accounts — separate npubs per language, cleanest for filtering but fragments the identity (see the org-account tension already documented in chapter 06 [20]). What clients actually render: most Nostr clients show the raw event content regardless of any l tag present — language tags are a filtering/search signal, not a rendering instruction, so a bilingual post still displays as one undifferentiated block unless the client explicitly builds a language switcher around it. No evidence found of any major client (Ditto included) doing that today.

Confidence: High on the ratification status (both PRs fetched directly, states unambiguous); Medium on "what clients actually render," which is a general-knowledge claim not independently verified against every client's source in this session.

5. Recommendation

Ranked recommendation: don't replace the runtime — extend it. i18next/react-i18next stays (it's already MIT, already proven inside an AGPL-3.0 Soapbox product, and copying Agora's src/i18n.ts into Ditto/Armada is near-zero migration cost). Add Lingo.dev as the AI-MT + CI automation layer on top — it's the one tool on this list built specifically to sit in a CI pipeline with a glossary and brand-voice config, which is exactly the "cutting-edge" piece the current stack is missing. Skip a new TMS platform for now — tightening Agora's existing (asymmetric) locales.test.ts into a symmetric same-commit gate gets the maintainers' existing discipline without adopting Tolgee/Weblate's operational overhead; revisit if the team scales past ad hoc PR review.

5-step adoption runbook:

1. Fork Agora's src/i18n.ts + src/locales/en.json pattern into the Ditto/Armada-derived TresPies base — proven, in-family, zero new dependencies to evaluate.
2. Stand up Lingo.dev: one i18n.json config pointing at src/locales/en.json, TresPies glossary + brand-voice rules configured once, CI Action wired to GitHub/GitLab so every push opens a translated-string PR.
3. Tighten the parity gate — extend the locales.test.ts pattern to fail the build on missing keys too, not just extra ones, matching the existing TresPies same-commit EN+ES rule.
4. Route every AI-MT'd PR through native-Spanish human review before merge — the existing TresPies review culture, unchanged; Lingo.dev's human-in-the-loop review surface can host this or a plain PR review works equally well.
5. Deploy with client-side detection only (Agora's pattern) as the default; treat a separate nsite named-site (d-tag = es) as an optional later add-on, not a day-one requirement.

Confidence: Medium-High — the runtime/parity-gate recommendation is grounded in verified repo evidence; the Lingo.dev pick is grounded in documented product capability but not independently load-tested by this research.

Open Questions

• Whether Lingo.dev's Vite compiler mode has been used in production with a Nostrify/@nostrify/react app specifically — no direct evidence found either way, worth a small spike before committing.
• Whether any Nostr client (Ditto or otherwise) actually reads NIP-32 l/L language tags to drive a UI language filter today, versus the tag existing in the spec but going unused in practice — not independently verified against client source code this session.
• Current status/adoption of eznix86's open i18n/l10n NIP proposal (#1127) beyond "still open as of 2026-03" — worth re-checking periodically since it's the only active path toward a ratified standard.
• Exact current pricing tiers for Lingo.dev at TresPies' likely usage volume — REPORTED as "usage-based" with an OSS/free CLI tier, but exact thresholds weren't independently priced out this session.
• Whether Shakespeare's AI model has actual training exposure to Agora's src/i18n.ts (same company, public repo) versus needing the pattern pasted in manually every time — untested this session.

Sources

1. inlang — Localization Tools; opral/paraglide-js (GitHub); Paraglide JS — inlang — accessed 2026-07-09 — MIT license, compiler architecture, bundle-size claim, Fink/Sherlock roles.
2. Lingo.dev; lingodotdev/lingo.dev (GitHub); Lingo.dev CLI — How it works; Lingo.dev Compiler — Advanced Configuration — accessed 2026-07-09 — Apache-2.0 license, CLI/CI/compiler mechanics, glossary/brand-voice/quality-scoring "localization engine" model.
3. Tolgee — Why open-source; Tolgee — Self-hosting Licensing; Tolgee EE License FAQ — accessed 2026-07-09 — Apache-2.0 core + dual-licensed EE features, free self-host seat limits.
4. Open-Source TMS Comparison 2026: Weblate vs Tolgee vs Pontoon — IntlPull — accessed 2026-07-09 — Weblate/Tolgee positioning, Crowdin integration-count claim, git-vs-translator-UI framing.
5. React i18n in 2026: react-intl vs i18next vs LinguiJS — auto18n; Best React i18n Libraries in 2026 — Tolgee — accessed 2026-07-09 — bundle-size comparison, extraction-method comparison, ICU-strictness framing.
6. AI Localization in 2026: Engine, Review, Collaboration — Prismy; AI Localization: Automating Content Workflows — Crowdin Blog; How enterprise teams automate localization with AI — Smartling — accessed 2026-07-09 — glossary/brand-voice/quality-routing AI-MT workflow pattern.
7. gitlab.com/soapbox-pub/ditto — package.json and src/ tree fetched directly via GitLab API 2026-07-09 — 155 deps, zero i18n-related packages, no locale directory; React 19.2.4/Vite 8/Tailwind/Nostrify confirmed.
8. gitlab.com/soapbox-pub/armada — package.json and src/ tree fetched directly 2026-07-09 — 99 deps, zero i18n packages, concord-v1/concord-v2 protocol dirs present, no locale directory.
9. gitlab.com/soapbox-pub/agora — package.json, src/i18n.ts, and src/locales/{en,es}.json fetched directly 2026-07-09 — i18next stack confirmed, 16 locales, 2,401/2,402 key parity computed programmatically, lazy-chunk architecture read from source comments.
10. gitlab.com/soapbox-pub/shakespeare — package.json and src/locales/ tree fetched directly 2026-07-09 — i18next stack confirmed, 6 locales (en/ha/ig/pt/yo/zh, no es), 574 leaf keys in en.json.
11. gitlab.com/soapbox-pub/soapbox.pub — package.json (name: "mkstack") fetched directly 2026-07-09 — zero i18n deps, no locale directory in src/.
12. gitlab.com/soapbox-pub/mkstack-nsp — README.md, CONTEXT.md, NIP.md fetched directly 2026-07-09 — NSP/Deno architecture, CLONE_URL-configurable base template, zero language/locale/i18n mentions across the 1,085-line spec.
13. gitlab.com/soapbox-pub/agora — AGENTS.md — accessed 2026-07-09 — verbatim parity-gate behavior and agent-parallelization instruction for translation work.
14. gitlab.com/soapbox-pub/agora — AppRouter.tsx — accessed 2026-07-09 — confirmed no path-prefix locale routing exists; only a /settings/language settings page.
15. gitlab.com/soapbox-pub/agora — src/lib/nsiteSubdomain.ts — accessed 2026-07-09 — NIP-5A subdomain derivation for root (kind 15128) vs. named (kind 35128, d-tag) nsite events, corroborating chapter 06's nsite citation.
16. NIP-37: Language Tag (PR #632) — accessed 2026-07-09 — author Alex Gleason, closed unmerged 2024-06-07, verbatim fiatjaf objection quote.
17. NIP-32: Labeling — accessed 2026-07-09 — verbatim ISO-639-1 language-labeling example.
18. NIP-50: Search Capability — accessed 2026-07-09 — language:<ISO 639-1> search filter extension.
19. NIP-C0: Code Snippets — accessed 2026-07-09 — confirms the l tag here means programming language, a distinct namespace from natural-language tagging.
20. NIP-XXX: Internationalization and Localization (PR #1127) — accessed 2026-07-09 — author eznix86, still open, last activity 2026-03-04, unmerged; proposes l-tag plus kind:0 language field.

Visualization Integration — Charting and Mapping Across the Soapbox Stack

Where interactive charts and census-scale maps can actually live across Shakespeare, Ditto, Blossom/nsite, and Nostr long-form content — and the reference pattern for building an Atlas-class dashboard on top of it, with zero origin servers.

Verified: 2026-07-09

Confidence: High for the landscape survey, licensing, and the Shakespeare/MKStack embedding answer (a live dependency-manifest fetch is primary evidence). Medium-High for the static/Blossom-hosting and Nostr long-form answers (protocol specs are primary and quoted verbatim, but real-world server behavior varies). Medium for Ditto's embedding ceiling (no widget/plugin doc was found across two source sweeps — an absence, not a documented "no"). Medium for the Atlas reference architecture itself: every component is independently well-sourced, but no live Nostr-stack census/civic-data project was found to validate the combination end-to-end — this pattern is this chapter's synthesis, not a Soapbox playbook.

1. The 2026 Landscape

Confidence: High — every cell above traces to a primary repo/license file or a 2026-dated comparison source.

2. Embedding in the Stack

The one fact that resolves most of this section: the MKStack template that Shakespeare scaffolds already depends on Recharts. A live fetch of its package.json shows React 19.2.5, Vite 8.0.10, Tailwind CSS v4.2.4, and Recharts v3.8.1 as a first-class dependency, alongside Radix UI, TanStack Query, and Nostrify [18]. A secondary write-up describes MKStack as "React 18.x... TailwindCSS 3.x" [43] — that's stale against the live manifest; treat any secondary MKStack description as provisional and re-fetch before quoting a client.

On (b), the fine print that matters for the Atlas pattern: nsite maps file paths to content via Nostr kind 34128 events (d tag = path, sha256 tag = content hash), storing raw bytes on Blossom servers; the spec is explicit that this is for "a simple application that doesn't use a backend" [26]. Blossom's own BUD-01 spec requires CORS — "Servers MUST set the Access-Control-Allow-Origin: * header on all responses" — but only recommends byte-range support: "servers should support range requests (RFC 7233 section 3)" [27]. That word "should" is load-bearing: PMTiles depends on range requests to work at all, so a given Blossom server may or may not serve a census-scale map efficiently — verify per-server before committing production tiles to nsite (see Open Questions).

Confidence: High for (a) and (d) — primary manifest and primary spec text. Medium-High for (b) — primary specs, but real-server range-support behavior is untested here. Medium for (c) — a documented absence, not a documented limit.

3. The Atlas Pattern — Reference Architecture

A census/ACS dashboard (Equity Atlas-class: county→tract drill-down, choropleth fill, bilingual labels) fits this stack only as a build-time-baked, fully static app. No component in the pipeline below needs an origin server at request time.

Build runbook:

1. Pull ACS 5-year variables and TIGER/Line geometry (county, tract) via the Census API, tidycensus/tigris (R), or cenpy (Python).
2. Join ACS attributes to geometry; export the attribute table only (no geometry) to Parquet for the DuckDB-WASM/pre-aggregation path.
3. Convert geometry to GeoJSON, then to PMTiles with Tippecanoe (v2.17+ writes PMTiles directly) — e.g. tippecanoe -zg -o tracts.pmtiles -l tracts tracts.geojson — tuning min/max zoom for the state→county→tract drill-down [30]. A documented precedent exists at this exact scale: a 650,000-plus-feature Texas census-block PMTiles build via Tippecanoe [31].
4. Precompute heavy rollups (state/county summaries) as static JSON at build time — an Observable Framework data loader or a plain build script both work [1][2].
5. Host PMTiles + JSON + Parquet as static assets. Cloudflare R2/Pages is the verified-safe default: Protomaps documents a direct Cloudflare integration [35], though a stock Cloudflare CDN path has been reported to corrupt PMTiles' byte-range responses unless served through a Worker or R2 directly [37] — configure CORS to allow the range and if-match headers explicitly [36]. nsite+Blossom is reachable but its range-request support is a spec-level "should," not a guarantee (§2) — pilot it, don't default to it for production tiles.
6. Render with MapLibre GL JS plus the pmtiles:// protocol handler; add a choropleth fill layer keyed to the joined ACS variable.
7. Wire drill-down as client-side view state: zoom/tap swaps the active PMTiles zoom range and re-queries either the in-browser DuckDB-WASM Parquet or the pre-aggregated JSON for the side panel.
8. Hook the bilingual layer at two boundaries only — the component string table, and the Intl.NumberFormat/Intl.DateTimeFormat call for chart ticks and tooltips — full locale-file strategy is the parallel i18n chapter's job, not this one's.
9. Ship the frontend as a static build — React via Shakespeare/MKStack, or a standalone Svelte 5 app — to Cloudflare Pages, GitHub Pages, or nsite. No origin server exists anywhere in this stack.
10. Before first paint in production, curl -I the tile host and confirm accept-ranges: bytes and access-control-allow-origin are actually present — MapLibre degrades silently (slow, not broken) when range requests aren't honored.

Confidence: High on each individual component (Tippecanoe, PMTiles, MapLibre, DuckDB-WASM are all independently well-documented). Medium on the architecture as a combination — no Nostr-stack precedent for census/civic-data work was found in this pass; TresPies would be first-of-kind here.

4. Framework Tension — React vs. Svelte 5

Recommendation: treat ECharts (general charts) and MapLibre GL JS (maps) as the portable spec layer — write the chart option / map style once, wrap it twice. Use Recharts/shadcn charts only inside Shakespeare-generated React surfaces, where it's already a zero-cost dependency [14][18]. Use LayerChart/unovis only inside standalone Svelte 5 builds. Never hand-port Recharts JSX into Svelte or vice versa — re-point the same underlying option object instead; that's the actual reuse boundary, not the component code.

Confidence: High — grounded directly in the fetched MKStack manifest, this manual's own prior Ditto/Agora architecture findings, and the maintainers' own standing Svelte 5 convention.

5. Recommendation

Ranked pick:

1. MapLibre GL JS + PMTiles — the map layer, non-negotiable for anything Atlas-shaped.
2. Apache ECharts — the general chart layer: framework-agnostic, highest-adoption, one spec reusable across the React and Svelte shells in §4.
3. Recharts (shadcn) inside Shakespeare/MKStack surfaces; LayerChart/unovis inside standalone Svelte 5 — not a single winner, a routing rule per §4.

Gap list — what still needs an external service:

• Address/geocoding lookups need the Census Geocoder API (or similar) called at request time — the one piece that can't be fully baked static.
• Range+CORS-verified tile hosting on Blossom/nsite specifically is unverified end-to-end (§2, §3) — Cloudflare R2/Pages is the proven fallback.
• The bilingual string/number pipeline itself is intentionally out of scope here — hook points only (§3, step 8); full design lives in the parallel i18n chapter.
• Any query workload that outgrows what DuckDB-WASM can hold client-side (multi-GB full-resolution microdata, not summary tables) needs a real backend or a hosted DuckDB/MotherDuck endpoint — the static pattern has a ceiling.

Confidence: Medium-High — license/adoption facts are High confidence; the equity-data-fit scoring is this chapter's judgment call, not a third-party benchmark.

Open Questions

• Whether any production Blossom server in the wild actually serves Accept-Ranges: bytes on blob GETs — BUD-01 only recommends it [27]; untested against a real nsite deployment this pass.
• Whether Ditto has any embed/widget surface beyond CSS theme tokens that simply isn't publicly documented yet — two independent doc sweeps found none, which is evidence of absence, not proof of it.
• Exact current version numbers for Vega-Lite and Observable Framework's newest release notes beyond the ~1.13.x line observed on npm — worth a fresh check before a client-facing commitment.
• Whether MKStack's dependency set (React 19.2.5, Vite 8.0.10, Tailwind v4.2.4, Recharts v3.8.1, observed live 2026-07-09) has moved again by the time this is read — re-fetch package.json from the GitLab repo rather than trusting this snapshot or any secondary blog description [18][43].
• No live example of a Nostr-stack census/civic-data dashboard was found — TresPies would be building the reference case, not following one.

Sources

1. observablehq/framework — GitHub — static-site generator description, data-loader language support. Accessed 2026-07-09.
2. Data loaders — Observable Framework — build-time data loaders, multi-language + binary invocation (DuckDB, ffmpeg). Accessed 2026-07-09.
3. @observablehq/framework — npm — current release line (~1.13.x, ~2026-03). Accessed 2026-07-09.
4. d3/d3 LICENSE — GitHub — ISC license confirmation. Accessed 2026-07-09.
5. Best Apache ECharts Alternative In 2026 — LightningChart and echarts vs vega-lite — npm trends — Apache 2.0 license, relative weekly-download adoption. Accessed 2026-07-09.
6. Vega and D3 — Vega docs — Vega-Lite BSD-3 license, relationship to D3. Accessed 2026-07-09.
7. deck.gl homepage and Using with MapLibre — deck.gl docs — MapView/MapboxOverlay camera sync with MapLibre. Accessed 2026-07-09.
8. Choropleths, Four Ways — Parker Ziegler — worked example of deck.gl choropleths on ACS 5-year California tract data. Accessed 2026-07-09.
9. Open Source Data Visualization Project deck.gl v9 Released — OpenJS Foundation and visgl/deck.gl LICENSE — MIT license, OpenJS/vis.gl governance. Accessed 2026-07-09.
10. maplibre/maplibre-gl-js — GitHub and LICENSE.txt — BSD-3 license, Linux Foundation incubation, fork lineage from Mapbox GL JS pre-Dec-2020. Accessed 2026-07-09.
11. Recharts v3 vs Tremor vs Nivo: React Charts 2026 — PkgPulse — bundle-size and positioning comparison. Accessed 2026-07-09.
12. Best React chart libraries in 2026 — LogRocket — bundle sizes, use-case framing for Recharts/Tremor/Nivo/visx. Accessed 2026-07-09.
13. airbnb/visx — GitHub — MIT license, low-level D3+React primitives, adoption figures. Accessed 2026-07-09.
14. Chart — shadcn/ui and Beautiful Charts & Graphs — shadcn/ui — official shadcn/ui chart components built directly on Recharts. Accessed 2026-07-09.
15. techniq/layerchart — GitHub — Svelte 4/5-compatible composable chart components, MIT. Accessed 2026-07-09.
16. f5/unovis — GitHub — multi-framework (incl. Svelte) viz framework, CSS-variable theming, MIT. Accessed 2026-07-09.
17. evidence-dev/evidence — GitHub and Evidence Docs — MIT license, SQL+Markdown static BI site, DuckDB-powered, in-app AI agent. Accessed 2026-07-09.
18. gitlab.com/soapbox-pub/mkstack — package.json (raw) — primary dependency manifest: React 19.2.5, Vite 8.0.10, Tailwind v4.2.4, Recharts v3.8.1, Radix UI, TanStack Query, Nostrify. Accessed 2026-07-09.
19. MKStack — Soapbox — product framing, "AI-Powered Nostr App Framework." Accessed 2026-07-09.
20. microsoft/data-formulator — GitHub and Data Formulator 0.7 — Microsoft Research — 2026 AI-native iterative chart-authoring tool. Accessed 2026-07-09.
21. I Vibe-Coded a Complex Data Visualization Dashboard — Generative AI in the Newsroom — LLM default to Recharts/Chart.js when generating React chart code. Accessed 2026-07-09.
22. maplibre/maplibre-agent-skills — GitHub — MIT-licensed, community-maintained AI coding-assistant skills for MapLibre. Accessed 2026-07-09.
23. maplibre-pmtiles-patterns SKILL.md — GitHub — PMTiles generation/hosting/connection patterns for AI agents. Accessed 2026-07-09.
24. NIP-23 — nostr-protocol/nips (raw) — primary spec text: HTML prohibition, optional image tag definition. Accessed 2026-07-09.
25. Kind 30023: Long-form Content — Nostrbook — secondary confirmation of kind 30023 structure. Accessed 2026-07-09.
26. lez/nsite — GitHub README — kind 34128 path/hash mapping, "a simple application that doesn't use a backend," redundant frontend/relay/Blossom architecture. Accessed 2026-07-09.
27. Blossom BUD-01 — hzrd149/blossom (raw) — primary spec text: range-request "should" language, CORS "MUST" requirement. Accessed 2026-07-09.
28. soapbox-pub/ditto — GitHub — 9 theme presets, 19 CSS token properties, 100+ UI components. Accessed 2026-07-09.
29. about.ditto.pub — customization docs: theme/profile personalization, Shakespeare-based deep customization framing ("completely redesign the UI"), no widget/embed architecture found. Accessed 2026-07-09.
30. Creating PMTiles — Tippecanoe / Protomaps Docs — Tippecanoe v2.17+ direct PMTiles output, CLI workflow. Accessed 2026-07-09.
31. Mapping 650,000+ Texas Census blocks with PMTiles — Walker Data — tigris + Tippecanoe pipeline at census-block scale, hosting notes. Accessed 2026-07-09.
32. Geo mark — Observable Plot — GeoJSON/TopoJSON-based choropleth mark, Albers-USA projection example. Accessed 2026-07-09.
33. Build your first choropleth map with Observable Plot — worked county-level choropleth tutorial. Accessed 2026-07-09.
34. protomaps/basemaps — GitHub and LICENSE_DATA.md — BSD-3 code license, CC0 cartographic styling, OpenStreetMap ODbL data license ("Produced Works of the OpenStreetMap dataset under the Open Database License"). Accessed 2026-07-09.
35. Cloudflare Integration — Protomaps Docs — documented PMTiles-on-Cloudflare hosting pattern. Accessed 2026-07-09.
36. Cloudflare Community — R2 CORS for PMTiles — practical CORS/range header configuration for R2-hosted tiles. Accessed 2026-07-09.
37. maplibre/demotiles Issue #35 — reported case of Cloudflare's CDN corrupting PMTiles range responses; Worker/R2-direct as the fix. Accessed 2026-07-09.
38. Query — DuckDB Wasm docs — client-side SQL over remote Parquet via HTTP range requests. Accessed 2026-07-09.
39. DuckDB Wasm: Analytical SQL Database in Your Browser — MotherDuck — in-browser analytics benefits, ~33MB wasm binary size note. Accessed 2026-07-09.
40. Is DuckDB Open Source? Yes — the MIT License, Explained — Definite — MIT license, DuckDB Foundation perpetuity statute. Accessed 2026-07-09.
41. Vercel acquires Tremor — Vercel Blog — Jan 2025 acquisition, Tremor Blocks made free/MIT. Accessed 2026-07-09.
42. react-i18next / i18next Issue #1201 — confirms i18next has no built-in number/date formatting; Intl API or a date library is required alongside it — the i18n hook-point boundary referenced in §3. Accessed 2026-07-09.
43. Using MKStack to Build Nostr Apps — PayPerQ Blog — secondary source describing MKStack as "React 18.x... TailwindCSS 3.x"; superseded by the primary manifest fetch [18] and flagged in Open Questions as a live-verify caution.

MKStack — The Framework Layer

The React/Vite/Tailwind scaffold every Nostr client on this stack forks from — and the piece that decides whether Claude Code, Cursor, Windsurf, or a custom Dojo-driven orchestrator can build here without Shakespeare, on any model provider.

Verified: 2026-07-09 · Delta pass: 2026-07-10 (NostrDeploy.com DNS tripwire; Stacks-platform relationship sharpened)

Amended: 2026-07-10 (v2 wave) — resolved .mcp.json concretely (nostr/js-dev packages + the five nostrbook tools, live-confirmed); cross-referenced new ch. 12 for the full 19-skill enumeration; catalogued all 17 Toybox experiments and disambiguated Chorus/Treasures/Blobbi source status; added the commit-pin + fetch-only-upstream pinning discipline, cross-ref ch. 15; flagged NostrHub's shared license-absence class with MKStack.

Confidence:

• High — scaffold anatomy, dependency versions, and the AGENTS.md/.mcp.json/opencode.json agent-compatibility findings (all fetched directly from the live repo). Also high for mkstack-nsp's AGPLv3 license (full text fetched).
• Medium-High — the mkstack template's license absence: well-evidenced (four 404s, no SPDX identifier, no GitLab-detected license, silent toolbox page), but Soapbox wasn't asked directly.
• Medium — Cursor/Windsurf compatibility: no dedicated rules file found for either; plausible but unconfirmed.
• Low — MKStack's exact public launch date: no dedicated announcement post found; repo-creation date used as proxy.

What It Is

MKStack is Soapbox's Nostr client scaffold: a React 19 + Vite + Tailwind v4 template pre-wired with Nostrify, shadcn/ui, and roughly twenty documented NIPs, at gitlab.com/soapbox-pub/mkstack [2], marketed at soapbox.pub/mkstack [1], product domain mkstack.xyz [2][13]. It is a template you fork, not a standalone CLI — the CLI that scaffolds it is a separate product, Stacks (@getstacks/stacks on npm) [16][17]. Get the direction of that relationship right: Stacks 1.0 (released 2025-08-20) is the generic template-sharing platform — templates publish as kind 30717 events and anyone can publish one [17][18] — and MKStack is just one published stack on it: Soapbox's own flagship stack, not the platform itself. Shakespeare is one client of a shared protocol, not MKStack's only front door.

Timeline: mkstack created 2025-04-17 → mkstack-nsp (the NSP backend, AGPLv3) created 2025-06-23 [12] → Shakespeare announced/launched 2025-07-10/14 (ch. 04) → Stacks 1.0 released 2025-08-20 [18] → Shakespeare Act 2, 2025-10-01 (ch. 04) → both repos still live today, mkstack committed this same day [10][21].