Skip to main content
Envie e receba mensagens diretas criptografadas de ponta a ponta no X: configure chaves, inicialize uma conversa, envie uma mensagem e descriptografe o tráfego de entrada. Os apps de X Chat usam duas partes em conjunto:
Pré-requisitos
  • Conta de desenvolvedor e um app configurado para OAuth 2.0
  • Token de acesso de usuário com dm.read, dm.write, tweet.read e users.read

1. Instale as dependências

O pacote no PyPI é chatxdk; importe-o como chat_xdk. Requer Python 3.10+.
Crie um cliente de API com seu token de acesso OAuth 2.0 de usuário:

2. Inicialize o Chat XDK com chaves existentes

Esta etapa carrega chaves que você já possui — use-a quando esta identidade já concluiu a configuração inicial:
  • Backup seguro de chave: construa o SDK com o juicebox_config do seu registro de chave pública e depois unlock com seu código de acesso para recuperar as chaves privadas (por exemplo, em um novo dispositivo).
  • Blob de chave: import_keys com um blob que você exportou previamente via export_keys, passando junto a versão de chave registrada (Rust e Go nomeiam essa variante como import_keys_with_version / ImportKeysWithVersion).
Em seguida, chame set_identity(user_id, signing_key_version) uma vez, com seu ID de usuário e o public_key_version do seu registro. Isso armazena a identidade da sessão: cada chamada posterior de criptografia e preparação assina como esta identidade, então você nunca passa um ID de remetente ou versão de chave de assinatura por chamada. Configurando pela primeira vez? Construa o SDK da mesma forma, mas pule unlock/import_keys, e continue para a etapa 3 para criar, fazer backup e registrar suas chaves.
Amostras de servidor e bot geralmente usam um blob de chave (export_keys / import_keys). Apps cliente geralmente usam backup seguro de chave (setup / unlock com um código de acesso). Veja a referência do Chat XDK para ambos os caminhos.
Trazendo suas próprias chaves? import_keys só aceita o blob opaco produzido por export_keys do Chat XDK — é uma serialização privada e versionada do estado completo das chaves, não chaves P-256 em bruto ou codificadas em PEM. Você não pode construir este blob por conta própria: gere chaves com generate_keypairs (etapa 3), exporte o blob uma vez e armazene-o codificado em base64. Blobs feitos à mão ou modificados falham ao importar.

3. Crie e registre as chaves (configuração inicial)

Pule esta etapa se você carregou chaves existentes na etapa 2. Caso contrário, a configuração única para uma nova identidade faz três coisas:
  1. Criar os pares de chavesgenerate_keypairs produz os pares de identidade e de assinatura.
  2. Armazenar as chaves privadassetup com um código de acesso as grava no backup seguro de chave (clientes), ou export_keys retorna um blob de chave para você armazenar de forma segura (servidores e bots).
  3. Registrar as chaves públicas — faça POST do payload de registro no endpoint add-public-key para que outros possam criptografar para você e verificar suas assinaturas.
Finalize chamando set_identity com a versão de chave do registro, para que esta sessão assine como a nova identidade.
Scripts prontos de registro único para todos os bindings ficam em chat-xdk/examples (Python, TypeScript, Go, Rust, C# e Java). Use-os em vez de montar o fluxo abaixo à mão quando você só precisa integrar uma nova identidade.
Use um código de acesso forte para o backup seguro de chave. Perder o código de acesso ou um blob de chave desprotegido pode impedir a descriptografia de mensagens antigas.

4. Configure as chaves de conversa

Chame prepare_conversation_key_change com a chave pública de identidade de cada participante; a identidade do remetente vem da sessão que você definiu na etapa 2. Uma chamada gera uma nova chave de conversa, criptografa-a para cada participante e assina a mudança. Faça POST do resultado no endpoint add conversation keys (POST /2/chat/conversations/{id}/keys) — o corpo precisa de conversation_key_version, conversation_participant_keys (SDK encrypted_key → API encrypted_conversation_key) e action_signatures (obrigatório; a API rejeita a chamada sem elas). Guarde a chave da conversa em bruto para envio. A resposta retorna o ID canônico da conversa (data.conversation_id — o par unido por hífen para 1:1, ou o ID com prefixo g para um grupo) e o data.sequence_id da mudança de chave. Use esse ID retornado para solicitações posteriores em vez de reconstruí-lo no cliente. A mesma chamada também rotaciona chaves depois: passe o ID de conversa existente para prepare_conversation_key_change e faça POST com a versão de chave mais nova. Rotacione quando suspeitar que a chave da conversa foi exposta — a rotação protege apenas mensagens futuras; mensagens criptografadas com versões anteriores permanecem legíveis para quem possui essas versões.
Verifique as chaves obtidas antes de empacotar. prepare_conversation_key_change criptografa a nova chave de conversa para quaisquer chaves públicas que você passar. Verifique cada registro obtido primeiro com verify_key_binding(identity, signing, signature) — passando os campos public_key, signing_public_key e identity_public_key_signature do registro da API de chaves públicas — para que uma chave de identidade substituída não possa receber a chave da conversa.

5. Envie uma mensagem

Criptografe com a chave da conversa em bruto da etapa 4. O SDK gera o ID da mensagem (um UUID), incorpora-o no evento assinado e o retorna no payload — você nunca cria um por conta própria. Na requisição de envio, mapeie: Use um ID de conversa com hífen no caminho da URL quando a API exigir (:-). O SDK em si é flexível: encrypt_message e encrypt_reply aceitam o ID em qualquer forma que você tenha — A:B de eventos, A-B de listagens ou caminhos de URL (em qualquer ordem), ou apenas o ID de usuário do destinatário — e o canonizam antes de assinar. IDs de grupo (com prefixo g) passam sem alteração.
Os snippets passam a chave da conversa explicitamente porque, neste fluxo, você acabou de criá-la na etapa 4. Uma vez que o cache de chaves esteja ativo e uma passagem por decrypt_events tenha verificado a chave da conversa (etapa 6), encrypt_message(conversation_id, text) sozinho já basta — o SDK preenche a chave verificada mais recente. Retentativas devem reenviar o mesmo payload criptografado, para que um ID nunca seja gerado duas vezes.

6. Receba e descriptografe

Use webhooks ou o activity stream para tráfego ao vivo, ou pagine os eventos da conversa para obter o histórico.
  • Campos do payload ao vivo: encoded_event, opcional conversation_key_change_event
  • Histórico: GET /2/chat/conversations/{id}/events — prefira decrypt_events em todos os eventos mais meta.conversation_key_events
  • Descriptografar precisa das chaves de assinatura dos remetentes para que o SDK possa verificar quem escreveu cada mensagem. Estas são as chaves públicas dos outros participantes — obtenha-as do mesmo endpoint de chaves públicas que você usou na etapa 4 e mapeie os campos para SigningKeyEntry (os snippets abaixo incluem o mapeamento)
  • Você pode passar as chaves de assinatura (e, para decrypt_event, as chaves de conversa) em cada chamada, ou definir dois armazenamentos opcionais de sessão uma vez e usar as formas curtas de chamada. Os snippets abaixo usam os armazenamentos: set_signing_keys(entries) guarda as chaves dos participantes, e set_cache_keys(true) (desligado por padrão) mantém a chave mais recente verificada por assinatura de cada conversa, para que chamadas posteriores possam omitir argumentos de chave. Ambos os estilos verificam de forma idêntica
  • JavaScript usa tipos de evento em camelCase (message); outras linguagens usam "Message" e campos em snake_case no JSON
Serverless ou multi-instância? O armazenamento de chaves de assinatura e o cache de chaves vivem na memória da instância do SDK. Onde isso não se encaixa — uma invocação descriptografa, outra envia — passe as chaves explicitamente: decrypt_events(events, signing_keys), decrypt_event(event_b64, conversation_keys, signing_keys) e os overrides conversation_key/conversation_key_version nos métodos de criptografia. Persista você mesmo os conversation_keys retornados por decrypt_events e passe-os de volta.
Bots completos que fazem poll e reply em todas as linguagens: chat-xdk/examples.

Boas práticas

  • Mantenha o armazenamento de chaves de assinatura atualizado: chame novamente set_signing_keys com o conjunto completo de participantes quando um remetente registrar uma nova versão de chave, e atualize em falhas de verificação de assinatura
  • Deduplique entregas ao vivo com event_uuid