Technologien

Der kryptografische Kern unseres Messengers ist in Rust geschrieben und vollständig von der Anwendung getrennt. iOS, Android, Windows, macOS und Linux verwenden dieselbe Umsetzung, mit identischem Verhalten auf jedem Gerät. Sicherheitsprüfungen betreffen dadurch genau eine Stelle statt fünf.

Für Schlüsselaustausch und Sitzungsverwaltung setzen wir auf Messaging Layer Security nach RFC 9420 über OpenMLS. Der Standard erkennt Manipulation und sichert Forward Secrecy zu: ein später kompromittierter Schlüssel gibt frühere Nachrichten nicht preis.

Private Schlüssel entstehen im Schlüsselspeicher des Betriebssystems und verlassen ihn nie. Der Server verarbeitet ausschliesslich Chiffrat, ein kompromittierter Server bedeutet deshalb keine gelesenen Inhalte.

Der Empfehlungsfeed unserer Social-Media-Plattform rankt mehrstufig. Ein HNSW-Vektorindex auf pgvector ermittelt zuerst die semantisch nächstliegenden Kandidaten, erst danach greift die teurere Bewertung aus Interessenprofil, Aktualität, Popularität und Diversität. Die Rechenzeit bleibt dadurch nahezu konstant, unabhängig davon, wie gross der Gesamtbestand wird.

Datenstrukturen legen wir so an, dass Millionen Beiträge verwaltet und relevante Inhalte gefunden werden können, ohne die Datenbank vollständig zu durchsuchen.

Was nicht sofort fertig sein muss, läuft über Warteschlangen: Medienverarbeitung, Analysen, Versand. Lastspitzen verlängern dann eine Schlange, statt Antwortzeiten zu verschlechtern.

Jeder Upload auf unserer Plattform durchläuft eine mehrstufige Analyse. CLIP ViT-L/14 überführt das Bild in ein 768-dimensionales Embedding, ein Bildbeschreibungsmodell erzeugt Text und Schlagwörter, ein Klassifikator markiert heikle Inhalte.

Für Objekterkennung arbeiten wir mit YOLO11 und Faster R-CNN, für Anomalieerkennung mit PatchCore. Welches Verfahren zum Einsatz kommt, entscheiden Messungen auf den echten Daten und nicht der Ruf des Modells.

Training läuft lokal auf eigener Hardware mit CUDA. Zwischenstände werden gesichert, sodass ein Lauf fortgesetzt statt neu begonnen wird, und jede Änderung wird gegen denselben Prüfsatz gemessen, damit Zahlen über Wochen vergleichbar bleiben.

Zeitgesteuerte Arbeit läuft über Cloud Tasks. Jeder geplante Vorgang bekommt einen eigenen Task mit exakter Auslösezeit, bis zu 30 Tage im Voraus. Der Taskname wird deterministisch abgeleitet, wodurch bereits das Anlegen idempotent ist: zwei Auslöser erzeugen denselben Task, nicht zwei.

Warteschlangen stellen grundsätzlich mindestens einmal zu. Ohne zusätzliche Absicherung entstehen daraus Doppelausführungen, deshalb gibt jeder Vorgang zusätzlich genau einmal frei, was zu tun ist.

Dateien liegen inhaltsadressiert in S3-kompatiblem Objektspeicher, ausgeliefert über ein Content-Delivery-Netz. Wo Daten das Haus nicht verlassen dürfen, läuft dasselbe auf eigenen Servern.

Wir arbeiten mit Flutter und React Native. Beide haben Stärken, die je nach Projekt den Ausschlag geben: enge Anbindung an bestehenden nativen Code, Anforderungen an die Darstellung, vorhandenes Wissen im Team des Kunden.

Grosse Listen stellen wir virtualisiert dar und laden vorausschauend nach. Übertragen wird nur, was tatsächlich gebraucht wird, damit auch sehr grosse Bestände auf dem Handy flüssig bleiben.

Veröffentlichung im App Store und bei Google Play gehört dazu, von Zertifikaten und Signierung über die Review-Auflagen bis zu Updates und Absturz-Auswertung nach dem Start.

Eigene Server ergeben dort Sinn, wo Vorgaben oder Verträge es verlangen, wo Datenmengen die Cloud teuer machen, oder wo eine dauerhaft laufende Berechnung günstiger auf eigener Hardware liegt als auf gemieteter. Für das Training unserer Modelle gilt genau das.

Wir betreiben beides und mischen, wo es passt: rechenintensive Arbeit und sensible Daten im Haus, weltweite Auslieferung über ein Content-Delivery-Netz. Was wo läuft, ist eine Entscheidung pro Projekt und keine Grundsatzfrage.