@xdevplatform/chat-xdk). Las claves privadas de identidad y de firma permanecen en el dispositivo del usuario. Tus servidores (y X) solo llegan a ver texto cifrado, claves públicas y tokens de OAuth: nunca el PIN ni el material de clave privada usado para cifrar y firmar mensajes.
Esta página describe la arquitectura recomendada para apps cliente. Para las reglas de PIN y manejo de claves que aplican a cualquier tipo de app, consulta Manejo de claves privadas.
Por qué WASM para apps de UI
Los usuarios finales nunca deben pegar su PIN de cifrado en tu backend, y tu backend nunca debe guardar sus claves privadas de identidad. Si un servidor de terceros recibe el PIN o las claves privadas raíz de un usuario, esa parte puede descifrar las claves de conversación envueltas para esa identidad incluso después de que el usuario revoque el acceso OAuth. El WASM del lado del cliente evita esa clase de fallo en apps legítimas.
Arquitectura recomendada
Separa la criptografía (navegador) del transporte de la API (tu backend o la X API directa con un token de usuario):
Un patrón común (usado por demos internas como clientes de chat en el navegador) es: WASM + React (o similar) en el frontend, XDK de TypeScript en rutas de API de Next.js (u otras) para que el navegador no hable con
api.x.com con un secreto de larga vida si prefieres no hacerlo. La criptografía sigue ejecutándose únicamente en el navegador.
Instala el paquete para navegador
@xdevplatform/chat-xdk; no hay una toolchain de Rust separada para los consumidores. Requiere un navegador moderno (y Node.js 18+ si compartes código con SSR: ejecuta la criptografía solo en el cliente).
Flujo de sesión (PIN una vez, claves en memoria)
No pidas el PIN en cada mensaje. Desbloquea una vez por sesión del navegador, mantén la instancia deChat en memoria (singleton de módulo, contexto de React, etc.), y luego cifra y descifra contra esa instancia desbloqueada.
Expectativas de UX
Lo que tu servidor puede ver
Los tokens de realm para Juicebox no son el PIN del usuario. Autorizan el protocolo de backup para ese usuario y esa versión de clave. Sigue emitiéndolos desde un backend que ya tenga el contexto OAuth del usuario.
Copia de seguridad segura de claves en el navegador
Las apps cliente deberían usar copia de seguridad segura de claves (setup / unlock con un código de acceso), no un archivo de claves crudo:
- Carga
juicebox_configdesde el registro de clave pública del usuario (public_key.fields=juicebox_config). createChat({ juiceboxConfig, getAuthToken }).- La primera vez:
generateKeypairs→ registra las claves públicas con X →setup(pin). - Después:
unlock(pin)en este dispositivo (o en uno nuevo con el mismo PIN).
createChat, por lo que no se anima al JavaScript de la aplicación a extraer los bytes de la clave raíz a la página. Prefiere ese modelo antes que volcados de claves artesanales en localStorage.
Pasos completos de registro y desbloqueo: Primeros pasos. Conceptos: Manual básico de criptografía.
Lista de verificación de endurecimiento del navegador
- Ejecuta el Chat XDK solo en bundles de cliente (sin SSR de claves desbloqueadas).
- Trata la instancia desbloqueada de
Chatcomo un secreto vivo de sesión: no la pongas enwindow, no la registres en logs, no la envíes a analítica. - Defiéndete de XSS: CSP, cuidado con
dangerouslySetInnerHTML/ renderizado de markdown, higiene de dependencias. Un XSS en una app de chat puede llegar a las claves en memoria aunque las claves nunca toquen la red. - Usa HTTPS en todas partes; nunca mezcles páginas de criptografía con scripts inseguros.
- Prefiere scopes de OAuth mínimos; solicita scopes de DM solo cuando sean necesarios y explícalos en la UI de tu producto.
- En el logout, llama a
lock()/free()y descarta la instancia.
localStorage, cómo pensar la persistencia de sesión) están en Manejo de claves privadas.
Próximos pasos
- Manejo de claves privadas — advertencias sobre el PIN, almacenamiento, bots vs. apps de UI
- Primeros pasos — registro completo de claves y primer mensaje
- Chat XDK — referencia de API para
createChat, encrypt, decrypt - Eventos en tiempo real — entrega texto cifrado al cliente para descifrar localmente