Ce qui passe entre les serveurs

Les nœuds se parlent en messages signés, un message par événement. Chaque message est signé par le nœud expéditeur et vérifié par le nœud destinataire avant qu’il ne s’y passe quoi que ce soit. Un message qui échoue à la vérification est refusé, et un message déjà vu est refusé à nouveau — un nœud garde une trace de chaque message qu’il a déjà accepté.

Tout ce qui suit est ce que contiennent ces messages. Rien d’autre ne voyage.

Trouver une personne

Un nœud publie une réponse de découverte pour chacune de ses personnes. Demande- lui un identifiant et il retourne l’identifiant de cette personne, son serveur d’origine, sa clé d’identité publique, et les versions de protocole que le nœud parle. La réponse est signée.

C’est toute la réponse. Pas d’adresse e-mail, pas de score de confiance, pas de nombre de connexions, pas de nom. Quiconque connaît l’identifiant peut lire cette réponse, pas seulement les autres nœuds.

Si l’identifiant n’existe pas, le nœud le dit — et signe aussi cette réponse, pour qu’un réseau intermédiaire ne puisse pas inventer une réponse disant qu’une personne a disparu.

La découverte peut être désactivée, auquel cas le nœud est invisible et les autres nœuds ne peuvent résoudre personne dessus.

Rechercher un code

Quand quelqu’un vérifie un code appartenant à une personne sur un autre nœud, les mots eux-mêmes ne voyagent pas. Seul un hash voyage.

Le nœud propriétaire du code répond. Selon ce qui était demandé, la réponse est soit un simple oui ou non, soit — en cas de correspondance — les détails qui vont avec : le nom affiché et la photo du propriétaire du code, comment le code était étiqueté et pourquoi il servait, quand il cesse d’être valide, son score de confiance et les compteurs dont il est fait, et l’organisation à laquelle le code appartient s’il y en a une. Rien d’autre sur la personne n’est envoyé.

Un code invité à usage unique est consommé une seule fois même si plusieurs demandes arrivent au même instant ; celles qui perdent la course apprennent que le code est déjà consommé. Une balise reçoit la même réponse mais n’est jamais consommée, parce que c’est un contrôle de présence plutôt qu’un code à usage unique.

Si le propriétaire d’une balise a choisi d’afficher son adresse e-mail dessus, cette adresse fait partie de la réponse de la balise. C’est un réglage que chacun active pour soi-même, et il est désactivé tant qu’on ne l’active pas.

Le nœud propriétaire du code enregistre qui a demandé.

Invitations

Une invitation envoyée à quelqu’un sur un autre nœud porte les clés d’identité publiques des deux personnes, le nom affiché de l’invitant, une référence à la connexion sur le nœud invitant, et le message d’invitation chiffré.

Le nœud destinataire la met en attente. Il ne crée pas de compte et ne crée pas de connexion. Rien n’existe du côté de l’invité tant que l’invité lui-même n’accepte pas.

Il y a un cas où une invitation porte une adresse e-mail : quand un membre d’un nœud invite quelqu’un qui n’a de compte nulle part et que le nœud ne peut pas créer de comptes lui-même. Le nœud propose alors l’invitation à trusted.codes, et l’adresse e-mail de la personne invitée l’accompagne, pour qu’elle puisse s’y inscrire. Ce comportement est un réglage, il est désactivé sauf si l’exploitant l’active, et le côté récepteur doit aussi accepter les propositions venant de ton nœud. Voir les réglages du nœud de ton serveur pour les deux moitiés.

Secrets de connexion

Le matériel qui produit les codes que voient deux personnes est enveloppé par l’appareil de la personne expéditrice pour l’appareil de la personne destinataire. Il traverse les deux serveurs comme un bloc opaque. Aucun des deux serveurs ne peut l’ouvrir.

Les deux personnes voient des codes qui correspondent parce que leurs appareils les dérivent de ce secret partagé. Chaque serveur détient aussi sa propre valeur séparée pour sa comptabilité locale ; cette valeur n’est pas d’où viennent les codes.

Le nom de la connexion voyage chiffré.

Changements d’appartenance

Quand quelqu’un rejoint une connexion, la quitte, ou que la connexion est supprimée, l’autre nœud en est informé. Quand quelqu’un supprime son compte, son nœud l’annonce et chaque autre nœud retire ce qu’il détenait sur cette identité. Quand un appareil est retiré, le retrait est annoncé pour que les autres nœuds cessent de faire confiance à la clé de cet appareil.

Un nœud peut aussi demander à un autre nœud si une connexion qu’il reflète existe encore et si certaines personnes en font encore partie. Il ne peut demander que sur des personnes qu’il nomme déjà. La liste des membres n’est jamais retournée, et un nœud qui ne fait pas lui-même partie de cette connexion n’apprend rien du tout.

Notifications push

Un nœud qui gère ses propres utilisateurs ne peut toujours pas envoyer directement à Apple et Google — les identifiants de l’application mobile partagée ne sont pas à l’exploitant de les détenir. Un nœud confie donc les jetons d’appareil à trusted.codes pour livraison.

Le relais porte les jetons et le type de réveil, rien d’autre. Il n’y a ni titre ni corps. L’appareil se réveille, demande les vraies données à son propre serveur d’origine, et les affiche localement. Si le relais échoue, rien ne casse ; l’application se rattrape la prochaine fois qu’elle est ouverte.

Ce qui ne sort jamais

Les comptes, les mots de passe et les sessions. La base de données elle-même. Le texte en clair d’un code. Le contenu d’un coffre. Le nom et l’adresse e-mail de quiconque n’a fait partie d’aucun échange.

Toute clé fournie par l’exploitant pour des services optionnels — géolocalisation, IA, tableaux de bord — appartient à ce déploiement. Personne d’autre ne les voit.