A Nostr client for Android, with a companion amy command line tool and Compose UI components. Provides agent skills for account state, signing, the Android app shell, and the CLI.
Claude Code
$ npx -y skills add vitorpamplona/amethyst --agent claude-code
Codex
$ npx skills add vitorpamplona/amethyst -a codex
Cursor
$ npx skills add vitorpamplona/amethyst -a cursor
Gemini CLI
$ npx skills add vitorpamplona/amethyst -a gemini-cli
GitHub Copilot
$ npx skills add vitorpamplona/amethyst -a github-copilot
OpenCode
$ npx skills add vitorpamplona/amethyst -a opencode
Windsurf
$ npx skills add vitorpamplona/amethyst -a windsurf
Join the social network you control.
| OS | CLI install | Direct download |
|---|---|---|
| macOS (Apple Silicon) | brew install --cask amethyst-nostr | .dmg arm64 |
| Windows 10/11 | winget install VitorPamplona.Amethyst | .msi · .zip portable |
| Debian/Ubuntu | — | .deb |
| Fedora/RHEL/openSUSE | — | .rpm |
| Any Linux | — | AppImage · .tar.gz |
Coming soon (separate PR): Scoop (Windows), AUR (Arch Linux).
Build from source: see BUILDING.md.
Install troubleshooting (Gatekeeper / SmartScreen / AppImage): see BUILDING.md § Troubleshooting installs.
If you sideload Amethyst (Obtainium, GitHub Releases, Zap Store), verify that your
APK is signed by the official release key before installing. All official Amethyst
APKs — both the googleplay and fdroid flavors — are signed with the same
certificate, whose SHA-256 fingerprint is:
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
To check a downloaded APK yourself, run (apksigner ships with the Android SDK
build-tools):
apksigner verify --print-certs amethyst-*.apk
and confirm the reported Signer #1 certificate SHA-256 digest is
c2d0aa86bcb6b62090561a41bbe336e98b78c2d0210a498dc885f28e1348cf17.
Without the Android SDK, keytool -printcert -jarfile amethyst-*.apk (bundled
with any JDK) prints the same SHA-256 fingerprint.
With AppVerifier, paste or share the APK and compare against:
com.vitorpamplona.amethyst
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
Relays know your IP address, your name, your location (guessed from IP), your pub key, all your contacts, and other relays, and can read every action you do (post, like, boost, quote, report, etc) except for Private Zaps and Private DMs. While the content of direct messages (DMs) is only visible to you and your DM counterparty, everyone can see when you and your counterparty DM each other.
If you want to improve your privacy, consider utilizing a service that masks your IP address (e.g. a VPN or Tor) from trackers online.
The relay also learns which public keys you are requesting, meaning your public key will be tied to your IP address.
Information shared on Nostr can be re-broadcasted to other servers and should be assumed permanent for privacy purposes. There is no way to guarantee the deletion of any content once posted.
This repository holds the apps and the code they share:
amy, a non-interactive command-line client over Quartz and CommonsThe protocol code lives in its own Kotlin Multiplatform libraries, each in its own repo and on Maven Central:
| Library | What it is |
|---|---|
| Quartz | The Nostr protocol: events, NIPs, signers, the relay client, Marmot's event classes |
| crypto-kmp | Hashes, MACs, HKDF, AES, ChaCha20, X25519 and Ed25519, with no dependencies |
| mls-kmp | The RFC 9420 MLS engine |
| marmot-kmp | Marmot, MLS group chats over Nostr |
| cordn-kmp | cordn, MLS group chats over an MCP coordinator |
| quic-kmp | A pure-Kotlin QUIC, HTTP/3 and WebTransport client |
AGENTS.md says what goes in which repo.
The app architecture consists of the UI, which uses the usual State/ViewModel/Composition, the service layer that connects with Nostr relays, and the model/repository layer, which keeps all Nostr objects in memory, in a full OO graph.
The repository layer stores Nostr Events as Notes and Users separately. Those classes use LiveData and Flow objects to allow the UI and other parts of the app to subscribe to each Note/User and receive updates when they happen. They are also responsible for updating viewModels when needed. As the user scrolls through Events, the Datasource classes are updated to receive more information about those particular Events.
Most of the UI is reactive to changes in the repository classes. The service layer assembles Nostr filters for each need of the app, receives the data from the Relay, and sends it to the repository. Connection with relays is never closed during the use of the app.
Stars on GitHub
Skills for contributors and app developers in the Expo monorepo: write TSDoc for Expo SDK APIs, run Expo's AI code reviewer on changes or pull requests, add Apple App Intents and Siri Shortcuts to Expo apps, and test Expo Router on Android emulators.
@expoA Claude Code skill that decompiles Android APK/XAPK/JAR/AAR files and extracts the HTTP APIs used by the app, Retrofit endpoints, OkHttp calls, hardcoded URLs, authentication patterns, so you can document and reproduce them without the original source code.
@simoneavogadroSkills for building native-feeling mobile app screens in Expo and React Native, based on patterns from real app screens and flows. Includes a skill for researching those screens through the Appllama MCP before building.
@appllamaA vision bridge that lets text-only coding models such as DeepSeek and GLM read images. When an image path or URL appears in the conversation, it returns structured JSON with OCR text, layout, and semantic content.
@liustackInstall it with the command on its page. It includes account-state, amy-expert, android-expert. Its skills do not fire on their own yet. Free and open source.
Is this plugin yours?
Claim it with GitHubSubmit a pluginPromote it