CraysFormstr
Formstr is an open-source Nostr form builder that treats a form as something you can publish, share, encrypt, embed and carry with you instead of renting from a platform forever.
The form is where trust gets real
Forms look boring until you remember what people put into them. Names, email addresses, applications, complaints, survey answers, event registrations, payment hints, membership requests, sometimes even medical or political context. A form is not just a web page with boxes. It is a small trust ceremony. Someone asks for data. Someone else decides whether the asker deserves it.
That is why Formstr is more interesting than its plain label suggests. NostrApps describes it as a web app for creating and sharing forms. The official site says the larger point more sharply: a decentralized forms application that lets you custody your own data through Nostr. Strip away the protocol words and the question becomes simple: what if a form did not have to live inside Google's account system, Typeform's account system, Airtable's account system or any one company's database?
Formstr answers by moving the form object into Nostr. You create a form, publish it to relays, share it as an address, collect responses as Nostr events and keep the important keys close to the people who need them. That does not make every form magically private. It does make the architecture worth paying attention to, because the usual form-builder deal is lopsided. The service owns the database, the dashboard, the export path and the shutdown risk. Formstr tries to make the form portable before it becomes valuable.
That is the attitude to bring when you read this app. Do not ask whether it is "like Google Forms but decentralized" and stop there. Ask where the form lives, where the responses go, who can read them, what keys are needed, which relays are involved and whether the form can keep working when the website you first used is no longer the center of the story.
What Formstr actually publishes
The Formstr repository calls the project a forms implementation on the Nostr protocol. Its current GitHub home is formstr-hq/nostr-forms, an MIT-licensed TypeScript monorepo created on August 29, 2023 and still active when checked on June 6, 2026. The repo was last pushed on June 2, 2026, with 74 stars, 53 forks and 91 open issues. That is a useful signal: this is not just a landing page with a slogan. There is a product, an app package and a separate SDK package.
The technical heart is Formstr's NIP-101 work, titled "Forms on nostr" in the official NIPs repository. Be careful with the wording here. As of June 6, 2026, pull request 1190 is still open, not merged into the canonical NIP set. So the honest description is this: Formstr is building around a proposed forms-on-Nostr event model. In that model, a form template is a replaceable event of kind 30168, while responses are kind 1069 events that point back to the form through an address tag.
That sounds dry, but it is the part that makes the app different. A form is not merely a JSON blob on a private server. Its fields are represented as tags: a unique identifier, a name, settings, relay tags and field tags. Public forms can expose those tags directly. Private forms can put the sensitive material into encrypted content. Responses attach to the form by saying, in effect, "this answer belongs to this form address." The SDK code normalizes those tags back into a JavaScript object, renders an HTML form and publishes submitted answers to the relays listed by the form.
If you have ever lost access to a SaaS dashboard, this matters. The form address can be encoded as a Nostr naddr. The form can name its relays. The SDK can fetch it, decrypt it when you provide the right key material, render it and submit responses without asking one central backend for permission. That does not remove every dependency. You still need working relays, a useful client or page and key handling that you do not fumble. But the shape of the dependency changes.
Private forms, view keys and the quiet part
Privacy is the place where a form tool has to earn your trust. Formstr's code distinguishes public and encrypted forms. When a form is encrypted, the app generates a form signing key and a separate view key. The form template event keeps the kind 30168 shell, but the actual form tags can be encrypted into the content field with NIP-44. Fetching code then uses an nkeys value, extracts the viewKey and derives the conversation key needed to decrypt the form event.
The access-control trail goes further. The repository context describes view access and edit access as separate ideas. A view key lets someone read a private form. A signing key controls edits to the form template. Gift-wrapped events, connected to NIP-59 style wrapping, can distribute those keys to selected people. The createForm code also adds participant and editor handling, pushing p tags and allowed tags where relevant. The point is not simply "password protected form." The point is closer to a key-based access model that speaks Nostr's language.
Responses have their own careful edge. In the SDK, a submitted response becomes a kind 1069 event. Identified submissions can be signed by the user's signer and encrypted to the form's pubkey using NIP-44. Anonymous submissions use an ephemeral key, so a person can answer without turning the act into a permanent identity flex. Fetching responses is done by querying relays for kind 1069 events that reference the form's kind 30168 address.
That is elegant, but you should not confuse elegance with a guarantee. A public form is public. Relay operators may see metadata. Form authors can still learn plenty from responses, timing and content. If you collect sensitive answers, you need to explain what you are asking, why you need it, who can decrypt it and how long you plan to keep it. Nostr gives Formstr a better ownership model, but it does not absolve the form owner from behaving like an adult.
The SDK changes the shape of the product
The most important clue in the repo may be the package split. The web app is one thing. The SDK is another. The web app is the builder and dashboard: React 18, TypeScript, Ant Design, Tailwind, styled-components, React Router, nostr-tools, i18next, Recharts, xlsx and the usual build machinery around Webpack. The SDK is a smaller library, currently versioned 0.2.7, with nostr-tools, NIP-44 support, AES-JS, bech32 nkeys handling, validation and a browser bundle path.
Why should a reader care? Because an SDK turns Formstr from a destination into infrastructure. The SDK fetches a form by naddr, can fetch with a view key, normalizes raw Nostr tags, renders an HTML form, attaches a submit listener and publishes responses. That means a developer can embed a Nostr form somewhere else without asking every visitor to understand the Formstr dashboard. It also means Formstr can become a quiet layer underneath a site, a community page, a popup at an event or a small static tool.
The newer portable-form feature makes that even more concrete. In a June 27, 2025 long-form post, the Formstr account introduced downloadable forms: a form can be exported as a standalone HTML file, opened locally, hosted elsewhere or archived, while still submitting responses to Nostr relays when it has network access. That is a very Formstr idea. The form is not a database row you are allowed to visit. It is a file and an address and a set of keys and relay instructions.
You can feel the difference in practical terms. A community can publish a call for volunteers without forcing people through a big platform. A small event can carry its registration form as a single file. A researcher can keep a copy of the form that was actually sent. A builder can embed it in another site and still have responses move through Nostr. This is not glamorous, but it is deeply useful in the way infrastructure is useful: it reduces the number of places where your work can be trapped.
Where I would use it
I would reach for Formstr when the form itself needs to outlive the platform page. A meetup signup is an obvious use. So is a project application, a bug-report intake form, a community survey, a guest list for a small venue, a contact form for a creator, a feedback loop for an open-source release or a lightweight submission path for a Nostr directory. If the thing you collect is casual and reversible, Formstr is a good experiment. If the thing is highly sensitive, Formstr may still be interesting, but the privacy design needs to be part of the work, not a line in the footer.
The app also fits people who already live with Nostr signers. The README names NIP-07 browser extensions and NIP-46 remote signers as prerequisites for development. In user terms, that means Formstr belongs in the same mental drawer as Alby, nos2x, nsec.app, Amber, Nostr Connect and the rest of the signer conversation. If you understand why your private key should not be typed into every site, you understand why a form builder that leans on signers is trying to solve a real problem.
There is also a small but important continuity feature: "My Forms." The SDK and project context describe a kind 14083 list used to remember a user's forms and store the form secret material in encrypted content. That matters because a form creator needs more than a public link. They need to find their own forms again, edit them and read responses. Formstr is trying to do that with Nostr events and encrypted lists rather than a normal account database. It is a hard problem, and the rough edges are visible, but the direction is coherent.
The caution is the same one I would give for any live Nostr product with serious data flow. Test with a harmless form first. Submit once with a signer and once anonymously. Check which relays accepted the event. Export responses. Try the standalone HTML path. Confirm whether your intended recipients can open a private form with the key material you send them. If your workflow depends on deletion, legal erasure, enterprise audit logs or a support desk that can recover everything after you lose your keys, be honest: Formstr is probably not that product yet.
But if your goal is to understand what open social infrastructure can do beyond timelines, Formstr is one of the better examples. It takes a boring web primitive and asks the right question: can this become a signed, portable, relay-published object? Once you see forms that way, other things start to look different too. Invitations, applications, checklists, intake flows, receipts, lightweight CRM records - all of them can be thought of as structured events first and platform screens second.
Sources worth opening
This article keeps claims close to the public project trail: the official app, the current repository, the SDK code, the proposed NIP and Formstr's own long-form update.
- Official project
- NostrApps listing
- formstr-hq/nostr-forms on GitHub
- Repository README
- Project context and NIP-101 notes
- Web app package
- SDK package
- Form creation code
- Response fetching code
- Formstr SDK implementation
- Form template fetching and decryption
- nkeys encoding utility
- NIP-101 pull request: Forms on nostr
- Formstr post about downloadable forms
- Nostr protocol NIPs repository
- NIP-01 basic protocol flow
- NIP-05 DNS identifiers
- NIP-07 browser signer capability
- NIP-10 text note threading
- NIP-11 relay information document
- NIP-19 bech32 encoded entities
- NIP-44 versioned encryption
- NIP-46 remote signing
- NIP-51 lists and mute lists
- NIP-56 reporting
