Instalar
- Python
- TypeScript
- Rust
- Go
- C#
- Java
chatxdk; impórtalo como chat_xdk. Requiere Python 3.10+.Inicio rápido
Carga las claves, configura tu identidad una vez, descifra un backlog, descifra un evento en vivo y cifra un mensaje. Conecta el cuerpo del envío aPOST /2/chat/conversations/{id}/messages como en Primeros pasos.
Los snippets usan los dos almacenes de sesión opcionales para las formas de llamada más cortas: set_signing_keys guarda las claves públicas de los demás participantes (obtenidas del endpoint public-keys) para que las llamadas de descifrado puedan verificar a los remitentes sin un argumento por llamada, y set_cache_keys(true) permite al SDK recordar la clave verificada de cada conversación para que las llamadas de cifrado solo necesiten el ID de conversación y el texto. Omite cualquiera y pasa los mismos valores por llamada en su lugar—ambos estilos verifican de forma idéntica; consulta Descifrar.
- Python
- TypeScript
- Rust
- Go
- C#
- Java
Ciclo de vida y claves
Construye el SDK, almacena las claves privadas (copia de seguridad segura de claves protegida por código de acceso, o un blob de claves local), registra las claves públicas con la Chat API, y llama aset_identity(user_id, signing_key_version) después de unlock o import—establece el remitente y la versión de la clave de firma que cada acción firmada usa por defecto, así los métodos encrypt y prepare funcionan sin argumentos de identidad por llamada. Llama a generate_keypairs una vez por identidad de dispositivo/app; publica el payload de registro en el endpoint public-keys. Usa setup / unlock (y helpers de código de acceso relacionados) para la copia de seguridad segura de claves en cada binding. export_keys / import_keys (persistencia de blobs de claves en bruto para bots y servidores) están disponibles solo en los bindings nativos—Python, Go, .NET, JVM y Rust. El binding JS/WASM no expone exportación ni importación de claves en bruto: en un navegador cualquier script que acceda a la instancia podría exfiltrar la identidad, así que JS mantiene las claves dentro de la copia de seguridad segura de claves. Un servidor JS que quiera evitar un round-trip a un realm de backup por solicitud debería reutilizar una única instancia Chat desbloqueada entre solicitudes, o ejecutar un binding nativo donde se admitan blobs de claves.
El SDK también necesita la versión que la X API reporta para tu clave pública registrada, así que las entradas de key-change dirigidas a otras versiones se omiten. set_identity la registra junto con el user id; import_keys la acepta directamente como argumento opcional (Rust y Go usan import_keys_with_version / ImportKeysWithVersion).
- Python
- TypeScript
- Rust
- Go
- C#
- Java
juicebox_config de la X API (recomendado—se pasa literalmente), un wrapper completo sdk_config, o un token_map desnudo.
Opcional: la verificación de firmas está activada por defecto (reject_unverified = true)—llama a set_reject_unverified(false) para desactivarla (no recomendado); update_config si cambia la configuración del realm de backup; is_unlocked / has_identity_key para el estado de la UI. Las listas completas de campos están en los stubs del repo chat-xdk.
Claves de conversación
Los tres métodos prepare hacen que una llamada haga todo lo que necesita un cambio de clave: generar una nueva clave de conversación, cifrarla para cada participante (a partir de las claves públicas que pases) y firmar el cambio. La identidad del remitente y la versión de la clave de firma provienen de la sesión (set_identity); establece sender_id / signing_key_version en los params para anularlas. Todos devuelven la misma forma PreparedConversationChange, lista para POST—renombra el campo del SDK encrypted_key a encrypted_conversation_key en conversation_participant_keys, y mapea las firmas de acción al campo requerido action_signatures del cuerpo.
Conserva los bytes de la clave en bruto para
encrypt_message y multimedia; nunca pases el sobre cifrado de la API al cifrar.
Usa extract_conversation_keys en los payloads de eventos de cambio de clave para reconstruir { keys, latest_version }. decrypt_conversation_key desenvuelve un solo blob ECIES.
- Python
- TypeScript
- Rust
- Go
- C#
- Java
prepare_group_create; nuevos más la lista actual para prepare_group_members_change)—consulta Grupos para ejemplos. Ambos devuelven dos firmas de acción; el POST debe incluir ambas.
Descifrar
decrypt_events es para historial y backlog: extrae las claves de conversación del stream, devuelve mensajes descifrados y recopila errores por evento en lugar de fallar todo el batch. decrypt_event es para un solo evento en vivo; lanza/tira en caso de fallo.
Pasa las claves de firma para que el SDK pueda verificar a los remitentes. Mapea los campos de public-key de la API a SigningKeyEntry: public_key_version → public_key_version (mismo nombre), signing_public_key → public_key, public_key → identity_public_key, más identity_public_key_signature y user_id.
Dos almacenes de sesión opt-in te permiten omitir los argumentos de clave por llamada:
set_signing_keys(entries)almacena las claves de firma de los participantes; una llamada de descifrado que omita (o pase un argumento vacío de) las claves de firma usa el almacén en su lugar. La verificación en sí no cambia—las claves entran al almacén solo a través de esta llamada, nunca desde los eventos que se descifran. Cada llamada reemplaza el conjunto anterior.set_cache_keys(true)habilita la caché de claves de conversación (desactivada por defecto). Mientras está activada,decrypt_eventsguarda en caché, por conversación, la última clave cuyo cambio de clave llevaba una firma válida;decrypt_eventrecurre a ella cuando se omite su argumento de claves de conversación, y los helpers de cifrado resuelven una clave de conversación omitida a partir de ella. Desactivarla limpia la caché.
errors para decrypt_events, lanzados para decrypt_event). Para saltarte la verificación realmente, primero debes llamar a set_reject_unverified(false) (no recomendado en producción).
- Python
- TypeScript
- Rust
- Go
- C#
- Java
Helpers de cifrado y envío
encrypt_message(conversation_id, text) construye el texto cifrado firmado para un mensaje de texto; opcionales entities, attachments (vía media_hash_key), should_notify y ttl_msec. La identidad del remitente se resuelve desde la sesión (set_identity) y la clave de conversación desde la caché de claves opt-in (set_cache_keys)—o pasa sender_id / signing_key_version y conversation_key + conversation_key_version explícitamente. El SDK genera el message_id (un UUID incrustado en el evento firmado) y lo devuelve en el payload—nunca generes el tuyo; reutiliza el mismo payload en los reintentos para que el ID nunca se genere dos veces. Mapea el payload al cuerpo de send-message: message_id → message_id, encrypted_content → encoded_message_create_event, encoded_event_signature → encoded_message_event_signature.
Las respuestas se basan en eventos. encrypt_reply(conversation_id, text, reply_to_event) toma el evento en bruto codificado en base64 al que se responde. El SDK deriva la vista previa citada (sequence id, remitente, texto, entidades, adjuntos) a partir de él e incrusta el original firmado en el mensaje saliente para que los destinatarios puedan validar la cita. Pasa reply_to_ckces—los eventos de cambio de clave en bruto—cuando el original se cifró con una versión de clave más antigua que la respuesta. Cuando el original fue editado, pasa el evento de edición en bruto como reply_to_edit_event: la vista previa entonces cita lo que dice el mensaje ahora (su texto y entidades vienen de la edición), y la edición viaja junto al original para que el receptor la compruebe. Los campos explícitos reply_to_* permanecen como anulaciones para los que ya no tienen el evento en bruto.
Las reacciones también se basan en eventos. encrypt_add_reaction(target_event, emoji) y encrypt_remove_reaction(...) derivan el ID de conversación y el sequence id del objetivo a partir del evento en bruto al que se reacciona; los mismos params pueden añadir y más tarde eliminar una reacción. Establece conversation_id y target_message_sequence_id explícitamente solo cuando ya no tengas el evento en bruto.
En el lado receptor, un mensaje descifrado que cita una respuesta lleva reply_preview_validation ("Valid" / "Invalid"; el binding JS usa 'valid' / 'invalid'): el SDK verificó la firma del original incrustado contra tus claves de firma—nunca una clave llevada en el evento—lo descifró y comparó el contenido citado y el autor contra él. Cuando la vista previa incrusta un evento de edición, el SDK verifica la edición de la misma forma (misma conversación, mismo autor que el original) y comprueba el texto citado contra el contenido editado en lugar del texto previo a la edición. El campo está ausente cuando el mensaje no lleva vista previa o la vista previa no incrusta un original. Trata las vistas previas Invalid como no confiables: el mensaje en sí es auténtico, pero el material citado no lo es—renderiza las citas solo desde el original validado.
encrypt / decrypt son para metadatos UTF-8 bajo la clave de conversación (por ejemplo un nombre de grupo cifrado)—no sobres de mensajes. encrypt_stream / decrypt_stream cifran bytes de adjuntos; consulta Multimedia. Los sign / verify / verify_key_binding de bajo nivel soportan flujos avanzados; los cambios de clave de conversación, creaciones de grupo y adiciones de miembros son firmados por los métodos prepare.
El ID de conversación pasado a encrypt_message / encrypt_reply puede ser cualquier forma que tengas—A:B de eventos, A-B de listados o rutas URL (en cualquier orden), o el user id del destinatario a secas—el SDK lo canonicaliza antes de firmar. Los IDs de grupo (con prefijo g) pasan sin cambios.
- Python
- TypeScript
- Rust
- Go
- C#
- Java
Streams de multimedia
Cifra los bytes del archivo con la misma clave de conversación usada para texto, sube mediante las APIs de multimedia del Chat y adjuntamedia_hash_key en encrypt_message. Este no es el modelo de multimedia de Posts (expansions=attachments.media_keys). Flujo completo de subida/descarga: Multimedia.
- Python
- TypeScript
- Rust
- Go
- C#
- Java
Streaming incremental para multimedia grande
Para archivos grandes, evita mantener todo el payload en memoria:stream_encryptor() / stream_decryptor() devuelven un StreamEncryptor / StreamDecryptor al que le pasas trozos (de aproximadamente 1 MB cada uno) con push(chunk), y luego llamas a finish() una vez al final. Al descifrar, finish() detecta un stream truncado (falla si la entrada terminó antes del frame final), así que no trates el texto plano acumulado como completo hasta que tenga éxito.
- Python
- TypeScript
Utilidades
Los helpers de Base64/hex, detección de MIME y dimensiones de imagen están disponibles como funciones a nivel de módulo (Python/JS/Rust/Go) oChatXdkUtilities (C#/Java)—útiles al construir metadatos de adjuntos sin traer bibliotecas adicionales.
- Python
- TypeScript
- Rust
- Go
- C#
- Java
Tipos importantes
Estos tipos conceptuales aparecen en todos los lenguajes (los nombres exactos de los campos varían; JS suele usar discriminadores de eventos en camelCase comomessage):
- SendPayload — valor de retorno de
encrypt_messagey de los demás helpers de cifrado: elmessage_idgenerado por el SDK (un UUID incrustado en el evento firmado—envíalo como elmessage_iddel mensaje y consérvalo para deduplicar),encrypted_content,encoded_event_signature, metadatos de firma,conversation_key_versionyshould_notify. Mapea al cuerpo de send de la Chat API. - PublicKeyRegistrationPayload — salida de
generate_keypairs/ getters de public-key para la API add-public-key. - SigningKeyEntry — material público del remitente pasado al descifrar para verificación de firma, o almacenado mediante
set_signing_keys. - PreparedConversationChange — salida de los tres métodos prepare: el
conversation_idderivado o pasado, los bytes en bruto deconversation_key,conversation_key_version,participant_keys(user_id,encrypted_key,public_key_version) yaction_signatures(message_id,encoded_message_event_detail,signature,signature_version,public_key_version, opcionalsignature_payload—omitido en firmas de key-change porque ese payload incrusta la clave en texto plano). - DecryptEventsResult — mensajes, errores opcionales y
conversation_keysextraídas. Los mensajes descifrados que citan una respuesta llevanreply_preview_validation(consulta Helpers de cifrado y envío).
docs/API.md, *.pyi, index.d.ts).
Errores
Python normalmente lanzaValueError con un mensaje descriptivo (por ejemplo, un código de acceso inválido). TypeScript/JavaScript lanza Error. Go devuelve (value, error). Prefiere decrypt_events para el historial para que un evento defectuoso no aborte el batch; inspecciona la colección de errores para ver fallos parciales.
Algunos errores de verificación son permanentes. Las firmas son inmutables y se verifican reconstruyendo el payload firmado a partir del propio evento, así que un evento antiguo que falla con signature missing or no matching signing key o una discrepancia ECDSA fallará en cada carga futura—ningún reintento, refresco de claves ni llamada a la API puede sanarlo. Trátalos como tombstones, no como errores transitorios. Rotar la clave de conversación inicia un historial limpio y verificable a partir de ese punto hacia adelante.
Próximos pasos
Primeros pasos
Conecta el Chat XDK con la Chat API
Multimedia
Cifrado de streams y REST de multimedia
Eventos en tiempo real
Webhooks y entrega de actividad
Solución de problemas
Fallos comunes