SSP Wallet v1.15.0 abre la puerta a las dApps. La versión amplía la API de SSP Wallet hasta convertirla en una superficie de propósito general con la que cualquier sitio web puede dialogar: pedirle a la cartera la información que necesita y proponerle al usuario las acciones que puede ofrecer, sin tocar jamás las claves. Lo que empezó como una sola acción pay dentro de SSP Connect se convierte ahora en una plataforma real de integración, con una especificación pública en SSP_Wallet_API.md con la que cualquier desarrollador puede empezar a construir hoy.
De Pay a una API completa
La primera versión de SSP Connect, lanzada con la v1.1.0, añadió exactamente una acción saliente: pay. Una dApp podía solicitar un pago en una cadena, hacia una dirección y por un importe; la cartera se encargaba de la firma en los dos dispositivos del usuario. El alcance era intencional. Sirvió para probar la frontera —la cartera firma, la dApp pide— y nos dio algo que endurecer en la práctica.
La v1.15.0 da el siguiente paso. La cartera expone ahora una API más amplia que permite a un sitio emparejarse con un usuario de SSP, leer información puntual que el usuario apruebe de forma explícita y solicitar acciones que la cartera soporta. El modelo sigue siendo el mismo: la cartera es la autoridad, el sitio es un solicitante y el usuario es quien pulsa el botón verde. Lo nuevo es que la superficie ya no es una sola función: es una interfaz documentada.
Lo que expone la API
La API ampliada se centra en lo que casi toda dApp necesita saber para ser útil al usuario y en las acciones que la cartera puede ofrecer sin comprometer su modelo de seguridad.
Del lado de la lectura, la API permite a un sitio pedirle a la cartera información como el identificador de cuenta del usuario conectado, las cadenas que la cartera soporta y las direcciones que el usuario acepte compartir con ese sitio en particular. Es clave entender que «pedir» no significa «recibir automáticamente». Cada solicitud de lectura abre un aviso en la interfaz de la cartera y el usuario puede concederla, acotarla o rechazarla.
Del lado de las acciones, la API mantiene la misma frontera que el flujo original de pay. Se le puede pedir a la cartera que construya, revise y co-firme una transacción; la dApp nunca ve material de firma. La multifirma no se negocia: cada gasto que toca fondos sigue siendo firmado por las dos mitades del setup SSP —la extensión del navegador y la SSP Key en el teléfono del usuario— exactamente como ocurre en un envío iniciado a mano. No hay llamada de API que permita a un sitio saltarse ese flujo, ni «aprobación de sesión» que convierta a la cartera en un sello automático.
Las firmas completas de los métodos, los esquemas de las peticiones y la semántica de los eventos viven en la especificación SSP_Wallet_API.md, que es la fuente de verdad para quienes integren.
Modelo de seguridad
Una API de cartera vale lo que vale su modelo de seguridad, así que conviene ser explícitos sobre lo que la v1.15.0 impone.
Comprobaciones de origen. Cada llamada de API lleva el origen de la página que la realiza, y la cartera trata ese origen como la identidad del solicitante. Los permisos están delimitados por origen; un permiso concedido a un sitio no es un permiso concedido a su vecino en el mismo navegador. Si una página maliciosa intenta reutilizar la sesión de otro sitio, la solicitud se rechaza antes de llegar al usuario.
Aprobación explícita del usuario. Tanto las lecturas como las acciones requieren un aviso en la cartera la primera vez que ocurren, y las acciones materiales —cualquier cosa que firme o gaste— exigen un aviso nuevo en cada ocasión. La cartera no aprueba transacciones de forma silenciosa, ni siquiera para sitios a los que el usuario ya se ha conectado antes. La dApp no decide qué es «suficientemente fiable».
La firma sigue siendo local. Lo que siempre ha hecho de SSP una cartera SSP —que la firma ocurra localmente en dos dispositivos y que ningún servicio remoto tenga jamás una clave sin firmar pero gastable— no cambia. La API le da a un sitio una vía estructurada para pedirle una firma a la cartera; no le da ninguna vía para obtenerla sin el usuario ni para saltarse una clave.
El invariante de multifirma es el mismo con el que la cartera arrancó el día uno. La API es alguien que llama educadamente a la puerta, no una llave maestra.
Construir contra ella
La especificación en SSP_Wallet_API.md es el punto canónico de partida. Describe los métodos disponibles, los eventos que la cartera emite cuando cambia el estado y los códigos de error que una dApp debe esperar. Combínalo con las notas de la v1.15.0 en GitHub para tener el contexto completo de lo que se ha lanzado.
Para quien venga de otros ecosistemas de cartera, el modelo resulta familiar: emparejamiento basado en sesiones, permisos indexados por origen, estado guiado por eventos. Lo diferente es lo que falta: no hay «trampilla» para aprobar todas las transacciones futuras, ni material criptográfico que pueda salir de los dos dispositivos del usuario.
Qué sigue para SSP Connect
SSP Connect deja de ser un solo protocolo para convertirse en un paraguas que cubre la superficie externa de la cartera. Habrá más métodos documentados, más eventos y ejemplos más afinados para las formas de integración más comunes. La meta no es ser la API más grande de cripto: es ser la más aburrida —predecible, bien acotada y conservadora respecto a lo que un sitio puede pedirle a la cartera.
Si estás construyendo algo y quieres hablar con SSP, la especificación es la puerta.