Five protocol-level fixes and a batch of harness correctness fixes to get
the headless Marmot/Whitenoise interop harness from 1/13 to 5/13 passing
cleanly, with the remaining failures all rooted in wn's per-account
serial event-processor retry backoff (which drops undecryptable
pre-membership commits after several minutes) rather than amy behaviour.
quartz + commons
----------------
* MarmotGroupData: hold CURRENT_VERSION at 2. mdk-core (the Rust MLS
engine used by whitenoise-rs) strict-rejects v3 payloads with
`ExtensionFormatError("Trailing bytes in NostrGroupDataExtension")`
— our v3 welcomes and GCE commits never apply, so every cross-client
group flow dies at welcome processing. We still parse v3 happily on
the way in; we just don't emit it until mdk publishes the
forward-compat fix MIP-01 mandates.
* MarmotManager.updateGroupMetadata: MERGE extensions instead of
REPLACING. RFC 9420 §12.1.7 says GCE proposals blow away the old
extension list; callers that pass only [marmot_group_data] dropped
[required_capabilities], which peers then reject. Preserve every slot
except the one we're updating.
* MarmotManager.createGroup: new optional `initialMetadata` parameter
that bakes MarmotGroupData into epoch-0 GroupContext.extensions
directly. Without it, creators had to publish a pre-membership
"bootstrap" commit that no later joiner could decrypt — each such
peer then burned their retry budget on an undecryptable kind:445
before seeing the real state. Threaded through MlsGroup.create /
MlsGroupManager.createGroup.
* MarmotManager.mlsGroupIdHex: new translation helper so any code
juggling the MIP-01 nostr_group_id (what amy indexes on) and the
MLS GroupContext groupId (what mdk indexes on) can cross-reference
them without reaching into MlsGroupManager directly.
amethyst module
---------------
* Account.leaveMarmotGroup: self-demote before SelfRemove per MIP-01,
and promote a surviving member to admin first if the caller is the
sole admin (otherwise we'd throw "admin depletion"). Matches the
cli/GroupMembershipCommands.leave flow.
cli (amy)
---------
* Context.syncIncoming: don't advance `giftWrapSince` on empty polls
(so the first-ever sync doesn't bump the cursor past every
past-timestamped wrap we've ever been sent), subtract 2 days lookback
when filtering (NIP-59 randomWithTwoDays gift wraps can have any
createdAt in the last 48h), and only advance `groupSince` for groups
we actually received events for.
* Context.syncIncoming: after ingest, if any Welcome consumed a
KeyPackage, rotate and publish a fresh one immediately. MIP-00
requires this — a KP can only be welcomed once and leaving the
consumed one on relays just means later senders invite us with a
bundle we no longer have private keys for.
* Context.resolveGroupId: accept either nostr_group_id (amy's primary
key) or the MLS GroupContext groupId (what wn emits) on every verb
that takes a group id. Wired through GroupAdd/Remove/Leave/Metadata
/Read, Message send/list, and all the await* verbs so harness
scripts never have to juggle both forms for a single group.
* GroupCreateCommand: bake initial metadata into epoch 0 (see the
quartz change above). Dropped the now-redundant bootstrap commit
publish and tightened the JSON output to include `mls_group_id`.
* GroupMembershipCommands.leave: self-demote admin before SelfRemove;
promote an heir if we're the only admin, otherwise the GCE would
deplete admins and the leave aborts.
* MarmotIngest.ingestGiftWrap: unwrap the sealed-rumor layer. NIP-59
wrap is gift-wrap(kind:1059) → seal(kind:13) → rumor; the old code
only unwrapped once and then checked `inner.kind == 444`, which is
always false because inner is actually the seal. Unseal once more
before the Welcome check. This single fix is what unsticks every
amy-side Welcome ingestion.
wn harness patches + scripts
----------------------------
* whitenoise-defaults-env.patch: honour $WHITENOISE_DISCOVERY_RELAYS in
`Relay::defaults()` (release builds otherwise bake damus.io / primal
/ nos.lol into every new account's NIP-65 / Inbox / KeyPackage
lists, which breaks publishing and prevents the inbox subscription
plane from ever reaching an operational state in a sandbox).
* setup.sh: sleep 2s after amy's initial kind:30443 publish so
nostr-rs-relay has a chance to fsync before wn's first targeted
discovery query. Without it wn's `keys check` races the relay's
WAL flush and intermittently returns NotFound.
* lib.sh: peel wn's `{"result": …}` wrapper in `jq_group_id`,
`wait_for_invite`, `wait_for_message`, `wait_for_member`. Post-v0.2
wn `--json` output nests everything under `.result` (and
`groups invites[]` nests further under `.group.mls_group_id`) —
these helpers were still pattern-matching on the flat shape, so
they returned empty strings for a perfectly good response.
* tests-{create,manage,extras}.sh: track both group IDs per test
(amy's nostr + wn's MLS), pass each CLI the id it understands, and
bump the post-commit wait timeouts to 90–120s so wn's exponential
retry backoff has time to work through the pre-membership commits
it can't decrypt and get to the ones it can.
https://claude.ai/code/session_016kAxdp6ubB5CnF9URhCEzP
Amethyst
Nostr Client for Android
Join the social network you control.
Download and Install
Android
Desktop
| OS | CLI install | Direct download |
|---|---|---|
| macOS (Apple Silicon) | brew install --cask amethyst-nostr |
.dmg arm64 |
| macOS (Intel) | brew install --cask amethyst-nostr |
.dmg x64 |
| 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.
Supported Features
- Basic protocol flow (NIP-01)
- Follow List (NIP-02)
- OpenTimestamps Attestations (NIP-03)
- Encrypted Direct Message (NIP-04)
- DNS-based Identifiers (NIP-05)
- Key Derivation from Mnemonic (NIP-06)
- window.nostr for Web Browsers (NIP-07, Not applicable)
- Handling Mentions (NIP-08)
- Event Deletion Request (NIP-09)
- Text Notes and Threads (NIP-10)
- Relay Information Document (NIP-11)
- Proof of Work (NIP-13)
- Subject Tag in Text Events (NIP-14)
- Nostr Marketplace (NIP-15)
- Private Direct Messages (NIP-17)
- Reposts (NIP-18)
- bech32-encoded Entities (NIP-19)
- nostr: URI Scheme (NIP-21)
- Comment (NIP-22)
- Long-form Content (NIP-23)
- Extra Metadata Fields and Tags (NIP-24)
- Reactions (NIP-25)
- Delegated Event Signing (NIP-26)
- Text Note References (NIP-27)
- Public Chat (NIP-28)
- Relay-based Groups (NIP-29)
- Custom Emoji (NIP-30)
- Dealing with Unknown Events (NIP-31)
- Labeling (NIP-32)
- git stuff (NIP-34)
- Torrents (NIP-35)
- Sensitive Content (NIP-36)
- Draft Events (NIP-37)
- User Statuses (NIP-38)
- External Identities in Profiles (NIP-39)
- Expiration Timestamp (NIP-40)
- Authentication of Clients to Relays (NIP-42)
- Relay Access Metadata and Requests (NIP-43)
- Encrypted Payloads / Versioned (NIP-44)
- Counting Results (NIP-45)
- Nostr Remote Signing (NIP-46)
- Nostr Wallet Connect (NIP-47)
- Proxy Tags (NIP-48)
- Private Key Encryption (NIP-49)
- Search Capability (NIP-50)
- Lists (NIP-51)
- Calendar Events (NIP-52)
- Live Activities (NIP-53)
- Wiki (NIP-54)
- Android Signer Application (NIP-55)
- Reporting (NIP-56)
- Lightning Zaps (NIP-57)
- Zap Splits (NIP-57)
- Private Zaps (NIP-57)
- Zapraiser (NIP-57)
- Badges (NIP-58)
- Gift Wrap (NIP-59)
- Pubkey Static Websites (NIP-5A)
- Cashu Wallet (NIP-60)
- Nutzaps (NIP-61)
- Request to Vanish (NIP-62)
- Chess / PGN (NIP-64)
- Relay List Metadata (NIP-65)
- Relay Discovery and Liveness Monitoring (NIP-66)
- Picture-first Feeds (NIP-68)
- Peer-to-peer Order Events (NIP-69)
- Protected Events (NIP-70)
- Video Events (NIP-71)
- Moderated Communities (NIP-72)
- External Content IDs (NIP-73)
- Zap Goals (NIP-75)
- Negentropy Syncing (NIP-77)
- Application-specific Data (NIP-78)
- Threads (NIP-7D)
- Highlights (NIP-84)
- Trusted Assertions (NIP-85)
- Relay Management API (NIP-86)
- Ecash Mint Discoverability (NIP-87)
- Polls (NIP-88)
- Recommended Application Handlers (NIP-89)
- Data Vending Machines (NIP-90)
- Media Attachments (NIP-92)
- File Metadata (NIP-94)
- Binary Blobs (NIP-95/Draft)
- HTTP File Storage Integration (NIP-96)
- HTTP Auth (NIP-98)
- Classified Listings (NIP-99)
- Voice Messages (NIP-A0)
- Public Messages (NIP-A4)
- Web Bookmarks (NIP-B0)
- Blossom (NIP-B7)
- Nostr BLE Communications Protocol (NIP-BE)
- Code Snippets (NIP-C0)
- Chats (NIP-C7)
- MLS Protocol (NIP-EE)
- Audio Tracks (zapstr.live) (kind:31337)
- Lightning Tips
- Image/Video/Url/LnInvoice/Cashu Previews
- Push Notifications (Google and Unified Push)
- In-Device Automatic Translations
- Hashtag Following and Custom Hashtags
- Login with QR
- Bounty support (nostrbounties.com)
- De-googled F-Droid flavor
- Multiple Accounts
- Markdown Support
- Medical Data (NIP-xx/Draft)
- Embed events (NIP-xx/Draft)
- Edit Short Notes (NIP-xx/Draft)
- NIP Events (NIP-xx/Draft)
- Relationship Status (NIP-xx/Draft)
- Signed Filters (NIP-xx/Draft)
- Key Migration (NIP-xx/Draft)
- Image Capture in the app
- Video Capture in the app
- Local Database
- Workspaces
Privacy and Information Permanence
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 is split between Amethyst, Quartz, Commons, and DesktopApp:
- Amethyst - Native Android app with Kotlin and Jetpack Compose
- Quartz - Nostr-commons KMP library for protocol classes shared across platforms
- Commons - Kotlin Multiplatform module with shared UI components (icons, robohash, blurhash, composables)
- DesktopApp - Compose Multiplatform Desktop application reusing commons and quartz
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
Full release + bootstrap runbooks (Android AAB upload, desktop packaging, Homebrew cask, Winget manifest, Apple Developer signing budget time-box) live in BUILDING.md § Release runbook and BUILDING.md § Bootstrap runbook (one-time).
TL;DR for cutting a release:
- Bump
appingradle/libs.versions.toml(e.g."1.08.1") - Bump
versionCodeinamethyst/build.gradle git commit -am "chore(release): 1.08.1" && git tag -s v1.08.1 && git push --tags- Wait for
Create Release Assetsworkflow — 20 Android assets + 8 desktop assets go live on GH Release; Homebrew + Winget auto-bump on stable tags - Upload AAB to Play Store manually (existing step)
Using the Quartz library
Installing
Add Maven Central and Google Maven to your repositories:
repositories {
mavenCentral()
google()
}
Add the following line to your commonMain dependencies:
implementation('com.vitorpamplona.quartz:quartz:1:05.0')
Variations to each platform are also available:
implementation('com.vitorpamplona.quartz:quartz-android:1:05.0')
implementation('com.vitorpamplona.quartz:quartz-jvm:1:05.0')
implementation('com.vitorpamplona.quartz:quartz-iosarm64:1:05.0')
implementation('com.vitorpamplona.quartz:quartz-iossimulatorarm64:1:05.0')
Check versions on MavenCentral
How to use
Manage logged in users with the KeyPair class
val keyPair = KeyPair() // creates a random key
val keyPair = KeyPair("hex...".hexToByteArray())
val keyPair = KeyPair("nsec1...".bechToBytes())
val keyPair = KeyPair(Nip06().privateKeyFromMnemonic("<mnemonic>"))
val readOnly = KeyPair(pubKey = "hex...".hexToByteArray())
val readOnly = KeyPair(pubKey = "npub1...".bechToBytes())
Create signers that can be Internal, when you have the private key or a read-only public key, or External, when it is controlled by Amber in NIP-55.
Use either the NostrSignerInternal or NostrSignerExternal class:
val signer = NostrSignerInternal(keyPair)
val amberSigner = NostrSignerExternal(
pubKey = keyPair.pubKey.toHexKey(),
packageName = signerPackageName, // Amber package name
contentResolver = appContext.contentResolver,
)
Create a single NostrClient for the entire application and control which relays it will access by
registering subscriptions and sending events. The pool will automatically change based on filters +
outbox events.
You will need a coroutine scope to process events and if you are using OKHttp, we offer a basic wrapper to create the socket connections themselves.
val appScope = CoroutineScope(Dispatchers.Default + SupervisorJob())
val rootClient = OkHttpClient.Builder().build()
val socketBuilder = BasicOkHttpWebSocket.Builder { url -> rootClient }
val client = NostrClient(socketBuilder, appScope)
If you want to auth, given a logged-in signer:
val authCoordinator = RelayAuthenticator(client, appScope) { authTemplate ->
listOf(
// for each signed-in user, return an event
signer.sign(authTemplate)
)
}
To make a request subscription simply do:
val metadataSub = client.req(
relay = "wss://nos.lol",
filter = Filter(
kinds = listOf(MetadataEvent.KIND),
authors = listOf(signer.pubkey)
)
) { event ->
/* consume event */
}
The client will add the relay to the pool, connect to it and start receiving events. The
metadataSub will be active until you call metadataSub.close(). If the client disconnects
and reconnects, the sub will be active again.
To manage subscriptions that change over time, the simplest approach is to build mutable subscriptions with a filters lambda that you can change at will.
val metadataSub = client.req(
filters = {
// Let's say you have a list of users that need to be rendered
val users = pubkeysSeeingInTheScreen()
// And a cache repository with their outbox relays
val outboxRelays = outboxRelays(users)
val filters = listOf(
Filter(
kinds = listOf(MetadataEvent.KIND),
authors = users
)
)
outboxRelays.associateWith { filters }
}
) { event ->
/* consume event */
}
In that way, you can simply call metadataSub.updateFilter() when you need to update
subscriptions to all relays. Or call metadataSub.close() to stop the sub
without deleting it.
When your app goes to the background, you can use NostrClient's connect and disconnect
methods to stop all communication to relays. Add the connect to your onResume and disconnect
to onPause methods.
Feature Parity Table
| Feature Category | Feature / Component | Android / JVM Support | iOS Support | Notes |
|---|---|---|---|---|
| Cryptography | Secp256k1 (Schnorr, Keys) | ✅ Full | ✅ Full | |
| LibSodium (ChaCha20, Poly1305) | ✅ Full | ✅ Full | ||
| AES Encryption (CBC & GCM) | ✅ Full | ✅ Full | ||
| Hashing (SHA-256, etc.) | ✅ Full | ✅ Full | ||
| MAC (HmacSHA256, etc.) | ✅ Full | ✅ Full | ||
| Data & Serialization | JSON Mapping (Optimized) | ✅ Full | ✅ Full | A fully custom implementation exists in commonMain. |
| GZip Compression | ✅ Full | ✅ Full | ||
| BitSet | ✅ Full | ✅ Full | ||
| LargeCache | ✅ Full | ✅ Full | ||
| NIP Support | NIP-96 (File Storage Info) | ✅ Full | ✅ Full | |
| NIP-46 (Remote Signer) | ✅ Full | ⚠️ Partial | Some methods in NostrSignerRemote are unimplemented in commonMain. |
|
| NIP-03 (OTS / Timestamps) | ✅ Full | ❌ No | BitcoinExplorer and RemoteCalendar have stubs in commonMain. |
|
| Utilities | URL Encoding / Decoding | ✅ Full | ✅ Full | |
| Unicode Normalization | ✅ Full | ✅ Full | ||
| Platform Logging | ✅ Full | ✅ Full | iOS uses NSLog, Android uses standard Log. |
|
| Current Time | ✅ Full | ✅ Full | Implemented using NSDate on iOS. |
Contributing
Issues can be logged on: https://gitworkshop.dev/repo/amethyst
GitHub issues and pull requests here are also welcome. Translations can be provided via Crowdin
You can also send patches through Nostr using GitStr to this nostr address
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.





