Die eine architektonische Entscheidung, die alles andere in dieser App prägt, ist einfach zu formulieren und unbequem, tatsächlich um sie herum zu bauen: Die Fotoplatte wird streng schreibgeschützt geöffnet und nie beschrieben. Keine Begleitdatei neben den Originalen, kein versteckter Metadaten-Ordner, keine Umbenennung, keine verschobene Kopie. Die Festplatte, die hereinkommt, ist die Festplatte, die wieder herausgeht, Byte für Byte.
Diese Einschränkung klingt nach einem netten Extra, bis man merkt, was sie ausschließt. Sie schließt die gesamte Klasse von Tools aus, die deine Dateien „organisieren", indem sie sie verschieben oder umbenennen. Sie schließt es aus, irgendeinen abgeleiteten Zustand — Vorschaubilder, Gesichts-Embeddings, Ereignisgrenzen — irgendwo in der Nähe der Originale zu speichern. Alles, was die App über ein Archiv lernt, muss komplett anderswo leben, was bedeutete, früh zu entscheiden, wo dieses „anderswo" sein würde.
Alles Abgeleitete lebt auf der internen Festplatte
Die Antwort ist SQLite, auf der internen Festplatte des Macs, nicht auf der externen Festplatte. Der Index (Daten, Gesichter, Ereignisgrenzen, Embeddings für die Suche) und der Vorschaubild-Cache leben dort beide, vollständig getrennt vom Archiv selbst. Lösche das Datenverzeichnis der App, und das Archiv ist nachweislich unberührt, weil nichts am Archiv je von der Existenz dieses Verzeichnisses abhing. Installiere neu von Grund auf, und die App baut ihr Verständnis wieder auf, indem sie die Festplatte erneut liest, nicht indem sie einem Backup ihres eigenen Zustands vertrauen muss.
Das Write-Ahead-Log von SQLite war das einzelne Stück, das in der Praxis am meisten zählte, nicht in der Theorie. Während der Entwicklung gab es zwei buchstäbliche harte Abstürze — echte Stromausfälle, kein simulierter Fehlertest — mitten im Schreibvorgang, während die Analyse gegen ein echtes Archiv lief. Beide Male bedeutete WAL-Journaling null Datenverlust: Die Datenbank kam beim nächsten Start wieder in einem konsistenten Zustand hoch, machte ungefähr dort weiter, wo sie aufgehört hatte, und brauchte keine manuelle Reparatur. Das ist die Art von Garantie, die man gebraucht, aber nicht selbst getestet haben möchte — aber zwischen einer externen Festplatte, einer stundenlang laufenden Hintergrund-Analyse und einem Haushalt, in dem gelegentlich das Kabel angestoßen wird, wurde sie vor dem Launch echt getestet, zweimal.
Was „es lesen" tatsächlich zurückgewinnt
Eine Schreibschutz-Garantie ist nur so gut wie das, was man tatsächlich extrahieren kann, während man sie einhält, und Metadaten in einem echten Familienarchiv sind unordentlicher als ein saubere Testmenge. Im Gründungsarchiv trugen 92 % der Dateien von sich aus verwendbare EXIF-Daten. Die verbleibenden 8 % brauchten Ausweichlösungen — Dateisystem-Zeitstempel, Datumsangaben aus Ordnernamen, Ableitung aus benachbarten Fotos im selben Ereignis — und nach diesen Ausweichlösungen erreichte die Abdeckung 98,1 %. Diese letzten zwei Prozent sind der ehrliche Boden: Manche Dateien tragen einfach nirgendwo ein Signal, weder in der Datei noch um sie herum, und keine Ausweichkette erfindet eines aus dem Nichts.
Durchsuchbar, bevor das Verständnis fertig ist
Schreibschutz und abgeleiteter Zustand anderswo lösen das Sicherheitsproblem, aber es gibt ein separates Geduldsproblem: Eine vollständige Analyse eines großen Archivs dauert Stunden, und niemand will einen Fortschrittsbalken anstarren, bevor er ein einziges Foto ansehen kann. Die Bibliothek wird innerhalb von Minuten durchsuchbar, nachdem die App zum ersten Mal auf eine Festplatte gerichtet wurde — ein früher Durchlauf bringt genug vom Index und genug Vorschaubilder an ihren Platz, um das grundlegende Durchsuchen echt zu machen, nicht nur eine Attrappe davon. Die tieferen Durchläufe (Gesichts-Clustering, Ereignisbenennung, die Embeddings, die die Bedeutungssuche antreiben) laufen dahinter weiter, füllen still reichhaltigere Antworten aus, während du schon Fotos ansiehst, statt den ersten nützlichen Moment hinter den letzten teuren zu stellen.
Ressourcen-Governance ist eine Regel, kein Vorschlag
Das letzte Stück ist das, das sich leicht überspringen lässt und teuer wird, wenn man es schlecht überspringt: Eine Analyse, die einige Hunderttausend Dateien liest und versteht, ist wirklich schwere Arbeit, und schwere Hintergrundarbeit auf dem einzigen Mac einer Person, während sie versucht, ihn für etwas anderes zu nutzen, ist genau der Weg, wie „datenschutzfreundliche lokale KI" zu „warum ist mein Laptop ein Heizlüfter" wird. Die Regel hier ist eine harte, keine nach bestem Bemühen: Hintergrund-QoS-Priorisierung, damit die Analyse nie um Priorität mit Vordergrundarbeit konkurriert, adaptive Worker-Anzahlen, die sich innerhalb von Sekunden zurückziehen, sobald die Nutzerin oder der Nutzer aktiv wird, eine feste Obergrenze für den Speicherverbrauch und eine sofortige Pause bei Akku- oder Wärmedruck. Eine vollständige Analyse, die auf einem Basis-Mac läuft, sollte nichts sein, das man spüren kann. Wenn doch, ist das ein Fehler, kein Kompromiss.
Alles davon — schreibgeschützte Originale, abgeleiteter Zustand auf der internen Festplatte, absturzsicheres Journaling, Ressourcengrenzen, die tatsächlich halten — ergibt eine ziemlich unglamouröse Ingenieurs-These: Das Interessante an „local-first" ist nicht, dass die KI auf dem Gerät statt auf einem Server läuft, obwohl das stimmt. Es ist, dass es überhaupt keinen Server gibt, dem man vertrauen müsste, was bedeutet, dass jede dieser Garantien nur für eine einzige Maschine wahr sein muss, die auf deinem Schreibtisch steht und der du bereits alles andere darauf anvertraust.