Cifratura e verifica di Matrix in OpenClaw

Le stanze Matrix cifrate funzionano solo quando il dispositivo del Gateway è considerato attendibile dall’account che lo possiede, e su Matrix la fiducia è una catena: archiviazione dei segreti, chiavi di firma incrociata, un dispositivo verificato e un backup delle chiavi delle stanze. OpenClaw racchiude questa catena in un piccolo insieme di comandi ed è esplicito su cosa dimostra ciascun segnale di fiducia. Ecco come si attiva la cifratura, come funzionano stato e verifica, come si inizializza o si ripara la firma incrociata, come si ripristinano o si reimpostano i backup, i comandi SAS e le note operative.

Attivazione e stato

• Nelle stanze cifrate gli eventi immagine in uscita usano un file di miniatura cifrato, così le anteprime sono cifrate insieme all’allegato, senza alcuna configurazione perché il plugin rileva lo stato di cifratura della stanza; ogni comando Matrix accetta i flag di verbosità, JSON e account, e l’output è conciso per impostazione predefinita.
• Il comando di configurazione della cifratura inizializza l’archiviazione dei segreti e la firma incrociata e crea un backup delle chiavi delle stanze se serve, con la chiave di recupero letta da stdin, così non compare mai negli argomenti del processo, e un flag esplicito per scartare l’identità di firma incrociata attuale; un nuovo account può attivare la cifratura alla creazione, ed entrambi i percorsi completano le operazioni del client prima di salvare la configurazione, così un Gateway in esecuzione può ricaricarla subito dopo, mentre un bootstrap fallito salva comunque l’impostazione e indica i passaggi successivi.
• Lo stato di verifica riporta tre segnali indipendenti: attendibile in locale, cioè attendibile solo per questo client; verificato tramite firma incrociata, riportato dall’SDK; e firmato dal proprietario, una diagnostica che indica che il dispositivo porta la tua chiave di auto-firma. Un flag per includere la chiave di recupero conferma solo, nell’output testuale, che una chiave grezza è disponibile e ti rimanda al JSON, che a quel punto va tenuto privato.
• Verificare il dispositivo con una chiave di recupero via stdin riporta tre stati, chiave accettata, backup utilizzabile e dispositivo verificato dal proprietario, ed esce con un codice diverso da zero quando la fiducia nell’identità non è completa, anche se la chiave ha sbloccato il materiale del backup; per completare serve allora un’auto-verifica da un altro client, che il comando di auto-verifica attende finché la firma incrociata non risulta verificata.

“Verified by owner” è “yes” solo quando “Cross-signing verified” è “yes”; la fiducia locale o la sola firma del proprietario non bastano.

Riparazione e backup

Il comando di bootstrap è il percorso di riparazione e configurazione degli account cifrati: inizializza l’archiviazione dei segreti riutilizzando una chiave di recupero esistente quando possibile, inizializza la firma incrociata e carica le chiavi pubbliche mancanti, contrassegna e firma in modo incrociato il dispositivo corrente, e crea un backup lato server delle chiavi delle stanze se non ne esiste uno; quando l’homeserver richiede l’autenticazione interattiva per caricare le chiavi, OpenClaw prova prima senza autenticazione, poi con la fase di login fittizio, poi con il login tramite password, che richiede la password dell’account nella configurazione. Lo stato del backup mostra se esiste un backup lato server e se questo dispositivo può decifrarlo, il ripristino importa le chiavi delle stanze salvate nel crypto store locale, e una modifica la cui cronologia non è completamente decifrata si risolve ripristinando le chiavi mancanti e riprovando, oppure inviando un nuovo messaggio quando le chiavi sono andate perse. Un reset del backup sostituisce un backup danneggiato con una nuova base di partenza, accettando la perdita della cronologia irrecuperabile e ricreando facoltativamente l’archiviazione dei segreti, e un flag di rotazione va aggiunto solo quando la chiave di recupero precedente non deve più sbloccare la nuova base.

SAS, account, avvio

• Il comando verify list mostra le richieste in sospeso, e verify request ne invia una: un’auto-verifica con il flag del proprio utente, da accettare in un altro client dello stesso utente, oppure verso un utente, un dispositivo o una stanza specifici; i comandi di ciclo di vita di livello più basso accettano una richiesta, avviano il flusso SAS, stampano le emoji o i numeri decimali, confermano o rifiutano la corrispondenza e annullano con un motivo e un codice, e tutti accettano indicazioni di follow-up per i DM quando sono ancorati a una stanza diretta.
• Senza un flag di account i comandi usano l’account predefinito implicito; con più account con nome e nessun predefinito si rifiutano di tirare a indovinare, e un account con nome senza cifratura segnala la propria chiave di configurazione. Con la cifratura attiva, la verifica all’avvio vale if-unverified per impostazione predefinita: un dispositivo non verificato richiede l’auto-verifica in un altro client, saltando i duplicati entro un periodo di attesa di ventiquattro ore che si può regolare o disattivare, e all’avvio viene eseguito anche un passaggio di bootstrap prudente che tenta una riparazione protetta senza password e non causa un errore fatale quando è richiesta l’autenticazione tramite password.
• Gli avvisi del ciclo di vita della verifica (richiesta, pronto con le indicazioni sulle emoji, avvio, completamento e dettagli SAS) vengono pubblicati come avvisi nella stanza DM di verifica rigorosa e non raggiungono mai la pipeline dell’agente; le richieste in arrivo da un altro client vengono tracciate e accettate automaticamente, e l’auto-verifica avvia il flusso SAS in automatico e conferma il proprio lato mentre tu fai ancora il confronto nel tuo client. Un dispositivo che non è più elencato sull’homeserver si sostituisce aggiungendo di nuovo l’account con un login tramite password o un nuovo token di accesso, i dispositivi obsoleti si elencano e si eliminano con i comandi devices, e lo stato crittografico risiede nella directory di stato, in radici per account indicizzate per homeserver, utente e hash del token, dove una singola radice più vecchia è normale continuità di rotazione, mentre più radici popolate vanno ispezionate e archiviate anziché eliminate.

Questo articolo approfondisce OpenClaw su Matrix, il post dedicato al canale; per le configurazioni con più account, gli homeserver privati e i formati delle destinazioni c’è la pagina complementare su account e homeserver Matrix in OpenClaw.

Su Diali

Matrix è nell’elenco dei canali collegabili di Diali, insieme a WhatsApp, Telegram, Discord, Slack, Mattermost, SMS e voce: l’account sull’homeserver e l’elenco delle stanze autorizzate sono tuoi, il Gateway è nostro. La guida per collegare il tuo primo canale in cinque minuti spiega come si collegano, e la pagina sulla sicurezza di Diali descrive il confine che vale per ciascuno.

Cosa garantisce la regola di fiducia

Pretendere la verifica tramite firma incrociata anziché la fiducia locale significa che un dispositivo rubato o riprodotto non può essere fatto passare dal Gateway stesso; solo il proprietario dell’account, da un altro client, può completare la catena. OpenClaw ospitato su Diali è l’assistente e OpenClaw doctor è il comando che fa emergere i problemi dello stato crittografico insieme al resto della configurazione.

• Configurazione, verifica, bootstrap, backup: quattro comandi.
• Chiavi di recupero via stdin, mai sulla riga di comando.
• Conta solo la firma incrociata; completa da un altro client.