SSP Wallet v1.15.0 は dApp のための扉を大きく開きます。本リリースは SSP Wallet API を汎用の表面へと拡張し、あらゆるウェブサイトがそれと対話できるようにします。ウォレットに必要な情報を尋ね、ウォレットが提供できるアクションをユーザーに提案する——その間、鍵には一切触れません。かつて SSP Connect 内のたった一つの pay アクションだったものが、いまや本物の統合プラットフォームへ成長し、開発者は公開仕様 SSP_Wallet_API.md をもとに今日からビルドを始められます。
Pay から完全な API へ
SSP Connect の最初のバージョンは v1.1.0 と一緒に出荷され、外向きのアクションをただ一つだけ追加しました。それが pay です。dApp はあるチェーン上で、ある住所宛に、ある金額の支払いを要求でき、ウォレットはユーザーの 2 台のデバイス上で署名フローを処理しました。スコープは意図的に狭く保たれていました。それは境界——ウォレットが署名を所有し、dApp は要求を所有する——を実証し、実戦で硬化させるための素地を私たちに与えました。
v1.15.0 は次の一歩を踏み出します。ウォレットはより広い API を公開し、サイトが SSP ユーザーとペアリングし、ユーザーが明示的に承認した選択的な情報を読み取り、ウォレットが対応するアクションを要求できるようにします。モデルは変わりません。ウォレットが権威、サイトは呼び出し側、緑のボタンを押すのはユーザーです。新しいのは、表面がもはや単一の関数ではなく、文書化されたインターフェイスである点です。
API が公開するもの
拡張された API は、ほぼすべての dApp がウォレットユーザーに対して有用であるために知っておくべきこと、そしてウォレットがそのセキュリティモデルを損なわずに提供できるアクションに焦点を当てています。
読み取り側では、API はサイトに、接続中ユーザーのアカウント識別子、ウォレットが対応するチェーン、そして当該サイトに共有してよいとユーザーが同意したアドレスといった情報を尋ねることを許します。重要なのは、「尋ねる」が「自動的に受け取る」を意味することは決してないという点です。すべての読み取り要求はウォレット UI 内でプロンプトを引き起こし、ユーザーは付与・絞り込み・拒否のいずれかを選べます。
アクション側では、API は元来の pay フローと同じ境界を保ちます。ウォレットにはトランザクションの構築、確認、共同署名を依頼できます。dApp は署名素材を見ることはありません。マルチシグは交渉の余地がありません。資金に触れるあらゆる支出は依然として SSP セットアップの二つの半分——ブラウザ拡張とユーザーの電話上の SSP Key——によって署名され、手動で開始された送付とまったく同じです。サイトにそのフローを回避させる API 呼び出しは存在せず、ウォレットを自動押印に変える「セッション承認」もありません。
完全なメソッドシグネチャ、リクエストの形、イベントの意味論は SSP_Wallet_API.md 仕様に置かれており、これがインテグレーターにとっての真実の源です。
セキュリティモデル
ウォレット API はそのセキュリティモデルの分だけ価値があるので、v1.15.0 が何を強制するかを明示する価値があります。
**Origin チェック。**すべての API 呼び出しは要求元ページの origin を伴い、ウォレットはその origin を呼び出し側の身元として扱います。権限は origin 単位でスコープされます。あるサイトに付与された権限は、同じブラウザ内の隣のサイトに付与された権限ではありません。悪意あるページが他サイトのセッションを再利用しようとした場合、要求はユーザーに到達する前に拒絶されます。
**明示的なユーザー承認。**読み取りもアクションも初回はウォレット内プロンプトを必要とし、実質的なアクション——署名や送金をともなうもの——は毎回新しいプロンプトを必要とします。ウォレットはトランザクションを黙って承認することはなく、ユーザーが過去に接続済みのサイトに対しても同様です。何が「十分に信頼できる」かを dApp が決めることはできません。
**署名はローカルにとどまります。**SSP を SSP ウォレットたらしめている根幹——署名が 2 台のデバイス上でローカルに行われ、リモートサービスが署名済みでないが消費可能な鍵を保持することは決してない——は変わりません。API はサイトにウォレットへ署名を要求する構造化された方法を与えますが、ユーザー抜きでそれを取得する方法や、鍵を一つ飛ばす方法は一切与えません。
マルチシグの不変条件は、ウォレットがリリース初日に持っていた不変条件と同じです。API は丁寧にドアをノックする来客であって、合鍵ではありません。
それに対して構築する
仕様 SSP_Wallet_API.md が標準の出発点です。利用可能なメソッド、状態が変わった際にウォレットが発するイベント、そして dApp が想定すべきエラーコードが記述されています。v1.15.0 の GitHub リリースノートと併せて読むと、何が出荷されたかの全体像が掴めます。
他のウォレットエコシステムから来る開発者には、モデルは見覚えのあるものです。セッションベースのペアリング、origin で索引付けられた権限、イベント駆動の状態。違うのは「ないもの」です——dApp の将来の全トランザクションを一括承認する「裏口」もなく、ユーザーの 2 台のデバイスを離れることのできる鍵素材も存在しません。
SSP Connect の次
SSP Connect はもはや単一のプロトコルというより、ウォレットの外向き表面の上にかかる傘です。今後はもっと文書化されたメソッド、もっと多くのイベント、もっとも一般的な統合パターンに対するより鋭い例を期待してください。一番の目標は暗号領域で最大の API になることではなく、最良の意味で「最も退屈」な API になることです——予測可能で、スコープが整い、サイトがウォレットに何を要求できるかについて保守的であること。
何かを構築していて SSP と対話したいなら、仕様こそがその扉です。