Amethyst ships five Linux package formats and one signing key, and its release titles are free text

An Android app that now publishes five Linux package formats

The download section opens on Android with four routes, including two sideloading stores, the GitHub releases and Google Play. Then it moves to desktop, which is where the shape of the project becomes clear. Only two rows have a command line install: one Homebrew cask for macOS, used for both Apple Silicon and Intel, and a Windows package manager entry, paired with an installer and a portable archive. Every Linux row has an empty command column and a file instead. Debian and Ubuntu get one package, three other distributions get another, and the catch-all row offers an AppImage and a compressed archive. A line under the table says Scoop and the Arch repository are coming soon in a separate pull request, which is the clearest statement on the page about the order things are being done in.

One certificate signs both Android flavors, and the page prints its fingerprint

Because most people get this app by sideloading, the README spends more space on signature verification than on features. All official packages, both the Google Play flavor and the F-Droid flavor, are signed with the same release certificate, and its SHA-256 fingerprint is printed in full so you have something to compare against. Two commands are given for checking it yourself, one using the signer tool that ships with the Android build tools and one using a certificate tool bundled with any Java runtime kit for people who do not have the Android SDK installed:

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

Both are expected to report the same digest as the one on the page, and the page spells out which field in the output to read. A third route exists for verifying someone else's copy: paste or share the package with a hosted verifier, which is told to compare both the application identifier and the fingerprint.

Ninety-two protocol entries, five unchecked, four with a placeholder number

The feature list is a checklist against the protocol's numbered proposals, and it is worth reading as a document rather than as marketing. Ninety-two rows appear. Ninety of them are ticked. The five unticked ones are specific. One is the browser extension API, marked not applicable rather than missing, because an Android and desktop client cannot expose a page's window object. One is a group messaging protocol using a mechanism this client does not implement. Three are drafts listed as such. Meanwhile four rows that are ticked are also marked as drafts with no number at all, written as a placeholder plus the word draft, covering medical data, embedded events, editing short notes and event type events. So the honest reading is that the client tracks proposals rather than implements a standard, and it says so in the list itself.

One proposal occupies four rows and one release title has a stray letter

Two details in the list show how it is maintained rather than curated. The lightning payment proposal appears four separate times, split into plain payments, splits between recipients, payments between private accounts and a fundraising variant, each ticked on its own row. That is a reasonable way to show partial coverage, and it also means a reader counting ticks is not counting features. The release history has its own version of the same looseness. Three releases land inside six days in September 2026, one of them a major version whose title is a list of features, one a patch whose title describes a build fix, and one whose title begins with its own version number and then carries a stray capital letter after the digits. The titles are free text, so nothing checks them.

Two libraries with animal names and a shelf of operational documents

The repository root is large enough that its structure is itself information. Beyond the Android application module there is a desktop module, a command line module, shared interface and logic modules, and a set of libraries that are separately named: a module published to a Maven central repository under the author's own group, a networking library, a QUIC library and a matching benchmark, a benchmarking module of its own, a baseline profile module, and two more with names borrowed from the landscape rather than from software. Alongside them sits a shelf of documents that a client of this size needs and a hobby project does not: one for release operations, one for privacy, one for security, one for plans, one for pull request notifications, and a contributing guide written specifically for AI-assisted contributions, next to a skill file and a directory of agent configuration.

Sideloading, hosted translations and a build-from-repository service

The distribution machinery is spread across four services, each doing one job. A store configuration file describes the listing in the sideloading store that Android users are pointed at. A hosted translation service configuration means new strings go through an external platform rather than through pull requests. A second configuration makes the library consumable directly from a build-from-repository service, which is why the README links a repository-hosted package page next to the central repository page. And a release directory belongs to a mobile delivery automation tool. Two smaller signals sit alongside: the product site is written with plain http while every badge and link in the same block is https, and the install page routes Gatekeeper, SmartScreen and AppImage problems to a troubleshooting section in the build document rather than describing them itself.

The feature list stops in the middle of its last line

The checklist ends mid-entry. The final visible row is a ticked item for capturing video inside the app, and its text stops after the words describing where the capture goes, with no closing punctuation and nothing after it. Everything before that is complete: the protocol rows, the payment rows, and then a tail of features that are not protocol proposals at all, among them push notifications through two different services, automatic translation on the device, following hashtags and custom ones, signing in by QR code, bounty support through an external site, a de-googled F-Droid build, multiple accounts on one device, Markdown, and a media preview that covers images, video, links, payment requests and ecash. The last line is where the update stopped, which tells you the list is edited in place rather than generated.

The project describes itself twice in one line

The repository description repeats itself. It reads as a client for Android, then restates that in full as an Android Nostr client, then appends the slogan about joining a social network you control. The page itself is shorter than that description and leads with the same slogan. It is a small thing, and it is the kind of thing that survives because nobody edits the field once the repository exists. The more useful summary comes from the list instead: this is a client that syncs, and its identity is the protocol coverage rather than any feature of its own. Everything on the page after the download table supports that reading, from the protocol checklist to the operational documents to the emphasis on verifying a signature rather than on any interface.

Editorial conclusion

Amethyst suits someone who wants a Nostr client on Android who also wants the same account on a desktop, and who is technical enough to check a signing fingerprint. Three things to know before installing a sideloaded copy. The verification instructions are not optional decoration, because three of the four Android distribution routes are outside a store whose signature check you do not perform. The two desktop package managers listed are macOS and Windows only, so on Linux you are fetching a file and, for two of the formats, dealing with Gatekeeper and SmartScreen prompts yourself. And the protocol support list is long enough to be a checklist of a moving target: about ninety entries, four of which are shipped under a placeholder draft number.

Frequently asked questions

Official sources

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