Criptografia e verificação do Matrix no OpenClaw

Salas criptografadas do Matrix só funcionam quando o dispositivo do Gateway é confiável para a conta dona dele, e a confiança no Matrix é uma cadeia: armazenamento de segredos, chaves de assinatura cruzada, um dispositivo verificado e um backup das chaves de sala. O OpenClaw encapsula essa cadeia em um pequeno conjunto de comandos e deixa explícito o que cada sinal de confiança prova. Veja como a criptografia é ativada, como o status e a verificação funcionam, como a assinatura cruzada é inicializada ou reparada, como os backups são restaurados ou redefinidos, os comandos SAS e as notas operacionais.

Ativação e status

• Em salas criptografadas, os eventos de imagem de saída usam um arquivo de miniatura criptografado, para que as prévias sejam criptografadas junto com o anexo, sem nenhuma configuração, já que o plugin detecta o estado de criptografia da sala; todo comando do Matrix aceita flags de verbose, JSON e conta, e a saída é concisa por padrão.
• O comando de configuração da criptografia inicializa o armazenamento de segredos e a assinatura cruzada e cria um backup das chaves de sala, se necessário, com a chave de recuperação lida do stdin para que ela nunca apareça nos argumentos do processo, e com uma flag deliberada para descartar a identidade de assinatura cruzada atual; uma conta nova pode ativar a criptografia na criação, e os dois caminhos concluem as operações do cliente antes de salvar a configuração, para que um Gateway em execução possa recarregá-la depois, enquanto um bootstrap que falha ainda salva a opção e informa os próximos passos.
• O status de verificação informa três sinais independentes: confiável localmente, ou seja, confiável apenas para este cliente; verificado por assinatura cruzada, informado pelo SDK; e assinado pelo proprietário, um diagnóstico de que o dispositivo carrega a sua chave de autoassinatura. Uma flag para incluir a chave de recuperação apenas confirma, na saída em texto, que uma chave bruta está disponível e indica o JSON, que então precisa ser mantido em sigilo.
• Verificar o dispositivo com uma chave de recuperação via stdin informa três estados (chave aceita, backup utilizável e dispositivo verificado pelo proprietário) e sai com código diferente de zero quando a confiança total na identidade não está completa, mesmo que a chave tenha desbloqueado o material de backup; concluir, então, significa fazer a autoverificação a partir de outro cliente, que o comando de autoverificação aguarda até que a assinatura cruzada informe verificado.

O campo Verified by owner só marca yes quando Cross-signing verified marca yes; a confiança local ou uma assinatura do proprietário, sozinhas, não bastam.

Reparo e backup

O comando de bootstrap é o caminho de reparo e configuração para contas criptografadas: ele inicializa o armazenamento de segredos reutilizando uma chave de recuperação existente quando possível, inicializa a assinatura cruzada e envia as chaves públicas que faltam, marca e assina de forma cruzada o dispositivo atual e cria um backup das chaves de sala no servidor se não houver nenhum; quando o homeserver exige autenticação interativa para enviar chaves, o OpenClaw tenta sem autenticação, depois a etapa de login dummy e depois o login com senha, que precisa da senha da conta na configuração. O status do backup mostra se existe um backup no servidor e se este dispositivo consegue descriptografá-lo; a restauração importa as chaves de sala do backup para o armazenamento criptográfico local; e uma edição cujo histórico não está totalmente descriptografado é corrigida restaurando as chaves que faltam e tentando de novo, ou enviando uma nova mensagem quando as chaves se perderam. Uma redefinição do backup substitui um backup quebrado por uma nova base, aceitando a perda do histórico irrecuperável e, opcionalmente, recriando o armazenamento de segredos, e uma flag de rotação só é adicionada quando a chave de recuperação anterior não deve mais desbloquear a nova base.

SAS, contas, inicialização

• O comando verify list mostra as solicitações pendentes, e verify request envia uma, seja uma autoverificação com a flag de próprio usuário, a ser aceita em outro cliente do mesmo usuário, seja para um usuário, dispositivo ou sala específicos; os comandos de ciclo de vida de nível mais baixo aceitam uma solicitação, iniciam o fluxo SAS, mostram os emojis ou os decimais, confirmam ou rejeitam a correspondência e cancelam com um motivo e um código, todos aceitando dicas de acompanhamento por DM quando ancorados a uma sala direta.
• Sem a flag de conta, os comandos usam a conta padrão implícita; com várias contas nomeadas e nenhuma padrão, eles se recusam a adivinhar; e uma conta nomeada sem criptografia informa a própria chave de configuração. Com a criptografia ativada, a verificação na inicialização tem o padrão if-unverified: um dispositivo não verificado solicita a autoverificação em outro cliente, ignorando duplicatas dentro de um intervalo de espera de vinte e quatro horas que pode ser ajustado ou desativado, e a inicialização também executa uma passada conservadora de bootstrap que tenta um reparo protegido sem senha e não é fatal quando a autenticação por senha é exigida.
• Os avisos do ciclo de vida da verificação (solicitação, pronto com orientação de emojis, início, conclusão e detalhes do SAS) são publicados na sala estrita de verificação por DM como avisos e nunca chegam ao pipeline do agente; solicitações recebidas de outro cliente são acompanhadas e aceitas automaticamente, e a autoverificação inicia o fluxo SAS automaticamente e confirma o próprio lado enquanto você ainda compara no seu cliente. Um dispositivo que não aparece mais no homeserver é substituído adicionando a conta de novo com login por senha ou um novo token de acesso, dispositivos obsoletos são listados e removidos com os comandos devices, e o estado criptográfico fica no diretório de estado, em raízes por conta indexadas por homeserver, usuário e hash do token, onde uma única raiz mais antiga é continuidade normal de rotação, mas várias raízes populadas devem ser inspecionadas e arquivadas em vez de excluídas.

O OpenClaw no Matrix é o post sobre o canal que este aprofunda; a página complementar sobre configurações com várias contas, homeservers privados e formatos de destino é a de contas e homeservers do Matrix no OpenClaw.

Na Diali

O Matrix está na lista de canais conectáveis da Diali, ao lado de WhatsApp, Telegram, Discord, Slack, Mattermost, SMS e voz: a conta no homeserver e a lista de permissões de salas são suas; o Gateway é nosso. O guia para conectar seu primeiro canal em cinco minutos explica como essas partes são vinculadas, e a página de segurança da Diali descreve a fronteira que se aplica a cada uma.

O que a regra de confiança garante

Exigir a verificação por assinatura cruzada, em vez da confiança local, significa que um dispositivo roubado ou reutilizado via replay não pode ser liberado pelo próprio Gateway; só o dono da conta, a partir de outro cliente, pode completar a cadeia. O OpenClaw hospedado na Diali é o assistente, e o OpenClaw doctor, o comando que expõe problemas de estado criptográfico junto com o resto da configuração.

• Configuração, verificação, bootstrap, backup: quatro comandos.
• Chaves de recuperação via stdin, nunca na linha de comando.
• Só a assinatura cruzada conta; conclua a partir de outro cliente.