Cross-App-Timeline — jede Änderung ist sichtbar, auch KI-Änderungen
Eine zentrale Zeitleiste über alle Vereins-Apps zeigt in Echtzeit, was sich in den eigenen Daten geändert hat — von wem, wann, in welcher App, und ob ein Mensch oder eine KI sie geschrieben hat.
Die übliche Software-Sicht auf Daten-Änderungen sieht so aus: man öffnet eine App, sieht den aktuellen Stand, und nimmt an, dass alles, was dort steht, von einem selbst stammt. Manchmal stimmt das. Manchmal hat die App im Hintergrund Daten ergänzt, eine KI hat Vorschläge in eigene Notizen geschrieben, ein automatischer Sync hat Konflikte aufgelöst. Das alles passiert lautlos.
Wir wollten das umdrehen. Wenn alle Schreibungen ohnehin als Events durch
den sync2-Ledger laufen, lässt sich daraus trivial eine Zeitleiste
ableiten — eine, die auch zeigt, was sonst stillschweigend passiert
wäre. hub.mana.how/timeline ist genau das: die chronologische Sicht
auf alle eigenen Änderungen über alle Vereins-Apps, mit Akteur-Attribution.
Ein menschlicher Edit sieht anders aus als ein Service-Schreib,
und ein KI-Edit sieht wieder anders aus.
Die Pointe: das ist keine Marketing-Feature. Es ist ein Read-Modell auf die existierende Event-Geschichte, ein paar hundert Zeilen Code. Sobald die Daten-Architektur (siehe Event-Sourcing) richtig sitzt, fällt die Timeline daraus ab. Genauso die Export-Funktion, das Audit-Log, die DSGVO-Auskunft — alles Sichten auf denselben Ledger.
Wir sind in Phase 1: Aggregation im Browser, ohne Server-seitige Verkettung. Phase 2 (native App), Phase 3 (KI-Erklärungen direkt am Event), Phase 4 (App-Vignetten in der Timeline) bauen wir später, wenn das Fundament tragfähig ist. Für heute reicht uns die Behauptung: es gibt keine stille KI-Schreibung in einer mana-App, die nicht in der Timeline auftaucht.
Wie genau das funktioniert
- `hub.mana.how/timeline` aggregiert client-seitig Events aus allen Apps der angemeldeten Nutzerin in einer chronologischen Liste.
- Jeder Event trägt eine Akteur-Attribution: `user`, `service`, `ai` — KI-Schreibungen sind nicht versteckt, sondern als solche sichtbar.
- Filter nach App, Akteur-Typ und Zeitfenster. Ein Klick auf einen Event führt zur Quell-App.
- Optional: Webhooks/RSS — die eigene Timeline als Feed exportierbar, inkl. KI-Aktionen.
- Die Aggregation passiert ausschließlich im Browser der Nutzerin, keine Server-seitige Verkettung über Apps hinweg.
Was uns das kostet
Jeder Lösung hat einen Preis. Diese hier zahlen wir bewusst — weil das, was wir damit erreichen, mit nachgelagerten Tricks nicht ehrlich zu bauen ist.
- Eine vollständige Timeline kann lang werden. Default-Ansichten müssen sinnvoll filtern, ohne wichtige Änderungen zu verstecken.
- KI-Aktionen sichtbar zu machen, bedeutet auch, dass jede automatische Empfehlung als Event auftaucht. Das ist gewollt, aber für UX anspruchsvoll.
- Client-seitige Aggregation kostet Bandbreite. Für sehr viele Events brauchen wir später eine optionale, opt-in-basierte Server-seitige Aggregation mit klarem Berechtigungs-Modell.
Wo es im Code/in der Doku steht
Welche Probleme dieser Lösung adressiert
Diagnose ohne Antwort ist Lamentation; Antwort ohne Diagnose ist Ingenieurs-Spielerei. Hier verbindet sich beides.
- Daten-Monetarisierung — du bist nicht die Kundin, du bist die WareWenn das Produkt kostenlos ist, ist nicht selten dein Verhalten das eigentliche Produkt — und dein Profil wird in Echtzeit versteigert.
- Enshittification — Software wird über Zeit schlechterWenn Wachstum, Werbung und Aktionärsrendite den Takt geben, verschlechtert sich jedes erfolgreiche Software-Produkt zwangsläufig.
Welche Grundsätze er trägt
Offene Punkte
- Phase 2 (eigene Timeline-Native-App), Phase 3 (KI-Erklärungen pro Event), Phase 4 (App-Vignetten) sind bewusst offen — zuerst Stabilität der Phase 1.
Weitere Lösungen dieser Art
Wie die Daten fließen — strukturelle Entscheidungen.
- Event-Sourcing als Daten-ArchitekturStatt aktuelle Zustände in einer App-Datenbank zu mutieren, schreiben unsere Apps jede Änderung als unveränderliches Event in einen zentralen, signierten Ledger. Daraus folgt vieles, was sich sonst nicht bauen lässt: Audit-Trail, Cross-App-Timeline, vollständige Lösch- und Export-Pfade, transparente KI-Aktionen.
- Föderation statt Lock-InDaten gehen über App-Grenzen hinweg über offene Plattform- Protokolle (Share, Links, Events, MCP, Search), nicht über hauseigene Vendor-APIs. Jede App kann zur Allmende beitragen, jede App kann fortgehen — der Export ist gleichwertig zur internen API.
- Local-First + Login-OptionalWo es geht, rechnet die App auf dem Gerät, speichert auf dem Gerät und funktioniert ohne Konto. Ein Login ist nur dann nötig, wenn die Nutzerin tatsächlich Geräte-übergreifend syncen oder Mana-Aktionen ausführen möchte.
- PWA vor Native — Web-App, wo es gehtWo der Plattform-Vorteil einer nativen App nicht zwingend gebraucht wird, liefern wir eine progressive Web-App statt. Das spart den App-Store-Tribut, verkürzt die Update-Schleife und hält die Installation in der Hand der Nutzerin.
Lösungen sind die strukturellen Antworten des Vereins. Werte sagen, wonach wir uns ausrichten; Probleme sagen, wogegen; Lösungen sagen, was wir daraus baulich machen.