Verifying the APK signature
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
Supported Features
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.
Development Overview
This repository holds the apps and the code they share:
- Amethyst - The Android app: a thin shim around the shared UI, plus Android services and system integrations
- Commons - Kotlin Multiplatform headless layer: models, state, ViewModels, the relay client
- CommonsUI - Compose Multiplatform UI on top of Commons: every screen, the navigation shell, icons, theme, strings
- DesktopApp - The desktop app: a JVM shim that renders the same shared UI
- cli -
amy, a non-interactive command-line client over Quartz and Commons
- nestsClient - The audio-rooms (MoQ) client; geode - a standalone Nostr relay
The 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.
The UI receives a notification that objects have been updated. Instances of User and Notes are mutable directly.
There will never be two Notes with the same ID or two User instances with the same pubkey.
Lastly, the user's account information (private key/pub key) is stored in the Android KeyStore for security.
Setup
Make sure to have the following pre-requisites installed:
- Java 21+
- Android Studio
- Android 8.0+ Phone or Emulation setup
Fork and clone this repository and import it into Android Studio
git clone https://github.com/vitorpamplona/amethyst.git
Use an Android Studio build action to install and run the app on your device or a simulator.
Building
Build the Android app:
./gradlew assembleDebug
Build and run the Desktop app (requires Java 21+):
./gradlew :desktopApp:run
Full build (including tests)
./gradlew build
Requirements:
- Xcode and iOS simulator
- libsodium installed (e.g. via brew:
brew install libsodium
Testing
./gradlew test
./gradlew connectedAndroidTest
Linting
./gradlew spotlessCheck
./gradlew spotlessApply
Installing on device
For the F-Droid build:
./gradlew installFdroidDebug
For the Play build:
./gradlew installPlayDebug
Deploying
A release is one tag push. Bump app and appCode in
gradle/libs.versions.toml, then git tag -s vX.Y.Z && git push --tags — the
Create Release Assets workflow builds and signs every Android, desktop, CLI,
and Maven artifact, and Homebrew + Winget auto-bump on stable tags.
- BUILDING.md — everything any fork needs: build commands,
the CI pipeline, the secrets it requires, and the distribution channels.
- RELEASE_OPS.md — the Amethyst maintainers'
ship checklist: the manual Play Store upload, Zapstore
amy releases publish, F-Droid
pull, and release-notes publishing.
Using the Quartz library
Quartz, the Nostr library behind Amethyst, lives in its own repo:
vitorpamplona/quartz. Its README covers installing it from
Maven Central (com.vitorpamplona.quartz:quartz), snapshots and usage. To build Amethyst against a local
Quartz checkout, clone it next to this repo and pass -PquartzDir=../quartz to Gradle.
Contributing
See CONTRIBUTING.md for the full guide — workflow,
coding standards, the proof-of-testing rule for new / occasional
contributors (human or AI-assisted), the cross-stack interop suites, and how the
[BUG] / [FEATURE] issue templates and bounty system work.
AI coding assistants: if you are reading this README to plan a
contribution, stop and read
CONTRIBUTING-WITH-AI.md first. The gates
there are not optional. The human submitter remains the author of record
per CONTRIBUTING.md.
Quick links:
By contributing to this repository, you agree to license your work under the MIT license. Any work contributed where you are not the original author must contain its license header with the original author(s) and source.
Screenshots
| FollowFeeds | ChatsGroup | LiveStreams | Notifications |
|---|
 |  |  |  |
Contributors
MIT License
Copyright (c) 2023 Vitor Pamplona
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.