AmethystをNostrの広い仕様群で読む: Android中心のKotlinクライアントと配布経路

Androidアプリから共有モジュールまで

リポジトリの説明はAmethystをAndroid向けNostrクライアントと位置付けています。READMEの構成を見ると、単独の画面アプリだけではありません。KotlinとJetpack Composeで作るAndroidアプリに加え、共有UIを担うCommons、NostrのプロトコルクラスをまとめたQuartz、CommonsとQuartzを使うDesktopAppが同居します。中心はAndroidのままですが、同じコード資産をJVMやデスクトップへ広げる設計です。

この切り分けは、利用者と開発者で意味が異なります。利用者はGoogle Play、F-Droid系の配布、GitHub Releasesなどからアプリを選び、開発者はQuartzをライブラリとして組み込めます。READMEは主対象をAndroidとしながら、macOS、Windows、Linux向けのデスクトップ配布物も案内しています。対応範囲を判断する時は、Androidクライアントと共有ライブラリを同じ製品とみなさず、必要な部分を分けて確認するのが安全です。

配布物の選択とAPK署名の照合

Android版の入手先としてREADMEはZap Store、Obtainium、GitHub Releases、Google Playを挙げています。デスクトップではApple SiliconとIntelのmacOS用dmg、Windows 10と11向けのmsiおよびポータブルzip、Debian系のdeb、Fedora系などのrpm、AppImageとtar.gzが並びます。macOSではHomebrewのamethyst-nostr、Windowsではwingetのインストール名も記載されています。ScoopとAURは別のプルリクエストで対応予定とされ、現行経路と混同しない方がよいでしょう。

サイドロードでは、READMEがgoogleplayとfdroidの公式APKに同じ証明書を使うと説明しています。掲載されたSHA-256フィンガープリントは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です。apksignerのprint-certs、JDKのkeytool、AppVerifierで、取得したファイルの署名者ダイジェストと照合できます。これは配布物が正しいかを見る手順であり、アプリの安全性全体を証明するものではありません。

NIP対応表が示す実装の幅

READMEのチェックリストは、基本的なNIP-01のイベント処理から、フォロー、メンション、スレッド、リアクション、長文、コミュニティ、メディア添付まで幅広い項目を扱います。NIP-44の暗号化ペイロード、NIP-46のリモート署名、NIP-47のWallet Connect、NIP-57のLightning Zap、NIP-60のCashuウォレットなど、Nostrの周辺機能も完了印付きで並びます。NIP-55のAndroid Signer ApplicationやQRログインもAndroid利用に関係する項目です。

一方で、MLS ProtocolのNIP-EE、Relationship Status、Signed Filters、Key Migrationなどは未完了として残っています。チェックリストは実装の対象範囲を読む手掛かりですが、各項目の対応深度、相互運用性、既存アカウントでの移行結果までは示しません。特定のリレーやウォレット、暗号化DMと組み合わせるなら、必要なNIPだけを実機と相手側の実装で確かめる必要があります。

リレー中心のデータ経路とプライバシー

Amethystの利用で見落としにくいのが、アプリの画面よりもリレーとの関係です。READMEのプライバシー説明では、リレーはIPアドレス、公開鍵、連絡先を知り、プライベートZapとプライベートDMを除けば行動の多くを読み取れるとされています。VPNやTorでIPアドレスを隠す選択肢も案内されますが、ネットワーク上の観測者、利用するリレーの運用者、投稿先の保存方針は別々に考える必要があります。

公開したコンテンツは永続的と考えるべきだという警告もあります。削除リクエストのNIPに対応していても、既に別のリレーやクライアントが保存したコピーまで消えるとは限りません。秘密鍵と公開鍵はAndroid KeyStoreに保存されるとREADMEにありますが、リレー側の見える範囲、バックアップ、端末紛失時の復旧まで含む運用設計は、利用者が自分で確認する領域です。

UI、サービス、オブジェクトグラフ

READMEはアプリをUI層、サービス層、モデルとリポジトリ層に分けて説明します。UIはState、ViewModel、Compositionを使い、サービス層はNostrリレーへの接続、フィルター作成、受信データの受け渡しを担当します。モデルとリポジトリ層では、Nostrオブジェクトをメモリ上のオブジェクトグラフとして保持し、イベントをNotes、利用者をUsersとして管理します。変更の購読にはLiveDataとFlowが使われます。

READMEが強調する不変条件は、同じIDを持つ二つのNoteや、同じpubkeyを持つ二つのUserインスタンスを作らないことです。接続を開いたままイベントを集約し、画面側が変化を購読する設計と読めます。ただし、READMEだけでは大量イベント時のメモリ上限、リレー切断時の再同期、ローカルデータベースの未完了項目の扱いまでは判断できません。ここは利用前の検証項目です。

アプリの構造を読む時は、画面に表示された結果と、Nostrイベントを保持するモデルの状態を分けて観察します。UI層のState、ViewModel、Compositionは表示と操作の入口であり、サービス層はリレー接続、検索フィルター、受信イベントの配布を担います。モデル層がNotesとUsersを一意に維持するため、同一IDや同一公開鍵を持つ対象が複数表示されないことが設計上の確認点になります。返信、引用、反応、プロフィール更新を同時に受信した時、関連する画面がどの順序で更新されるかを確認します。

購読を始める時は、対象リレー、フィルター、取得期間、受信イベントの種類を固定します。新しい投稿だけを受けるのか、過去の長文やメディアを遡るのかで、読み込み量と画面状態は変わります。リレーごとに同じイベントを返す場合は、イベント識別子による重複排除を確認し、別の署名や更新を同一ノートへ誤って結び付けないようにします。接続切断後の再購読、遅延イベント、削除要求、未知イベントの処理も、一覧表の完了印だけから推定せず実際の受信結果で判定します。

Android KeyStoreによる鍵保管、複数アカウント、QRログイン、Android Signer Applicationは、利用者の操作順序に影響する境界です。ログイン直後に表示された公開鍵、投稿前に選ばれた署名鍵、暗号化DMの受信者、ウォレット接続の相手を記録し、切り替え後も誤送信が起きないか調べます。端末内自動翻訳やプッシュ通知を使う場合は、原文、翻訳文、通知本文、保存イベントを別々に扱い、翻訳結果や通知の欠落が原文保存を壊さないことを確認します。

開発者は、CommonsとQuartzを変更した時にAndroidとDesktopAppへどの影響が及ぶかを追跡します。共有コードの変更、Nostrイベントの解析、UI購読の変更、鍵処理の変更を同じ更新として扱わず、対象モジュールと対象端末を明示します。Java 21以上、Android 8.0以上、Android Studio、必要なSDKを固定し、assembleDebug、desktopAppの起動、test、connectedAndroidTest、Spotless検査の結果を版番号と一緒に保存します。これにより、広い機能一覧を構成、通信、署名、配布、検証の単位へ落とし込めます。

開発条件とリリースの読み方

開発者向けのREADMEには、Androidのデバッグビルドに./gradlew assembleDebug、デスクトップの起動に./gradlew :desktopApp:run、全体ビルドに./gradlew buildを使う例があります。テストは./gradlew testとconnectedAndroidTest、整形や検査はspotlessCheckとspotlessApplyです。前提としてJava 21以上、Android Studio、Android 8.0以上の端末またはエミュレーターが挙げられています。

リリースについては、一つのタグをプッシュすることが公開の単位だと説明され、詳しい作業はBUILDING.mdとRELEASE_OPS.mdに分かれています。取得したメタデータでは、デフォルトブランチはmain、ライセンスはMIT、直近のリリースはv1.14.0です。リリース番号やスター数は更新される情報なので、固定的な性能や互換性の保証として読まず、使う版のタグと付属文書を保存しておくべきです。

Quartzを組み込む場合の境界

Quartzは、プラットフォーム間で共有するNostrプロトコルクラス向けのKotlin Multiplatformライブラリとして説明されています。READMEにはMaven Centralからcom.vitorpamplona.quartz:quartz:1.13.1を追加する方法と、スナップショット用にJitPackを使う方法があります。KeyPair、署名者、NostrClient、サブスクリプションリクエストの例があり、AndroidとJVM、iOSの機能差を表で確認できる構成です。

このライブラリを使えば、Amethyst本体の画面を採用せずに共有プロトコル層を利用できます。ただし、READMEの例はAPIの入口を示すもので、アプリ固有の鍵保護、リレー選択、同期、通知を自動で引き受けるとは書かれていません。MITライセンスは利用、改変、再配布を認めますが、ソフトウェアは現状のまま提供され、セキュリティ保証や本番運用の約束はライセンスから読み取れません。

採用前に固定して確認する項目

Amethystを評価する時は、対応NIPの一覧をそのまま採用理由にせず、自分が必要とする通信と保存の流れへ分解します。まず利用するリレーを決め、公開鍵、プロフィール、投稿、返信、反応、メディア、削除要求が各リレーでどう扱われるかを確認します。次に暗号化DM、Private Zap、Wallet Connect、リモート署名を分け、送信時にどの鍵とどの相手を選ぶのかを記録します。NIP-44とNIP-47に対応していても、利用する相手側クライアントが同じ方式を実装していなければ、期待する通信にはなりません。

Android利用では、Google Play、F-Droid系、Obtainium、GitHub Releasesのどの経路を採用するかを決め、取得したAPKの版、タグ、署名者、SHA-256フィンガープリントを保存します。署名一致は改変検出に役立ちますが、リレーが保持するデータの公開範囲や、端末紛失時の鍵復旧を解決するものではありません。複数アカウントを使う場合は、アカウントごとの公開鍵、通知先、投稿先、署名要求を画面で確認できる試験を用意します。

デスクトップ版では、macOSのCPU種別、Windowsの配布形式、Linuxのパッケージ方式を固定します。開発側でQuartzを直接使う場合は、Maven Centralの版とJitPackのスナップショットを混ぜず、Android、JVM、iOSの機能差を表に沿って比較します。ビルド時はJava 21以上、Android 8.0以上という前提を満たし、assembleDebug、desktopAppの起動、テスト、Spotless検査を別々に実行します。READMEにない性能上限、同期保証、リレーの保存期間は、確認できない項目として記録してから運用範囲を決めるべきです。

この確認方法なら、Amethystを単なる機能数で評価せず、Nostrの分散した保存先、端末鍵、共有コード、配布物を一つの運用境界として扱えます。READMEが示す完了項目は実装の入口を示しますが、利用者のリレー構成や相手クライアントとの互換性まで保証する資料ではありません。採用判断は、必要なNIPの送受信、署名、再接続、復旧、削除要求を自分の条件で再現できた範囲に限定するのが妥当です。

実務では、最初に少数のテストアカウントと検証用リレーを準備し、公開投稿と暗号化投稿を混ぜない手順を作ります。公開鍵の表示、署名要求、投稿本文、添付メディア、返信関係、反応、削除要求を一件ずつ記録し、送信後に別クライアントから同じイベントを取得できるかを確認します。リレーを複数指定する場合は、片方だけが成功した状態を全体成功と数えず、各リレーの応答と再接続結果を分けて残します。通知を使う場合も、通知到着をイベント保存の証拠にしないで、実際のイベントIDと本文を照合します。

鍵をAndroid KeyStoreに保管する設計を確認した後も、端末変更、アプリ再導入、複数アカウント切り替えの復旧手順を用意します。READMEには鍵のバックアップ方式や復旧保証は記載されていないため、秘密鍵をどこへ保存するかは利用者側の責任範囲です。デスクトップとAndroidで同じ公開鍵を使うなら、どの端末が署名を担当するのか、リモート署名を許すのか、ウォレット接続をどこで承認するのかを明文化します。

このように、対応表、配布物、鍵、リレー、共有ライブラリを個別に検証すると、READMEの機能宣言と実際の利用条件を分離できます。Amethystの広い対象範囲は魅力ですが、未完了のNIP、ドラフト項目、相手実装の差、公開データの永続性が残ります。確認できた組み合わせだけを運用対象にし、未確認の機能は使えると断定しないことが、採用後の影響を小さくします。

検証記録には、対象タグ、取得URL、ファイルハッシュ、署名者情報、使用端末、Android版、接続リレー、テスト用公開鍵を含めます。NIPの対応可否を一行で記録するのではなく、イベント生成、署名、送信、取得、表示、更新、削除要求の各段階へ分けて判定します。NIP-23の長文、NIP-28の公開チャット、NIP-29のリレー型グループ、NIP-71の動画イベントのように、保存量や表示方式が異なる項目は個別に扱います。画像、動画、音声、外部URLのプレビューについても、リレー保存と端末表示を分離し、失敗時に本文まで失われるかを調べます。

暗号化機能では、受信者が正しい公開鍵か、署名前に表示される相手情報が一致するか、別端末で復号できるかを確認します。Private ZapやNostr Wallet Connectを使う場合は、支払いやウォレット操作の承認境界をAmethystの表示だけに委ねず、接続先、金額、要求内容を別記録に残します。Android Signer Applicationやリモート署名を使う場合も、端末内秘密鍵を直接扱う場合と同じ復旧手順があるとは考えません。READMEが説明する機能と、実際の鍵管理責任を分けることが必要です。

開発者がQuartzだけを採用する場合は、Amethyst本体のUI実装、通知、データ保存、リレー選択が含まれない点を設計書に明記します。Maven Central版、JitPackスナップショット、AndroidとJVMとiOSの対象を固定し、プロトコルクラスの更新で署名形式やイベント解析が変わらないかを確認します。アプリ利用者がデスクトップ版を使う場合は、共有モジュールの再利用が機能完全一致を意味するとは限らないため、OSごとの配布物と入力装置、通知、鍵保管を別試験にします。

Amethystは、Nostrの複数仕様と多様な配布環境を一つのリポジトリにまとめている点が特徴です。その反面、広い対応表は評価範囲も広げます。採用の根拠は、スター数や完了印ではなく、必要なイベントが相手クライアントと正しく往復し、鍵と公開範囲を管理でき、失敗時に復旧できることに置きます。READMEで確認できない性能限界、同期保証、リレーの保存方針、セキュリティ監査は未確認のまま残し、検証できた事実と利用者の判断を明確に分けてください。

確認後の運用では、機能追加のたびに対象NIP、対象リレー、鍵の利用者、保存先、復旧手順を更新します。リリースタグがv1.14.0から変わった時は、前版との互換性を推測せず、APK署名、共有ライブラリ版、ビルド条件、重要なイベントの送受信を再確認します。公開データと秘密データを同じ試験結果で扱わず、第三者が取得可能な投稿については永続保存の前提を崩しません。未完了項目やドラフト仕様を使う場合は、相手実装と失敗時の代替経路を明記し、未検証のまま利用者へ提供しないことが求められます。

編集部の結論

Amethystは、Nostrの多様なイベントと暗号化機能をAndroidで使いたい人に向く構成です。デスクトップ版やQuartzの再利用も選べますが、リレーが知る情報、投稿の永続性、端末側の鍵保護を自分の運用条件に照らして確認してください。サイドロードする場合は、配布元だけでなくAPKの署名フィンガープリントも照合するのが出発点です。公開鍵、秘密鍵、署名要求、接続先、保存先、復旧経路を利用者自身が管理し、対応NIPの完了表示と相互接続の実証を分けて判定できる場合に採用してください。

公式情報源

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