CraysAegis
Aegis is not trying to be your social feed. Its job is quieter and more dangerous: hold the signing authority, answer clients, and make sure a Nostr app only gets the permission you meant to give.
The app that stands between you and the signature
Aegis is easy to misunderstand if you put it next to clients such as Damus, Amethyst, Primal or noStrudel. It is not there to give you a better feed. It is there to make every other Nostr app ask before speaking with your voice.
That is the whole signer idea. In Nostr, your private key is not just a login password. It is the authority to publish notes, edit profile metadata, approve zaps, decrypt messages, join rooms, claim identity and connect one app to another. If you paste that key into every new client because the screenshot looks fun, you are spreading the most important thing you own across a pile of code you probably have not read. Aegis exists to narrow that mess.
NostrApps describes Aegis as a cross-platform Nostr signer supporting multiple connection methods. The GitHub README says the same thing more plainly: "Aegis is a simple and cross-platform Nostr signer that supports multiple connection methods." This is one of those rare product descriptions where the modest wording is better than the pitch. A good signer should not feel like a celebrity. It should feel like a door with a guard who reads the request before opening it.
The interesting part is the "cross-platform" ambition. Browser extensions gave Nostr its early signer pattern through NIP-07. Android has its own signer route through NIP-55. Remote signing has NIP-46 and bunker URLs. iOS needs handoff tricks because the platform does not behave like Android or desktop browsers. Aegis is trying to sit across all of that instead of choosing one camp and pretending the rest of the world does not exist.
The name fits better than most app names in this ecosystem. In mythology, an aegis is a shield. In Nostr, a signer is supposed to be exactly that: not the warrior, not the town square, not the stage, but the thing between your identity and the tools that want to act with it. If a client wants to publish a note, decrypt something, sign a zap request or open a Nostr app, Aegis should make the moment visible before the key says yes.
That also means Aegis is not a beginner toy. It can help beginners, but only if the surrounding explanation is honest. A new user may think "login" means the same thing it means on a normal website. Aegis is a way to teach the harder truth: there is no central account desk behind the page. There is a key, there are apps asking for signatures, and there must be a place where the human can still refuse.
Why signers exist in the first place
NIP-46 says the quiet part clearly: private keys should be exposed to as few systems as possible because every app, operating system and device adds attack surface. That sentence is the heart of Aegis. It is also the sentence a new Nostr user should read before pasting an nsec into a random web app.
A remote signer changes the shape of trust. The user-facing client can ask for a signature, but the key does not have to live inside that client. The client sends a request, the signer answers, and the signer can show the human what is being requested. In NIP-46, that request is a kind 24133 event with JSON-RPC-like content encrypted with NIP-44. The client can ask for things such as get_public_key, sign_event, nip44_encrypt or nip44_decrypt. The signer can approve, deny, remember or limit.
That changes the rhythm of using Nostr. Instead of "log in once and hope the app behaves forever," you get a relationship between a client and a signer. The client may request broad powers or narrow powers. The signer may remember some approvals and interrupt others. The user may choose convenience or friction. This is not a small UX detail. It is the difference between carrying your passport in every pocket and keeping it in one place while other tools request stamped copies.
Aegis leans into that model. Its latest release trail talks about permission labels, TTL-based remembered approvals, signing policy and NIP-46 crypto validation. Those phrases are not decoration. They are the work. A signer is only useful if it helps the user understand what just happened, what will happen next time, and how long a remembered yes should remain alive.
NIP-46 also explains why the client and the signer must be treated as different identities in the connection flow. The client has a temporary communication key, the signer has a remote-signer key, and the user has the actual public key that represents the account. A client is supposed to call get_public_key after connection and validate the secret returned during Nostr Connect. That is dry protocol language, but it is exactly where spoofing and sloppy UX can enter if a signer is careless.
So when Aegis talks about crypto validation and policy unification, it is not merely polishing the settings page. It is trying to make sure the signer understands the request path well enough to say no, remember yes for a limited time, or switch relays when the client chose a bad relay set. The more Nostr apps adopt signers, the more this kind of boring correctness becomes part of everyday safety.
Aegis is not married to one connection trick
Aegis is valuable because it accepts that Nostr apps do not all connect in the same way. The README lists NIP-46, NIP-55, NIP-07, local relay support and Nostr app integration. NostrApps adds the same clues from the directory side: bunker links, iOS URL-scheme redirection, Android NIP-55 intents, local relay support, multiple account management and NIP-49 encrypted key support.
NIP-46 is the bunker path. A signer can present a bunker:// URI or answer a nostrconnect:// flow. A client connects through relay messages, requests permissions, and asks the signer to perform actions. This is the path that makes Aegis useful beyond one operating system. It can sign for clients that know how to talk to a remote signer rather than demanding the raw private key.
Android gets a more direct route through NIP-55. That standard describes how an Android signer and an Android client communicate through intents and content resolvers. In human terms: another app can hand a signing request to Aegis, Aegis can show the user what is being asked, and the result can be returned to the client. For Android, this matters because it lets Nostr feel less like a browser-extension hobby and more like a native app ecosystem.
NIP-07 is the browser-shaped route. Aegis supports an in-app browser that injects window.nostr, giving web Nostr apps access to familiar functions such as getting the public key and signing events. That does not turn Aegis into a general-purpose browser extension. It creates a controlled browser space where web apps can use Aegis as the signer.
Then there is the local relay idea. The README documents local relay addresses such as wss://127.0.0.1:28443 and ws://127.0.0.1:8081 for on-device communication with Nostr apps. This is the kind of detail that sounds dull until you need it. A local relay can reduce how much pairing traffic needs to leave the device path, and it gives native clients another way to speak to the signer.
The iOS path is its own small puzzle. Aegis documents custom URL schemes, including aegis:// and nostrsigner://, with an x-callback-url flow for NIP-46 authentication. A client sends a Nostr Connect URI into Aegis, identifies the source app, and provides success or error callbacks. If the user approves, Aegis returns control through the callback with a local relay hint. That is not as elegant as a native Android signer bridge, but it is the kind of workaround iOS Nostr apps need if they want signer handoff instead of private-key paste.
NIP-55 adds another distinction worth knowing. On Android, a client can use intents for visible approval or a content resolver for background responses after the user has previously chosen to remember permissions. That is powerful and dangerous in the same breath. Background signing can make apps feel normal. It can also hide too much if the signer does not show clear permission history. Aegis's remembered approvals and logs are important because Android's best flow depends on memory.
Permissions are the product
The hardest thing about a signer is not the signature. The hard thing is helping a normal person decide whether to say yes.
That is why Aegis should be judged less by its logo and more by its approval screens, app list, remembered permissions, logs and recovery behavior. A signer that signs everything silently is just a softer way to lose the key. A signer that interrupts every tiny request without context will train the user to approve blindly. The product lives in the middle: clear labels, sane defaults, visible history and a fast way to revoke a bad relationship.
The May 12, 2026 v0.5.1 release points in that direction. It adds an app logs page with filtering, TTL-based remembered approvals, permission labels and signing policy, a Relay Hub page with status and reconnect controls, app PIN protection using secure storage, and activity filtering. The release also mentions NIP-46 crypto validation and policy unification. That is exactly the work a signer must do as it matures. Not more vibes. More auditability.
NIP-49 support matters here too. NIP-49 defines a way to encrypt a Nostr private key with a password into an ncryptsec value. It uses scrypt for key derivation and XChaCha20-Poly1305 for encryption. For a signer, encrypted key import and storage are part of the trust story. They do not remove the need to trust the signer app itself, but they are better than throwing raw secrets around in plain text.
The right mental model is simple: Aegis is not a vault that makes risk disappear. It is a control point. It can reduce key exposure. It can show requests. It can remember permissions for limited time. It can keep separate account contexts. But if you approve a dangerous request, use a weak device, install a fake build, or ignore the app list, the signer cannot save you from your own yes.
That is why the app logs page may be one of the most important features in the whole project. A feed client can get away with being emotionally obvious: you saw the post, you liked it or you did not. A signer needs memory. Which app asked for which permission? Was it a one-time approval? Was it remembered? Which relay carried the connection? Did the same app suddenly ask for decryption instead of only signing a public note? Logs turn invisible trust into something you can inspect after the moment has passed.
The Relay Hub points in the same direction. In remote signing, relays are not only social infrastructure; they are part of the command path between client and signer. If that path is stale, blocked, badly chosen or confusing, the user experience breaks and the security story gets harder to explain. A signer that lets you see relay status and reconnect quickly is not adding nerd furniture. It is exposing the road your approvals travel on.
What the code trail says
The public project trail points to ZharlieW/Aegis on GitHub. The repository is open source under the LGPL-3.0 license, with a Flutter app structure across Android, iOS, Linux, macOS, web and Windows folders. GitHub lists Dart as the main language, with Java, C++, Objective-C, CMake and Kotlin also present. The README says development needs Flutter, plus Rust for the nostr_rust plugin, with platform targets for iOS, Android and macOS.
Those details tell you how the project is built. Flutter carries the UI across platforms. Rust appears in the signing/protocol layer through the Nostr plugin path. The future plans in the README make that direction explicit: refactor the logic layer in Rust while Flutter stays responsible for UI, add local relay maintenance features, support local WebXDC format, and support an MLS signer with MLS state storage.
On June 6, 2026, the GitHub page shows 432 commits, 59 stars, 8 forks and 17 releases, with v0.5.1 listed as the latest release from May 12, 2026. Those numbers are not a verdict. Nostr tooling can be important before it is popular. But they do show this is a live project trail, not a directory ghost.
The named maintainer trail is GitHub user ZharlieW. Beyond that, the public sources are strongest on code, releases and standards, not on a large company story. That is fine. A signer review does not need a founder mythology. In this category, the more important question is whether the code, release cadence and permission model give you enough reason to test it carefully.
The package file adds a few useful clues. Version 0.5.1+10 is listed in pubspec.yaml. The dependencies include cryptography, BIP340, Pointy Castle, bech32, WebSocket channels, a SOCKS proxy package, QR scanning, secure storage, Android content-provider support, a webview, Isar storage and a local nostr_rust plugin. That is the dependency shape you would expect from a signer that has to parse Nostr identifiers, talk over relays, store sensitive local data, scan connection material, inject browser signing and answer Android requests.
It also has preset assets for app icons, browser bookmarks, NApp lists and NApp updates. That connects Aegis to the same wider trend you see in 0xchat: signers are no longer only "approve this event" utilities. They are becoming launch and permission surfaces for small Nostr apps. That makes the signer more useful, but it also means the UI must keep separating app discovery from key authority. A fun NApp list should never blur into an unexamined signing habit.
How to test Aegis without handing it your life
Start with a test key. This is not drama; it is basic hygiene. A signer is a serious tool, and your main nsec should not be the first thing you feed to a new workflow. Create a small Nostr identity, pair it with Aegis, connect one client, and sign something harmless.
Then read the request screen. Does Aegis show the app name? Does it show the permission type? Can you tell the difference between signing a public note, decrypting a private message and granting a remembered approval? If the screen does not help you understand the request, slow down. A signer that asks technical questions in a fog will eventually teach you to click through.
Next, test the connection paths one at a time. Use a NIP-46 client with a bunker or Nostr Connect flow. On Android, test a NIP-55-capable app. Try the in-app browser for a web Nostr app that expects window.nostr. Watch the logs. Revoke the app. Reconnect it. Change a relay. The goal is not to break Aegis for sport. The goal is to learn where the control surfaces live before your real identity depends on them.
Finally, check update behavior and backups. Aegis has fast release movement, which is good for a young signer and also a reason to stay current. If you use NIP-49 encrypted keys, make sure you understand where the encrypted material lives, what password protects it, and what happens if your phone dies. A signer protects your key from casual spread, but it does not remove the need for a recovery plan.
Aegis is for people who want Nostr to become multi-app without becoming multi-leak. That is a serious need. The more apps you try, the more valuable a signer becomes. The trick is to remember that the signer is not a ceremonial add-on. It is the place where your Nostr identity says yes or no.
One more test is worth doing: approve something for a short TTL, wait, and try the same action again. Then approve a different permission and look for it in the logs. A signer is not only about the dramatic first pairing. It is about what happens on the fifth request, the fiftieth request and the request you forgot you approved last week. If Aegis makes that memory visible, it earns its place.
Also test the bad path. Cancel an approval. Feed it a malformed Nostr Connect URI. Use the iOS callback path from a small test app if you can. Disconnect a relay and reconnect through the Relay Hub. A signer that only works on the happy path is not ready for a real identity. The point is not to be paranoid. The point is to learn whether Aegis stays legible when the request is awkward.
Sources worth opening
Read the app through its code and the standards it implements. That is where the real story is.
- Aegis on GitHub
- Aegis releases
- Aegis v0.5.1 release notes
- Aegis README
- Aegis pubspec.yaml
- Aegis iOS URL scheme guide
- Aegis on NostrApps
- NIP-46 remote signing
- NIP-55 Android signer application
- NIP-07 browser signer capability
- NIP-49 private key encryption
- NIP-55 Android signer applications
- 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
