Che cosa passa tra i server

I nodi si parlano con messaggi firmati, un messaggio per evento. Ogni messaggio è firmato dal nodo mittente e verificato dal nodo ricevente prima che accada qualsiasi cosa con esso. Un messaggio che fallisce il controllo viene rifiutato, e un messaggio già visto in precedenza viene rifiutato di nuovo — un nodo tiene un registro di ogni messaggio che ha già accettato.

Tutto quello che segue è ciò che questi messaggi contengono. Nient’altro viaggia.

Trovare una persona

Un nodo pubblica una risposta di discovery per ciascuna delle sue persone. Chiedigli un handle e restituisce l’handle di quella persona, il suo server di origine, la sua chiave di identità pubblica, e le versioni di protocollo che il nodo parla. La risposta è firmata.

Questa è l’intera risposta. Nessun indirizzo email, nessun punteggio di fiducia, nessun conteggio di connessioni, nessun nome. Chiunque conosca l’handle può leggere quella risposta, non solo gli altri nodi.

Se l’handle non esiste, il nodo lo dichiara — e firma anche questo, così che una rete di mezzo non possa inventare una risposta che dica che una persona non c’è più.

La discovery può essere disattivata, nel qual caso il nodo è buio e gli altri nodi non possono risolvere nessuno su di esso.

Cercare un codice

Quando qualcuno verifica un codice appartenente a una persona su un altro nodo, le parole stesse non viaggiano. Viaggia solo un hash di esse.

Risponde il nodo che possiede il codice. A seconda di che cosa è stato chiesto, la risposta è un semplice sì o no, oppure — in caso di corrispondenza — i dettagli che l’accompagnano: il nome visualizzato e la foto del proprietario del codice, come era etichettato il codice e a che cosa serviva, quando smette di essere valido, il suo punteggio di fiducia e i conteggi da cui è costruito, e l’organizzazione a cui appartiene il codice dove ne esiste una. Nient’altro sulla persona viene inviato.

Un codice ospite monouso viene consumato esattamente una volta anche se arrivano più richieste nello stesso istante; a chi perde la corsa viene detto che il codice è già consumato. Un faro riceve risposta allo stesso modo ma non viene mai consumato, perché è un controllo di presenza piuttosto che un codice monouso.

Se il proprietario di un faro ha scelto di mostrare il proprio indirizzo email su di esso, quell’indirizzo fa parte della risposta del faro. È un’impostazione che ciascuna persona attiva per sé, ed è disattivata a meno che non lo faccia.

Il nodo che possiede il codice registra chi ha chiesto.

Inviti

Un invito inviato a qualcuno su un altro nodo porta le chiavi di identità pubbliche delle due persone, il nome visualizzato di chi invita, un riferimento alla connessione sul nodo che invita, e il messaggio di invito cifrato.

Il nodo ricevente lo tiene in sospeso. Non crea un account e non crea una connessione. Non esiste nulla sul lato dell’invitato finché l’invitato stesso non accetta.

C’è un solo caso in cui un invito porta con sé un indirizzo email: quando un membro di un nodo invita qualcuno che non ha un account da nessuna parte e il nodo non può creare account da sé. Il nodo allora offre l’invito a trusted.codes, e l’indirizzo email della persona invitata lo accompagna, così che possa registrarsi lì. Quel comportamento è un’impostazione, è disattivato a meno che l’operatore non lo attivi, e il lato ricevente deve accettare offerte dal tuo nodo a sua volta. Vedi le impostazioni del nodo del tuo nodo per entrambe le metà.

Segreti della connessione

Il materiale che produce le parole di codice viste dalle due persone viene avvolto dal dispositivo della persona mittente per il dispositivo della persona ricevente. Passa attraverso entrambi i server come un blob opaco. Nessuno dei due server può aprirlo.

Le due persone vedono parole di codice corrispondenti perché i loro dispositivi le derivano da quel segreto condiviso. Anche ciascun server custodisce un proprio valore separato per la propria contabilità locale; quel valore non è ciò da cui provengono le parole di codice.

Il nome della connessione viaggia cifrato.

Cambiamenti di appartenenza

Quando qualcuno entra in una connessione, la lascia, o la connessione viene eliminata, l’altro nodo viene informato. Quando qualcuno elimina il proprio account, il suo nodo lo annuncia e ogni altro nodo rimuove ciò che custodiva su quell’identità. Quando un dispositivo viene rimosso, la rimozione viene annunciata così che gli altri nodi smettano di fidarsi della chiave di quel dispositivo.

Un nodo può anche chiedere a un altro nodo se una connessione che rispecchia esiste ancora e se determinate persone ne fanno ancora parte. Può chiedere solo di persone che già nomina. L’elenco dei membri non viene mai restituito per intero, e a un nodo che non fa parte di quella connessione non viene detto nulla.

Notifiche push

Un nodo che gestisce i propri utenti non può comunque inviare direttamente ad Apple e Google — le credenziali per l’app condivisa per telefono non spettano all’operatore. Così un nodo cede i token dei dispositivi a trusted.codes perché li consegni.

Il relay porta i token e il tipo di sveglia, nient’altro. Non c’è titolo e non c’è corpo. Il dispositivo si sveglia, chiede al proprio server di origine i dati veri, e li mostra localmente. Se il relay fallisce, non si rompe nulla; l’app si riallinea la prossima volta che viene aperta.

Che cosa non esce mai

Account, password e sessioni. Il database stesso. Il testo in chiaro di un codice. Il contenuto di un vault. Il nome e l’indirizzo email di chiunque non sia stato parte di uno scambio.

Qualsiasi chiave fornita dall’operatore per servizi opzionali — geolocalizzazione, IA, le dashboard — appartiene a quella installazione. Nessun altro le vede.