SSP Wallet v1.15.0 öffnet dApps die Tür. Das Release erweitert die SSP Wallet API zu einer allgemeinen Oberfläche, mit der jede Website sprechen kann: die Wallet nach Informationen fragen, dem Nutzer Aktionen anbieten — und dabei niemals Schlüssel berühren. Was als einzelne pay-Aktion innerhalb von SSP Connect begann, wird zur echten Integrationsplattform, mit einer öffentlichen Spezifikation in SSP_Wallet_API.md, gegen die Entwickler heute schon bauen können.
Von Pay zur vollständigen API
Die erste Version von SSP Connect, ausgeliefert mit v1.1.0, brachte genau eine ausgehende Aktion: pay. Eine dApp konnte eine Zahlung auf einer Chain, an eine Adresse, über einen Betrag anfragen; die Wallet übernahm den Signaturablauf auf den zwei Geräten des Nutzers. Das war bewusst eng gefasst. Es belegte die Grenze — die Wallet signiert, die dApp fragt — und gab uns etwas zum Härten im Realbetrieb.
v1.15.0 geht den nächsten Schritt. Die Wallet stellt nun eine breitere API bereit, mit der eine Website sich mit einem SSP-Nutzer koppeln, ausgewählte Informationen lesen kann, denen der Nutzer ausdrücklich zustimmt, und Aktionen anfordern kann, die die Wallet unterstützt. Das Modell bleibt dasselbe: die Wallet ist die Autorität, die Website ist Anruferin, der Nutzer drückt den grünen Knopf. Neu ist, dass die Oberfläche nicht mehr eine einzelne Funktion ist — sie ist eine dokumentierte Schnittstelle.
Was die API freigibt
Die erweiterte API konzentriert sich auf das, was nahezu jede dApp wissen muss, um für einen Wallet-Nutzer nützlich zu sein, und auf Aktionen, die die Wallet anbieten kann, ohne ihr Sicherheitsmodell zu kompromittieren.
Auf der Leseseite kann eine Website die Wallet nach Informationen wie der Account-Kennung des verbundenen Nutzers, den unterstützten Chains und den Adressen fragen, die der Nutzer mit dieser speziellen Seite teilen möchte. Entscheidend: „Fragen" heißt nie „automatisch erhalten". Jede Lese-Anfrage löst einen Hinweis in der Wallet-Oberfläche aus, und der Nutzer kann zustimmen, einschränken oder ablehnen.
Auf der Aktionsseite hält die API dieselbe Grenze wie der ursprüngliche pay-Ablauf. Die Wallet kann gebeten werden, eine Transaktion zu bauen, zu prüfen und mitzusignieren; die dApp sieht niemals Signaturmaterial. Multisig ist nicht verhandelbar: jede Ausgabe, die Mittel berührt, wird weiterhin von beiden Hälften des SSP-Setups signiert — der Browser-Erweiterung und dem SSP Key auf dem Telefon des Nutzers — genau wie bei einem manuell angestoßenen Versand. Es gibt keinen API-Aufruf, der einer Website erlaubt, diesen Ablauf zu umgehen, und keine „Session-Freigabe", die die Wallet in einen automatischen Stempel verwandelt.
Vollständige Methoden-Signaturen, Anfrage-Strukturen und Event-Semantik liegen in der Spezifikation SSP_Wallet_API.md, die die Quelle der Wahrheit für Integratoren ist.
Sicherheitsmodell
Eine Wallet-API taugt nur so viel wie ihr Sicherheitsmodell — also lohnt es, explizit zu sein, was v1.15.0 erzwingt.
Origin-Prüfungen. Jeder API-Aufruf trägt den Origin der aufrufenden Seite mit sich, und die Wallet behandelt diesen Origin als Identität des Anrufers. Berechtigungen sind je Origin gescoped; eine Berechtigung, die einer Seite erteilt wurde, ist keine Berechtigung für ihren Nachbarn im selben Browser. Versucht eine bösartige Seite, die Session einer anderen Seite zu übernehmen, wird die Anfrage abgelehnt, bevor sie den Nutzer erreicht.
Ausdrückliche Nutzer-Zustimmung. Lese- wie Aktions-Anfragen brauchen beim ersten Mal einen Wallet-Prompt, und materielle Aktionen — alles, was signiert oder ausgibt — verlangen jedes Mal einen frischen Prompt. Die Wallet stimmt Transaktionen niemals stillschweigend zu, auch nicht für Seiten, mit denen sich der Nutzer schon verbunden hat. Die dApp entscheidet nicht, was „vertrauenswürdig genug" ist.
Signieren bleibt lokal. Was SSP immer zu einer SSP-Wallet gemacht hat — dass das Signieren lokal auf zwei Geräten passiert und kein Remote-Dienst je einen unsignierten, aber ausgabefähigen Schlüssel hält — ändert sich nicht. Die API gibt einer Website einen strukturierten Weg, die Wallet um eine Signatur zu bitten; sie gibt der Website keinen Weg, eine zu bekommen ohne den Nutzer oder einen Schlüssel zu überspringen.
Die Multisig-Invariante ist dieselbe, mit der die Wallet am Tag eins gestartet ist. Die API klopft höflich an die Tür; sie ist kein Generalschlüssel.
Dagegen bauen
Die Spezifikation SSP_Wallet_API.md ist der kanonische Startpunkt. Sie beschreibt die verfügbaren Methoden, die Events, die die Wallet bei Statuswechseln aussendet, und die Fehlercodes, mit denen eine dApp rechnen sollte. Kombinieren Sie sie mit den Release Notes zur v1.15.0 auf GitHub, um den vollen Kontext zu bekommen.
Für Entwickler aus anderen Wallet-Ökosystemen ist das Modell vertraut: Session-basiertes Pairing, Origin-indizierte Berechtigungen, Event-getriebener Zustand. Anders ist, was fehlt — keine „Hintertür", um alle künftigen Transaktionen einer dApp pauschal zu genehmigen, und kein Schlüsselmaterial, das die beiden Geräte des Nutzers verlässt.
Wie es mit SSP Connect weitergeht
SSP Connect ist weniger ein einzelnes Protokoll als ein Schirm über der nach außen gerichteten Wallet-Oberfläche. Erwarten Sie mehr dokumentierte Methoden, mehr Events und schärfere Beispiele für die häufigsten Integrationsmuster. Das erste Ziel ist nicht, die größte API in Krypto zu sein, sondern die langweiligste im besten Sinn: berechenbar, eng gefasst und konservativ darin, was eine Website von der Wallet verlangen darf.
Wenn Sie etwas bauen und mit SSP sprechen wollen, ist die Spezifikation die Tür.