Abgrenzung zu bestehenden Lösungen
Viele verfügbaren Apps und Projekte, die für mehr Selbstbestimmung werben, nutzen Dateien. Nur erfüllen Dateien bei weitem nicht mehr die Erwartung an moderne digitale Handlungsabläufe. Verglichen zu Tätigkeiten in Cloud-Anwendungen, könnte man den Vergleich zwischen Fax und E-Mail herstellen. Dateien spiegeln in ihrer hierarchischen Struktur und verfügbaren Formaten, nicht vollständig wider wie Nutzer:innen über ihre Daten wirklich nachdenken. Ebenso sind Dateien nicht gut indiziert, haben keine standardisierten Metadaten und sind daher unpraktisch und aufwendig zu organisieren und plattformübergreifend zu synchronisieren. Das wirkt sich dann auch auf die Sinnhaftigkeit von Import/Export Funktionalitäten von Apps aus. Nur weil es theoretische Möglichkeiten gibt, bedeutet das nicht, dass diese zugänglich, einfach oder sinnvoll sind.
Das Iza Projekt baut auf dem "local-first" Konzept auf und strebt an, ein Baustein in dem Ökosystem zu werden. Weil die Standardprogramme von Iza nicht direkt mit dem Internet interagieren, trifft der "-first" Teil des Begriffs nicht ganz zu, es sind einfach lokale Apps. Die 7 Ideale von local-first ("Fast, Multi-device, Offline, Collaboration, Longevity, Privacy, User control") werden trotzdem alle erfüllt. Das Paper von Ink & Switch ist hierzu sehr interessant und inspirierend.
local-first Apps und Bibliotheken sind ein sehr wichtiger Bestandteil der Lösung. Doch auch eine Fülle von local-first Apps wird nicht genügen, den Nutzer:innen möglichst viel Kontrolle zu geben und vor allem kontinuierlich zu garantieren. Nutzer:innen sind weiterhin stärker abhängig vom Wohlwollen der App-Anbieter als nötig.
Die Forderung nach einem "Firebase für local-first" wird an vielen Stellen gestellt, und dann meistens als ein erweiterbares/austauschbares SaaS (Software-as-a-Service) für local-first Apps skizziert. Iza kann vielleicht diesen Wunsch erfüllen, nur mit dem Perspektivwechsel (und potenzielle Einschränkungen), dass nicht die Entwickler:innen entscheiden welches Übertragungssystem genutzt wird, sondern die Nutzer:innen. Mit Iza werden verschiedene "state-based" Synchronisierungen mit verschiedenen Apps verknüpft.
Nextcloud ist eine großartige Software mit einem beachtlichen Ökosystem. Die ethischen Bestrebungen sind sehr ähnlich zu Iza. Dennoch ist Nextcloud eine Cloud-Anwendung. Auch wenn Nextcloud gedacht ist zum self-hosting, wird der Server, in der praktischen Umsetzung, immer noch von einem Unternehmen betrieben, welches dann lesbaren Zugriff auf die Daten hat. Dazu kommt das self-hosting nur eine kleine Zielgruppe bedient, also niemals für jeden funktionieren kann.
Das Solid Project hat einige überschneidende Aspekte mit Iza, aber ist sehr viel umfassender in der Auslegung. Iza geht einige Dinge pragmatischer an, z.B. braucht es kein vollständiges Vokabular für jedes Datenformat und eine Internetfunktionalität wird generell ausgeklammert und an Drittanbieter (Storage Provider) ausgelagert.
Syncthing ist fantastisch und auch große Inspiration für den lokalen Synchronisierung Ansatz von Iza. Syncthing funktioniert leider nur mit Dateien.
Es gibt verschiedene peer-to-peer (p2p) Frameworks und Konzepte die ebenfalls das Ziel haben Nutzer:innen mehr Kontrolle zu geben. Diese Projekte haben meistens als Ziel ein globales Netzwerk zu bilden, was eine Vielzahl großer Herausforderungen mit sich bringt. Unter anderem ist man abhängig vom Netzwerkeffekt und wegen der aktuellen Architektur des Internets sind Server trotzdem nötig. Hinzu kommen Fragen der Moderation und generell die Schwierigkeit einer guten Nutzererfahrung auf (digitale Identität und Verschlüsselung). Viele diese Herausforderung fallen weg, wenn man sich auf das lokale Netzwerk beschränkt.
Auch wenn globale P2P-Netzwerke spannende technische Projekte sind, bringen sie meiner Meinung nach fragwürdige Komplexität zur Lösung von Daten Speicherung/Übertragung mit sich. Durch ein allgemeines Datenformat und klare Verantwortlichkeiten, werden Cloud-Anbieter austauschbar und verlieren ihre Machtstellung. Wenn selektiver entschieden werden kann, welche Daten für welchen Zweck mit welchen Anbieter geteilt werden, ist bereits viel gewonnen, und das effiziente Konzept von Servern muss nicht komplett aufgegeben werden. Es spricht eigentlich nichts gegen eine bezahlte und verschlüsselte Backup-Dienstleistung.
Angedachte Funktionsweise der Iza Apps
Iza Agent
Der Iza Agent ist eine App, die im Hintergrund läuft und für alle Apps eine Schnittstelle über einen Unix-Socket anbietet, um auf die Daten der Nutzer:in zuzugreifen und neue hinzuzufügen.
Daten die geschrieben oder gelesen werden, sind alle in einem eigenen Datencontainer, das bestimmte Metadaten enthält, und ansonsten von Apps typisiert und beliebig mit Daten erweitert werden kann. Datencontainer sind als "Typen" für die Nutzer:in sichtbar und sind darauf zugeschnitten wie sie wirklich benutzt werden. Was vielleicht mal häufiger nicht der technischen Einordnung entspricht.
Zugriffsberechtigung. Wenn eine App sich das erste Mal mit dem Agent verbindet, muss die Nutzer:in das in der Benutzeroberfläche des Agents bestätigen. An der Stelle könnte langfristig auch präzise Zugriffsregeln für die spezifische App eingebaut werden. Diese Kontrolle ist nicht nur aus Sicherheitsgründen, sondern auch um einen kontrollierten Fluss zwischen Apps herzustellen, der die Aufteilung der Daten-Verantwortung bestärken soll.
Apps werden (ab Zugrifferteilung) unterschieden zwischen "Storage Provider" und normale Apps. Storage Provider sind für externe Speicher oder Synchronisierung-Apps gedacht.
Die normalen Apps können Daten schreiben und lesen. Es gibt eine Suchfunktion die nach Metadaten (also z.B. Datum und Referenzen) sucht. Apps können dem Agent ein Typschema bereitstellen, sodass bestimmte Felder eines Anwendungsspezifischen-Formats, von der Iza Agent Suche durchsuchbar werden. Das gilt dann aber auch immer für alle Apps und führt im besten Fall zu mehr Teil-Offenlegung von Datenformaten.
Die Storage Provider Apps dürfen die Daten lesen, einen Index mit Versionen abfragen (um diesen mit ihrem eigenen Bestand zu vergleichen) und sie dürfen nur Daten im Agent schreiben, wenn diese "woanders" verändert wurde. Im Gegenzug wird beim Schreiben eine Konflikterkennung durchgeführt und ggf. ein Konflikt erstellt, der von einer App, die mit diesem Datenformat was anfangen kann, gelöst werden kann (automatisch oder manuell). Die Konflikterstellung erfolgt auf Basis von Versions-Vektoren, sodass einzelne Apps ein CRDT oder ähnliches als Datenformat nutzen können. Außerdem können Storage Provider dem Iza Agent eine Liste von "Share-Destinations" zur Verfügung stellen, die aussagen, wohin dieser Provider Daten teilen kann. Die kann die Nutzer:in dann wiederum in anderen Apps auswählen und dadurch spezifische Daten dem Storage Provider verfügbar machen.
Der Agent soll auf allen Geräten der Nutzer:in gleichzeitig laufen. Der Agent kann auch auf einem Server oder Raspberry-Pi in der Command-Line betrieben und ohne Benutzeroberfläche konfiguriert werden.
Neben der Möglichkeit App Zugriffsberechtigungen zu konfigurieren, bietet der Agent auch ein Storage Management an. Alle regulär genutzten Agents einer Nutzer:in sollten den gleichen Daten Index haben. Nur möchte man womöglich nicht auf jedem Gerät die großen Filmdateien oder die gesamte Foto-Bibliothek automatisch herunterladen. Das ist also für jedes Gerät konfigurierbar.
Apps sollen nicht einfach immer alles in dem Agent speichern. Am Ende entscheidet natürlich immer die Nutzer:in, aber grundsätzlich sollten es nur Daten seien, mit der die Nutzer:innen was anfangen können.
Iza Navigator
Hintergrund
Apps haben sich zunehmend dazu hin gewandelt ihre eigenen Datenverwaltung-Benutzeroberflächen zu implementieren und die Dateimanager der Betriebsysteme außen vorzulassen. Auf Smartphones wurden Dateimanager nie richtig etabliert.
Damit das Iza Konzept funktioniert, muss den Nutzer:innen kontinuierlich vermittelt werden, über welche Daten sie Handlungsmacht und eigene Kontrolle besitzen. Ein System mit fragmentierten Datenverwaltungen in den jeweiligen Apps wird dem wahrscheinlich nicht gerecht. Nötig ist eine zentrale und allgemeine Datenverwaltung, wie zum Beispiel der Iza Navigator sie anbietet. Die große Menge der Daten, die transparent dargestellt werden sollen, braucht neue Interaktionskonzepte, die für einige Nutzer:innen ungewohnt sein werden. Neben starken Fokus auf UX und Ergebnisse von User-Tests, ist es auch wichtig, dass so ein Navigator universell ist, also auf allen Plattformen verfügbar und gleich funktioniert. Also die neuen Interaktionen nur einmal erlernt werden müssen.
Eine zentrale und private Datenverwaltung kann viele neue und praktische Dinge ermöglichen. Auch in die andere Richtung benötigt eine App wie der Iza Navigator das Iza Konzept und so ein Programm wie den Iza Agent, das viele verschiedene Datenformate zusammenführt. Ein Iza Navigator könnte nicht umgesetzt werden, wenn es nur mit Dateien arbeitet.
Der Iza Navigator nutzt wie jede andere Drittanbieter-App die Iza Agent Schnittstelle für normale Apps. Bei Bedarf kann die App mit anderen Datenverwaltung-Apps ausgetauscht werden, auch welche mit fundamental anderen Ansätzen.
Im Navigator können alle Daten mühelos miteinander referenziert werden. Entlang dieser Referenzen kann dann entlang navigiert werden. Es gibt einige Produktivität-Apps, die das als "Wikilinks" oder Ähnliches umsetzen. So eine Funktion bildet sehr viel besser ab, wie wir über Daten nachdenken und arbeiten. Mit Dateien ist es bisher nicht möglich so etwas umzusetzen. Auf diesem Weg die App-Begrenzung aufzubrechen wird einige neue und praktische Fähigkeiten ermöglichen.
Beispiel Szenario. Du kannst von einem Kalendereintrag, dir deine Foto-Bibliothek zu dem gleichen Zeitpunkt ansehen. Du kannst dir den Ort von einem Foto, auf der Weltkarte anzeigen lassen und schauen, was für Musik du an einem spezifischen Ort entdeckt und zu Iza hinzugefügt hast. Und das komplett ohne Zutun einer bestimmten App (oder einer KI) und das einfach nur mit den Fähigkeiten von Metadaten.
Es ist eine berechtigte Frage, ob solche "coolen" Funktionen, wie eine detaillierte Standortaufzeichnung, angeboten werden sollten. Auch wenn im Falle von Iza niemand darauf standardmäßigen Vollzugriff hat, steht das im Gegensatz zum Prinzip der Datensparsamkeit. Schlussendlich muss das abgewogen werden mit der Konkurrenzfähigkeit zu typischen Cloud-Anwendungen.
Die Organisation im Navigator ist dazu optimiert mit Referenzen und mit Tags (Schlagwörter) zu arbeiten. Tags sind aber ein Zusatz, zu den vielen impliziten und manuellen Referenzen. Tags werden vom Navigator als eigenes (nicht sichtbares) Datenformat hinzugefügt und sind nicht Teil des allgemeinen Iza Konzepts.
Darstellung von Daten
Die Suche ist für Geräte ohne Tastatur einfach zu bedienen, indem alle Referenzen als Filter Optionen angezeigt werden. Alle Referenzoptionen sind miteinander kombinierbar, seien es "Tags", Personen, der Datenformat-Typ (Fotos, Text, etc.), Orte oder Zeitpunkte. Es werden nur die Optionen angezeigt, die nach einer Kombination auch Resultate liefern ("faceted search"). Für Geräte mit Tastatur können die Filter Optionen in einem Textfeld mit Autovervollständigung ausgewählt werden.
Die Anzeige der Suchresultate passt sich dem Datenformat an, falls nur ein Datenformat in den Resultaten beinhaltet ist. So werden Medien in einem Kachelmuster angezeigt, wie das z.B. gewohnt ist von Foto-Bibliotheken. Die ausgewählten Suchfilter können gespeichert werden um sie z.B. als Shortcut zu hinterlegen und gleiche Suche nochmal auszuführen.
Alle Daten, auch unbekannte Formate, werden innerhalb Listen dargestellt. Für diese Vorschau können Apps einem Datencontainer einen Titel, einen kleinen Text und/oder ein Thumbnail in den Metadaten speichern. Der Datencontainer kann direkt in einer, von der Nutzer:in ausgewählten App, geöffnet werden, oder im Navigator die Detail-Ansicht öffnen.
Die Attraktivität des Navigators wird erhöht, indem bestimmte typische Datenformate direkt sinnvoll in der Detail-Ansicht mit interagiert werden können (z.B. Text, Media- und Produktivitäts-Formate). Um das realisierbar für alle Plattformen zu machen (inkl. CLI), werden einfache Formate präferiert und stattdessen die Möglichkeit geboten Daten untereinander zu referenzieren. Also anstatt ein Bild in einen Fließtext zu setzen, wird das Bild als global verfügbare Referenz gespeichert.
Funktionen zur Interaktion mit Storage Provider
Wenn der Agent durch die Interaktion mit Storage Provider, einen Daten-Konflikt erkennt, wird der gespeichert. Falls dieser nicht von einer App automatisch schon im Hintergrund gelöst wurde, wird der Konflikt der Nutzer:in angezeigt und die Möglichkeit geboten, sich die Daten Vorschau beider Versionen anzusehen, für eine zu entscheiden oder in zwei Versionen aufzuteilen.
Storage Provider wurden in der Sektion zum Iza Agent genauer erläutert. In der Detail-Ansicht von Daten wird in einem Menü dargestellt, auf welchen anderen Geräten oder Cloud-Anbieter die jeweiligen Daten verfügbar sind. Zusätzlich können in diesem Menü, die sog. "Share-Destinations" eines Storage Provider hinzu- oder abgewählt werden. Mit den Share-Destinations wird dem Agent mitgeteilt, welche Daten welchen Storage Provider verfügbar sein sollen. Damit hat die Nutzer:in eine direkte differenzierte Möglichkeit zu steuern, an welche Personen oder Gruppen, über welche Plattform, ihre Daten übertragen werden.
Iza Local Sync
Iza Local Sync ist die standardmäßige Komponente von Iza, um die eigenen Daten mit persönlichen Geräten im gleichen lokalen Netzwerk zu synchronisieren und mit Geräten anderer Personen Daten selektiv zu teilen. Dafür nutzt die App die Iza Agent Schnittstelle, wie jeder andere Storage Provider eines Drittanbieters.
Mehrere Geräte einer Person mit einem Iza Agent und der Local Sync App bilden einen Synchronisierungs-Cluster. Jedes Mal, wenn sich zwei Geräte automatisch finden, schicken sie sich ihren Daten-Index mit Versionen, sodass das andere Gerät überprüfen kann, ob es sich neuere Versionen herunterladen kann. Es wird ein einfaches einfache Remote-Procedure-Call Protokoll über TCP genutzt. Die Daten werden nicht direkt an (oder "über") andere verbundene Geräte weitergeleitet, sie werden lediglich informiert über eine Veränderung des Daten-Index und können selber entscheiden, welche Daten sie herunterladen. Mit diesem "Benachrichtigungs-Pull-Prinzip" wird die Komplexität gering gehalten. Für diese Funktionsweise war Syncthing eine Inspiration.
Zu dem Protokoll soll noch TLS hinzugefügt werden, um die Übertragungen zu sichern.
Die Benutzeroberfläche von der Local Sync App, beschränkt sich auf die Konfiguration von dem persönlichen Synchronisierungs-Cluster.
Storage Provider die globale P2P-Netzwerk Protokolle implementieren, könnten eine Alternative zu dieser App bieten.
Hintergrund
So eine Funktionalität muss heutzutage von Apps meist selbst umgesetzt werden, weil die bereitgestellten Funktionen der Betriebsysteme, keinen ausreichenden Funktionsumfang bieten, nicht existieren oder an eine bestimmte Plattform gebunden sind. Die meisten Apps sparen sich den Entwicklungsaufwand. Dateien innerhalb lokaler Netzwerke zu übertragen, muss meistens manuell mit Kopieren oder Verschieben durchgeführt werden. Das ist weit entfernt von der praktischen Nutzererfahrung mit vielen Cloud-Anbietern und Apps mit Cloud-Anbindung.
Doch diese lokale Möglichkeit sollte zumindest immer als Ausweichmöglichkeit existieren, und muss mindestens genauso praktisch in der Benutzung sein, wie wenn mit Cloud-Anbietern interagiert wird. Das ist technisch ohne weiteres umsetzbar. Lokale Übertragungen haben den Nachteil der begrenzten Verfügbarkeit, also das beide Geräte z.B. angeschaltet im gleichen WLAN sein müssen. Wenn die Nutzer:in ein Foto abrufen will, während sie in der S-Bahn sitzt und ihr Laptop zu Hause ist, geht das nicht unbedingt. Doch für die Fälle bei denen die Nutzer:in zu Hause ist, ist dieses Standardverhalten wahrscheinlich sogar schneller (keine Umwege über Datacenter) und einfach unabdingbar für eine umfassende Selbstbestimmung.
