# 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].

```mermaid
flowchart LR
    U["You: chat prompt\n('add a contact form')"] --> AI["AI Provider\nfree NSP / BYOK / local model"]
    AI --> GEN["esbuild-wasm\nTypeScript to React, in-browser"]
    GEN --> FS["IndexedDB + LightningFS\n(your browser = the disk)"]
    FS --> GIT["isomorphic-git\n(git, no backend)"]
    FS --> PREVIEW["Live preview\nhot reload, side-by-side"]
    PREVIEW --> DEPLOY["Deploy"]
    DEPLOY --> D1["*.shakespeare.wtf\n(built-in, free, 1-click)"]
    DEPLOY --> D2["Export ZIP / git push\n(deploy anywhere)"]
```

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].

| Path | Who gets paid | Marginal cost per mockup | Catch |
|---|---|---|---|
| **Free Gemini Flash NSP** | Nobody — Soapbox-subsidized | **$0** | *"We're currently offering a free Gemini Flash NSP so you can try Shakespeare without adding credits!"* [2] — promotional language, no published end date or usage cap found |
| **BYO API key, budget model** (Z.ai GLM 4.5, etc.) | Model provider, directly | Cents | GLM 4.5 is *"often 60–80% less expensive than Claude with comparable results"* [20]; Shakespeare "takes no cut" on BYOK [3] |
| **BYO API key, premium** (Claude Sonnet 4.5) | Model provider, directly | ~$4/M prompt + $16/M completion tokens via the Shakespeare AI proxy [12] | Best quality; still no Shakespeare markup |
| **Local model** (Ollama, GPT-OSS, DeepSeek R1, Gemma 3) | Nobody | **$0** after setup [17][20] | Needs decent hardware; slower, lower ceiling than frontier cloud models |
| **Official paid NSP** (MKStack + Claude Sonnet 4) | Soapbox, via Stripe or Lightning | Pay-per-use, rate not published | The *only* path where it applies: *"Shakespeare only takes a cut if you use our paid NSP: MKStack + Claude Sonnet 4"* [13] |

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.

| Funnel need | Native? | Mechanism | Gap-fill if not native |
|---|---|---|---|
| Landing page / mockup | Yes | Chat → React site, live preview [1][3] | — |
| Contact form (UI) | Yes | Documented prompt example [1] | — |
| Contact form (usable lead data) | **No** *(inferred)* | No default backend/DB; Nostr events are public, not a private CRM [5] | Prompt it to `fetch()` a Formspree/Basin endpoint or a webhook |
| Email list capture | No | Nostr has no email primitive | Embed Beehiiv/ManyChat signup script — already in your stack |
| Scheduling | No | Not Nostr-specific; nothing baked in | Cal.com/Calendly iframe — trivial, it's a normal React page |
| Bitcoin/Lightning payment | **Yes** | NIP-57 zaps, NIP-60 Cashu, NIP-61 nutzaps, NIP-47 wallet-connect ship in MKStack's 50+ NIPs [6]; Agora runs a live donation flow on this exact stack [24] | — |
| Credit-card payment (Stripe) | No | Not a Nostr primitive | Stripe Checkout link or JS embed — doable, not one-click |
| Analytics | Not documented | No mention in any primary source found | Plausible/Fathom/GA script tag |

**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

```mermaid
flowchart TD
    P[Finished project in browser] --> A["Built-in free deploy\n1 click, instant public URL"]
    A --> A1["project.shakespeare.wtf\n(observed live: mi.shakespeare.wtf,\nlinkbio.shakespeare.wtf) [3]"]
    P --> B["Export: ZIP or git push"]
    B --> B1["Netlify / Vercel / Cloudflare\nRailway / Deno Deploy\nGitHub Pages / GitLab Pages\n(8 named targets across [16][17])"]
    B --> B2["Decentralized: nsite + Blossom\nvia Stacks CLI 'npm run deploy'\n-> NostrDeploy.com (⚠ DNS-dead 2026-07-10),\nnpub subdomain [7][9][28]"]
    B1 --> C1["Custom domain: standard host DNS\n(host's own docs — well trodden)"]
    B2 --> C2["Custom domain: reported working\n(espy.you observed live) [3] — exact\nrunbook not published, verify before promising"]
```

**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:

| What | License | Source |
|---|---|---|
| The Shakespeare **tool itself** (if you fork/self-host it) | AGPLv3 | "Fully auditable codebase under AGPL 3.0 license" [2][5] |
| Code Shakespeare **generates for your project** | No license imposed *(inferred)* | Soapbox's own comparison: unlike Replit, which "automatically licenses apps with MIT," Shakespeare's code "stored in browser — Soapbox has no control over it" [17] |

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

| | **Shakespeare** | Lovable | Bolt.new | v0 (Vercel) | Webflow | Framer |
|---|---|---|---|---|---|---|
| Client mockups, cost | BYOK/free-tier/local → effectively $0–cents [2][3] | Free tier + paid plans (subscription) | Free tier + paid plans (subscription) | 5 free credits, then **$20–$100/mo, no pay-as-you-go** [16] | Free-to-build, paid to publish/subscribe | Free-to-build, paid to publish/subscribe |
| Production backend | Nostr events/relays; no managed DB out of the box, though Shakespeare claims support for "backend frameworks like databases, containerization" [16] | Managed **Supabase** DB, one prompt away | Multi-framework, backend via integrations | **"Front-end only. No backends, no databases"** — Shakespeare's own characterization [16] | CMS + hosting, no custom app logic | Marketing sites; limited app logic |
| Ownership / lock-in | Local-first, no imposed license, no account to ban [5][17] | Code not Vercel/Lovable-owned, but lives on their platform | Platform-hosted by default | Vercel "collects your source code, billing info... and location data," "can't delete your own data" — per Shakespeare's framing [16] | Platform-locked (hosted CMS) | Platform-locked |
| Payments baked in | Bitcoin/Lightning/Cashu (NIP-57/60/61/47) native [6]; card payments need manual wiring | One-click Stripe pattern | Manual wiring | Manual wiring | Native e-commerce | Forms native; commerce via add-ons |
| Templates / visual editor | **None** — chat-only | Chat-only, growing gallery | Chat-only | Chat-only | **Deep** editor + template marketplace | **Deep** editor, design-forward templates |
| Non-technical handoff | Needs re-prompting or hand-edits; no CMS | Similar chat-only friction | Similar | Similar | Best-in-class for marketers | Best-in-class for marketers |
| Track record | ~1 year old (launched Jul 2025) [2][10] | Longer, larger base | Longer, larger base | Vercel-backed, mature | Decade+, mature | Mature, design-standard |

**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

| Connects to | Mechanism | Enables |
|---|---|---|
| **MKStack** | Shakespeare *is* the browser front-end to MKStack's template + 50+ NIPs [1][6] | Every Nostr-native primitive (profiles, zaps, Cashu, DMs) available on request |
| **Agora** (built with Shakespeare+MKStack at an HRF hackathon) | Reference implementation, not an embeddable widget | Proof a live Lightning-donation/crowdfunding flow works in production on this stack [24][25] |
| **Ditto** | Separate product (Nostr community server, self-hostable or ditto.pub) [23] | Pairing pattern: **Shakespeare = funnel/marketing site; Ditto = retained community/membership layer** post-conversion — a two-product package, not a plug-in |
| **NostrHub** | Discovery/publishing hub for Nostr apps, NIPs, repos [26] | Distribution channel for your *own* templates/portfolio in the Nostr dev ecosystem — minor to client funnels directly |
| **Beehiiv / ManyChat** (common funnel-stack tools) | Embed signup script or webhook into generated site | Real email capture — the piece Nostr doesn't natively provide |
| **Cal.com / Calendly** | iframe/embed, no Nostr dependency | Scheduling step in a funnel — trivial since output is a normal React page |
| **Stripe** | JS SDK or Checkout link, manually prompted | Credit-card conversion step for non-Bitcoin clients |
| **Git hosts (GitHub/GitLab/custom) + Nostr Git** | Native git integration, incl. `nostr://` remote [3][5] | Backup/handoff independent of any single platform |

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](https://soapbox.pub/shakespeare) — product marketing page: pricing claims, provider list, deployment/export claims. Accessed 2026-07-09.
2. [Introducing Shakespeare: AI-Powered Website Builder on Nostr](https://soapbox.pub/blog/announcing-shakespeare) — 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](https://soapbox.pub/blog/announcing-shakespeare-act-2/) — 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](https://soapbox.pub/blog/announcing-shakespeare-community/) — community structure, channels, no multiplayer/payment features mentioned. Accessed 2026-07-09.
5. [gitlab.com/soapbox-pub/shakespeare](https://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](https://soapbox.pub/mkstack/) — 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](https://soapbox.pub/tools/stacks/) — 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](https://soapbox.pub/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](https://soapbox.pub/blog/mkstack-tutorial/) — 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](https://www.prnewswire.com/news-releases/shakespeare-launches-as-open-source-competitor-to-ai-site-builders-302503727.html) — launch date/venue, Alex Gleason quote. Accessed 2026-07-09.
11. [Understanding Nostr Service Providers (NSPs)](https://soapbox.pub/blog/understanding-nostr-service-providers/) — NSP payment structure (pay-per-use, subscription, free tiers), how to pick one. Accessed 2026-07-09.
12. [ai.shakespeare.diy](https://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](https://www.producthunt.com/products/shakespeare-3) — 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](https://techcabal.com/2025/12/10/inside-soapboxs-push-to-keep-ai-open-for-everyone/) — Gleason's origin motivation quote, "trust-based" business framing, no revenue/funding disclosed. Accessed 2026-07-09.
15. [Soapbox Blog index](https://soapbox.pub/blog/) — 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](https://soapbox.pub/blog/shakespeare-vs-v0/) — official feature/pricing comparison table (Soapbox's own framing). Accessed 2026-07-09.
17. [Shakespeare vs. Replit](https://soapbox.pub/blog/shakespeare-vs-replit/) — official comparison incl. ban/ownership contrast, deployment target list. Accessed 2026-07-09.
18. [Shakespeare Resources — FAQ & Guides](https://www.soapbox.pub/shakespeare-resources/) — 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](https://soapbox.pub/blog/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?](https://www.soapbox.pub/blog/shakespeare-ai-model-selection/) — model recommendations by budget, GLM 4.5 vs Claude cost comparison, local-model framing. Accessed 2026-07-09.
21. [Using Version Control in Shakespeare](https://soapbox.pub/blog/shakespeare-version-control) — rollback UI, GitHub/GitLab sync workflow, terminal git access, Nostr git backup. Accessed 2026-07-09.
22. [The Shakespeare Origin Story](https://soapbox.pub/blog/shakespeare-origin-story/) — Goose → Stacks → Shakespeare evolution narrative. Accessed 2026-07-09.
23. [Ditto — Your Content. Your Vibe. Your Rules.](https://soapbox.pub/ditto) and [github.com/soapbox-pub/ditto](https://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](https://soapbox.pub/blog/agora-connecting-freedom-fighters) — Agora product description, Bitcoin/Lightning support flow. Accessed 2026-07-09.
25. [Building Agora: From Hackathon to Real-World Activism](https://soapbox.pub/blog/building-pathos/) — confirms Agora built with MKStack and Shakespeare at an HRF hackathon. Accessed 2026-07-09.
26. [gitlab.com/soapbox-pub/nostrhub](https://gitlab.com/soapbox-pub/nostrhub) and [NostrHub](https://soapbox.pub/tools/nostrhub/) — protocol/app discovery hub description. Accessed 2026-07-09.
27. Web search summaries on the `nsite` spec ([github.com/lez/nsite](https://github.com/lez/nsite), [nsite.info](https://nsite.info/learn)) — 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](10-mkstack.md), source [26], which ran the same check the same day.