SSP Wallet v1.15.0 szerzej otwiera drzwi dla dAppów. Wydanie rozszerza API SSP Wallet do uniwersalnej powierzchni, z którą może rozmawiać każda strona: pytać portfel o informacje, których potrzebuje, i proponować użytkownikowi działania, które potrafi obsłużyć — nigdy nie dotykając kluczy. To, co zaczęło się jako pojedyncza akcja pay w ramach SSP Connect, staje się prawdziwą platformą integracyjną z publiczną specyfikacją w SSP_Wallet_API.md, na której deweloperzy mogą już dziś budować.
Od Pay do pełnego API
Pierwsza wersja SSP Connect, wydana z v1.1.0, dodała dokładnie jedną akcję wychodzącą: pay. dApp mogła poprosić o płatność na danym łańcuchu, na dany adres, na daną kwotę; portfel zajmował się przepływem podpisu na dwóch urządzeniach użytkownika. Zakres był celowo wąski. Pozwolił udowodnić granicę — portfel podpisuje, dApp prosi — i dał nam coś, co można było wzmocnić w realnych warunkach.
v1.15.0 robi kolejny krok. Portfel udostępnia teraz szersze API, które pozwala stronie sparować się z użytkownikiem SSP, czytać wybrane informacje za jego wyraźną zgodą oraz prosić o działania, które portfel wspiera. Model pozostaje ten sam: portfel jest autorytetem, strona jest klientem, a użytkownik to ten, kto klika zielony przycisk. Nowe jest to, że powierzchnia nie jest już pojedynczą funkcją — to udokumentowany interfejs.
Co API udostępnia
Rozszerzone API skupia się na rzeczach, które prawie każda dApp musi wiedzieć, aby być użyteczna dla użytkownika portfela, oraz na działaniach, które portfel może oferować bez naruszania swojego modelu bezpieczeństwa.
Po stronie odczytu API pozwala stronie zapytać portfel o informacje, takie jak identyfikator konta podłączonego użytkownika, łańcuchy obsługiwane przez portfel oraz adresy, które użytkownik zgadza się udostępnić tej konkretnej stronie. Kluczowe: „pytać" nigdy nie znaczy „otrzymywać automatycznie". Każde żądanie odczytu wywołuje monit w interfejsie portfela, a użytkownik może je przyznać, ograniczyć albo odrzucić.
Po stronie działań API utrzymuje tę samą granicę co pierwotny przepływ pay. Portfel można poprosić o zbudowanie, przejrzenie i współpodpisanie transakcji; dApp nigdy nie widzi materiału podpisu. Multisig nie podlega negocjacji: każdy wydatek dotykający środków nadal jest podpisywany przez obie połowy zestawu SSP — rozszerzenie przeglądarki i SSP Key w telefonie użytkownika — dokładnie tak, jak przy wysyłce zainicjowanej ręcznie. Nie ma wywołania API, które pozwoliłoby stronie pominąć ten przepływ, ani „zatwierdzenia sesji", które zamieniałoby portfel w automatyczną pieczątkę.
Pełne sygnatury metod, kształty żądań i semantyka zdarzeń żyją w specyfikacji SSP_Wallet_API.md, która jest źródłem prawdy dla integratorów.
Model bezpieczeństwa
API portfela jest warte tyle, ile jego model bezpieczeństwa, więc warto wyraźnie powiedzieć, co wymusza v1.15.0.
Sprawdzanie origin. Każde wywołanie API niesie ze sobą origin strony, która je formułuje, a portfel traktuje ten origin jako tożsamość wywołującego. Uprawnienia mają zakres per origin; uprawnienie przyznane jednej stronie nie jest uprawnieniem przyznanym jej sąsiadowi w tej samej przeglądarce. Jeśli złośliwa strona próbuje wykorzystać sesję innej strony, żądanie zostaje odrzucone, zanim w ogóle dotrze do użytkownika.
Wyraźna zgoda użytkownika. Zarówno odczyty, jak i działania wymagają monitu w portfelu przy pierwszym wystąpieniu, a działania materialne — wszystko, co podpisuje albo wydaje — wymagają świeżego monitu za każdym razem. Portfel nie zatwierdza transakcji po cichu, nawet dla stron, z którymi użytkownik już się łączył. dApp nie decyduje, co jest „wystarczająco zaufane".
Podpisywanie pozostaje lokalne. To, co zawsze czyniło z SSP portfel SSP — podpisywanie lokalnie na dwóch urządzeniach i brak jakiejkolwiek zdalnej usługi trzymającej niepodpisany, lecz nadający się do wydania klucz — nie zmienia się. API daje stronie ustrukturyzowany sposób, by poprosić portfel o podpis; nie daje stronie żadnego sposobu, by uzyskać go bez użytkownika ani by pominąć klucz.
Niezmiennik multisig jest ten sam, z którym portfel wystartował pierwszego dnia. API to grzeczne pukanie do drzwi, a nie klucz uniwersalny.
Budowanie na nim
Specyfikacja SSP_Wallet_API.md jest kanonicznym punktem startu. Opisuje dostępne metody, zdarzenia, które portfel emituje przy zmianach stanu, oraz kody błędów, których dApp powinna się spodziewać. Sparuj to z notatkami wydawniczymi v1.15.0 w GitHubie, aby mieć pełny kontekst tego, co zostało wydane.
Dla deweloperów z innych ekosystemów portfelowych model jest znajomy: parowanie sesyjne, uprawnienia indeksowane per origin, stan sterowany zdarzeniami. Inne jest to, czego brakuje — żadnej „klapki na zatwierdzenie wszystkich przyszłych transakcji", i żadnego materiału klucza, który mógłby opuścić dwa urządzenia użytkownika.
Co dalej z SSP Connect
SSP Connect to już nie pojedynczy protokół, ale parasol nad zewnętrzną powierzchnią portfela. Można się spodziewać większej liczby udokumentowanych metod, większej liczby zdarzeń i ostrzejszych przykładów dla najpopularniejszych wzorców integracji. Pierwszy cel to nie być największym API w krypto: to być najnudniejszym w najlepszym znaczeniu — przewidywalnym, dobrze ograniczonym i konserwatywnym co do tego, o co strona może poprosić portfel.
Jeśli budujesz coś i chcesz porozmawiać z SSP, specyfikacja jest tymi drzwiami.