Amethyst: a Nostr client for Android that ships its own protocol stack

The problem Amethyst solves, and who it is aimed at

Nostr is a protocol, not a service. A client has to speak enough of it to be useful: fetch events from relays, sign them locally, show threads, handle direct messages, and let the user move between relays without losing their identity. Amethyst is one such client, written in Kotlin and aimed at Android first. The README's tagline is direct: "Join the social network you control." The audience is people who already have, or want, a Nostr key pair and do not want a company holding it.

The scope is broader than a Twitter-style timeline. The supported-features list covers NIP-01 through NIP-BE, including NIP-17 private direct messages, NIP-47 Nostr Wallet Connect, NIP-57 Lightning zaps, NIP-60 Cashu wallets, NIP-29 relay-based groups, NIP-72 moderated communities, NIP-34 git stuff, and NIP-B7 Blossom for media. That breadth is the project's main argument: one client that covers most of what the protocol currently defines, instead of a minimal reader plus a pile of companion apps.

A few items on the list are unchecked. NIP-07 (window.nostr) is marked "Not applicable", which is expected for a native app. NIP-EE (MLS Protocol) is unchecked, as are three draft NIPs: Relationship Status, Signed Filters, and Key Migration. If your workflow depends on any of those, Amethyst is not the client for it yet.

How Amethyst is put together: modules, Quartz and the desktop build

The repository is a Gradle multi-module project. Alongside the Android app module (amethyst/), the top level contains quartz/, commons/, commonsUI/, desktopApp/, cli/, quic/, marmotQuic/, marmotBench/, relayBench/, benchmark/, baselineprofile/, geode/, nappletHost/, nestsClient/ and tools/. Quartz is published separately on Maven Central as com.vitorpamplona.quartz, and the README links it from the badge row. That split matters: the protocol and event-handling code lives outside the Android app, which is why a desktop target exists at all.

The desktop builds are not a reimplementation. The README lists macOS, Windows, Debian/Ubuntu, Fedora/RHEL/openSUSE and a generic Linux AppImage, all pointing at the same release artifacts. Two entries are marked as coming in a separate PR: Scoop for Windows and AUR for Arch Linux. Treat those as unavailable today.

The README does not describe the relay connection strategy, the caching layer, or how events are stored on device. It points to BUILDING.md for compiling from source and to a DeepWiki link for deeper documentation. If you need to know how Amethyst decides which relays to query for a given feed, the README will not tell you; you would be reading Kotlin in quartz/ and amethyst/.

Installing Amethyst on Android and verifying the APK

The README offers four Android install paths: Zap Store, Obtainium, GitHub Releases, and Google Play (package id com.vitorpamplona.amethyst). If you sideload from any of the first three, the project asks you to verify the signing certificate first, because all official APKs, both the googleplay and fdroid flavors, share one release key.

With the Android SDK build-tools installed, apksigner prints the certificate digests for a downloaded APK:

apksigner verify --print-certs amethyst-*.apk

The reported Signer #1 certificate SHA-256 digest must match the fingerprint in the README. Without the Android SDK, keytool from any JDK prints the same value:

keytool -printcert -jarfile amethyst-*.apk

The expected digest is c2d0aa86bcb6b62090561a41bbe336e98b78c2d0210a498dc885f28e1348cf17. If it differs, do not install the file. AppVerifier is listed as an alternative: paste or share the APK and compare against the package name com.vitorpamplona.amethyst and the same fingerprint.

For desktop, the README gives package-manager commands rather than a manual install. On macOS:

brew install --cask amethyst-nostr

On Windows 10 or 11:

winget install VitorPamplona.Amethyst

Linux users get .deb, .rpm, AppImage or .tar.gz files from the releases page, with no CLI install listed. The README warns that Gatekeeper, SmartScreen and AppImage installs may need extra steps and points to BUILDING.md section "Troubleshooting installs".

A first real session: keys, relays and what the app expects

After install, the first task is identity. Amethyst supports key derivation from a mnemonic (NIP-06), private key encryption (NIP-49), login with QR, and multiple accounts, according to the feature list. It also implements NIP-46 remote signing, so the signing key can live in a separate signer rather than in the app. The README does not walk through any of these flows; it lists them as supported and stops there.

The second task is relays. Amethyst implements NIP-65 relay list metadata and NIP-66 relay discovery and liveness monitoring, plus the NIP-86 relay management API. In practice that means you publish a relay list as an event and the client follows it, rather than you editing a hardcoded server list. The README does not document a default relay set or a first-run relay picker, so expect to bring your own list or import one.

Beyond that, the client assumes a Lightning wallet for zaps (NIP-57) and optionally a Cashu wallet (NIP-60, NIP-61). Push notifications are handled through Google or Unified Push, and the F-Droid flavor is described as de-googled, which is the one to pick if you want to avoid the Google push path. In-device automatic translations and Markdown support are listed as features, not as configuration.

Where Amethyst is the wrong tool

Amethyst is a client. It is not a relay, not a signing library you import into a server, and not a headless tool for scripting Nostr operations. The cli/ and tools/ directories exist in the repository, but the README does not document them as user-facing entry points, so you cannot plan around them from the published material.

The NIP-07 line is the clearest boundary. "window.nostr for Web Browsers (NIP-07, Not applicable)" means Amethyst cannot act as a browser extension signer. If your setup is a web client plus a signer extension, Amethyst does not fill that role; NIP-46 remote signing is a different mechanism and requires the other side to speak it.

Four protocol areas are unimplemented or draft-only: MLS Protocol (NIP-EE), Relationship Status, Signed Filters, and Key Migration. If you need end-to-end encrypted group messaging at the MLS level, or a documented path to migrate keys between clients, the feature list says Amethyst does not have it. The README also does not document rollback or downgrade behavior, so if a release regresses something you rely on, the published material gives no recovery procedure beyond reinstalling an older artifact.

How Amethyst differs from other Nostr clients

The obvious comparison is with clients that treat Nostr as a text-note protocol only. Amethyst's feature list goes well past that: NIP-52 calendar events, NIP-53 live activities, NIP-23 long-form content, NIP-34 git repositories, NIP-64 chess, NIP-71 video events, NIP-88 polls, NIP-90 data vending machines, and NIP-C0 code snippets. A minimal client implements NIP-01, NIP-02, NIP-10 and NIP-19 and stops. The difference in approach is scope versus surface area: Amethyst tries to cover the protocol as it stands, which means more code paths and more places for a NIP to lag behind its spec.

The second difference is the platform split. Amethyst is Android-first with desktop builds generated from the same codebase through the quartz/ and desktopApp/ modules. A web client has no install step and no APK signature to verify, but it also cannot use NIP-55, the Android signer application role, which Amethyst lists as supported. If you want your phone to act as a signer for other apps, that is a capability a browser client does not have.

The third difference is packaging. Amethyst ships through Google Play, F-Droid, Zap Store, Obtainium, GitHub Releases, Homebrew, winget and distribution packages. That is a lot of distribution surface, and the README's insistence on verifying the APK fingerprint is a direct consequence of it.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-08-22. The most recent release in the repository is v1.14.0 ("New Share Intents, Faster Start") on the same date, preceded by v1.13.1 on 2026-07-29 and v1.13.0 on 2026-07-28. That is a steady release cadence over the last two months, with patch releases following feature releases closely.

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are included. That is a permissive licence, and it is the same for the app and, presumably, for the Quartz artifact published on Maven Central. This is not legal advice; check the LICENSE file and the Maven Central metadata for Quartz if you plan to redistribute either.

Upgrade cost is the part the README leaves open. There is no documented migration procedure between releases, and no statement about whether an upgrade can change how existing events are stored or signed. The CHANGELOG.md and RELEASE_OPS.md files exist at the top level, and those are the places to look before moving a production account to a new version. Sideloaded users also have to re-verify the APK fingerprint after each download, which is a real recurring step, not a one-time check.

Editorial conclusion

Adopt Amethyst if you want a Nostr client that implements a very long list of NIPs, including private direct messages, zaps, Cashu wallets, relay groups and Blossom, and you are willing to run it on Android or one of the desktop platforms the README lists. Do not adopt it as a library or a headless relay tool: it is a client, and the desktop builds are distributed as installers rather than as a documented API surface. Before installing a sideloaded APK, verify the SHA-256 fingerprint C2:D0:AA:86:BC:B6:B6:20:90:56:1A:41:BB:E3:36:E9:8B:78:C2:D0:21:0A:49:8D:C8:85:F2:8E:13:48:CF:17 with apksigner verify --print-certs.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes