昨晚私は書斎でコンピューターを開き、Dusk Connect のサンプルを初めて見たときに availableProviders[0] が出てきて、思わず驚いて手が止まりました。複数の対応ウォレットが同時に見つかり、かつ providerId がない場合、コードは最初のウォレットを選び出せます。一方でプロダクト側への提案としては、同じページでユーザーにウォレット選択を委ねるべきだと考えています。
私は当初、provider discovery を適応作業を省ける技術的な利便性だと思っていました。でも今は、それがとても具体的な権限の配分でもあると感じています。dApp がユーザーの最初のウォレットを決めるのか、それとも署名前に選択をユーザー側へ残すのか、という点です。ウォレットチームにとっては、オープンな発見によって特定の拡張が入口としてハードコードされるのを回避できます。一方、ユーザーにとって重要なのは、現在選択されているウォレット、ネットワーク、アカウントが自分で見えているかどうかです。
悪いシナリオは大げさではありません。ブラウザには対応ウォレットが2つ入っていて、1つはメインネット資産、もう1つはテスト用やチーム用のアカウントです。あるアプリが手間を省こうとして最初のものを自動で選んだため、ユーザーは署名ページまで進んで初めて口座が違うことに気づくのです。取引が拒否されるならまだ幸運ですが、最悪なのは、間違った環境で、本来行うべきでない権限付与をユーザーが完了してしまい、後になって覚えているのが「Dusk ウォレットを間違って繋いだ」という一言だけ、というケースです。コストはユーザーとサポートが負担し、自動選択した側はたいてい現場にいません。
だから私は、Dusk Connect のマルチウォレット発見を単なるインターフェース能力だとは捉えなくなりました。@Dusk が本当に守るべきものは、発見のあとにその選択権がユーザーの手の中に残っているかどうかです。$DUSK のようなアプリが増えるほど、私は接続画面で provider、ネットワーク、アカウントがはっきり表示され、自動選択が行われる場合でもユーザーが選び直せる“見える余地”が提示されるのをもっと見たいと思っています。#dusk