Dusk Connect において最も重要な言葉は「discover」だと思います。

Dusk Network は、開発者プレビューとして SDK を公開し、ブラウザ dApp が互換性のあるウォレットを見つけ、プロフィールへのアクセスを要求し、選択したネットワークを追跡し、ユーザーが承認したトランザクションを送信できるようにしました。これは、特定の 1 つの拡張機能にハードコードするのではなく、共有プロバイダーパターンに従っています。

それはフロントエンドの配管のようなものです。でも、それはエコシステムの意思決定だと思います。

すべてのアプリケーションが 1 つのウォレットを直接統合すると、そのウォレットは非公式の門番になります。競合するウォレットがプロトコルをサポートできたとしても、各 dApp にはカスタム作業が必要になるため、ユーザーには見えないままになり得ます。Dusk Connect は、その選択をディスカバリ層に移します。アプリケーションは利用可能なプロバイダーは何かを尋ね、ユーザーが選びます。

SDK はフレームワークに非依存で、型付きで、実行時の依存関係がありません。これらの詳細は、統合の摩擦を減らします。ただし、2 つのウォレットが権限、秘匿アドレス、署名、ネットワーク変更をまったく同じ解釈で扱うことを保証するわけではありません。

だからこそ、私は洗練された「接続」ボタンよりも適合性テスト（conformance tests）のほうを重視しています。

Dusk は共通のインターフェースを公開できますが、インターフェースが標準になるのは、独立したウォレットがそれを一貫して実装したときです。接続は成功するのに、その後のプロフィール変更の扱いが異なるプロバイダーは、アプリケーションのバグに見える失敗を生みかねません。

私は 3 つのシグナルを見ています。同じフローで発見される、プロダクションに対応した別のウォレット。コアメソッドにまたがる公開された互換性結果。そして、カスタムのブランチなしでプロバイダーを切り替える dApp です。

これらが現れれば、Dusk Connect はウォレットへのアクセスを簡単にする以上のことを実現したことになります。Dusk のアプリケーション層を、単一のウォレット実装への依存から切り離すことができるからです。

本当の試験は、最初の（第一者の）ウォレットが接続できるかどうかではありません。次のウォレットが、すべての Dusk 開発者に許可を求めることなく到来できるかどうかです。

#dusk $DUSK @Dusk