NIP-55: Android Signer Application
Android clients need to not all become key vaults
NIP-55 is the on-device cousin of NIP-46. The problem is the same: a Nostr client wants to act as the user, but it must not have to hold the user's private key. On Android, the solution can be local. A signer app owns the key. Other apps ask it to sign.
That changes mobile UX. A user can install a signer, approve a client, remember permissions for safe background use and keep the key out of experimental clients. Web pages can also use the signer through Android intent-style flows, with warnings about clipboard and callback behavior.
Amber is the obvious public example. It holds the nsec and lets other Android clients request signatures, while Amethyst and other clients can integrate with that signer model.
Intents, content resolver, package names and remembered permissions
NIP-55 defines three communication methods: Android intents, content resolver and web. Intents open the signer so the user can approve or reject. Content resolver can run in the background, but only for permissions the user has previously chosen to remember. Web returns results through a callback URL or clipboard-style behavior.
The connection starts with get_public_key. The signer returns the user pubkey and its Android package name. The client needs to store both and address future requests to that package name rather than repeatedly rediscovering the signer.
Methods include sign_event, NIP-04 and NIP-44 encrypt/decrypt calls, and public-key retrieval. Permissions can be scoped by method and, for signing, by event kind. This is where the user gets a real chance to approve narrowly instead of trusting a whole app forever.
greenart7c3 shaped the Android signer path in public
greenart7c3 added the visible Android signer NIP in November 2023 and has remained central in later changes. The file picked up package-name handling, permissions, intent flags, web method changes, rejected permission checks, content resolver guidance and return-field fixes.
In 2025 and 2026, the file was sharpened around how to initiate a connection, how to use get_public_key with content resolver and how to simplify the spec. This history is useful because Android signing is not abstract protocol theory. It is Android platform behavior, user prompts and permission storage.
A NIP-55 page needs to therefore be practical. The standard succeeds only if clients and signers make the approval surface understandable.
Amber proves the signer idea in daily Android use
Amber's project page and repository describe it as a Nostr event signer for Android, supporting NIP-55 and NIP-46 style signing. It is important because it turns the NIP into something a user can install and a client can call.
A client implementing NIP-55 needs to detect a signer through the nostrsigner scheme, request only the permissions it needs, keep the returned package name, and distinguish rejected, missing and approved permissions. A signer needs to show the event kind, app identity and requested method before asking for approval.
The dangerous anti-pattern is a client that treats the signer as an invisible signing daemon. The whole point is that the user can understand and control signing.
Local signing can still be confusing
A local signer reduces key exposure, but it can still train users to approve blindly. Poor prompts, unclear package names or remembered permissions that are too broad weaken the benefit.
Web flows carry extra risk because callback and clipboard paths can leak or confuse results. The NIP includes warnings because the Android platform gives options, not automatic safety.
Read NIP-55 in the wild
NIP-55 brings Android into the signer story. It lets Android apps request signing from a dedicated signer application instead of embedding the private key everywhere.
The trust boundary is app-to-app communication. You need to see which app asks, what it asks to sign and which signer responds. A mobile permission prompt is not enough if the event itself is opaque.
What changes when you actually use it
For you, NIP-55: Android Signer Application is felt when identity stops being a username and becomes authority. A client, signer, name, proof or auth event may look like account plumbing, but it decides who can publish, approve, connect, recover or be recognized. Read NIP-46 beside it so you can tell the difference between a convenient identity surface and the key material that actually controls the account.
What changes for builders and operators
For builders, NIP-55: Android Signer Application means making authority visible before action. A signer prompt, name proof, delegation, encrypted key, external identity or HTTP auth event needs plain language around scope, expiry, destination and recovery. If a person has to guess what they are authorizing, the protocol has already lost the trust battle.
What the official file makes concrete
The official file is organized around Rationale, Terminology, Communication methods, Setup, Initiating a connection, Methods, Using Intents, Using Content Resolver. Inspect kind 1, draft, com.example.signer, nostrsigner, AndroidManifest.xml, user-pubkey, package name, type because these are the pieces most likely to surface as product behavior. Read it beside NIP-46 before treating it as isolated.
NIP-55: Android Signer Application is an authority path, not decoration. A name, key, signer, delegation or auth event decides who can act as you.
Where it breaks
The failure mode in NIP-55: Android Signer Application is authority drift. A name resolves to an old key, a signer approves too broadly, an auth event gets replayed, a delegation lasts too long or a private key backup gives false comfort. The product has to keep control boundaries visible after onboarding, not only during setup.
Where this appears outside the markdown
In the ecosystem, NIP-55: Android Signer Application usually appears at the doorway: account setup, profile recognition, signer approval, cross-platform proof, remote signing, HTTP auth or recovery. That doorway needs unusually clear language because identity mistakes are sticky. Once a key, signer or proof is trusted in the wrong place, every later feature inherits the confusion.
The nearby-standard trap
The nearby-standard trap in NIP-55: Android Signer Application is confusing recognition with control. A name, signer, URI, encrypted key, delegation or auth signature may all sit near identity, but they answer different questions. Read NIP-46 and ask one thing each time: who can act, who can verify, and what can be revoked?
Language that keeps the feature honest
Good product copy for NIP-55: Android Signer Application names the authority. It says whether you are sharing a public key, approving a signature, trusting a domain, exporting an encrypted secret, delegating power or authenticating to a service. Small labels matter because identity mistakes do not feel small after they happen.
What this page does not promise
NIP-55: Android Signer Application does not make identity effortless or risk-free. It can help keys, names, signers, delegation or authentication become portable, but it cannot decide who you trust, how you back up secrets or whether a domain, app or signer deserves authority. Read NIP-46 as a control map before handing any interface the power to sign, verify or speak for you.
Read it as a field test
Start NIP-55: Android Signer Application with the moment of authority: signing, naming, delegation, authentication, encryption or recovery. Then ask which key or service can act. The source terms kind 1, draft, com.example.signer, nostrsigner, AndroidManifest.xml, user-pubkey are useful because they turn vague identity language into concrete control points. Without that, a friendly login screen can hide the most important security decision.
Where the standard earns trust
The source links give you places to test the interpretation in public: Amber GitHub repository, OpenSats Amber page, Amethyst GitHub repository, Android intents documentation. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-55 source is the anchor for exact wording, and NIP-55 commit history shows how that wording moved over time. The strongest secondary clues here are Amber GitHub repository, OpenSats Amber page, Amethyst GitHub repository. Treat this evidence chain as part of the article, not as footnotes. A NIP page becomes useful when you can move from claim to source to working behavior without guessing.
Keep the chain visible for NIP-55: Android Signer Application: first the human promise, then kind 1, draft, com.example.signer, nostrsigner, AndroidManifest.xml, user-pubkey, then the implementation record, then the real-world failure case. That order keeps NIP-55 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Who gains authority when this NIP is used: your key, a signer, a domain, a delegated key, a wallet or a web service?
- Can you revoke, rotate, back up or inspect that authority before something goes wrong?
- Does the interface separate public recognition from private signing power in language you can act on?
What to verify before you rely on it
- Find
kind 1,draft,com.example.signer,nostrsigner,AndroidManifest.xmlin the official file and check where the UI exposes the same concept. - Read NIP-46 as context before treating NIP-55 as a complete product story.
- Open at least one implementation, mirror, pull request or library source from the source links before trusting that the idea is mature.
- Test the unhappy path: missing relays, stale metadata, invalid signatures, blocked events, expired state, revoked permissions or unavailable media.
- Write the user-facing copy in plain language. If a standard changes authority, privacy, money, moderation or recovery, say that before the click.
Direct sources
Use these sources for NIP-55: Android Signer Application in that order: Official NIP-55 source for the current wording; NIP-55 commit history for the change record; Amber GitHub repository, OpenSats Amber page, Amethyst GitHub repository for public context. The article gives you the consequence in plain language, but the source trail is where exact fields, status notes, unresolved debates and implementation proof stay checkable.
