Craysnos2x
nos2x is one of the early pieces of Nostr plumbing that made web clients safer to use. It is not a feed, not a wallet, not a social network. It is the little signer sitting between a website and your secret key, asking one hard question every time: should this site be allowed to sign that?
window.nostr to web apps, signs events with nostr-tools, supports NIP-04 and NIP-44 encryption methods, stores permissions per host and keeps the private key inside extension storage instead of handing it to every site you visit.The browser should not own your key
nos2x exists because the early Nostr web had a dangerous temptation: paste your private key into a website, then hope the website behaves. That can work once. It cannot become a sane social protocol. Your Nostr key is not a password you reset when a service leaks it. It is the signing identity behind your notes, follows, profile metadata, deletions, reactions and encrypted conversations. Lose control of it and someone else can speak as you until the rest of the network learns to distrust that key.
The clean idea behind nos2x is brutally simple. Let the web app ask the browser for a Nostr capability, but keep the private key in the extension. The site does not receive your secret. It receives a public key, a signed event or an encrypted/decrypted payload after you have allowed the action. That is why NostrApps calls nos2x the original signer and why the project still matters even now that newer signers exist.
When you use a Nostr web client, the client wants to do something on your behalf. Maybe it wants your public key so it can load your profile. Maybe it wants to sign a note. Maybe it wants to decrypt a direct message. A signer is the person at the door asking whether that request is reasonable. nos2x is not a glamorous door. It is plain, small and direct. But the entire safety model of Nostr web apps depends on doors like this existing.
The project comes from fiatjaf, one of the original names attached to Nostr itself. The public GitHub repository was created in January 2022, lives at fiatjaf/nos2x, is written mostly in JavaScript, and its README describes the tool as a Nostr signer extension. The Chrome Web Store lists it as offered by fiatjaf, version 2.5.2, updated on April 3, 2025, with thousands of users. So the right way to read nos2x is not nostalgia. It is early infrastructure that is still being touched.
What nos2x actually injects
NIP-07 is the center of the story. The standard defines a browser-side window.nostr object. Websites can check whether it exists and call methods on it. The required core is small: get the public key and sign an event. Optional methods cover older NIP-04 encryption and newer NIP-44 encrypted payloads. nos2x implements that shape directly.
The extension injects a provider script into pages. The content script appends nostr-provider.js to the document, listens for messages from that provider and passes requests to the background service worker with the current host attached. The provider then exposes window.nostr.getPublicKey(), window.nostr.signEvent(event), NIP-04 encrypt/decrypt methods and NIP-44 encrypt/decrypt methods. It also has peekPublicKey() and a small nostr-link replacement helper for nostr: links.
The background script is where the sensitive work happens. It reads the private key from browser extension storage, derives the public key with nostr-tools, signs events with finalizeEvent, validates them, and performs NIP-04 or NIP-44 encryption and decryption. For NIP-44 it caches conversation keys in a small LRU cache and clears that cache when the signing key changes. That detail is not flashy, but it tells you the extension is handling the repeated cryptographic work as a living browser tool, not as a static demo.
The manifest tells another part of the story. nos2x is Manifest V3, Chromium-focused, with a background service worker, an options page, a popup, a content script running at document_end across frames, and permissions for storage, active tab and windows. Notifications are optional. The build is bundled with esbuild from source files such as background.js, content-script.js, prompt.jsx and options.jsx. That is useful because it keeps the article honest: this is not magic. It is a browser extension with the normal moving parts of a browser extension.
Permission is the product
The main user interface of a signer is not a feed. It is a permission moment. nos2x opens a prompt when a site asks for a protected operation. The prompt shows the host, explains the requested permission, and, when an event is involved, displays the event data. The buttons are not merely yes and no. You can authorize once, authorize a kind forever, reject once or reject a kind forever. That means nos2x understands that not all signatures carry the same risk.
That matters because Nostr event kinds are behavior. A kind 1 text note is not the same as a metadata update, a deletion, a list, a report or a direct-message payload. A signer that lets you allow only a kind is giving you a practical language for trust. You might trust a web client to ask for read-only public-key access. You might trust it to sign normal notes. You may not want it signing every possible event forever.
The permissions live as per-host policies in extension storage. The common helper checks whether a host already has an allow or deny rule for a permission, and for signing it can match conditions against the event kind. The options page then shows these policies in a table, including the domain, permission, answer, conditions and timestamp, with a revoke flow. This is the part many Nostr users never inspect, and it is exactly the part they should. A signer is only as good as the permissions you let accumulate inside it.
The options page also handles the key. It accepts a private key as nsec or hex, can generate a new key, stores the raw key in extension local storage after validation, and can display a QR code when you reveal it. It also supports an encrypted ncryptsec path through NIP-49 tooling: a password can be used to decrypt an imported encrypted key, and the page can also produce an encrypted display value. That does not remove the need for care. It does show that nos2x is not only a signer prompt; it is a small key and permission console.
The old signer is still live
The phrase "OG signer" can make a project sound frozen in amber. nos2x is older than many apps around it, but it is not dead. The Chrome Web Store page lists version 2.5.2 and an April 2025 update. The GitHub repository shows recent activity, hundreds of stars, dozens of forks and a public issue tracker. The package uses current Nostr libraries such as nostr-tools, plus webextension-polyfill, React for the extension pages and esbuild for the build.
Still, you should read its age with clear eyes. The README says Chromium-only and points Firefox users to nos2x-fox. The provider currently returns an empty object from getRelays(), so when old directory text talks about relay preference storage, do not turn that into a big modern feature claim without testing the current build. The real center of nos2x today is NIP-07 signing, encryption/decryption support, per-host permissions and link handling.
The Chrome Web Store privacy disclosure says the developer states that the extension does not collect or use your data. That is good to see, but with signers you should always think one layer deeper. The most important privacy fact is not a store badge. It is that the code is public, the extension purpose is narrow, and the website never needs the raw private key to request signatures. Store pages can be stale. Source code can be inspected.
There is also a larger historical point. nos2x helped make NIP-07 feel normal. Before Nostr Connect flows, mobile signer apps and polished wallet/signing hybrids became common, the browser signer extension was the obvious bridge between web clients and key custody. It let web Nostr grow without teaching every user the worst possible habit. That is the kind of product contribution that does not always look impressive in screenshots. It changes the default behavior of an ecosystem.
How to read it today
If you are new to Nostr, nos2x teaches one lesson better than any explainer: your private key should not be the login form. Install a signer, let sites request signatures, and make the permission prompt part of your reading. Do not click forever because the site feels familiar. Notice the host. Notice the event kind. Notice whether the request matches the thing you are trying to do.
If you are building a Nostr web app, nos2x gives you the baseline etiquette. Check for window.nostr. Ask for the public key only when you need it. Ask to sign only the event the user is actually trying to publish. Do not hide important event content behind clever UI. Do not ask for broad permission just because it is easier for your code. A signer makes bad permission design visible.
If you already use a newer signer, nos2x is still worth understanding because it is the clean old shape of the idea. Newer tools may add remote signing, mobile approval, Lightning features, account switching, better UI or stronger key-management patterns. But the core remains the same: the app prepares an unsigned event, the signer holds the key, the user approves or refuses, and the signed event can travel through relays.
That is why nos2x deserves a real article rather than a tiny catalog note. It is not just another app tile. It is one of the pieces that helped separate Nostr identity from web-client custody. Once you understand nos2x, a lot of Nostr becomes clearer. You start asking better questions: who has the key, what is being signed, which host gets permission, can I revoke it, and will the signed result still make sense outside this website?
Sources worth opening
This article keeps claims close to the public project trail. Start with these pages when you want to verify the product yourself.
- nos2x on the Chrome Web Store
- fiatjaf/nos2x GitHub repository
- nos2x README
- nos2x package.json
- extension manifest
- content-script.js
- nostr-provider.js
- background.js
- common.js permission helpers
- options.jsx
- prompt.jsx
- NostrApps listing
- NIP-07 window.nostr capability
- NIP-04 encrypted direct messages
- NIP-44 encrypted payloads
- NIP-49 ncryptsec private key encryption
- NIP-55 Android signer applications
- NIP-49 private key encryption
- 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
