Ziele & Roadmap

Vier Vorhaben stehen an. Sie sind nach Wirkung sortiert, nicht nach Aufwand – und keines davon hat ein Datum, weil TalX ein privates Projekt ohne Team dahinter ist. Was hier steht, ist eine Absicht, keine Zusage.

1 · Unabhängiges externes Audit

Warum es an erster Stelle steht: Es ist der einzige Punkt, den TalX aus eigener Kraft nicht lösen kann. Alle bisherigen Prüfungen sind intern – gründlich dokumentiert, regressionsgetestet, auf echter Hardware nachgemessen. Aber Betriebsblindheit lässt sich nicht durch mehr eigene Sorgfalt beseitigen. Genau das ist der Sinn eines externen Blicks.

Der Befund ist als F-07 mit Schweregrad hoch offen geführt, und die Empfehlung des internen Berichts ist eindeutig: vor jeder 1.0- oder Produktivaussage ein Audit durch ein spezialisiertes Labor.

Vorgesehene Schwerpunkte:

• der Ratchet-Bootstrap einschließlich der serverlosen Prekey-Rotation,
• die Choreografie des passwortauthentifizierten Schlüsselaustauschs,
• die Integration des Post-Quanten-Anteils in den Wurzelschlüssel,
• Anruf- und Medien-Signalisierung,
• das Protokoll der Vermittlung.

Was es blockiert: Geld. Ein Audit dieser Art ist die mit Abstand teuerste Position des Projekts – und der wichtigste Grund, warum es überhaupt eine Spendenseite gibt.

Bis dahin bleibt der Satz stehen: TalX ist nicht auditiert.

2 · Erweiterung der Serverlandschaft

Das Problem heute: Die serverlosen Wege funktionieren ohne jede Infrastruktur – im Nahfunk, im lokalen Netz, direkt zwischen zwei Geräten. Sobald aber eine Nachricht an einen gerade offline befindlichen Kontakt über das Internet gehen soll, läuft sie über eine einzelne, vom Projekt betriebene Vermittlung. Sie ist selbst betreibbar, aber es ist ein einzelner Punkt.

Das Ziel: ein Verbund statt eines einzelnen Knotens.

• Mehrere Standorte statt eines, damit ein Ausfall nicht die gesamte Internet-Zustellung trifft.
• Geografische Nähe – die Vermittlung mit der kürzesten Laufzeit gewinnt.
• Gemeinsamer Store-and-Forward-Puffer, damit es keine Rolle spielt, an welchem Knoten ein Gerät gerade hängt.
• Föderation: Ein selbst betriebener Knoten soll gleichberechtigt mitspielen können, nicht bloß ein isolierter Ersatz sein.

Der schwierige Teil ist nicht die Technik, sondern die Metadaten. Mehr Knoten heißt zunächst mehr Stellen, an denen sichtbar wird, wer wann mit wem kommuniziert. Der Ausbau soll deshalb zusammen mit einer Verbesserung an dieser Front kommen – die Absenderkennung gegenüber dem Betreiber ist heute sichtbar, und daran ändert der Absender-Marker im Chunk nichts.

Was sich dabei nicht ändert: Ein Knoten sieht ausschließlich Ciphertext. Das ist keine Betriebsentscheidung, sondern eine Eigenschaft des Protokolls.

3 · iOS-Version

Die größte Funktionslücke im Alltag. TalX ist Android-only. In gemischten Freundeskreisen ist das ein K.o.-Kriterium – nicht weil die App etwas nicht kann, sondern weil die Hälfte der Leute sie nicht installieren kann.

Was auf iOS anders wird, ehrlich vorweg:

Baustein	Auf Android heute	Auf iOS zu erwarten
Nahfunk offline	Google Nearby Connections (Bluetooth, WLAN-Direct)	Muss neu gebaut werden – die Plattform bietet eigene Bausteine mit anderen Eigenschaften
Lokales Netz	mDNS und direkte TCP-Verbindung	vergleichbar machbar
Empfang bei geschlossener App	Vordergrunddienst	deutlich enger reglementiert; Push wird eine größere Rolle spielen
Schlüsselaufbewahrung	Android-Keystore, StrongBox	Secure Enclave – konzeptionell vergleichbar
Transkription und Übersetzung	On-Device-Engines	Ersatz nötig

Ein Teil der Serverlosigkeit wird auf iOS also mehr Arbeit kosten oder anders aussehen. Das gehört gesagt, bevor jemand eine 1:1-Portierung erwartet.

Voraussetzung ist Punkt 4: Solange die Kryptografie im Android-Code verwoben ist, hieße eine iOS-Version, sie ein zweites Mal zu schreiben. Zwei Implementierungen desselben Protokolls sind zwei Gelegenheiten, es unterschiedlich falsch zu machen.

4 · Eigener modularer Krypto-Kern

Was gemeint ist: Die kryptografische Kernlogik – Ratchet, Prekey-Bootstrap, Post-Quanten-Einmischung, Sender-Keys, Wire-Format, Schlüsselhierarchie – soll aus der App herausgelöst und zu einer eigenständigen, plattformunabhängigen Einheit werden.

Was ausdrücklich nicht gemeint ist: eigene Chiffren. Der Grundsatz „kein selbstgebauter Chiffren-Code“ bleibt unangetastet. X25519, AES-GCM, HKDF, HMAC, ML-KEM, Argon2id und J-PAKE kommen weiterhin aus geprüften Bibliotheken. Modular wird die Schicht darüber – die Protokolllogik, die diese Bausteine zusammensetzt.

Was das bringt:

• Eine Implementierung für alle Plattformen. Android und iOS teilen sich denselben Kern statt zweier Varianten, die auseinanderlaufen.
• Ein klar umrissener Prüfgegenstand. Ein Audit, das auf ein Modul mit definierter Schnittstelle schaut, ist gründlicher und billiger als eines, das den Kern aus einer App herausklauben muss. Punkt 4 macht Punkt 1 wohlfeiler.
• Austauschbare Bausteine. Wenn ein Verfahren ersetzt werden muss – und irgendwann muss es das –, ist der Eingriff auf ein Modul begrenzt statt über die App verstreut.
• Testbarkeit ohne Gerät. Je mehr Protokolllogik ohne Android-Laufzeit prüfbar ist, desto mehr davon läuft in jedem Testlauf mit.

Der Preis: Ein Umbau am Krypto-Kern ist der riskanteste Umbau, den dieses Projekt machen kann. Er muss über die Rückwärtskompatibilitäts-Zusage hinweg funktionieren – mindestens zehn App-Versionen bleiben sende- und empfangsfähig zueinander. Das heißt: kein Stichtag, keine Umstellung auf einen Schlag, sondern Modul für Modul mit Regressionstests gegen den alten Weg.

Kleinere Vorhaben

Aus den internen Berichten, ohne Reihenfolge:

• Anonyme Zustellung („Sealed Sender“), damit der Betreiber der Vermittlung nicht mehr sieht, wer wem schreibt. Ehrlich dazu: Das erfordert eine Änderung am Server, und selbst danach bliebe die Zuordnung über die IP-Adresse – ohne einen zusätzlichen Schritt in dieser Richtung ist es nur ein halber Gewinn.
• Verschlüsselte Ratchet-Kopfdaten.
• Ephemere Dienstkennungen im lokalen Netz, die pro Sitzung wechseln, statt dauerhaft die eigene Kennung zu zeigen – mit Identitätsauflösung erst nach dem Verbindungsaufbau.
• Frischenachweis für Anruf- und Verbindungssignale.
• Getrennter, an die Nutzer-Entsperrung gebundener Schlüssel für besonders sensible Teile, ohne den Hintergrundempfang zu verlieren.
• Vollständiger Nachweis des Wiederherstellungswegs mit Cloud-Download und zweitem Faktor auf einem echten Gerät.
• Reproduzierbare Builds, damit unabhängig nachrechenbar wird, dass die ausgelieferte App aus genau diesem Quelltext entstand.

Was nicht kommt

Damit auch das klar ist: keine Status-Stories, keine Kanäle, keine Communities, kein Sticker-Ökosystem, keine Bots, keine Werbung, keine Analytik. Das sind keine offenen Punkte, sondern Entscheidungen.