Skip to main content
Envía y recibe mensajes directos cifrados de extremo a extremo en X: configura claves, inicializa una conversación, envía un mensaje y descifra el tráfico entrante. Las apps de X Chat usan dos piezas juntas:
Requisitos previos
  • Cuenta de desarrollador y una app configurada para OAuth 2.0
  • Token de acceso de usuario con dm.read, dm.write, tweet.read y users.read

1. Instala las dependencias

El paquete de PyPI es chatxdk; impórtalo como chat_xdk. Requiere Python 3.10+.
Crea un cliente de API con tu token de acceso OAuth 2.0 de usuario:

2. Inicializa el Chat XDK con claves existentes

Este paso carga claves que ya tienes—úsalo cuando esta identidad ya completó la configuración inicial:
  • Copia de seguridad segura de claves: construye el SDK con el juicebox_config de tu registro de clave pública y luego usa unlock con tu código de acceso para recuperar las claves privadas (por ejemplo, en un dispositivo nuevo).
  • Blob de claves: import_keys con un blob que exportaste previamente mediante export_keys.
Después establece la versión de tu clave pública registrada (public_key_version en tu registro). ¿Configuras por primera vez? Construye el SDK de la misma forma pero omite unlock/import_keys y continúa en el paso 3 para crear, respaldar y registrar tus claves.
Los ejemplos para servidor y bot suelen usar un blob de claves (export_keys / import_keys). Las apps cliente suelen usar la copia de seguridad segura de claves (setup / unlock con un código de acceso). Consulta la referencia del Chat XDK para ambos caminos.
¿Traes tus propias claves? import_keys solo acepta el blob opaco que produce export_keys del Chat XDK—es una serialización privada y versionada del estado completo de las claves, no claves P-256 en bruto ni codificadas en PEM. No puedes construir este blob por tu cuenta: genera las claves con generate_keypairs (paso 3), exporta el blob una vez y guárdalo codificado en base64. Los blobs hechos a mano o modificados fallan al importarse.

3. Crea y registra las claves (configuración inicial)

Omite este paso si cargaste claves existentes en el paso 2. De lo contrario, la configuración inicial de una identidad nueva hace tres cosas:
  1. Crear los pares de clavesgenerate_keypairs produce los pares de claves de identidad y de firma.
  2. Registrar las claves públicas — envía el payload de registro con POST al endpoint add-public-key para que otros puedan cifrar hacia ti y verificar tus firmas.
  3. Guardar las claves privadassetup con un código de acceso las escribe en la copia de seguridad segura de claves (clientes), o export_keys devuelve un blob de claves para que lo guardes de forma segura (servidores y bots).
Usa un código de acceso fuerte para la copia de seguridad segura de claves. Perder el código de acceso o un blob de claves desprotegido puede impedir el descifrado de mensajes anteriores.

4. Configura las claves de conversación

Llama a prepare_conversation_key_change con tu ID de usuario, tu versión de clave de firma y la clave pública de identidad de cada participante. Una sola llamada genera una nueva clave de conversación, la cifra para cada participante y firma el cambio. Envía el resultado con POST al endpoint add conversation keys (POST /2/chat/conversations/{id}/keys)—el cuerpo necesita conversation_key_version, conversation_participant_keys (SDK encrypted_key → API encrypted_conversation_key) y action_signatures (obligatorio; la API rechaza la llamada sin ellas). Conserva la clave de conversación en bruto para enviar. La respuesta devuelve el id canónico de la conversación (data.conversation_id—el par unido con guión para un 1:1, o el id con prefijo g para un grupo) y el data.sequence_id del cambio de clave. Usa ese id devuelto para solicitudes posteriores en lugar de reconstruirlo en el cliente. La misma llamada también rota las claves más adelante: pasa el id de conversación existente a prepare_conversation_key_change y haz POST con la versión de clave más reciente. Rota cuando sospeches que la clave de conversación quedó expuesta—la rotación protege mensajes futuros únicamente; los mensajes cifrados bajo versiones anteriores de la clave siguen siendo legibles para cualquiera que tenga esas versiones.
Verifica las claves recuperadas antes de envolverlas. prepare_conversation_key_change cifra la nueva clave de conversación hacia cualesquiera claves públicas que le pases. Comprueba primero cada registro obtenido con verify_key_binding(identity, signing, signature)—pasando los campos public_key, signing_public_key y identity_public_key_signature del registro obtenidos de la API de claves públicas—para que una clave de identidad sustituida no pueda recibir la clave de conversación.

5. Envía un mensaje

Cifra con los bytes en bruto de la clave de conversación. En la solicitud de envío, mapea: Usa un id de conversación con guión en la ruta URL cuando la API lo requiera (:-). El propio SDK es flexible: encrypt_message y encrypt_reply aceptan el id en cualquier forma que tengas—A:B de eventos, A-B de listados o rutas URL (en cualquier orden), o solo el id de usuario del destinatario—y lo canonicalizan antes de firmar. Los ids de grupo (con prefijo g) pasan sin cambios.

6. Recibe y descifra

Usa webhooks o el activity stream para el tráfico en vivo, o pagina los events de la conversación para el historial.
  • Campos de payload en vivo: encoded_event, conversation_key_change_event opcional
  • Historial: GET /2/chat/conversations/{id}/events — prefiere decrypt_events sobre todos los eventos más meta.conversation_key_events
  • Pasa las claves públicas del remitente al descifrar para la verificación de la firma (mapea los campos de la API a SigningKeyEntry; consulta Chat XDK)
  • JavaScript usa tipos de evento en camelCase (message); los demás lenguajes usan "Message" y campos snake_case en JSON
Bots completos de poll-and-reply para todos los lenguajes: chat-xdk/examples.

Buenas prácticas

  • Cachea las claves de conversación en bruto y las claves públicas de los remitentes; refréscalas ante fallos de verificación de firma
  • Deduplica las entregas en vivo con event_uuid
  • Pagina el historial de eventos hasta completar la paginación para no perder metadatos de cambio de clave
  • No registres códigos de acceso, claves privadas ni el texto plano de mensajes en producción
  • En apps web, mantén los tokens de OAuth (y la emisión de tokens de realm de la copia de seguridad de claves) en un servidor; procura mantener las claves privadas solo en el Chat XDK del cliente

Próximos pasos

Chat XDK

Métodos y tipos para todos los bindings de lenguaje

Multimedia

Imágenes y archivos adjuntos cifrados

Grupos

Conversaciones y metadatos con múltiples participantes

Eventos en tiempo real

Webhooks y entrega de actividad