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

1. Instalar 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. Inicializar o Chat XDK com chaves existentes

Este passo carrega chaves que você já tem — use-o quando esta identidade já concluiu a configuração inicial antes:
  • Backup seguro de chaves: construa o SDK com o juicebox_config do seu registro de chave pública e depois faça 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 anteriormente via export_keys.
Em seguida, defina sua versão de chave pública registrada (public_key_version no seu registro). Configurando pela primeira vez? Construa o SDK da mesma forma, mas pule unlock/import_keys e continue para o passo 3 para criar, fazer backup e registrar suas chaves.
Amostras de servidor e bots normalmente usam um blob de chave (export_keys / import_keys). Apps cliente frequentemente usam backup seguro de chaves (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 esse blob por conta própria: gere as chaves com generate_keypairs (passo 3), exporte o blob uma vez e armazene-o codificado em base64. Blobs criados à mão ou modificados falham na importação.

3. Criar e registrar chaves (configuração inicial)

Pule este passo se você carregou chaves existentes no passo 2. Caso contrário, a configuração única de uma nova identidade faz três coisas:
  1. Criar os pares de chavesgenerate_keypairs produz os pares de chaves de identidade e de assinatura.
  2. Registrar as chaves públicas — faça POST do payload de registro para o endpoint add-public-key para que outros possam criptografar para você e verificar suas assinaturas.
  3. Armazenar as chaves privadassetup com um código de acesso as grava no backup seguro de chaves (clientes), ou export_keys retorna um blob de chave para você armazenar com segurança (servidores e bots).
Use um código de acesso forte para o backup seguro de chaves. Perder o código de acesso ou um blob de chave desprotegido pode impedir a descriptografia de mensagens antigas.

4. Configurar chaves de conversa

Chame prepare_conversation_key_change com seu ID de usuário, sua versão de chave de assinatura e cada chave pública de identidade dos participantes. Uma única 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 eles). Mantenha a chave de conversa em bruto para envio. A resposta retorna o ID canônico da conversa (data.conversation_id — o par unido por hífen para uma 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 requisições subsequentes 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 nova versão de chave. Rotacione quando suspeitar que a chave de conversa foi exposta — a rotação protege apenas mensagens futuras; mensagens criptografadas sob versões de chave anteriores permanecem legíveis para quem possui essas versões.
Verifique as chaves buscadas antes de envelopar. 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 de conversa.

5. Enviar uma mensagem

Criptografe com os bytes da chave de conversa em bruto. Na requisição de envio, faça o mapeamento: Use um ID de conversa com hífen no path da URL quando a API exigir (:-). O próprio SDK é 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 paths de URL (em qualquer ordem), ou apenas o ID de usuário do destinatário — e o canonicalizam antes de assinar. IDs de grupo (prefixados com g) passam sem alteração.

6. Receber e descriptografar

Use webhooks ou o stream de atividades para tráfego ao vivo, ou pagine os eventos de conversa para o histórico.
  • Campos de 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, junto com meta.conversation_key_events
  • Passe as chaves públicas do remetente para descriptografar para verificação de assinatura (mapeie campos da API para SigningKeyEntry; veja Chat XDK)
  • JavaScript usa tipos de evento em camelCase (message); outras linguagens usam "Message" e campos snake_case no JSON
Bots completos de poll-and-reply para cada linguagem: chat-xdk/examples.

Melhores práticas

  • Faça cache das chaves de conversa em bruto e das chaves públicas do remetente; atualize em falhas de verificação de assinatura
  • Deduplique entregas ao vivo com event_uuid
  • Pagine o histórico de eventos até que a paginação esteja completa para não perder metadados de mudança de chave
  • Não registre códigos de acesso, chaves privadas ou texto simples de mensagens em produção
  • Em apps web, mantenha tokens OAuth (e a emissão do token do realm de backup de chaves) em um servidor; prefira manter chaves privadas apenas no Chat XDK do cliente

Próximos passos

Chat XDK

Métodos e tipos para todos os bindings de linguagem

Mídia

Imagens criptografadas e anexos de arquivos

Grupos

Conversas com múltiplos participantes e metadados

Eventos em tempo real

Entrega via webhooks e atividade