CraysNostrame
Nostrame is a browser-side Nostr vault: it injects window.nostr, signs events without handing private keys to websites, manages multiple accounts, encrypts its vault with a master password and lets you decide which sites may ask for which signing actions.
getnostrame/nostrame, and the Chrome Web Store listing is offered by anderson.juhasc.The signer is the boundary
Nostrame belongs to the small class of Nostr apps that do not try to be the place where you read everything. Its job is more sensitive: it sits between websites and your signing key. A Nostr web client can show you a button, build an event and ask for a signature. Nostrame is the extension that decides whether that request should receive one. That boundary is the whole point.
The project describes itself as a Nostr signer and account management extension for Chromium. NostrApps lists the same basic identity and highlights NIP-07, BIP-39 seed phrases, NIP-49 imports, AES-256-GCM encryption, per-website permissions, NIP-65 relay lists, encrypted vault backup and auto-lock. The GitHub repository currently resolves as getnostrame/nostrame, is public-domain software under the Unlicense, and traces back to the Chrome Web Store listing for extension ID phfdiknibomfgpefcicfckkklimoniej. On June 6, 2026, the repo had been updated on June 2, 2026, and its bundled manifest reported version 1.1.2. Store mirrors can lag; Extpose showed 1.1.1 with a June 1, 2026 update. That mismatch is exactly why a signer page should keep source links close.
The developer trail is public but modest. The Chrome Web Store and mirrors list the publisher as anderson.juhasc. The repo was created on April 25, 2024, has a small public footprint, and uses React, nostr-tools, webextension-polyfill, async-mutex, identicon.js, qrcode.react and react-router-dom. The README says Nostrame is based on fiatjaf's nos2x, the original NIP-07 browser extension. That lineage matters: Nostrame is not inventing the signer pattern. It is trying to make the pattern feel more like an account vault.
That is the right ambition. The worst way to use Nostr on the web is to paste an nsec into every app that asks nicely. The better way is to let websites request signatures and let a signer decide. Nostrame tries to give that signer enough account management, backup and permission memory that it can become a daily tool rather than a fragile demo.
What it injects into the browser
Nostrame is a Manifest V3 extension. Its manifest declares a background service worker, an options page, a popup, a content script that runs on <all_urls>, and a web-accessible nostr-provider.js file for HTTP(S) pages and local development origins. The declared permissions are storage, windows and alarms, with notifications as optional. In browser-extension language, that is the basic machinery needed to store encrypted state, open permission prompts and manage lock timers.
The content script injects nostr-provider.js into the page. That provider creates window.nostr with getPublicKey(), signEvent(event), nip04.encrypt(), nip04.decrypt(), nip44.encrypt() and nip44.decrypt(). Calls are sent from the page to the content script with window.postMessage, then forwarded to the background service worker through browser.runtime.sendMessage. The content script also sends the current host and favicon, so the permission window can show you which site is asking.
That architecture is the familiar NIP-07 bridge, but Nostrame's implementation adds a few useful hard edges. It handles extension-context invalidation by telling the page to reload instead of silently failing. It serializes errors into plain objects because some Chromium and Brave messaging paths otherwise lose the error message. These are not glamorous details, but they are the details that make an extension feel less haunted when the browser updates, sleeps or restarts the service worker.
The important reader takeaway is simple: websites do not get the private key through window.nostr. They get an API for requests. Nostrame's background worker is where signing and decryption happen, and that worker is also where the vault is unlocked or locked. That separation is the thing you are installing.
The vault is the real product
The source is unusually explicit about its vault model. The background code states a set of security invariants: the in-memory vaultKey is the single source of cryptographic truth; UI lock flags are only hints; service worker termination must be treated as automatic lock; private keys never leave background memory; and session storage contains no secrets. That is the kind of comment you want to see in a signer, because it tells you the author understands where the dangerous line is.
The crypto module uses PBKDF2-SHA256 with 600,000 iterations to derive a non-extractable AES-GCM key from the master password. It encrypts vault data with AES-256-GCM, a 32-byte salt and a 12-byte IV, and stores the output as a versioned v2: blob. It also contains a legacy decryptor for older AES-CBC data with 10,000 PBKDF2 iterations, then immediately migrates that data to the stronger v2 format on successful unlock. That migration path is worth noting because real extensions live across versions, and users do not always rebuild vaults from scratch.
When the vault is unlocked, Nostrame partitions sensitive material in background memory. Private keys, mnemonic words and the active account key are treated as private material. Public metadata is separated. On lock, the code attempts to wipe private fields, clears metadata, clears the cryptographic key and writes only a UI hint that the vault should appear locked. Auto-lock is implemented with Chrome alarms, and the default timeout is five minutes, with options for ten minutes, thirty minutes or never.
Precision matters here. The encrypted vault is stored by the extension, so the extension can remember your accounts. The decrypted keys are what Nostrame tries to keep only in memory while the vault is unlocked. That is a much stronger posture than leaving raw keys in extension storage, but it still means your master password, browser profile, extension update path and local machine security matter. A signer is a vault door, not a magic spell.
Accounts, imports and recovery
Nostrame is not only one key in a popup. The signup flow generates BIP-39-style seed words through nostr-tools/nip06, asks for a passphrase and a master password, derives the first private key, creates an encrypted vault and publishes a default relay-list event if the account does not already have one. The derive-account modal increments an account index and derives another private key from the same mnemonic and passphrase. That gives you multiple identities inside one vault without keeping separate seed phrases for each one.
Imports cover the formats a Nostr user is likely to bring from another tool. The import modal accepts nsec, raw hex, mnemonic words or ncryptsec. For ncryptsec, it uses NIP-49 decryption with a separate decryption password. It checks whether the key already exists among imported or derived accounts, stores the imported account, makes it active and re-encrypts the vault through the background worker. It also calls the relay-list helper so imported accounts can get a kind 10002 relay list when needed.
Backup and restore are intentionally plain. Export downloads a JSON file containing the encrypted vault blob. Import reads that JSON, asks for the backup password, sends the encrypted vault to the background worker, decrypts it, migrates legacy format if necessary and stores the new encrypted vault. The backup file is not a plaintext seed phrase. It is an encrypted object that is only useful with the right password. That is good, but it also means password discipline is not optional. Lose the password and the backup is supposed to be useless.
The privacy policy says Nostrame does not collect, store or transmit personal data, and that processing happens locally on the user's device. It also makes the necessary Nostr exception: the extension communicates with user-chosen or default relays, and only data the user intentionally makes public is transmitted. That is the honest version of privacy for a Nostr signer. The extension can avoid analytics and external servers, but Nostr itself is a relay network. Public events are public because you publish them.
Permissions are where trust gets real
A signer lives or dies by prompts. Nostrame's prompt UI shows the requesting host and favicon, names the requested capability and lets you reject once, reject forever, authorize once, authorize forever, or authorize a specific event kind when a signEvent request includes a kind. The common permission code stores policies per host, action and request type. For signing requests, kind-specific conditions are checked against the event. For non-signing calls, a remembered forever or kind policy can auto-authorize.
That is the right level of granularity. A website asking to read your public key is not the same as a website asking to sign a kind 1 text note, a kind 0 metadata event, a relay-list event or an encrypted-message action. Nostrame's prompt model lets you build memory around those differences. You can let a trusted client sign one class of events while still requiring prompts for others. You can reject a hostile site forever. You can avoid turning the extension into a silent rubber stamp.
The extension can optionally show notifications for allowed or denied actions. It can also open prompt windows and keep track of permission state in extension storage. This is why extension permissions deserve real attention. A NIP-07 signer must inject into pages and communicate with them; otherwise it cannot do its job. But because it sits in that position, you should install it only from the verified listing, review the public code when you can, and periodically check which sites you have allowed.
Nostrame's README lists supported NIPs as NIP-01 for event signing, NIP-04 for legacy encrypted direct messages, NIP-06 for mnemonic key derivation, NIP-07 for browser signing, NIP-19 for bech32 entities such as npub and nsec, NIP-44 for modern versioned encryption, NIP-49 for encrypted private keys and NIP-65 for relay list metadata. That is a strong signer surface. It also means the prompts matter more, not less.
Relays belong in account management
Nostrame includes a relay page because account management in Nostr is incomplete without relay management. A key tells the world who signed. A relay list tells clients where to look. The relay UI lets you add a wss:// relay, toggle read and write flags, remove entries, refresh from the network and publish changes. If no kind 10002 relay list is found for the account, the UI warns that it is using default relays and asks you to publish your relay list so other users can find your content.
The outbox helper is careful about the distinction. It says NIP-65 defines how users publish relay preferences, while the outbox model describes how clients use that information. When fetching another user's content, you query that user's write relays, not your own favorite relays. Nostrame fetches kind 10002 events from discovery relays such as wss://purplepag.es/, wss://relay.damus.io/, wss://nos.lol/ and wss://nostr.wine/, verifies signatures, rejects future timestamps, caches relay lists and falls back to defaults when no useful list is found.
Publishing a relay list uses an intentional tradeoff: the helper treats one successful relay publish as success, while logging failures. That gives fast feedback and avoids an all-or-nothing feel, but it does not guarantee broad propagation. This is a good example of the kind of product truth Nostr users need to learn. Publishing to relays is probabilistic in practice. A signer can help, but it cannot make every relay behave.
The relay work also explains why Nostrame feels like more than a key popup. It wants an account to carry a usable routing trail. Create a vault, derive an account, import a key or switch identities, and the extension tries to keep relay-list publishing in the workflow. That is a meaningful difference from a signer that only answers signEvent and leaves discovery as somebody else's problem.
How I would test it
First, verify the listing and code path. The Chrome Web Store listing is the install path, but the repo and bundled manifest should be part of your trust check. Confirm the extension ID, check the public repository, read the privacy file, and notice the version trail. With a signer, install source matters. A fake signer can be catastrophic even if the popup looks polished.
Second, create a throwaway vault before you bring in a real identity. Generate a mnemonic, set a strong master password, unlock and lock the vault, change the auto-lock timeout, and confirm that the extension behaves as if service-worker restarts can lock it. Then connect it to a harmless Nostr web client and watch the NIP-07 flow: get public key, sign one low-risk event, reject once, authorize once, authorize one event kind, and revoke a remembered permission.
Third, test account movement. Derive a second account, import a disposable nsec, import a ncryptsec if you use NIP-49, switch between accounts and check that the active public key changes in the client. Export an encrypted backup, import it into a clean browser profile if you have a safe test environment, and prove to yourself that the backup password is required. Do not wait until a real machine failure to learn how recovery works.
Finally, test relays. Add a relay, set read and write flags, publish a kind 10002 list, and check from another client whether discovery improves. Then step back and ask the adult question: do you want a browser extension to hold this identity, or do you want a separate signer, a hardware path, a remote signer or a mobile signer? Nostrame gives a serious Chromium vault. That is useful. It is also a place where your habits decide whether the tool becomes safety or convenience theater.
Sources worth opening
This article keeps claims close to the Chrome listing, mirrors, public repo and source files. Start here before trusting any signer with a real key.
- Nostrame on Chrome Web Store
- NostrApps listing for Nostrame
- Extpose mirror for Nostrame
- Nostrame GitHub repository
- Nostrame README
- Nostrame package.json
- Nostrame extension manifest
- Nostrame privacy policy
- Nostrame Unlicense text
- Nostrame provider script
- Nostrame content script
- Nostrame background service worker
- Nostrame crypto module
- Nostrame vault service
- Nostrame signup and seed flow
- Nostrame account switcher source
- Nostrame account import source
- Nostrame account derivation source
- Nostrame permission prompt source
- Nostrame permission policy helpers
- Nostrame relay list UI source
- Nostrame outbox and relay-list helper
- Nostrame vault export source
- Nostrame vault import source
- Nostrame auto-lock setting source
- nos2x, the original NIP-07 extension Nostrame credits
- NIP-06 mnemonic key derivation
- NIP-07 browser signer capability
- NIP-44 versioned encryption
- NIP-49 encrypted private keys
- NIP-65 relay list metadata
