SSP Wallet v1.15.0 шире открывает дверь для dApp. Релиз расширяет SSP Wallet API в универсальную поверхность, с которой может разговаривать любой сайт: запросить у кошелька нужную информацию и предложить пользователю те действия, которые кошелёк готов выполнить — не прикасаясь к ключам. То, что начиналось как одно действие pay внутри SSP Connect, превращается в полноценную платформу интеграции с публичной спецификацией в SSP_Wallet_API.md, против которой разработчики могут начинать строить уже сегодня.
От Pay к полноценному API
Первая версия SSP Connect, выпущенная вместе с v1.1.0, добавила ровно одно исходящее действие: pay. dApp могло запросить платёж в указанной сети, на указанный адрес, на указанную сумму; кошелёк брал на себя процесс подписи на двух устройствах пользователя. Сужение было намеренным. Оно подтвердило границу — кошелёк подписывает, dApp просит — и дало нам нечто, что можно было укрепить в реальных условиях.
v1.15.0 делает следующий шаг. Кошелёк теперь предоставляет более широкое API, которое позволяет сайту спариться с пользователем SSP, читать выборочную информацию, на которую пользователь явно даёт согласие, и запрашивать действия, поддерживаемые кошельком. Модель прежняя: кошелёк — авторитет, сайт — вызывающий, пользователь — тот, кто нажимает на зелёную кнопку. Новое в том, что поверхность больше не одна функция — это документированный интерфейс.
Что раскрывает API
Расширенное API сосредоточено на тех вещах, которые почти всякому dApp нужно знать, чтобы быть полезным пользователю кошелька, и на тех действиях, которые кошелёк может предлагать, не подрывая свою модель безопасности.
На стороне чтения API позволяет сайту запросить у кошелька информацию вроде идентификатора аккаунта подключённого пользователя, поддерживаемых сетей и адресов, которыми пользователь согласен поделиться именно с этим сайтом. Главное: «запросить» никогда не означает «автоматически получить». Каждый запрос на чтение поднимает уведомление в интерфейсе кошелька, и пользователь может его удовлетворить, сузить или отклонить.
На стороне действий API сохраняет ту же границу, что и исходный поток pay. Кошелёк можно попросить сконструировать, проверить и сопровождая подписать транзакцию; dApp никогда не видит подписного материала. Мультиподпись не подлежит обсуждению: каждое расходование, которое касается средств, по-прежнему подписывается обеими половинами установки SSP — расширением браузера и SSP Key на телефоне пользователя — ровно так же, как при отправке, инициированной вручную. Нет вызова API, который позволил бы сайту обойти этот поток, и нет «одобрения сессии», которое превращало бы кошелёк в автомат-штамп.
Полные сигнатуры методов, формы запросов и семантика событий живут в спецификации SSP_Wallet_API.md, и она — источник истины для интеграторов.
Модель безопасности
API кошелька стоит ровно столько, сколько стоит его модель безопасности, поэтому стоит явно сказать, что именно навязывает v1.15.0.
Проверки origin. Каждый вызов API несёт origin страницы, которая его делает, и кошелёк относится к этому origin как к идентичности вызывающего. Разрешения ограничены по origin; разрешение, выданное одному сайту, не является разрешением для его соседа в том же браузере. Если вредоносная страница пытается переиспользовать сессию другого сайта, запрос отклоняется ещё до того, как доходит до пользователя.
Явное согласие пользователя. И чтения, и действия требуют уведомления в кошельке при первом появлении, а материальные действия — всё, что подписывает или тратит — требуют свежего уведомления каждый раз. Кошелёк не одобряет транзакции молча, даже для сайтов, к которым пользователь уже подключался. dApp не решает, что «достаточно доверено».
Подпись остаётся локальной. То, что всегда делало SSP именно SSP-кошельком — что подписание происходит локально на двух устройствах и что ни один удалённый сервис никогда не держит неподписанный, но расходуемый ключ — не меняется. API даёт сайту структурированный способ попросить у кошелька подпись; оно не даёт сайту никакого способа получить её без пользователя или обойти ключ.
Инвариант мультиподписи — тот же, с которым кошелёк стартовал в день первый. API — это вежливый стук в дверь, а не отмычка.
Как строить против него
Спецификация SSP_Wallet_API.md — каноническое место, с которого нужно начинать. Она описывает доступные методы, события, которые кошелёк испускает при смене состояния, и коды ошибок, которых должно ожидать dApp. Соедините её с заметками к выпуску v1.15.0 на GitHub, чтобы получить полный контекст релиза.
Для разработчиков из других кошельковых экосистем модель знакома: парование на основе сессий, разрешения, индексированные по origin, состояние, управляемое событиями. Отличается то, чего нет — нет «лаза» для одобрения всех будущих транзакций для одного dApp и нет ключевого материала, который мог бы покинуть два устройства пользователя.
Что дальше для SSP Connect
SSP Connect теперь не столько единственный протокол, сколько зонтик над внешней поверхностью кошелька. Ожидайте больше документированных методов, больше событий и более тонкие примеры для самых распространённых сценариев интеграции. Первая цель — не стать самым большим API в крипто; стать самым скучным в лучшем смысле слова — предсказуемым, чётко ограниченным и консервативным в том, что сайту разрешено просить у кошелька.
Если вы что-то строите и хотите поговорить с SSP, спецификация — это и есть дверь.