SSP Wallet v1.15.0 ouvre grand la porte aux dApps. La version élargit l'API SSP Wallet en une surface généraliste à laquelle n'importe quel site peut parler : demander au portefeuille les informations dont il a besoin et proposer à l'utilisateur les actions qu'il peut offrir, sans jamais toucher aux clés. Ce qui n'était qu'une seule action pay à l'intérieur de SSP Connect devient désormais une vraie plateforme d'intégration, avec une spécification publique dans SSP_Wallet_API.md que les développeurs peuvent attaquer dès aujourd'hui.
De Pay à une API complète
La première version de SSP Connect, livrée avec la v1.1.0, ajoutait exactement une action sortante : pay. Une dApp pouvait demander un paiement sur une chaîne, vers une adresse et pour un montant donné ; le portefeuille gérait la signature sur les deux appareils de l'utilisateur. La portée était volontairement réduite. Elle a permis d'éprouver la frontière — le portefeuille signe, la dApp demande — et nous a donné quelque chose à durcir en conditions réelles.
La v1.15.0 franchit l'étape suivante. Le portefeuille expose maintenant une API plus large qui permet à un site de s'appairer avec un utilisateur SSP, de lire des informations ponctuelles que l'utilisateur approuve explicitement et de demander des actions que le portefeuille prend en charge. Le modèle reste le même : le portefeuille est l'autorité, le site est un appelant, l'utilisateur est celui qui clique sur le bouton vert. La nouveauté est que la surface n'est plus une fonction unique — c'est une interface documentée.
Ce que l'API expose
L'API élargie se concentre sur les éléments dont presque toute dApp a besoin pour être utile à un utilisateur, et sur les actions que le portefeuille peut offrir sans compromettre son modèle de sécurité.
Côté lecture, l'API permet à un site de demander au portefeuille des informations telles que l'identifiant de compte de l'utilisateur connecté, les chaînes prises en charge et les adresses que l'utilisateur accepte de partager avec ce site précis. Il est crucial de comprendre que « demander » ne veut jamais dire « recevoir automatiquement ». Chaque demande de lecture déclenche une invite dans l'interface du portefeuille, et l'utilisateur peut l'accorder, la restreindre ou la refuser.
Côté action, l'API conserve la même frontière que le flux pay d'origine. On peut demander au portefeuille de construire, vérifier et co-signer une transaction ; la dApp ne voit jamais le matériel de signature. Le multisig n'est pas négociable : toute dépense qui touche aux fonds reste signée par les deux moitiés du setup SSP — l'extension de navigateur et la SSP Key sur le téléphone de l'utilisateur — exactement comme pour un envoi initié manuellement. Aucun appel d'API ne permet à un site de contourner ce flux, et aucune « approbation de session » ne transforme le portefeuille en tampon automatique.
Les signatures complètes des méthodes, les schémas de requête et la sémantique des événements vivent dans la spécification SSP_Wallet_API.md, qui fait foi pour les intégrateurs.
Modèle de sécurité
Une API de portefeuille ne vaut que par son modèle de sécurité ; il vaut donc la peine d'être explicite sur ce que la v1.15.0 impose.
Contrôles d'origine. Chaque appel d'API porte l'origine de la page qui le formule, et le portefeuille traite cette origine comme l'identité de l'appelant. Les permissions sont délimitées par origine ; une permission accordée à un site n'est pas une permission accordée à son voisin dans le même navigateur. Si une page malveillante tente de réutiliser la session d'un autre site, la requête est rejetée avant même d'atteindre l'utilisateur.
Approbation explicite de l'utilisateur. Lectures comme actions exigent une invite dans le portefeuille la première fois, et les actions matérielles — tout ce qui signe ou dépense — exigent une nouvelle invite à chaque fois. Le portefeuille n'approuve pas silencieusement des transactions, même pour des sites auxquels l'utilisateur s'est déjà connecté. La dApp ne décide pas de ce qui est « assez fiable ».
La signature reste locale. Ce qui a toujours fait de SSP un portefeuille SSP — la signature locale sur deux appareils et l'absence de tout service distant détenant une clé dépensable non signée — ne change pas. L'API offre au site une voie structurée pour demander une signature au portefeuille ; elle ne lui offre aucune voie pour l'obtenir sans l'utilisateur, ni pour court-circuiter une clé.
L'invariant multisig est celui avec lequel le portefeuille a été lancé dès le premier jour. L'API frappe poliment à la porte ; ce n'est pas un passe-partout.
Construire avec elle
La spécification SSP_Wallet_API.md est le point de départ canonique. Elle décrit les méthodes disponibles, les événements émis par le portefeuille quand l'état change et les codes d'erreur qu'une dApp doit prévoir. Couplez-la aux notes de version de la v1.15.0 sur GitHub pour le contexte complet de ce qui a été livré.
Pour les développeurs venus d'autres écosystèmes, le modèle est familier : appairage par session, permissions indexées par origine, état piloté par événements. Ce qui diffère, c'est ce qui manque : aucune trappe pour approuver toutes les transactions futures d'une dApp, et aucun matériel de clé qui puisse quitter les deux appareils de l'utilisateur.
La suite pour SSP Connect
SSP Connect n'est plus un protocole unique mais un parapluie qui couvre la surface externe du portefeuille. Attendez-vous à davantage de méthodes documentées, plus d'événements et des exemples plus affûtés pour les schémas d'intégration les plus courants. Le but premier n'est pas d'être la plus grosse API de la crypto : c'est d'être la plus ennuyeuse, au meilleur sens du terme — prévisible, bien bornée et conservatrice sur ce qu'un site peut demander au portefeuille.
Si vous construisez quelque chose et que vous voulez parler à SSP, la spécification est la porte.