CraysAmber
Amber is the app you install when you want Android clients to stop touching your raw nsec. It turns the phone into a signing room: clients ask, Amber shows the request, and your key stays inside the signer.
The phone as the signing room
Amber begins with one of the least glamorous problems in Nostr and one of the most important: where does your private key live? A Nostr identity is not an email account with a password reset team behind it. It is a keypair. The public key is how the network recognizes you. The private key is how you prove that a note, reaction, profile update, zap receipt, relay-auth response or encrypted message action came from you. Lose control of that key and the account is no longer cleanly yours.
The lazy way to use Nostr is to paste the same nsec into every new client you try. It feels convenient for about five minutes. Then you realize every app, every update, every backup path, every web view and every phone permission now belongs in your threat model. Amber was built to change that habit on Android. It keeps the secret in one dedicated app and lets other apps ask for work to be signed.
This is why Amber should be read as infrastructure, not as another square in the app grid. It does not compete with Amethyst, Primal, Coracle, Yakihonne or a random experimental Android client by trying to show the prettiest feed. It sits beneath them. The feed client says: sign this event. Amber says: show the user, apply the permission rule, sign if allowed, return the result. The user can try more clients without spraying the raw key across all of them.
NostrApps describes Amber as a Nostr signer on Android and calls out the useful surface plainly: NIP-55 signing for Android apps, no need for the key to touch less trusted apps, NIP-46 bunker support, multiple accounts, fine-grained authorizations and an activity log. That list is not brochure language. It is the product.
Why Amber exists at all
The official README says Amber is a Nostr event signer for Android that lets users keep their nsec segregated in a single dedicated app. Its stated goal is to make the phone act as a NIP-46 signing device without extra servers or hardware. OpenSats uses the same framing: Amber is the app that holds your key so other apps do not have to.
That small shift changes the way you evaluate every Android Nostr client. The question is no longer "do I trust this app with my whole identity?" It becomes "do I trust this app to request signatures from Amber, and do I understand the requests I approve?" That is still a serious question, but it is narrower. A malicious or sloppy client can still ask for bad signatures. It cannot simply read the private key if the integration is doing its job.
The reason this matters is not theoretical. Nostr encourages movement between clients. That is one of the network's best ideas. Your identity and social graph can travel because they are not locked in a platform database. But mobility becomes dangerous if each trial asks you to paste the same secret. Amber lets Android users keep the best part of that freedom without turning every experiment into a key-custody decision.
There is also a cultural benefit. A signer makes signing visible. It reminds the user that every post, profile edit, relay auth event, zap-related action or encrypted-message operation has a private-key side. The app does not merely "log in." It asks to act as you. Amber gives that moment a separate room.
NIP-55 is the Android trick
NIP-55 is the Android-specific standard that makes Amber feel native instead of bolted on. It describes two-way communication between a signer app and a Nostr client running on the same device. The signer holds the private key. The client sends requests. The user approves or rejects. The result returns to the client without handing over the secret.
The NIP gives clients three ways to talk to the signer. Intents are the visible path: the signer opens, the user sees the request, and the result returns through Android's activity flow. Content Resolver is the quiet path: background signing can work for requests the user has already chosen to remember. Web is the browser path: a web app can use a nostrsigner: URL and receive the result through a callback URL or clipboard copy, although NIP-55 itself points web applications toward NIP-46 when background behavior matters.
That gives Amber a very Android shape. A client can first ask for the public key and signer package name. After that, it can direct requests to Amber specifically. For signing, the client passes event JSON; Amber returns a signature and, for sign_event, the signed event. For encryption and decryption, the methods include NIP-04 and NIP-44 paths. NIP-55 also defines decrypt_zap_event, which matters because Nostr payments and private receipt handling often cross the signer boundary.
The background path is especially important. If a user has approved a repeated request and chosen to remember it, an Android client can avoid opening the signer for every single operation. That is how a signer moves from "secure but annoying" toward "secure enough to use every day." The catch is obvious: remembered decisions must be narrow and reviewable. If the remembered permission is too broad, convenience quietly eats the point of the signer.
This is why Amber's Android identity matters. NIP-55 does not describe a generic web trick; it describes package names, intents, content providers and same-device app communication. The client should know which signer package it is talking to, and the signer should know which app is asking. In a world where the private key is the account, "which app asked?" is not a cosmetic label. It is the start of the audit trail.
Remote signing turns the phone into a bunker
Amber is not limited to same-device Android signing. Its other major role is NIP-46 remote signing. NIP-46 defines a way for a client and a remote signer, often called a bunker, to talk through relays. The client sends encrypted requests to the signer. The signer answers with a public key, signature, encrypted payload result or another method response. The user's private key stays with the signer.
In plain language: your desktop web client can ask your Android phone to sign. That is a big deal for web Nostr. Browser extensions such as NIP-07 signers are useful on desktop, but Android browser support is messy and mobile users often move between native apps and web apps. Amber gives the phone a role that is closer to a personal signing device. OpenSats notes that Amber works through NIP-46 remote signing and NIP-55, and that Tor is supported for the NIP-46 transport.
NIP-46 also explains why this pattern exists: private keys should be exposed to as few systems as possible, because each additional system widens the attack surface. That sentence is not paranoia. It is good product design for a protocol where the key is the account. If your phone is the signer, the browser tab on a laptop does not need to become the long-term home of your identity.
The tradeoff is that remote signing has more moving pieces. You need a connection string, relays for the signer traffic, permission handling, and a way to know which client is asking. Amber's job is to make those moving pieces visible enough that the user can make a decision. It cannot remove judgment from the process, and it should not pretend to.
Permissions are the product
A signer lives or dies by permission detail. "Allow this app" is too vague. A serious signer needs to care about which app is asking, which account is being used, which method is requested, which event kind is being signed, whether the user wants to remember the decision and whether the history later tells a story the user can audit.
Amber's public feature trail points in that direction. NostrApps highlights fine-grained app authorizations and an activity log. OpenSats describes remembered per-permission decisions for common kinds and background signing through Android content providers. The 6.2.0 release notes add a very specific clue: Amber added NIP-44 v3 encryption support with a dedicated approval screen, intent preview, bunker preview, history logging and auto-reject for invalid requests.
Those details matter more than a pretty settings screen. A user approving kind:1 text-note signing is doing something different from approving NIP-44 decrypt requests, relay-auth events or large batches of background signatures. A client that asks Amber to sign a normal public note should not receive the same mental trust as a client asking to decrypt private content. Good signer design helps the user feel those differences without making every action exhausting.
The activity log is part of that trust. If you can review what happened, you can spot a client that asked too often, asked for the wrong thing or behaved differently than expected. Logs do not make a bad decision good, but they turn an invisible mistake into evidence. That is a quiet but serious feature.
Who builds it, who funds it, and how it ships
The public maintainer trail is clear. Amber is built by Greenart7c3, who also builds Citrine, the Android-based Nostr relay. OpenSats first included Amber in its August 17, 2023 grant wave as "Amber: Nostr Event Signer." On October 15, 2024, OpenSats announced long-term support for Greenart7c3, naming him as creator and lead developer of both Citrine and Amber.
That funding history is useful context because signers are not always glamorous projects. A feed client can show screenshots and win attention quickly. A signer has to do patient work: permission prompts, Android intents, content providers, encryption methods, release verification, translations, compatibility with other clients, and bug reports from users who only notice the signer when something blocks them. Long-term support gives that kind of maintenance a better chance.
The code trail is also public. The GitHub repository is greenart7c3/Amber. It showed 2,200 commits, 318 stars, 28 forks and 187 releases when this article was checked on June 6, 2026. The codebase is almost entirely Kotlin, and GitHub lists the project under the MIT license. The README lists multiple accounts, background signing through content providers, web-app signing work, NIP-46 use, downloads through Zapstore, Obtainium, GitHub releases and F-Droid, and contribution paths through GitHub, GitWorkshop, Crowdin and Nostr patch tools.
Amber also treats release trust as part of the app. The README and verification guide explain GPG-signed releases, manifest signature checks and SHA-256 file integrity checks. The signing key fingerprint is published, and the guide tells users not to install if verification fails. F-Droid now lists Amber 6.2.0, build 193, as the suggested version added on June 2, 2026. It requires Android 8.0 or newer and is built and signed by the original developer from a corresponding source tarball. GitHub release 6.2.0 appeared on June 1, 2026 with NIP-44 v3 work and other signer-flow improvements.
The F-Droid permission list is also worth reading instead of ignoring. Amber requests network access, notification, startup, foreground service, camera/video, biometric and storage-related permissions. Some of that makes sense for a signer that scans QR codes, stays reachable for signing flows, shows notifications, uses biometric protection and downloads or verifies releases. But the point of listing it here is not to wave the permissions through. It is to remind you that a signer is a serious Android app with serious system powers. Install source, release verification and device hygiene all matter.
How to test Amber before trusting it with your main key
Do not start by importing your most important Nostr identity and pairing it with half a dozen clients. Start small. Install Amber from a source you understand. If you use GitHub releases, read the verification guide and check the manifest signature and file hash. If you use F-Droid or Zapstore, understand what that store is verifying for you and what it is not. A signer is the wrong place to be casual about provenance.
Then create or import a test key. Pair one Android client that supports NIP-55. Ask it to post a harmless note. Read the Amber prompt. What event kind is being signed? Which app is asking? Does the result show up in another client? Try a permission you do not remember, then one you do, and watch the difference between visible intent approval and background Content Resolver behavior. The goal is not to click through. The goal is to learn the rhythm of the signer.
If you test NIP-46, pair a web client through Amber as a remote signer and pay attention to the relay and permission flow. A remote signer is powerful precisely because it lets another device act through your key. That can be excellent when the phone remains your key home. It can be dangerous if you approve broadly and forget what you paired.
The final test is boring on purpose: open Amber's history after a few actions. Can you explain every request? If the answer is yes, the signer is doing its job and you are doing yours. If the answer is no, slow down before you move your main key into the setup. Amber gives Android users a much better key custody pattern, but it does not eliminate the need to read.
Also test the installation path itself. If you downloaded from F-Droid, check that updates arrive through the client. If you downloaded an APK from GitHub, practice the verification flow once with a harmless install before making Amber your real signer. If that feels tedious, that is useful information: a signer puts you in the part of Nostr where operational habits matter. The point is not to become paranoid. The point is to know the path your key depends on.
Sources worth opening
This article keeps claims close to the public project trail, release notes and Nostr standards. These are the best starting points for checking Amber yourself.
- Amber source code on GitHub
- Amber README
- Amber 6.2.0 release notes
- Amber release verification guide
- Amber on F-Droid
- NostrApps Amber listing
- OpenSats Amber project page
- OpenSats long-term support for Greenart7c3
- OpenSats August 2023 grant announcement
- NIP-55 Android Signer Application
- NIP-46 Nostr Remote Signing
- NIP-55 Android signer applications
- NIP-49 private key encryption
- Nostr protocol NIPs repository
- NIP-01 basic protocol flow
- NIP-05 DNS identifiers
- NIP-07 browser signer capability
- 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
