Skip to main content
O Chat XDK cuida do gerenciamento de chaves, criptografia, descriptografia e assinatura para o X Chat. Ele não chama a X HTTP API — combine-o com o XDK Python ou TypeScript, ou com HTTPS e um token de acesso do usuário. Passo a passo do app: Guia de introdução. Bots de exemplo: chat-xdk/examples.

Instalação

O pacote no PyPI é chatxdk; importe-o como chat_xdk. Requer Python 3.10+.

Início rápido

Descriptografe um backlog, faça cache das chaves, descriptografe um evento, criptografe uma resposta. Conecte o corpo de envio a POST /2/chat/conversations/{id}/messages como em Guia de introdução.

Ciclo de vida e chaves

Construa o SDK, armazene chaves privadas (backup seguro de chaves protegido por código de acesso ou blob de chave local), registre as chaves públicas com a Chat API e defina sua versão de chave pública registrada após unlock ou import. O backup seguro de chaves é implementado com o Juicebox, e é por isso que os campos de configuração relacionados carregam esse nome. Chame generate_keypairs uma vez por identidade de dispositivo/app; faça POST do payload de registro para o endpoint de chaves públicas. Use setup / unlock (e helpers de código de acesso relacionados) para o backup seguro de chaves em todos os bindings. export_keys / import_keys (persistência de blob de chave em bruto para bots e servidores) estão disponíveis apenas nos bindings nativos — Python, Go, .NET, JVM e Rust. O binding JS/WASM não expõe exportação nem importação de chave em bruto: em um navegador, qualquer script que alcance a instância poderia exfiltrar a identidade, então o JS mantém as chaves dentro do backup seguro de chaves. Um servidor JS que queira evitar um round-trip ao realm de backup por requisição deve reutilizar uma instância Chat desbloqueada entre requisições, ou rodar um binding nativo em que blobs de chave são suportados.
A configuração do backup seguro de chaves aceita três formatos: o objeto juicebox_config da X API (recomendado — passado verbatim), um wrapper sdk_config completo, ou um token_map puro. Opcional: a verificação de assinatura está ativa por padrão (reject_unverified = true) — chame set_reject_unverified(false) para desativá-la (não recomendado); update_config se a configuração do realm de backup mudar; is_unlocked / has_identity_key para o estado da UI. As listas completas de campos ficam nos stubs do repositório chat-xdk.

Chaves de conversa

Três métodos prepare fazem cada um uma única chamada que faz tudo o que uma mudança de chave precisa: gerar uma nova chave de conversa, criptografá-la para cada participante (das chaves públicas que você passa) e assinar a mudança. Todos retornam o mesmo formato PreparedConversationChange, pronto para POST — renomeie o campo do SDK encrypted_key para encrypted_conversation_key em conversation_participant_keys, e mapeie as assinaturas de ação para o campo obrigatório action_signatures no corpo. Mantenha os bytes da chave em bruto para encrypt_message e mídia; nunca passe o envelope criptografado da API para encrypt.
Verifique as chaves obtidas antes de envelopar. Os métodos prepare criptografam a nova chave de conversa para quaisquer chaves públicas que você passar. Antes de passá-las, chame verify_key_binding(identity, signing, signature) em cada registro obtido — seus campos public_key, signing_public_key e identity_public_key_signature da API de chaves públicas — para que uma chave de identidade substituída não possa receber a chave de conversa.
Use extract_conversation_keys em payloads de eventos de mudança de chave para reconstruir { keys, latest_version }. decrypt_conversation_key desencapsula um único blob ECIES.
Para criação de grupo e adições de membros, passe os parâmetros que cada método precisa (listas de IDs de membro/admin para prepare_group_create; novos mais a lista atual para prepare_group_members_change) — veja Grupos para exemplos. Ambos retornam duas assinaturas de ação; o POST deve incluir as duas.

Descriptografar

decrypt_events é para histórico e backlog: extrai chaves de conversa do stream, retorna mensagens descriptografadas e coleta os erros por evento em vez de falhar o batch inteiro. decrypt_event é para um único evento ao vivo quando você já tem um cache de chaves; lança/throws em falha. Passe as chaves de assinatura para que o SDK possa verificar remetentes. Mapeie os campos de chave pública da API para SigningKeyEntry: public_key_versionpublic_key_version (mesmo nome), signing_public_keypublic_key, public_keyidentity_public_key, além de identity_public_key_signature e user_id. A verificação é obrigatória por padrão: omitir ou passar uma lista de chaves de assinatura vazia não a pula — eventos assinados falham (coletados em errors para decrypt_events, lançados para decrypt_event). Para realmente pular a verificação, você deve primeiro chamar set_reject_unverified(false) (não recomendado em produção).

Helpers de criptografar e enviar

encrypt_message constrói o texto cifrado assinado para uma mensagem de texto (entidades opcionais, anexos via media_hash_key, TTL, flags de notificação). Mapeie o payload retornado para o corpo de envio de mensagem: encrypted_contentencoded_message_create_event, encoded_event_signatureencoded_message_event_signature, mais seu message_id. Use encrypt_reply, encrypt_add_reaction e encrypt_remove_reaction para respostas e reações (sequence_id aponta para o pai). encrypt / decrypt são para metadados UTF-8 sob a chave de conversa (por exemplo, um nome de grupo criptografado) — não envelopes de mensagem. encrypt_stream / decrypt_stream criptografam bytes de anexo; veja Mídia. Os métodos de baixo nível sign / verify / verify_key_binding suportam fluxos avançados; mudanças de chave de conversa, criação de grupos e adições de membros são assinadas pelos métodos prepare. O ID de conversa passado para encrypt_message / encrypt_reply pode ser em qualquer forma que você tenha — A:B de eventos, A-B de listagens ou paths de URL (em qualquer ordem), ou o ID de usuário do destinatário puro — o SDK o canonicaliza antes de assinar. IDs de grupo (prefixados com g) passam sem alteração.

Streams de mídia

Criptografe bytes de arquivo com a mesma chave de conversa usada para texto, envie via APIs de mídia do Chat e anexe media_hash_key em encrypt_message. Isto não é o modelo de mídia dos Posts (expansions=attachments.media_keys). Fluxo completo de upload/download: Mídia.

Streaming incremental para mídia grande

Para arquivos grandes, evite manter todo o payload em memória: stream_encryptor() / stream_decryptor() retornam um StreamEncryptor / StreamDecryptor que você alimenta em chunks (cerca de 1 MB cada) com push(chunk), e depois chama finish() uma vez ao final. Na descriptografia, finish() detecta um stream truncado (falha se a entrada terminar antes do frame final), então não trate o texto simples enviado como completo até que ele tenha sucesso.
Apenas JS/WASM: finish() consome e libera o objeto WASM subjacente — nunca chame free() após finish() (ele lança exceção). Chame free() apenas para abandonar um stream antes de finalizar (por exemplo, em um caminho de erro).

Utilitários

Helpers de Base64/hex, detecção de MIME e dimensões de imagem estão disponíveis como funções de nível de módulo (Python/JS/Rust/Go) ou ChatXdkUtilities (C#/Java) — úteis ao construir metadados de anexos sem trazer bibliotecas adicionais.

Tipos importantes

Estes tipos conceituais aparecem em todas as linguagens (os nomes exatos dos campos diferem; JS frequentemente usa discriminadores de evento em camelCase como message):
  • SendPayload — valor de retorno de encrypt_message e helpers de criptografia relacionados; mapeie para o corpo de envio da Chat API.
  • PublicKeyRegistrationPayload — saída de generate_keypairs / getters de chave pública para a API de adicionar chave pública.
  • SigningKeyEntry — material público do remetente passado para descriptografar, para verificação de assinatura.
  • PreparedConversationChange — saída dos três métodos prepare: o conversation_id derivado ou passado, os bytes da conversation_key em bruto, conversation_key_version, participant_keys (user_id, encrypted_key, public_key_version) e action_signatures (message_id, encoded_message_event_detail, signature, signature_version, public_key_version, opcional signature_payload — omitido em assinaturas de mudança de chave porque esse payload embute a chave em texto simples).
  • DecryptEventsResult — mensagens, erros opcionais e conversation_keys extraídas.
Para listas de campos completas, use stubs de linguagem no repositório chat-xdk (docs/API.md, *.pyi, index.d.ts).

Erros

Python normalmente lança ValueError com uma mensagem descritiva (por exemplo, um código de acesso inválido). TypeScript/JavaScript lança Error. Go retorna (value, error). Prefira decrypt_events para histórico para que um evento ruim não aborte o batch; inspecione a coleção de erros para falhas parciais. Alguns erros de verificação são permanentes. Assinaturas são imutáveis e verificadas reconstruindo o payload assinado a partir do próprio evento, então um evento antigo que falha com signature missing or no matching signing key ou uma incompatibilidade ECDSA falhará em cada carregamento futuro — nenhuma nova tentativa, atualização de chave ou chamada de API pode curá-lo. Trate esses como lápides, não como erros transitórios. Rotacionar a chave de conversa inicia um histórico limpo e verificável a partir daquele ponto.

Próximos passos

Guia de introdução

Conecte o Chat XDK à Chat API

Mídia

Criptografia de stream e REST de mídia

Eventos em tempo real

Entrega via webhooks e atividade

Solução de problemas

Falhas comuns