SSP Wallet v1.15.0 spalanca la porta alle dApp. Il rilascio amplia l'API di SSP Wallet trasformandola in una superficie generalista con cui qualsiasi sito può dialogare: chiedere al portafoglio le informazioni di cui ha bisogno e proporre all'utente le azioni che può offrire — senza mai toccare le chiavi. Quella che era una singola azione pay all'interno di SSP Connect diventa ora una vera piattaforma di integrazione, con una specifica pubblica in SSP_Wallet_API.md su cui gli sviluppatori possono lavorare da oggi.
Da Pay a un'API completa
La prima versione di SSP Connect, spedita con la v1.1.0, aggiungeva esattamente un'azione in uscita: pay. Una dApp poteva richiedere un pagamento su una catena, verso un indirizzo, per un importo dato; il portafoglio gestiva il flusso di firma sui due dispositivi dell'utente. La portata era volutamente limitata. È servita a dimostrare il confine — il portafoglio firma, la dApp chiede — e ci ha dato qualcosa da indurire sul campo.
La v1.15.0 fa il passo successivo. Il portafoglio espone ora un'API più ampia che permette a un sito di abbinarsi a un utente SSP, di leggere informazioni selettive che l'utente approvi esplicitamente e di richiedere azioni supportate dal portafoglio. Il modello rimane lo stesso: il portafoglio è l'autorità, il sito è un chiamante, l'utente è chi preme il bottone verde. La novità è che la superficie non è più una singola funzione: è un'interfaccia documentata.
Cosa espone l'API
L'API ampliata si concentra sulle cose che quasi ogni dApp deve sapere per essere utile a un utente e sulle azioni che il portafoglio può offrire senza compromettere il proprio modello di sicurezza.
Sul lato lettura, l'API consente a un sito di chiedere al portafoglio informazioni come l'identificativo dell'account dell'utente connesso, le catene supportate e gli indirizzi che l'utente accetti di condividere con quel sito specifico. È cruciale capire che «chiedere» non significa mai «ricevere in automatico». Ogni richiesta di lettura apre un prompt nell'interfaccia del portafoglio e l'utente può concederla, restringerla o rifiutarla.
Sul lato azione, l'API mantiene lo stesso confine del flusso pay originale. Si può chiedere al portafoglio di costruire, revisionare e co-firmare una transazione; la dApp non vede mai materiale di firma. La multifirma non è negoziabile: ogni spesa che tocca i fondi resta firmata da entrambe le metà del setup SSP — l'estensione del browser e la SSP Key sul telefono dell'utente — esattamente come accade per un invio avviato a mano. Non esiste chiamata API che permetta a un sito di saltare quel flusso, né «approvazione di sessione» che trasformi il portafoglio in un timbro automatico.
Firme complete dei metodi, formati delle richieste e semantica degli eventi vivono nella specifica SSP_Wallet_API.md, che è la fonte di verità per chi integra.
Modello di sicurezza
Un'API per portafogli vale quanto vale il suo modello di sicurezza, quindi vale la pena essere espliciti su ciò che la v1.15.0 impone.
Controlli di origine. Ogni chiamata API porta con sé l'origine della pagina che la fa, e il portafoglio tratta tale origine come l'identità del chiamante. I permessi hanno scope per origine; un permesso concesso a un sito non è un permesso concesso al suo vicino nello stesso browser. Se una pagina malevola prova a riusare la sessione di un altro sito, la richiesta viene rifiutata prima ancora di arrivare all'utente.
Approvazione esplicita dell'utente. Sia le letture sia le azioni richiedono un prompt nel portafoglio la prima volta che avvengono, e le azioni materiali — qualsiasi cosa che firmi o spenda — richiedono un prompt nuovo ogni volta. Il portafoglio non approva transazioni silenziosamente, nemmeno per siti a cui l'utente si è già connesso. La dApp non decide cosa sia «abbastanza affidabile».
La firma rimane locale. Ciò che ha sempre reso SSP un portafoglio SSP — la firma locale su due dispositivi e l'assenza di qualunque servizio remoto che detenga una chiave non firmata ma spendibile — non cambia. L'API offre al sito un modo strutturato di chiedere una firma al portafoglio; non offre al sito alcun modo di ottenerla senza l'utente né di saltare una chiave.
L'invariante di multifirma è lo stesso con cui il portafoglio è stato lanciato il giorno uno. L'API è qualcuno che bussa educatamente alla porta, non una chiave di servizio.
Costruire contro di essa
La specifica SSP_Wallet_API.md è il punto canonico da cui partire. Descrive i metodi disponibili, gli eventi che il portafoglio emette quando lo stato cambia e i codici di errore che una dApp deve aspettarsi. Abbina la lettura alle note di rilascio della v1.15.0 su GitHub per il contesto completo di cosa è stato spedito.
Per chi arriva da altri ecosistemi di portafogli, il modello è familiare: abbinamento per sessione, permessi indicizzati per origine, stato guidato da eventi. La differenza è ciò che manca: niente «trappola» per approvare tutte le transazioni future di una dApp e nessun materiale di chiave che possa uscire dai due dispositivi dell'utente.
Cosa c'è dopo per SSP Connect
SSP Connect smette di essere un singolo protocollo e diventa un ombrello sulla superficie esterna del portafoglio. Aspettatevi più metodi documentati, più eventi ed esempi più affilati per i pattern di integrazione più comuni. Il primo obiettivo non è essere l'API più grande della cripto: è essere la più noiosa, nel senso migliore del termine — prevedibile, ben delimitata e conservativa su ciò che un sito può chiedere al portafoglio.
Se stai costruendo qualcosa e vuoi parlare con SSP, la specifica è la porta.