CraysShakespeare
Shakespeare is what happens when the Soapbox/Nostr builder crowd looks at hosted AI site builders and says: fine, but what if the project files stayed in your browser, the code stayed open, the AI provider was your choice, and publishing could move through Nostr instead of a platform account?
Open Shakespeare and the first mental adjustment is simple: you are not entering a social feed. There is no infinite scroll, no public square, no row of trending notes. Shakespeare is closer to an editor, a small development environment, a project vault and an AI chat surface folded into one browser app. You describe what you want to build, the assistant edits files, the preview updates, and the result can become a real web app rather than a disposable screenshot.
That makes it easy to misread. If you only ask, "Is this a Nostr client?", the answer feels small. If you ask, "What does Nostr make possible for a builder tool?", the project gets much more interesting. Shakespeare uses Nostr for identity and signing, its companion AI provider uses NIP-98 instead of API keys, credits can be bought with Lightning, and recent releases added nsite deployment, ngit fields, remote signer login by QR code and Zapstore distribution for Android. In other words: the Nostr part is not just the badge on the door. It is part of the trust, payment and publishing machinery.
The tool that refuses to be a hosted account
The official GitLab README calls Shakespeare an open-source AI app builder that runs entirely in your browser. That one sentence carries more weight than it first seems. Most modern AI website builders ask you to work inside their hosted workspace. You prompt there, store your project there, preview there, deploy there, and only later discover how much of your work is shaped by one company's account system. Shakespeare tries to move the center of gravity back toward the user's device.
Technically, the project is a React PWA. Files live in IndexedDB through LightningFS, the browser-side filesystem from the isomorphic-git ecosystem. Git operations use isomorphic-git, so a project can be cloned, edited, committed, pushed and pulled without a local Git install. The app compiles compatible React and TypeScript projects in the browser with esbuild-wasm and custom plugins. That is a very specific architecture, and it matters because it gives the browser the job a small developer workstation would normally do.
The README also says Shakespeare does not host a normal backend for your workspace, aside from configurable microservices under the repository's services directory. Your code and configuration are stored in the browser; provider and Git settings are stored in localStorage. That is liberating, but it is not magic. Browser storage is still browser storage. Clear the wrong site data, use a locked-down corporate browser, switch devices without pushing or exporting, and you can hurt yourself. Shakespeare gives you more custody, but custody always comes with chores.
Where Nostr actually enters the room
The interesting Nostr piece is identity without a new SaaS login. The current app uses Nostr libraries such as Nostrify, @nostrify/react and nostr-tools, and the June 5, 2026 release added login with a remote signer by scanning a QR code. That release note explicitly calls out NIP-46, which is the Nostr pattern for signing from another device or signer service. For a builder app, this is not a small convenience. It means the browser workspace can ask for signatures without you pasting a secret key into yet another tool.
NIP-07 still matters for browser extensions, because it is the familiar "window.nostr" path many web apps use for signing. NIP-46 matters when your signer lives elsewhere, for example on a phone or in a bunker-style signer. NIP-98 matters because the companion Shakespeare AI Provider uses Nostr-signed HTTP authentication instead of traditional API keys. Put those together and you see the shape: Shakespeare wants the builder to carry a Nostr identity through editing, paying and publishing, not just through social posting.
The app also reaches into the Nostr publishing world. The 9.10.0 changelog added nsite deployment for decentralized hosting via Nostr. The 9.11.0 release added ngit repository and nsite deployment address fields in the app dialog, plus T-tag editing and app metadata pulled from Open Graph tags and web manifests. The 9.11.1 release changed the default nsite gateway to shakespeare.to and updated default Blossom servers and relay lists. Those details sound small until you have tried to keep a web app alive outside a single platform. They show Shakespeare treating "publish" as a portable act, not just a button owned by one host.
Who is behind it
The public code lives under the Soapbox Pub namespace on GitLab. The package metadata lists the author as shakespeare.diy with the contact address contact@shakespeare.diy, and the repository description calls it an AI-powered Nostr website builder. Soapbox's announcement says Shakespeare is developed by the team behind Soapbox, Ditto and Nostrify. The same ecosystem matters because Ditto is a serious Nostr/ActivityPub project and Nostrify is the TypeScript library stack that shows up inside Shakespeare itself.
The launch story also places Shakespeare in the MKStack lineage. The July 2025 Soapbox announcement presented it as bringing MKStack-style Nostr app generation into a friendlier web builder. A later Soapbox page frames Shakespeare 2.0 as an open-source builder with any-model-any-provider positioning, Git integration, local storage and full code access. You do not have to accept every marketing comparison on that page to see the product thesis: if AI coding is becoming normal, then the open-source Nostr world wants a version that does not make the workspace, the identity and the deployment path dependent on one hosted company.
One practical clue: the repository is alive. GitLab metadata shows the project created on July 26, 2025, with recent activity in June 2026. The package version exposed in package.json is 9.14.0, and the changelog for that version is dated June 5, 2026. Shakespeare is moving quickly enough that any article about it needs dates. A page like this should not pretend the interface is frozen.
What building feels like
The basic workflow is familiar if you have used any AI coding tool: create or import a project, describe what you want, inspect the files, preview the result, ask for another change, and keep shaping. Shakespeare's difference is that it makes the file tree visible and local. The public Zapstore metadata lists AI chat, live preview, a virtual filesystem stored in-browser through IndexedDB, Git integration, Nostr login, multiple AI providers, project management and ZIP import. That is a fair product summary because it tells you where the work actually happens.
The "import" piece is more important than it sounds. The README badge lets another project offer "Edit with Shakespeare", and the product pages talk about cloning GitHub or GitLab repositories. That means Shakespeare is not only for a blank landing page. It can also become an on-ramp into an existing codebase, especially for a person who is comfortable describing changes but not yet comfortable installing Node, Git, an editor and a deployment pipeline.
The preview system has clearly received attention. In April 2026, the changelog switched the preview pane to iframe.diy and then updated sandboxing and private preview subdomains. It also added support for module workers, static asset URLs and device permissions inside previews. These are not glamorous features, but they are the difference between a toy demo and a builder that can run stranger web apps without immediately falling apart.
The AI layer is not one black box
Shakespeare's README says users can configure OpenAI, Anthropic, OpenRouter, xAI, ZAI, DeepSeek and more. The package includes the OpenAI SDK, but the app is not limited to OpenAI. It also includes the Model Context Protocol SDK, which fits the direction of browser-side agents gaining tool access rather than only producing text. Recent changelog entries mention AI agents running commands through a POSIX-style shell and improvements to built-in Git and shell commands such as cat, cp, find, grep, ls, sed and sort. That is the kind of plumbing an agent needs when it is editing a real project rather than writing one-off snippets.
There is also a companion project, Shakespeare AI Provider. It exposes an OpenAI-compatible API at ai.shakespeare.diy/v1 and uses NIP-98 authentication, so clients sign HTTP requests with Nostr events instead of attaching a traditional API key. The provider README describes credit balances, payments, generations, gift cards, context-window validation and Stripe or Lightning top-ups. The public AI landing page lists models such as GLM-4.5 and Claude Sonnet 4.5 with token pricing. That does not mean you must use Shakespeare's provider. It means the ecosystem includes a Nostr-authenticated payment and model layer for users who do not want to bring their own keys on day one.
This is where the product becomes unusually honest and unusually sensitive at the same time. If you connect an external AI provider, that provider can see what you send it. If you use the Shakespeare AI Provider, that provider becomes part of your trust path. If you store API settings in a browser, you should understand what is being stored and where. Shakespeare lowers the friction of building, but it cannot repeal the privacy consequences of sending code and prompts to models.
The Android and Zapstore clue
Shakespeare is not only a desktop browser URL. The repository includes Capacitor configuration with app id diy.shakespeare.app and app name Shakespeare, and the April 2, 2026 changelog added an Android app powered by Capacitor, signed release builds, GitLab release publishing and Zapstore distribution. The Zapstore YAML describes the app as a browser-based AI-powered app builder with Nostr login, multiple AI providers, Git integration and ZIP import.
That does not turn Shakespeare into a simple mobile app. Building web apps from a phone will always have limits. But it says something about the intended audience. The team is not treating this as a developer-only tool that must live inside a desktop IDE. They are trying to make the builder available wherever a Nostr signer and a browser-like runtime can reach it. The latest NIP-46 QR login also fits that direction: mobile signing should not require copying long bunker strings by hand.
What to trust and what to check
The open-source license is a real strength. The package declares AGPL-3.0-or-later, the repository includes the GNU AGPL license, and the README explicitly says the goal is a free and open platform that respects user privacy and freedom. That is far better than a black-box builder asking you to trust a glossy website. But source availability is not the same as automatic safety. A fast-moving builder that runs generated code, stores local data and talks to external providers deserves adult handling.
First, treat the browser workspace as local work in progress, not as a permanent archive. Push to Git, export a ZIP, or publish through nsite when the work matters. Second, do not paste private production secrets into generated projects unless you understand where those secrets go. Third, read generated code before deploying it. The whole point of Shakespeare is that you get the files. Use that advantage. Fourth, remember that Nostr signing protects identity and authorization, but it does not make every generated app trustworthy.
Finally, watch the permissions. The preview layer has to run other people's code, your generated code and sometimes richer browser APIs. The changelog references sandboxing work for a reason. If Shakespeare asks a signer for a permission, read the request. If a generated app wants microphone, camera, wallet or relay permissions, slow down. The better a builder gets, the more important the permission boundary becomes.
Why it belongs on the App Hub
Shakespeare belongs here because it expands what a Nostr app can be. It is not another client for reading notes. It is a tool for making new web apps with Nostr identity, Nostr-authenticated AI access, Lightning credits, Git workflows and Nostr-native deployment options close at hand. That matters because a protocol ecosystem becomes stronger when users can build their own small tools, pages and experiments without begging a platform for space.
The best way to test Shakespeare is modest. Do not start by asking it to build your life's work. Ask it for a tiny Nostr-aware page, a personal link page, a relay-status widget, a small community site, a color palette toy, a venue page or a one-screen prototype. Then inspect the files, push the project somewhere, reload it on another device and see whether your work survives outside the first browser session. If it does, you have learned something real about the app. If it does not, you have found the exact boundary that needs attention.
That is the right spirit for this tool. Shakespeare is exciting not because it says "AI" loudly, but because it tries to make a builder feel less rented. Your files are visible. Your identity can be Nostr. Your payments can be Lightning. Your deployment can move toward nsites. Your Git history can leave the browser. None of that removes the need for judgement. It gives you more places to apply it.
Sources worth opening
This article keeps its claims close to public project pages, source files and protocol documents. Start here if you want to verify the current state yourself.
- Shakespeare official app
- Shakespeare GitLab repository
- Shakespeare README
- Shakespeare changelog
- Shakespeare package.json
- Shakespeare Zapstore metadata
- Shakespeare Capacitor config
- Shakespeare AGPL license
- Soapbox announcement: Introducing Shakespeare
- Soapbox Shakespeare product page
- Shakespeare AI Provider repository
- Shakespeare AI Provider public API page
- NostrApps listing for Shakespeare
- Shakespeare GitHub Pages mirror
- Shakespeare GitLab Pages mirror
- LightningFS project
- isomorphic-git project
- esbuild-wasm package
- Nostrify project
- NIP-07 browser signer capability
- NIP-46 remote signing
- NIP-98 HTTP authentication
- NIP-34 git stuff
- NIP-5A static websites and nsites
- NIP-23 long-form content
