• Every Nostr app wants your private key
• What NIP-55 actually specifies
• Amber: the app that created the spec
• What your phone actually protects (and what it doesn’t)
• NIP-55 vs NIP-46 vs hardware signers
• The iOS problem
• What you should actually do
• The pitch and the gap

§Every Nostr app wants your private key

You open a new #nostr client. Maybe someone on your timeline recommended it. You tap “Login” and it asks for your nsec. You paste it in. Now that app has your private key. Not a token, not a session cookie. The actual key. The one that is your identity.

Do this with three clients and your nsec exists in three separate app sandboxes, three clipboard histories, and whatever cloud sync those apps use for backup. Each one is a place your key can leak from. The developer doesn’t need to be malicious. The app just needs one dependency with a vulnerability, one unencrypted local database, one debug log that writes a little too much.

I wrote about this problem in my key management article. NIP-49 gives you encrypted storage. Browser extensions give you a safer login flow. But the fundamental issue remains: most Nostr clients want the raw key. They want to sign events themselves.

What if they didn’t have to? What if one app held the key and every other app just asked it to sign?

That is what NIP-55 does.

§What NIP-55 actually specifies

NIP-55 defines how Android apps talk to a dedicated signer app. The spec uses two Android mechanisms: Intents and Content Resolvers.

Intents are the manual path. Your Nostr client sends a nostrsigner: intent to the signer app. The signer pops up, shows you what’s being signed, and you approve or reject. The signed event goes back to the client. The nsec never leaves the signer’s process.

Content Resolvers are the background path. After the first approval, you can check “remember my choice.” Subsequent signing requests go through a Content Resolver and complete silently. No popup, no interruption. This is what makes the system usable rather than just theoretically secure.

The supported operations cover everything a client needs: get_public_key, sign_event, nip04_encrypt, nip04_decrypt, nip44_encrypt, nip44_decrypt, and decrypt_zap_event. A client can post notes, encrypt DMs, and process zap receipts without ever touching the private key.

The spec is explicit about intent: “Private keys should be exposed to as few systems as possible as each system adds to the attack surface.”

One detail worth noting. NIP-55 is literally titled “Android Signer Application.” greenart7c3 wrote the spec and built the first implementation. The specification and the app were born together, which is unusual for Nostr NIPs and probably why the spec is practical rather than abstract.

§Amber: the app that created the spec

greenart7c3 built Amber and authored NIP-55. Most protocol specs get written by one person and implemented by another. This one came from the developer who was actually building the thing. That shows in the design. The spec describes what Amber already does, not what someone imagined a signer should do.

What Amber does in practice: it holds your nsec in a single app. Other Android clients like Amethyst, or web clients accessed through the phone’s browser, request signatures through NIP-55. The key stays inside Amber. The client gets back a signed event and nothing else.

Amber also works as a NIP-46 bunker. It can serve as a remote signer for desktop or web clients over #nostr relays, using NIP-44 encrypted messages. Your phone becomes your signing server. You don’t need a VPS, you don’t need nsecBunker running on a machine somewhere. You just need your phone to be online.

The current version is 4.1.2 as of February 2026. The onboarding improved significantly in v3.2.8, which shipped in April 2025. The flow now is: create an account, set a display name, choose whether to auto-approve basic actions or manually approve each app, done. It is straightforward enough that someone new to Nostr could set it up without a tutorial.

Amber is not alone anymore. Primal Android shipped NIP-55 and NIP-46 signer support, and Aegis added nostrsigner: URI scheme support. Three signer options on Android, which means competition and less dependence on any single developer. Amber is available on F-Droid and GitHub. No Google Play, which is probably intentional.

§What your phone actually protects (and what it doesn’t)

Here is where most explanations of Amber get vague. “Your key is protected by the phone’s secure hardware” sounds good. The reality is more specific and more limited.

Android devices have a Trusted Execution Environment (TEE) and some have a dedicated Secure Element (StrongBox). These can generate and store cryptographic keys that never leave the secure hardware. The problem is which curves they support. Android’s Keystore supports secp256r1 (also called P-256). Nostr uses secp256k1. The Keystore does not support secp256k1.

This means Amber cannot sign events inside the secure element. The practical approach is hybrid: the private key is encrypted at rest using a key that is backed by TEE hardware. But when you actually sign an event, the nsec is decrypted into app memory and the signing happens in software. The key exists in plaintext in RAM for the duration of the signing operation.

Samsung devices are the one exception. Samsung’s Blockchain Keystore supports secp256k1 natively, because it was built for Bitcoin and Ethereum wallets. On a Samsung phone, it’s theoretically possible to keep the key inside secure hardware during signing. Whether Amber uses this path, I’m not certain.

So what does Amber actually defend against?

It defends against a compromised Nostr client extracting your key from its own storage. It defends against clipboard hijacking. It defends against a malicious web app that asks for your nsec and sends it somewhere. These are the common, realistic attacks that most #security breaches come from.

What it does not defend against: a rooted device. Physical access by someone who knows what they’re doing. Malware with accessibility permissions that can read what other apps display. A compromised Android OS. Your phone getting seized and forensically analyzed.

For most Nostr users, the threats Amber handles are the actual threats they face. The threats it doesn’t handle require a different class of attacker. Your phone is good enough as a signing device for most people. It is not good enough for everyone. Know which group you’re in.

§NIP-55 vs NIP-46 vs hardware signers

Three approaches to keeping your nsec away from clients. Each makes a different tradeoff.

NIP-55 local signing (Amber, Primal, Aegis): The key lives on your phone. Signing is near-instant because it’s local IPC, no network round-trip. Works offline. Android-only. The key is in the signer app’s memory during signing. If the phone is compromised at the OS level, the key is exposed.

NIP-46 remote signing (nsecBunker, Amber-as-bunker, nsec.app): The key lives on a separate device or server. Communication goes over Nostr relays, encrypted with NIP-44. The client never touches the nsec. Latency is 1-5 seconds per signing operation because every signature requires a relay round-trip. Works cross-platform, which is a real advantage. The signer must be online when you want to sign. For automation like scheduled posts or feed monitors, the signer needs to be always-on.

Hardware signers (NSD on ESP32, OneKey Pro, Nesigner): The key lives on a dedicated chip. Air-gapped or USB-connected. The nsec never exists in software on your phone or computer. This is the strongest #security guarantee. But: limited client support, clunky UX, another device to carry and charge. The LNbits NSD is a DIY option on an ESP32 board for under $50. OneKey Pro is commercial, with NSD support and Lightning integration built in. Both are niche.

Here’s how I think about it. Amber is the right default for most Android users today. It eliminates the most common attack vector (nsec in every client) with minimal friction. NIP-46 is better when your signing device and your posting device need to be separate, like signing from your phone for a desktop client. Hardware signers are for people who treat their Nostr identity with the same seriousness as their Bitcoin cold storage.

The gap between a hardware signer and Amber is real but narrow for most threat models. The gap between Amber and pasting your nsec into every client is enormous.

§The iOS problem

NIP-55 is built on Android Intents and Content Resolvers. iOS has nothing equivalent. Apple’s sandbox model prevents the kind of open inter-app communication that NIP-55 requires. This is not a temporary gap waiting for someone to write the right code. It is an architectural constraint.

What exists on iOS: Nowser is an early cross-platform signer available on TestFlight, supporting NIP-46 and NIP-55, but reviewers describe it as very early-stage and not comparable to Amber. Terry Yiu has iOS signer work in progress. Neither is mature.

iOS #nostr clients like Damus, Nostur, and Primal still accept nsec login as the primary flow. There is no mobile Safari equivalent of the nos2x browser extension.

NIP-46 remote signing works on iOS, because it communicates over relays rather than OS-level IPC. This means iOS users can use nsec.app, or run Amber on an Android device as their signer. But both options mean the key lives somewhere else, which is a different security model than having the signer on the device in your hand.

This is a real disadvantage for iOS Nostr users. Not a small one.

§What you should actually do

If you’re on Android: Install Amber. Import your nsec once. Delete the nsec from every other app. Configure auto-approve for basic actions like posting and reactions. Keep manual approval for sensitive operations like DMs and key exports. Use other clients exclusively through NIP-55.

If you’re on iOS: Use NIP-46 with nsec.app or another remote signer. If you have an old Android phone sitting in a drawer, install Amber on it and use it as a dedicated signer over Wi-Fi. It doesn’t need a SIM card or a data plan.

If your identity is high-value: Consider a hardware signing device, or NIP-46 with nsecBunker on a machine you control. The phone is a reasonable middle ground, not a fortress.

§The pitch and the gap

The pitch for dedicated Nostr signing is that your key never touches an app that doesn’t need it. Amber delivers on that pitch with real tradeoffs. It is software, not hardware. It is on a phone, not an air-gapped device. It is Android-only.

But the alternative that most people are currently living with, pasting their nsec into every client, is worse by any measure. The question is not whether Amber is perfect. The question is whether the gap between Amber and nsec-pasting is bigger than the gap between Amber and a hardware signer. It is. By a lot.

The secp256k1 limitation is worth keeping in mind. Until Android’s Keystore supports that curve natively, or Nostr adopts a curve that Android’s secure hardware already handles, every phone-based signer is doing software signing with hardware-encrypted storage. That is meaningfully better than plaintext nsec in a notes app. It is meaningfully worse than a chip that was built to never let the key out.

#nostr #security #privacy #nip55