CraysAmethyst
Amethyst is the Android-first Nostr client that turned into a broad protocol workbench: a social app with Tor, outbox relays, encrypted DMs, zaps, Cashu wallet support, media flows, live activities and a Kotlin library stack underneath it.
The Android client that grew wide
Amethyst began as an Android Nostr client and still makes the most sense from that starting point. It is a phone app for reading, posting, replying, messaging and moving around a Nostr social graph, but it does not stay inside the narrow shape of a Twitter-style clone. The public README says plainly that it is a Nostr client for Android and invites people to join a social network they control. The actual project has grown into something broader: a mobile client that tries to make many Nostr event families feel like one usable app.
That breadth is visible in ordinary use. Amethyst can show short notes, long-form content, profiles, reactions, reposts, direct messages, public chats, group chats, communities, hashtags, audio and video posts, voice notes, marketplace-like events, live streams, zaps, Cashu wallet surfaces and NIP-driven app handlers. It also includes account switching, QR login, external signer support, translations, media previews, file upload choices and notification paths. A user can stay in a familiar social feed while stepping into very different Nostr features.
The result is powerful and sometimes dense. Amethyst is not the quietest first client for someone who only wants a simple feed. Its value is that it exposes what Nostr can become on a serious Android device. When a protocol feature gets real adoption, Amethyst often becomes one of the places where Android users can actually touch it, test it and discover where the edges still feel rough.
The current public project
The public repository is `vitorpamplona/amethyst` on GitHub. It is described there as a Nostr client for Android, uses Kotlin as its main language and is licensed under the MIT License. The repository was created on January 11, 2023 and remained active on June 11, 2026, with recent pushes on that same date. GitHub topics include Android, Kotlin, Nostr and social network, which matches the app's public identity.
The project is closely associated with Vitor Pamplona. OpenSats lists Amethyst as a project by Vitor, points readers to the official website, GitHub repository, Zapstore listing and Nostr profile, and describes the app as a privacy-focused Nostr client for Android with built-in Tor support. OpenSats also records grant support beginning in the first wave of Nostr grants in 2023 and a long-term support grant for Vitor in August 2024.
That funding history matters because Amethyst is not a weekend toy sitting untouched in an app store. It is a large public codebase with a long changelog, a dedicated README, build instructions, privacy documentation, notification notes, security material and a visible release stream. The app is still evolving quickly, so users should read current release notes before assuming that an old review, screenshot or client comparison describes the version in their hand.
Install paths are part of the trust model
Amethyst is available through several channels. The README points Android users to Zapstore, Obtainium, GitHub releases and Google Play. That variety is useful because Nostr users do not all trust the same distribution path. Some prefer the automatic updates and device integration of Google Play. Some prefer GitHub releases, Zapstore or Obtainium because they want a more direct relationship with the open-source package.
The project has also moved beyond Android-only packaging. The README lists desktop install paths for macOS, Windows and Linux, including Homebrew cask, downloadable DMG files, Windows winget, MSI and ZIP packages, Debian and Ubuntu packages, RPM packages, AppImage and tar.gz builds. Those desktop builds are important, but Android is still the center of gravity. The desktop work should not sound as mature or culturally central as the Android app.
For a client that can hold private keys, connect wallets and handle encrypted messages, installation source matters. A cloned APK, stale mirror or fake listing can become a key-theft path. Before using Amethyst with a real identity, a user should verify that the package came from the official repository, official website, listed app store path or a trusted package channel. Convenience is not a replacement for package provenance.
What the app actually lets you do
Amethyst is most easily recognized as a social client. It loads timelines, profile pages, replies, reposts, reactions, hashtags and media posts. It supports multiple accounts and lets users move between public identity, follows, contacts and content views. That base layer is what most people will notice first: an Android app that makes Nostr feel like a living social space rather than a developer console.
The deeper feature list shows why Amethyst is difficult to summarize. The README lists support for long-form content, live activities, highlights, wiki-style content, Git-related event kinds, polls, labels, reports, calendar-like events, classified listings, marketplace and order events, voice messages, podcasts, bookmarks and recommended application handlers. Not every feature appears as a big named product area, but the app tries to interpret many event kinds instead of ignoring them.
This gives Amethyst a particular role in the ecosystem. A small client can be excellent by doing one thing cleanly. Amethyst is useful in a different way: it is a place where many protocol ideas collide with mobile interface reality. If an event kind is theoretically elegant but hard to understand on a phone, Amethyst often exposes that friction. If it works well, the app can make that part of Nostr feel normal.
Relays and the outbox model
Relay handling is one of Amethyst's defining technical choices. OpenSats describes the app as having moved to an outbox model and says it can connect to more than 1,000 relays on mobile without a noticeable battery or bandwidth cost. That is a large claim, but it points to the right idea: modern Nostr clients cannot rely on one fixed relay list and hope to find everyone efficiently.
The app uses granular relay roles. OpenSats describes inbox, outbox, direct-message, search, indexer, broadcast, local and other relay types. The README also lists NIP-65 relay list metadata and NIP-66 relay liveness monitoring among supported NIPs. This matters because relay selection affects whether posts are found, whether replies arrive, whether DMs can be retrieved and whether a user's social graph stays usable when different people publish to different places.
A user does not need to memorize every relay role to benefit from it. The practical point is simpler: Amethyst treats relay routing as a serious part of the product. It does not ask every user to hand-tune a few WebSocket URLs and live with missing context. It tries to discover, classify and use relays in ways that make a large decentralized social graph feel less broken on a phone.
Tor is not a decorative privacy label
Amethyst's privacy story starts with Tor because Tor is built into the product, not just mentioned in a blog sentence. OpenSats describes built-in Tor support as enabled by default so relay operators do not see the user's IP address. The app strings show internal Tor, Orbot setup, onion relay handling and several privacy presets, including modes for profile pictures, URL previews, media, money operations, NIP-05 checks and uploads.
That level of interface detail matters. Many apps say privacy, then leak most network behavior through ordinary fetches. Amethyst exposes a more complicated truth: Nostr privacy is not only about encrypted content. It is also about relay connections, IP addresses, media downloads, link previews, upload servers, NIP-05 verification, money-related requests and whether a third-party service sees the same identity across contexts.
Tor does not make Nostr magically private. Public posts remain public. Relays can still observe events and timing. Contacts, profile edits, likes, zaps and replies can reveal social patterns. But Amethyst's Tor work gives mobile users a realistic tool for reducing one major class of exposure. The best use is deliberate: understand which privacy preset is active, what it blocks and what it still cannot hide.
Private messages moved past old NIP-04
Amethyst has treated private messaging as a serious product area. The README lists older encrypted direct messages as well as NIP-17 private direct messages, NIP-44 versioned encryption, NIP-59 gift wrap and related chat features. OpenSats specifically notes early NIP-17 encrypted DM support and encrypted media uploads in private conversations. That is important because Nostr's original DM model was not enough for modern expectations.
NIP-17, NIP-44 and NIP-59 work together in a more private message design than the old visible-recipient event pattern. The content is encrypted with the current versioned encryption scheme, and gift wrapping changes how messages are delivered and identified. Amethyst's user interface hides much of that complexity, but the difference is meaningful: a private conversation should not be treated like a normal public event with a thin encrypted payload.
The app's own privacy material still warns about limits. Even when message content is protected, metadata can remain. People can often infer that two accounts communicate, and relays involved in storage or delivery can observe timing and retrieval patterns. A careful Amethyst user should therefore distinguish between encrypted content and anonymous communication. The former is a product feature. The latter requires much more discipline.
Zaps and Wallet Connect
Amethyst is not a wallet-first product, but money is woven into the app. The README lists Lightning tips, NIP-57 zaps and NIP-47 Nostr Wallet Connect. The Android strings include flows for connecting NWC wallets, checking NWC support, creating a NWC connection, handling invalid NIP-47 URLs and configuring Nostr Wallet Connect in zap settings. This is exactly where a social client crosses into wallet authority.
For the user, the important boundary is that Amethyst should not need to become the wallet. NIP-47 lets a Nostr app ask a wallet to create invoices, pay invoices or expose other wallet functions through a permissioned connection. That connection can be convenient for zapping posts, tipping creators and handling in-app payment flows, but it is not a harmless sign-in token. It can authorize money movement depending on the wallet's permissions.
Amethyst users should test Wallet Connect with tiny amounts and a dedicated connection. The connected wallet should show what permissions are granted, what budget exists, when the connection expires and which relay carries requests. A social app that can zap from the feed is delightful when the budget is small and intentional. It is dangerous when a permanent broad-spending connection is treated like a normal account preference.
Cashu and nutzaps inside a social app
Amethyst also follows the Cashu side of the Nostr money story. The README lists NIP-60 Cashu wallets and NIP-61 nutzaps. The app strings describe a Cashu wallet backed by a mint, tokens stored encrypted on relays, discovery of NIP-60 wallets and a separate P2PK key for receiving NIP-61 nutzaps. That vocabulary can sound technical, but it is directly relevant to small social payments.
Cashu changes the user experience because ecash can be passed around differently from normal Lightning invoices. It can make small-value flows feel faster and more private in some contexts, but the mint is still a trust point. Amethyst should therefore be read as a client that exposes Cashu features, not as proof that every mint is safe or that ecash removes custody risk.
Nutzaps are especially interesting because they bring Cashu into the social zap pattern. A normal zap is invoice-centered. A nutzap can represent ecash transfer behavior that fits Nostr events. For a user, the practical questions are which mint is involved, how wallet state is restored, which key receives tokens, where encrypted token state is stored and whether the app makes the difference between Lightning and ecash clear enough before value is at risk.
Media is more than image preview
Amethyst treats media as a first-class part of Nostr. The README lists image, video, URL, Lightning invoice and Cashu previews, in-device automatic translations, image and video capture, audio tracks, voice messages and live activities. The codebase includes upload service work for Blossom and HTTP upload flows, and the README lists NIP-94 file metadata, NIP-95 draft storage and NIP-96 HTTP file storage integration.
This is one place where Nostr clients become very different from simple text apps. A post may contain media references, file metadata, third-party upload URLs, previews, thumbnails, encrypted files, live stream information or external identifiers. A client has to decide what to fetch automatically, what to hide behind a tap, what to proxy, what to cache and which privacy mode should block a request.
Amethyst's media breadth is useful, but it also creates exposure. Loading a remote image can reveal IP information unless the privacy path blocks or routes it. Uploading media can reveal identity to a storage provider. Previewing a URL can call a third-party server. A good Amethyst setup pairs media convenience with the Tor and privacy controls described earlier, especially for accounts that need separation between identity and network location.
Moderation, labels and web of trust
Amethyst includes several tools that affect what a user sees and trusts. The README lists reporting, labeling, protected events, lists, mute-style behavior, user statuses, polls and NIP-85 trusted assertions. OpenSats says Vitor helped NIP-85 web-of-trust scoring. This is important because a Nostr client cannot rely on one platform moderation team to decide what is safe, spammy, abusive or useful.
In a decentralized social graph, moderation is partly a user-interface problem. The client has to make lists, labels, reports, communities and trust signals understandable without pretending they are universal truth. Amethyst's broad NIP support gives it raw material for that job. A relay can store events, but the app has to decide how to show context, warnings, reports, muted users, trusted contacts and recommended sources.
Users should still stay skeptical. Web-of-trust scoring can help reduce spam and impersonation, but it can also create bubbles if people never inspect the assumptions behind the trust graph. Labels can be helpful or hostile. Reports can be sincere or weaponized. Amethyst gives users more structure than a raw relay feed, but social judgment remains part of operating a Nostr identity.
Quartz underneath the interface
A major part of Amethyst is not visible as a screen. The repository separates the Android app from Quartz, a Kotlin Multiplatform Nostr commons library, plus shared UI and a Compose Multiplatform desktop app. OpenSats highlights Quartz as a Kotlin library and notes work on a high-performance local database with sub-microsecond queries for Quartz, as well as migration toward Kotlin Multiplatform.
This architecture matters because Amethyst is both a product and a protocol implementation bed. The app needs to parse many event kinds, maintain note and user objects, handle relay traffic, decrypt messages, store local state, prepare media, coordinate uploads, run notifications and present all of that through Android UI. A strong internal library helps the project keep those concerns from becoming one unmaintainable application blob.
The README describes a service layer that connects with relays, a model and repository layer that keeps Nostr objects in memory, and state-driven UI patterns. It also says account private keys and public keys are stored in Android KeyStore. These details do not make the app risk-free, but they show that Amethyst is trying to build a durable client architecture rather than a thin web wrapper around a feed.
Desktop exists, Android still leads
Amethyst now publishes desktop builds, and that is more than a footnote. The README lists packages for macOS, Windows and Linux, and OpenSats mentions desktop builds for Linux and Windows with an iOS port in development. The desktop work suggests that the project wants the Amethyst experience and Quartz stack to travel beyond Android.
Still, users should read the product honestly. Amethyst's public identity, app store history, feature feel and support culture remain Android-first. Many Nostr users mention Amethyst because they need a serious Android client, not because they are looking for a desktop client. Desktop builds can be valuable for continuity and testing, but they should not be presented as identical in maturity, polish or platform expectations.
The likely long-term value is shared implementation. If Quartz and Compose Multiplatform let the project reuse protocol logic across platforms, Amethyst can bring Android-tested Nostr features to desktop without starting from zero. That does not eliminate platform-specific work. It does, however, make Amethyst one of the more interesting clients for watching how Nostr app stacks move from single-platform apps toward shared codebases.
The privacy warning is worth reading
Amethyst's README and privacy material do not pretend that Nostr is private by default. They warn that relays can know an IP address, approximate location, public key, contacts, followed relays and public actions. They also warn that public content can be rebroadcast and that deletion cannot be guaranteed. This is not a small-print legal ritual; it is one of the most useful parts of the project documentation.
A Nostr client can encrypt messages, use Tor, reduce link-preview leaks and avoid obvious custodial traps, but it cannot erase the public nature of public events. A post signed by a key and sent to relays is designed to be copied. A deletion event is a request, not a command to every server on earth. A like, zap or follow can reveal a social relationship even when the text of a DM stays encrypted.
The right conclusion is not to avoid Amethyst. It is to use the app with the correct mental model. Public identity is public. Tor protects network location more than social behavior. Encrypted DMs protect content more than every metadata pattern. Wallet connections should be scoped. Media fetches should be controlled. Amethyst gives many controls, and the privacy page helps users understand why those controls exist.
What to test before settling in
A careful first run should start with identity and recovery. Create or import a low-risk account, confirm how the key is stored, decide whether to use an external signer such as Amber through NIP-55, and test account switching before bringing a primary identity into the app. Then check relay behavior: which relays are used for reading, writing, DMs, search and local state, and whether the app finds posts from people outside a small relay circle.
Private communication deserves a separate test. Send a NIP-17 DM to a trusted contact, attach a small test media file if needed, confirm whether the other client can read it, and inspect how Amethyst labels older NIP-04 messages versus newer private messages. For privacy-sensitive accounts, test Tor modes, media loading, URL previews and NIP-05 lookups on a network where leaks would matter.
Money should come last and start tiny. Connect a NWC wallet only with a small budget, send a test zap, receive a test zap, try Cashu or nutzaps only with throwaway value and read the wallet's permission screen carefully. Then test notifications, battery behavior and background reliability. A social client can be forgiven for missing a refresh. A wallet-connected client should earn trust one small action at a time.
Who Amethyst fits best
Amethyst fits Android users who want a serious, full-spectrum Nostr client and are willing to learn some of the network's machinery. It is especially strong for people who care about privacy controls, relay behavior, encrypted messaging, media, zaps, Cashu experiments and the ability to touch many NIPs from one app. Developers and protocol testers also get value because Amethyst often exposes newer event types before simpler clients do.
It is less ideal for someone who wants the calmest possible first hour. The app has many surfaces, many settings and many protocol concepts. A minimalist client can be easier for someone who only wants to follow a few accounts and post short notes. Amethyst's strength is not minimalism. Its strength is that it lets an Android user live closer to the full Nostr stack without leaving the phone.
For power users, that tradeoff is attractive. One app can handle public posts, private messages, media, zaps, relay lists, communities, live events, Cashu experiments and external signers. The cost is attention. A user should understand which privacy mode is active, which wallet is connected, which relays are involved and which feature is still experimental. Amethyst rewards people who want that control.
The reader takeaway
Amethyst is one of the clearest examples of Nostr as an application platform rather than only a microblogging protocol. It is an Android social client, but it also carries relay discovery, Tor privacy, encrypted messaging, zaps, Cashu, media storage, live activities, moderation signals and a serious Kotlin implementation stack. That combination makes it both useful and demanding.
The app's best quality is that it does not wait for every protocol idea to become boring before shipping it. Users can experience NIP-17 messages, NIP-47 wallet connections, NIP-57 zaps, NIP-60 Cashu wallets, NIP-61 nutzaps, NIP-65 relay lists, NIP-85 trust assertions, NIP-96 uploads and Blossom media paths in a real mobile client. The rough edges are part of the evidence that the app is working near the frontier.
The safe way to use Amethyst is to treat it as a powerful client, not a magic privacy wrapper. Verify the install source, protect keys, test relays, understand Tor modes, scope wallet permissions and keep payment experiments small until they are familiar. Used with that discipline, Amethyst is one of the most important Android windows into what Nostr can already do.
Sources worth opening
Useful primary sources are the official site, public repository, release notes, README, privacy file, OpenSats project material, app listings, source files and the NIPs that Amethyst implements or exposes to users.
- Amethyst official website
- Amethyst GitHub repository
- Amethyst README
- Amethyst MIT License
- Amethyst privacy documentation
- Amethyst security policy
- Amethyst build instructions
- Amethyst changelog
- Amethyst pull notification notes
- Amethyst Zapstore metadata
- Amethyst GitHub releases
- Amethyst v1.11.0 release
- Amethyst on Google Play
- Amethyst on Zapstore
- Amethyst OpenSats project page
- OpenSats first wave of Nostr grants
- OpenSats long-term support grant for Vitor Pamplona
- OpenSats advancements in Nostr clients
- Amethyst version catalog
- Amethyst Android strings
- Amethyst Android manifest
- Amethyst desktop application source
- Amethyst commons source
- Amethyst Blossom client source
- Amethyst Blossom auth source
- Amethyst Tor settings tests
- Amethyst NIP-17 plan notes
- Amethyst Cashu CLI plan notes
- Nostr NIP-01 basic protocol flow
- Nostr NIP-05 identifiers
- Nostr NIP-17 private direct messages
- Nostr NIP-44 versioned encryption
- Nostr NIP-47 Nostr Wallet Connect
- Nostr NIP-55 Android signer application
- Nostr NIP-57 Lightning zaps
- Nostr NIP-59 gift wrap
- Nostr NIP-60 Cashu wallets
- Nostr NIP-61 nutzaps
- Nostr NIP-65 relay list metadata
- Nostr NIP-66 relay liveness monitoring
- Nostr NIP-85 trusted assertions
- Nostr NIP-94 file metadata
- Nostr NIP-96 HTTP file storage integration
- Blossom specification
- Cashu protocol documentation
- Cashu NUT-00 cryptography and token model
- Tor Project
- Orbot by Guardian Project
- Android KeyStore documentation
- Kotlin Multiplatform documentation
- UnifiedPush project
