Fast im Changelog daran vorbeigerutscht: null Laufzeitabhängigkeiten. Unter größeren Überschriften zur SDK-Launch vergraben.
Leicht zu lesen: Dusk Connect macht die Wallet-Anbindung für Entwickler einfach. Genau, das ist der Pitch: ein schlankes SDK, einstecken, fertig.
Wenn man es etwas länger wirken lässt, geht es aber vor allem darum, wer die Connection-Layer besitzt. Dusk nutzt ein ereignisbasiertes Discovery-Muster: `dusk:announceProvider`, `dusk:requestProvider`, direkt nach dem Vorbild von Ethereums EIP-6963. Statt dass eine dApp um eine einzige Wallet herum fest verdrahtet ist, sendet sie eine Anfrage und lässt jede kompatible Wallet antworten. Die dApp muss nie wissen, welche Wallet gewinnt.
Was dabei übergangen wird: Discovery zu standardisieren bedeutet nicht, Vertrauen zu standardisieren. Jede Erweiterung kann auf dieses Request-Event lauschen und sich selbst als Provider ankündigen. EIP-6963 hat Ethereums altes window.ethereum-Rennproblem gelöst, aber es hat keine Wallet-Impersonation gelöst – es hat nur die Last, zu prüfen, welche Provider legitim sind, auf den Nutzer verlagert, jeweils in einer einzigen Verbindungsanfrage.
Derselbe Trade-off zeigt sich auch im klassischen Finanzwesen. Open-Banking-APIs haben standardisiert, wie Drittanbieter-Apps den Zugriff auf Konten anfragen, aber ein standardisiertes Anfrageformat hat nie garantiert, dass der Anfragende sicher ist – Banken schichten genau aus diesem Grund weiterhin separate Zustimmungs- und Verifikationsbildschirme darüber.
Mein erster Eindruck war: Zero Dependencies heißt einfach nur ein schlankeres Setup. Das ist mehr als das: Weniger Abhängigkeiten bedeutet auch weniger Stellen, an denen sich ein Supply-Chain-Compromise verstecken kann, und weniger Ausreden, falls doch einmal etwas durchrutscht.
Würdest du lieber sehen, dass Dusk als Nächstes stärker darauf fokussiert, dass mehr Wallet-Provider das übernehmen, oder darauf, dass dApps robuster prüfen, mit welchem Provider sie tatsächlich sprechen?
@Dusk #dusk $DUSK
Leicht zu lesen: Dusk Connect macht die Wallet-Anbindung für Entwickler einfach. Genau, das ist der Pitch: ein schlankes SDK, einstecken, fertig.
Wenn man es etwas länger wirken lässt, geht es aber vor allem darum, wer die Connection-Layer besitzt. Dusk nutzt ein ereignisbasiertes Discovery-Muster: `dusk:announceProvider`, `dusk:requestProvider`, direkt nach dem Vorbild von Ethereums EIP-6963. Statt dass eine dApp um eine einzige Wallet herum fest verdrahtet ist, sendet sie eine Anfrage und lässt jede kompatible Wallet antworten. Die dApp muss nie wissen, welche Wallet gewinnt.
Was dabei übergangen wird: Discovery zu standardisieren bedeutet nicht, Vertrauen zu standardisieren. Jede Erweiterung kann auf dieses Request-Event lauschen und sich selbst als Provider ankündigen. EIP-6963 hat Ethereums altes window.ethereum-Rennproblem gelöst, aber es hat keine Wallet-Impersonation gelöst – es hat nur die Last, zu prüfen, welche Provider legitim sind, auf den Nutzer verlagert, jeweils in einer einzigen Verbindungsanfrage.
Derselbe Trade-off zeigt sich auch im klassischen Finanzwesen. Open-Banking-APIs haben standardisiert, wie Drittanbieter-Apps den Zugriff auf Konten anfragen, aber ein standardisiertes Anfrageformat hat nie garantiert, dass der Anfragende sicher ist – Banken schichten genau aus diesem Grund weiterhin separate Zustimmungs- und Verifikationsbildschirme darüber.
Mein erster Eindruck war: Zero Dependencies heißt einfach nur ein schlankeres Setup. Das ist mehr als das: Weniger Abhängigkeiten bedeutet auch weniger Stellen, an denen sich ein Supply-Chain-Compromise verstecken kann, und weniger Ausreden, falls doch einmal etwas durchrutscht.
Würdest du lieber sehen, dass Dusk als Nächstes stärker darauf fokussiert, dass mehr Wallet-Provider das übernehmen, oder darauf, dass dApps robuster prüfen, mit welchem Provider sie tatsächlich sprechen?
@Dusk #dusk $DUSK
