Skip to main content
Chat XDK は、X Chat の鍵管理、暗号化、復号、および署名を処理します。X の HTTP API は呼び出しませんPython または TypeScriptXDK、あるいは HTTPS とユーザーアクセストークンと組み合わせて使用してください。 アプリのウォークスルー: Getting Started。サンプルボット: chat-xdk/examples

インストール

PyPI パッケージは chatxdk です。chat_xdk としてインポートします。Python 3.10+ が必要です。

クイックスタート

バックログを復号し、鍵をキャッシュし、1 つのイベントを復号し、返信を暗号化します。Getting Started のように、送信ボディを POST /2/chat/conversations/{id}/messages に接続します。

ライフサイクルと鍵

SDK を構築し、秘密鍵を保存し(パスコード保護された安全な鍵バックアップまたはローカル鍵 blob)、公開鍵を Chat API に登録し、アンロックまたはインポート後に登録済みの公開鍵バージョンを設定します。安全な鍵バックアップは Juicebox で実装されており、関連する設定フィールドがその名前を持つのはこのためです。デバイス/アプリ ID ごとに generate_keypairs を 1 回呼び出します;登録ペイロードを公開鍵エンドポイントに投稿します。すべてのバインディングで安全な鍵バックアップには setup / unlock(および関連するパスコードヘルパー)を使用します。export_keys / import_keys(ボットとサーバー用の未加工鍵 blob 永続化)は、ネイティブバインディングのみ — Python、Go、.NET、JVM、Rust — で利用できます。JS/WASM バインディングは未加工の鍵のエクスポートやインポートを公開しません: ブラウザではインスタンスに到達するスクリプトは identity を流出できるため、JS は鍵を安全な鍵バックアップ内に保持します。リクエストごとのバックアップ realm ラウンドトリップを避けたい JS サーバーは、リクエスト間で 1 つのアンロック済み Chat インスタンスを再利用するか、鍵 blob がサポートされているネイティブバインディングを実行するべきです。
安全な鍵バックアップ設定は 3 つの形を受け付けます: X API の juicebox_config オブジェクト(推奨 — そのまま渡す)、完全な sdk_config ラッパー、または裸の token_map オプション: 署名検証はデフォルトで有効reject_unverified = true)— 無効にするには set_reject_unverified(false) を呼び出します(推奨されません);バックアップ realm 設定が変更された場合は update_config;UI 状態には is_unlocked / has_identity_key。完全なフィールドリストは chat-xdk リポジトリ のスタブにあります。

会話鍵

3 つの prepare メソッドは、それぞれ 1 回の呼び出しで鍵変更に必要なすべて(新しい会話鍵の生成、渡された公開鍵からすべての参加者向けに暗号化、変更への署名)を行います。すべて同じ PreparedConversationChange 形を返し、POST の準備が整います — SDK フィールドの encrypted_keyconversation_participant_keys の中で encrypted_conversation_key に名前を変え、アクション署名を必須の action_signatures ボディフィールドにマップしてください。 未加工の鍵バイトを encrypt_message およびメディア用に保持してください;API の暗号化エンベロープを encrypt に渡してはいけません。
ラップする前に取得した鍵を検証してください。 prepare メソッドは、渡された任意の公開鍵に対して新しい会話鍵を暗号化します。渡す前に、各取得済みレコードに対して verify_key_binding(identity, signing, signature) を呼び出してください — public-keys API のレコードの public_keysigning_public_keyidentity_public_key_signature フィールド — 置き換えられた identity 鍵が会話鍵を受け取れないようにするためです。
鍵変更イベントペイロードで extract_conversation_keys を使い、{ keys, latest_version } を再構築します。decrypt_conversation_key は単一の ECIES blob をアンラップします。
グループの作成とメンバー追加については、各メソッドが必要とするパラメータを渡します(prepare_group_create にはメンバー/管理者 ID リスト;prepare_group_members_change には新規プラス現在のロスター) — サンプルは Groups を参照してください。両方とも2 つのアクション署名を返します;POST には両方含める必要があります。

復号

decrypt_events は履歴とバックログ用です: ストリームから会話鍵を取り出し、復号済みメッセージを返し、バッチ全体を失敗させる代わりにイベントごとのエラーを収集します。decrypt_event は、鍵キャッシュをすでに持っている場合の単一のライブイベント用です。失敗時に raise/throw します。 送信者を SDK が検証できるように署名鍵を渡します。API の公開鍵フィールドを SigningKeyEntry にマップします: public_key_versionpublic_key_version(同じ名前)、signing_public_keypublic_keypublic_keyidentity_public_key、加えて identity_public_key_signatureuser_id。検証はデフォルトで必須です: 空の署名鍵リストを省略または渡してもスキップされません — 署名付きイベントは失敗します(decrypt_events では errors に収集され、decrypt_event ではスローされます)。実際に検証をスキップするには、まず set_reject_unverified(false) を呼び出す必要があります(本番環境では推奨されません)。

暗号化と送信ヘルパー

encrypt_message は、テキストメッセージ用の署名済み暗号文を構築します(オプションの entities、media_hash_key 経由の attachments、TTL、通知フラグ)。返されたペイロードを送信メッセージボディにマップします: encrypted_contentencoded_message_create_eventencoded_event_signatureencoded_message_event_signature、および message_id 返信とリアクション(sequence_id は親をターゲットにします)には、encrypt_replyencrypt_add_reaction、および encrypt_remove_reaction を使用します。encrypt / decrypt は、会話鍵の下での UTF-8 メタデータ(たとえば暗号化されたグループ名)用です — メッセージエンベロープ用ではありません。encrypt_stream / decrypt_stream は添付バイトを暗号化します;Media を参照してください。低レベルの sign / verify / verify_key_binding は高度なフローをサポートします;会話鍵の変更、グループの作成、およびメンバーの追加は prepare メソッド によって署名されます。 encrypt_message / encrypt_reply に渡す会話 ID は、保持している任意の形式で構いません — イベントからの A:B、リストや URL パスからの A-B(どちらの順序でも)、または受信者のユーザー ID だけ — SDK は署名する前に正規化します。グループ ID(g プレフィックス付き)はそのまま渡されます。

メディアストリーム

テキストに使用されたものと同じ会話鍵でファイルバイトを暗号化し、Chat メディア API 経由でアップロードし、encrypt_messagemedia_hash_key を添付します。これは Posts メディアモデル(expansions=attachments.media_keys)ではありません。完全なアップロード/ダウンロードフロー: Media

大きなメディア向けのインクリメンタルストリーミング

大きなファイルの場合、ペイロード全体をメモリに保持しないでください: stream_encryptor() / stream_decryptor() は、StreamEncryptor / StreamDecryptor を返します。push(chunk) でチャンク(約 1 MB ずつ)を供給し、最後に finish() を 1 回呼び出します。復号では、finish() は切り詰められたストリームを検出します(最終フレームより前に入力が終わった場合は失敗します)ので、成功するまでプッシュされた平文を完全なものとして扱わないでください。
JS/WASM のみ: finish() は基になる WASM オブジェクトを消費して解放します — finish() の後には決して free() を呼び出さないでください(例外がスローされます)。free() は、finish の前にストリームを放棄する場合(たとえばエラーパス)にのみ呼び出してください。

ユーティリティ

Base64/hex ヘルパー、MIME スニッフィング、および画像寸法は、モジュールレベルの関数(Python/JS/Rust/Go)または ChatXdkUtilities(C#/Java)として利用できます — 追加のライブラリを取り込まずに添付メタデータを構築するときに便利です。

重要な型

これらの概念的な型は、複数の言語にわたって現れます(正確なフィールド名は異なります;JS では message のように camelCase のイベント識別子を使うことが多いです):
  • SendPayloadencrypt_message および関連する暗号化ヘルパーの戻り値;Chat API 送信ボディにマップします。
  • PublicKeyRegistrationPayload — add-public-key API 用の generate_keypairs / 公開鍵ゲッターの出力。
  • SigningKeyEntry — 署名検証のために decrypt に渡される送信者の公開素材。
  • PreparedConversationChange — 3 つの prepare メソッドの出力: 導出されたまたは渡された conversation_id、未加工の conversation_key バイト、conversation_key_versionparticipant_keysuser_idencrypted_keypublic_key_version)、および action_signaturesmessage_idencoded_message_event_detailsignaturesignature_versionpublic_key_version、オプションの signature_payload — そのペイロードが平文の鍵を埋め込むため鍵変更署名では省略されます)。
  • DecryptEventsResult — メッセージ、オプションのエラー、抽出された conversation_keys
完全なフィールドリストについては、chat-xdk リポジトリ の言語スタブ(docs/API.md*.pyiindex.d.ts)を使用してください。

エラー

Python は通常、記述的なメッセージ(たとえば無効なパスコード)で ValueError を発生させます。TypeScript/JavaScript は Error をスローします。Go は (value, error) を返します。履歴には decrypt_events を優先してください、そうすれば 1 つの不良イベントがバッチを中止しません;部分的な失敗については errors コレクションを検査してください。 一部の検証エラーは恒久的です。署名は不変であり、イベント自体から署名済みペイロードを再構築することで検証されるため、signature missing or no matching signing key または ECDSA の不一致で失敗する古いイベントは、将来のすべてのロードで失敗します — 再試行、鍵の更新、または API 呼び出しでは治せません。これらは一時的なエラーではなく、トゥームストーンとして扱ってください。会話鍵をローテーションすると、その時点からクリーンで検証可能な履歴が始まります。

次のステップ

Getting Started

Chat XDK を Chat API に接続する

Media

ストリーム暗号化とメディア REST

Real-time events

Webhook とアクティビティ配信

Troubleshooting

よくある失敗