Nostr archive

NIP-07: Browser Signers

A Crays archive page for NIP-07, explaining what it does, where it fits in Nostr and why it matters for identity, apps, relays and real-world systems.

NIP-07 defines the browser window.nostr interface used by extensions and web signers.

What it standardizes

It gives web apps a safer route to request public keys, event signatures and optional encryption without demanding that users paste private keys into every website.

  • Protocol layer. NIP-07 is not a consumer product. It is a convention that clients, relays or adjacent services may choose to support.
  • Interoperability. The value is not that every app looks the same. The value is that different apps can understand the same signed data.
  • Optionality. NIPs are implementation possibilities. Builders should implement the pieces that serve their product, security model and user journey.

Implementation notes

A browser extension or compatible signer injects a window.nostr object. Web apps request actions and the signer decides what to expose or approve.

  • Client responsibility. Clients need to explain the feature clearly because the user sees an experience, not a spec.
  • Relay responsibility. Relays may support only the parts that fit their storage, moderation, authentication and business model.
  • Indexing responsibility. Search, discovery and context often require extra indexers or opinionated clients on top of the raw protocol.

Crays relevance

Crays.net can use signer flows to make profiles, posts, votes and payments safer for users moving through the Crays ecosystem.

  • Crays.net. Profiles, creator pages and social proof need portable identity rather than a closed account table.
  • Crays World. Real venues need local context, member state, reputation and payments that can survive app changes.
  • DAO path. Future governance needs signed identity, membership context and auditable participation signals.

Risks and design discipline

Bad permission prompts, confusing UX or malicious clients can still create risk. Users need clear consent and key boundaries.

  • Do not overpromise. A NIP gives a shared format. It does not magically solve onboarding, moderation, UX or custody.
  • Keep the private key away. Any feature that increases private-key exposure increases the attack surface.
  • Use plain language. Most users need outcomes: login, pay, publish, vote, prove status, access a venue.
Back to the Crays Nostr page