CraysKeys Band
Keys Band is a Toastr.Space NIP-07 signing extension for Nostr, built to keep nsecs out of web apps while managing multiple keys, site permissions, relays and signing history.
The signer, not the stage
Keys Band sits in the quiet part of the Nostr stack, which is usually the part you should care about most. A feed client can be beautiful, ugly, fast, slow or full of weird design choices. You can switch it. Your private key is different. Lose it and you lose the account. Leak it and someone else can sign as you. That is why signers matter: they separate the app you are using from the secret that proves you are you.
The public site says it plainly: "Safe nsecs" and "Fortify Your Nostr Keys." The Chrome Web Store description is even more direct: Keys.Band lets you sign Nostr events on web apps without giving those apps your keys. The GitHub README calls it a multi-key Nostr signing extension and says it implements NIP-07. That puts Keys Band in the same family of tools as nos2x, Alby-style browser signing and other `window.nostr` extensions. It is not trying to be your social network. It is trying to be the thing your social network asks before it signs.
The project trail is public. The website credits the Toastr.Space team. The repository lives at `toastr-space/keys-band`, uses an MIT license, and is written mainly in TypeScript and Svelte. As of June 6, 2026, GitHub showed the repo created on June 19, 2023, updated on June 6, 2026, last pushed on January 21, 2026, with 38 stars, 9 forks and 6 open issues. The contributor list is led by `ssakone` and `satoshisound`, with additional contributions from Giszmo and dependabot. The Chrome Web Store listing identifies Keys.Band as a social networking extension and discloses that the developer does not collect or use user data.
What NIP-07 does here
NIP-07 is the browser-extension bridge that lets a website talk to a Nostr signer through `window.nostr`. In practical terms, a web client can ask for your public key, ask for an event to be signed, ask for relay information, or ask for encryption and decryption support. The important part is that the website does not need to hold your private key. It sends a request; the extension decides what to do.
Keys Band's README lists the core methods it exposes: `getPublicKey()`, `signEvent(event)`, `getRelays()`, `nip04.encrypt(pubkey, plaintext)` and `nip04.decrypt(pubkey, ciphertext)`. The background code matches that list. For `getPublicKey`, it derives the public key from the selected private key. For `signEvent`, it fills in the pubkey when needed and finishes the event with `nostr-tools`. For `getRelays`, it returns a NIP-07 style map of relay URLs with read and write policies. For NIP-04 encryption and decryption, it calls the matching `nostr-tools` functions.
That sounds technical, but the user experience is simple: a Nostr web app wants to do something with your identity, and Keys Band becomes the gate. The extension injects a provider script into pages when `window.nostr` is not already present. The content script listens for messages from the page and forwards them to the extension runtime. The background side checks permission state, builds a response, records history, and either returns the signed or decrypted result or sends back a rejection.
This is why signers are such a good teaching tool. They reveal the difference between "logging into a website" and "authorizing an app to ask for signatures." A centralized site can create an account for you. Nostr does not work that way. Your key signs events. The signer makes that act visible enough that you can stop giving your nsec to every web page with a shiny compose box.
Permissions are the product
The strongest part of Keys Band is not the icon or the phrase "safe nsecs." It is the permission model. The website highlights fine-grained control for each website, including duration of authorization and scope of access. It also talks about blocking untrusted websites, tracking activity history and managing notifications for events by priority. That is exactly the right framing. A signer is only useful if it gives you a memory of what you allowed.
The source code shows this idea in motion. A site can be allowed or rejected. A permission can be session-length or persistent. The background controller checks whether the current domain is allowed, rejected or still undecided. The code records request history by domain and request type. If the site is not already authorized, the extension can ask the user before returning a public key, signing an event, decrypting a message or exposing relay data.
That history matters because Nostr activity can be deceptively casual. A small web app might only ask for your public key. Another might ask to sign a post. Another might ask to decrypt something. Another might ask again and again until you stop reading the dialog. Keys Band gives you a place to see and manage that relationship. The best security interface is not one giant warning. It is repeated, understandable friction at the moments where a signature changes something.
Multi-key support also changes the way a reader should think. Many Nostr users eventually carry more than one key: a personal key, a test key, a project key, maybe a throwaway key for experiments. Keys Band's website names multi-key management as a main feature, and the code stores profiles rather than assuming one global identity. That is useful because Nostr identity is portable but not always singular. The tool lets you switch context without treating every website as worthy of your main account.
Relays, multiple keys and code
Keys Band also cares about relays. The website says you can manage relays and toggle notifications. NostrApps calls out saved preferred relays. The utility code has default relays such as `wss://nos.lol`, `wss://relay.damus.io` and `wss://nostr.wine`, checks relay availability, avoids repeatedly hammering recently failed relays, and can read a user's kind 10002 relay list. It also builds NIP-07 relay-policy responses where each relay can be read, write or both.
The relay-writing code is worth reading carefully. It creates a kind 10002 relay-list event, signs it with the selected private key and publishes it through the relay pool. There is a small source-level wrinkle: the code constructs a relay tag with read/write access but then pushes the simpler relay URL tag into the array. That may be intentional, old, or simply an implementation detail that changed around it; there is no need to turn that into drama. The larger point is clear: Keys Band is not only a signing button. It also understands that a Nostr identity carries relay preferences.
The build stack is modern and fairly small: Svelte, Vite, TypeScript, Tailwind, Skeleton UI, daisyUI, `nostr-tools`, webextension-polyfill, Vitest, browser storage tests and relay-publish tests. The public site still frames the extension as a Chromium browser tool, and the README says it is Chromium-only. At the same time, the package scripts include `build:firefox`, and the repository contains a Firefox manifest with a Gecko extension ID. That does not mean every user should assume a polished Firefox distribution exists. It does mean the codebase has moved beyond a one-browser-only idea internally.
The extension manifest is also revealing. The Chrome manifest is Manifest V3, uses a background service worker, popup, side panel, storage permission, scripting, tabs and sidePanel access. It injects `content.js` and exposes the `assets/nostr-provider.js` script to pages. Those details are normal for this class of extension, but they should remind you that a signer is powerful. Browser extension permissions are not decorations. They are the reason this tool can stand between websites and your key.
The caution that matters
Keys Band is useful because it lowers one bad habit: pasting an nsec into every Nostr web app. It does not remove the need for judgment. A browser signer still lives in your browser profile. It still depends on extension updates, local device safety, backup habits and your willingness to read permission prompts. If your computer is compromised, if you install a malicious extension, or if you approve every request without looking, a signer cannot rescue you from yourself.
The right way to test Keys Band is boring and serious. Install it from the official route. Check that the extension and repository match. Create or import a low-risk key first. Pair it with one familiar Nostr web app. Watch exactly what the site requests. Look at the history. Change permissions. Try a second app. Confirm that a rejected request stays rejected. Confirm that your preferred relays look the way you expect. Then decide whether it deserves a more important key.
Who is Keys Band for? It is for readers who use Nostr in Chromium-based browsers and want a cleaner signing workflow than raw nsec login. It is for people with multiple keys. It is for users who try many web clients and need a boundary between curiosity and custody. It is also for developers who want to test NIP-07 flows against a compact open-source extension rather than asking users to trust a custom key box inside every app.
Keys Band is a small app with a large responsibility. That is the right way to respect it. It will not make your feed better, write better posts, or teach relays how to behave. It does one quieter thing: it asks websites to request signatures instead of swallowing your private key whole. In Nostr, that distinction is not a detail. It is the line between using open apps and handing your identity to whichever app you opened last.
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.
- Keys Band official site
- Keys.Band on the Chrome Web Store
- toastr-space/keys-band on GitHub
- Keys Band README
- Keys Band package metadata
- Chrome extension manifest
- Firefox extension manifest in the repository
- NIP-07 browser extension specification
- NIP-04 encrypted direct message specification
- NostrApps listing for Keys Band
- Nostr protocol NIPs repository
- NIP-01 basic protocol flow
- NIP-05 DNS identifiers
- 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
- NIP-57 lightning zaps
- NIP-65 relay list metadata
- NIP-89 recommended application handlers
- NIP-94 file metadata
- NIP-98 HTTP auth
