Was zwischen Servern übertragen wird

Knoten sprechen miteinander in signierten Nachrichten, eine Nachricht pro Ereignis. Jede Nachricht wird vom sendenden Knoten signiert und vom empfangenden Knoten geprüft, bevor irgendetwas damit geschieht. Eine Nachricht, die die Prüfung nicht besteht, wird abgelehnt, und eine Nachricht, die bereits einmal gesehen wurde, wird erneut abgelehnt — ein Knoten führt Buch über jede Nachricht, die er bereits angenommen hat.

Alles Folgende ist, was diese Nachrichten enthalten. Nichts anderes reist mit.

Eine Person finden

Ein Knoten veröffentlicht für jede seiner Personen eine Antwort auf Auffindungsanfragen. Frag ihn nach einem Handle, und er gibt das Handle dieser Person, ihren Heimatserver, ihren öffentlichen Identitätsschlüssel und die Protokollversionen zurück, die der Knoten spricht. Die Antwort ist signiert.

Das ist die ganze Antwort. Keine E-Mail-Adresse, kein Trust Score, keine Anzahl an Verbindungen, kein Name. Wer das Handle kennt, kann diese Antwort lesen, nicht nur andere Knoten.

Existiert das Handle nicht, sagt der Knoten das — und signiert auch das, damit ein Netzwerk dazwischen keine Antwort erfinden kann, die vorgibt, eine Person sei verschwunden.

Das Auffinden lässt sich abschalten; der Knoten ist dann dunkel, und andere Knoten können niemanden auf ihm auflösen.

Einen Code nachschlagen

Wenn jemand einen Code verifiziert, der einer Person auf einem anderen Knoten gehört, reisen die Wörter selbst nicht mit. Nur ein Hash davon.

Der Knoten, dem der Code gehört, antwortet. Je nachdem, wonach gefragt wurde, ist die Antwort entweder ein einfaches Ja oder Nein, oder — bei einer Übereinstimmung — die dazugehörigen Details: der Anzeigename und das Bild der Code-Eigentümerin oder des Code-Eigentümers, wie der Code beschriftet war und wofür er gedacht war, wann er ungültig wird, ihr Trust Score samt der Werte, aus denen er sich zusammensetzt, sowie die Organisation, zu der der Code gehört, sofern es eine gibt. Sonst wird nichts über die Person gesendet.

Ein einmal verwendbarer Gastcode wird genau einmal verbraucht, selbst wenn mehrere Anfragen im selben Moment eintreffen; wer das Rennen verliert, erfährt, dass der Code bereits verbraucht ist. Ein Beacon wird auf dieselbe Weise beantwortet, aber nie verbraucht, weil er eine Lebendigkeitsprüfung ist und kein Einmalcode.

Hat die Eigentümerin oder der Eigentümer eines Beacons entschieden, ihre E-Mail-Adresse daran anzuzeigen, ist diese Adresse Teil der Beacon-Antwort. Das ist eine Einstellung, die jede Person für sich selbst aktiviert, und sie ist abgeschaltet, sofern sie das nicht tut.

Der Knoten, dem der Code gehört, zeichnet auf, wer gefragt hat.

Einladungen

Eine Einladung, die an jemanden auf einem anderen Knoten geschickt wird, trägt die öffentlichen Identitätsschlüssel der beiden Personen, den Anzeigenamen der einladenden Person, einen Verweis auf die Verbindung auf dem einladenden Knoten und die verschlüsselte Einladungsnachricht.

Der empfangende Knoten legt sie zwischen. Er legt weder ein Konto noch eine Verbindung an. Nichts existiert auf der Seite der eingeladenen Person, bis sie selbst annimmt.

Es gibt einen Fall, in dem eine Einladung eine E-Mail-Adresse trägt: wenn ein Mitglied eines Knotens jemanden einlädt, der nirgendwo ein Konto hat, und der Knoten selbst keine Konten anlegen kann. Der Knoten bietet die Einladung dann trusted.codes an, und die E-Mail-Adresse der eingeladenen Person geht mit, damit sie sich dort registrieren kann. Dieses Verhalten ist eine Einstellung, sie ist abgeschaltet, sofern der Betreiber sie nicht einschaltet, und die empfangende Seite muss ebenfalls Angebote von deinem Knoten akzeptieren. Beide Hälften findest du unter Node Settings deines Knotens.

Verbindungsgeheimnisse

Das Material, das die Codewörter erzeugt, die zwei Personen sehen, wird vom Gerät der sendenden Person für das Gerät der empfangenden Person eingehüllt. Es passiert beide Server als undurchsichtiger Datenblock. Kein Server kann es öffnen.

Die beiden Personen sehen übereinstimmende Codewörter, weil ihre Geräte diese aus demselben gemeinsamen Geheimnis ableiten. Jeder Server hält zusätzlich seinen eigenen, separaten Wert für seine eigene lokale Buchführung; aus diesem Wert leiten sich die Codewörter nicht ab.

Der Name der Verbindung reist verschlüsselt.

Änderungen der Mitgliedschaft

Tritt jemand einer Verbindung bei, verlässt sie, oder wird die Verbindung gelöscht, wird der andere Knoten informiert. Löscht jemand sein Konto, verkündet sein Knoten das, und jeder andere Knoten entfernt, was er zu dieser Identität gespeichert hatte. Wird ein Gerät entfernt, wird die Entfernung angekündigt, damit andere Knoten dem Schlüssel dieses Geräts nicht mehr vertrauen.

Ein Knoten kann einen anderen Knoten auch fragen, ob eine Verbindung, die er spiegelt, noch existiert und ob bestimmte Personen noch darin sind. Er darf nur nach Personen fragen, die er bereits benennt. Die Mitgliederliste wird nie zurückgemeldet, und ein Knoten, der selbst nicht Teil dieser Verbindung ist, erfährt gar nichts.

Push-Benachrichtigungen

Ein Knoten, der eigene Nutzer betreibt, kann trotzdem nicht direkt an Apple und Google senden — die Zugangsdaten für die gemeinsam genutzte Mobile App gehören nicht dem Betreiber. Deshalb übergibt ein Knoten die Geräte-Tokens zur Zustellung an trusted.codes.

Das Relais trägt nur die Tokens und die Art des Weckens, sonst nichts. Es gibt weder Titel noch Text. Das Gerät wacht auf, fragt seinen eigenen Heimatserver nach den echten Daten und zeigt sie lokal an. Scheitert das Relais, geht nichts kaputt; die App holt beim nächsten Öffnen einfach nach.

Was den Knoten nie verlässt

Konten, Passwörter und Sitzungen. Die Datenbank selbst. Der Klartext eines Codes. Der Inhalt eines Tresors. Name und E-Mail-Adresse von jedem, der nicht Teil eines Austauschs war.

Alle Schlüssel, die der Betreiber für optionale Dienste hinterlegt hat — Geolokalisierung, KI, die Dashboards — gehören zu dieser Installation. Niemand sonst sieht sie.