Local-First + Login-Optional

Die übliche Web-Architektur kommt mit einer impliziten Annahme: dass jede Aktion eine Server-Anfrage ist, jeder Datensatz eine Server- Zeile, und jedes Konto eine Server-Identität. Daraus folgt, dass jede Nutzung einer App eine Spur auf einem Server hinterlässt, auch wenn der Anbieter ehrlich vorhat, nichts damit zu tun.

Local-First dreht diese Grundannahme um. Die App ist zuerst eine Anwendung auf dem Gerät, mit ihrer eigenen Datenbank, ihrer eigenen Suche, ihrer eigenen KI-Inferenz, soweit Apple- und Open-Source-Modelle das leisten. Sync ist eine zusätzliche Funktion für Leute, die zwei Geräte haben — kein Default-Verhalten. Konto ist eine zusätzliche Funktion für Leute, die syncen oder mit Mana zahlen wollen — kein Eintritt für die App.

Daraus fällt eine ungewöhnliche Eigenschaft ab: man kann viele unserer Apps benutzen, ohne dass irgendwo am Verein eine Zeile über die Nutzerin existiert. Keine Statistik, kein Profil, kein „last seen”. Wir wissen, dass die App existiert und runtergeladen wurde — sonst nichts. Das ist nicht „Privacy by Marketing”, das ist „Privacy by absence of data”.

Die Kehrseite hängt mit der Architektur zusammen: Local-First- Datenmodelle sind anspruchsvoller als CRUD-Server, Sync-Konflikte muss man lösen, und einige Komfort-Features (z.B. Cross-App- Suggestions, Geräte-übergreifende Recall) funktionieren ohne Sync-Aktivierung nicht. Wir bauen das so, dass die Bequemlichkeit ein Knopf ist, den die Nutzerin drückt — nicht ein Default, der sie ohne ihr aktives Zutun erwischt.