From ccae2026a42bef08361d6e5e6eef0a8da96ef5e1 Mon Sep 17 00:00:00 2001 From: marc Date: Tue, 25 Aug 2026 00:16:39 +0200 Subject: [PATCH] docs(ideen): HoneyOS selbst als PWA, und der Umzug unter eine Domain Co-Authored-By: Claude Opus 5 --- IDEAS.md | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 55 insertions(+) diff --git a/IDEAS.md b/IDEAS.md index 52efed2..c2616ba 100644 --- a/IDEAS.md +++ b/IDEAS.md @@ -133,6 +133,43 @@ Token-Weg kann daneben bleiben, damit PWA und Offline-Betrieb unangetastet sind. Erledigt zugleich den Token-Schlüssel (siehe „Offene Entscheidungen"). +### 1.5b HoneyOS selbst als PWA + +Heute ist HoneyOS eine Website: Es hat `theme-color`, aber kein Manifest, kein +Symbol und keinen Service Worker — installierbar ist es damit nicht. Am Handy +landet man also im Browser mit Adressleiste, während Aether und InkNote als +eigene Apps danebenliegen. Das ist genau der Bruch, den das Ganze eigentlich +verhindern soll: Der Schreibtisch sollte sich am wenigsten nach Website +anfühlen. + +Was dazugehört, klein bis groß: + +1. **Manifest** — Name, Startadresse, `display: standalone`, Hintergrund- und + Themenfarbe. Die Farben sollten der eingestellten Röhre folgen; sie liegen + im Server, das Manifest kann also erzeugt statt fest hinterlegt werden + (Aether macht das beim Symbol schon so). +2. **Symbol** — ein Pixelglyph in 192 und 512 px, im Amber-Look. Passt zum + Rest und ist ohne fremde Werkzeuge zu machen. +3. **Service Worker** — nötig für die Installierbarkeit. Hier ist zu + entscheiden, was er überhaupt soll (siehe unten). + +**Die eigentliche Frage ist der Offline-Fall.** HoneyOS zeigt fremde Apps und +später deren Daten — ohne Netz gibt es davon nichts. Ein Schreibtisch, der +offline mit leeren Kacheln dasteht, ist schlimmer als ein ehrlicher Hinweis. +Sinnvoll wäre: Oberfläche und App-Liste im Cache, damit man die Symbole sieht +und antippen kann, und ein deutlicher Vermerk „ohne Verbindung". Widgets +bleiben leer, statt Altes von gestern als aktuell auszugeben. + +**Aus dem Aether-Debakel gelernt und hier von Anfang an zu beachten:** Ein +Eintrag im Cache ist eine ganze Antwort **samt Kopfzeilen**. Wird die Startseite +vorab abgelegt, friert damit auch ihre CSP ein — und eine Änderung an der +Konfiguration erreicht den Browser nie wieder. Also Navigationen Netz zuerst, +Cache nur als Rückfall. + +**Reihenfolge:** Erst umziehen (siehe unten), dann installierbar machen. Ein +Ursprungswechsel macht aus einer installierten PWA eine fremde App — wer +vorher installiert, installiert zweimal. + ### 1.6 Widget-Rahmen Ein Fenstertyp, der einen Inhalt holt, ihn anzeigt und sich benimmt, wenn es @@ -277,6 +314,24 @@ eine Verzweigung, die für immer funktionieren muss. Sinnvoll wäre der Schnitt: Farbe und Verhalten ja (das ändert man wirklich), Maße nein (die stellt man einmal ein und nie wieder — dann kann es auch gleich richtig fest stehen). +### Alle Apps unter eine Domain ziehen? + +`honeyos.duckdns.org` als Dach, die Apps darunter (`cloud.honeyos.duckdns.org` +und so fort). Am 25.08.2026 gemessen: Dann schickt der Browser die +HoneyOS-Sitzung an die Leiste mit, über eine fremde Site hinweg nicht. + +Damit möglich, was heute nicht geht: **mehrere Nutzer mit eigenem Aussehen**, +persönliche Apps, der Name in der Leiste. Und `HONEYBAR_KEY` samt CORS-Ausnahme +wird überflüssig — der Umzug räumt Komplexität weg, statt welche zu schaffen. + +Kosten sind einmalig, aber real: Redirect-URIs in PocketID, `PUBLIC_URL` und +die Office-Adressen in Aether, InkNotes Token liegt pro Domain im localStorage +(alle werden abgemeldet), Pangolin-Ressourcen, Zertifikate, PWAs einmal neu +installieren, alte Freigabelinks per Weiterleitung am Leben halten. + +→ **Lohnt sich, sobald mehr als eine Person zugreift.** Vorher ist es +Geschmackssache, danach ist es die einzige Möglichkeit. + ### Ideen hier oder als Gitea-Issues? Vorerst hier. Issues erst, wenn etwas konkret als Nächstes drankommt und der