From dfc5621f3ba9abadc95ec29870affb6ea26cfd4d Mon Sep 17 00:00:00 2001 From: marc Date: Mon, 24 Aug 2026 16:18:05 +0200 Subject: [PATCH] =?UTF-8?q?docs:=20IDEAS.md=20=E2=80=93=20Reihenfolge=20f?= =?UTF-8?q?=C3=BCr=20App-Schublade,=20Widgets=20und=20offene=20Entscheidun?= =?UTF-8?q?gen?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Nur Notizen, keine Änderung am Verhalten. Hält fest, was aufeinander aufbaut (Fundament → erstes Widget → Ausbau), welche zwei Entscheidungen offen sind (Symbole, Token-Schlüssel) und was bewusst nicht geplant ist, damit iframes und PWA-Weg nicht alle paar Monate neu diskutiert werden. Co-Authored-By: Claude Opus 5 --- IDEAS.md | 141 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 141 insertions(+) create mode 100644 IDEAS.md diff --git a/IDEAS.md b/IDEAS.md new file mode 100644 index 0000000..8a9e929 --- /dev/null +++ b/IDEAS.md @@ -0,0 +1,141 @@ +# Ideen und Reihenfolge + +Was noch kommen könnte, in der Reihenfolge, in der es aufeinander aufbaut. +Nichts davon ist beschlossen — beschlossen ist, was im [README](README.md) steht. + +Grundsatz für alles hier: **Fundament zuerst, dann ein Widget, dann ausbauen.** +Nicht zehn Fenster auf einmal planen, sondern eines bauen und sehen, ob man +wirklich hinschaut. + +--- + +## 1 · Fundament + +Ohne diese Stücke ist alles danach nicht möglich. + +### 1.1 App-Schublade in den Apps + +**Die Idee:** In Aether und InkNote ein Knopf, der eine Übersicht aller Apps +aufklappt — mit Symbol. Die Liste kommt aus HoneyOS, nicht aus der App. Eine +neue App trägt man einmal ein und sie taucht überall auf, ohne dass eine App +angefasst wird. + +**Stand:** Die Hälfte steht schon. `honeybar.js` holt die Liste aus `/api/apps`, +bringt seine eigene Sitzung mit und hat bereits ein Aufklappmenü. Was fehlt, ist +die Darstellung als Raster mit Symbolen statt einer Textliste. + +**Der eigentliche Punkt: die Symbole.** Heute lebt das Pixelraster in `os.js` +(`GLYPHS`), die Leiste kennt es nicht und zeigt nur Namen. Zwei Wege: + +- **Pixelglyphen teilen** — `GLYPHS` + `glyphSvg()` in eine eigene Datei, die + Desktop und Leiste beide laden. Kein Upload, kein Speicher, passt zum Look. + Nachteil: nur die eingebauten Symbole. +- **Echte Bilder** — pro App eine Bildadresse oder ein Upload in HoneyOS. + Flexibler, aber: Speicher, Größenbegrenzungen, Auslieferung, und der + Retro-Look bekommt bunte Fremdkörper. + +→ **Empfehlung: Pixelglyphen teilen.** Eine gemeinsame Datei löst es. Bilder +später nachrüsten, falls je eine App dabei ist, für die kein Symbol passt. + +### 1.2 CORS in Aether + +Damit der Desktop Aether überhaupt etwas fragen darf. Aethers Sitzung ist ein +Cookie, und weil alles unter derselben Domain liegt, schickt der Browser es +schon heute mit — es fehlt allein die Freigabe im Go-Backend +(`Access-Control-Allow-Origin` für `os.…` plus `Allow-Credentials`). + +Kleiner Eingriff, aber **die Voraussetzung für jedes Aether-Widget** und +nebenbei auch für die Anmeldeanzeige auf der Kachel. + +### 1.3 InkNote: Sitzung zusätzlich als Cookie + +InkNote weist sich mit einem Bearer-Token aus, der im localStorage liegt. Der +ist **pro Domain** — von `os.…` aus grundsätzlich unerreichbar, und daran ändert +keine Konfiguration etwas. + +Solange das so bleibt, kann HoneyOS **keine InkNote-Daten anzeigen**. Der Weg +wäre, dass InkNote seine Sitzung zusätzlich als `HttpOnly`-Cookie setzt; der +Token-Weg kann daneben bleiben, damit die PWA und der Offline-Betrieb +unangetastet bleiben. + +Erledigt das zugleich: der Token-Schlüssel in der App-Verwaltung wird überflüssig +(siehe „Offene Entscheidungen"). + +### 1.4 Widget-Rahmen im Desktop + +Ein Fenstertyp, der einen Inhalt holt, ihn anzeigt und sich benimmt, wenn es +schiefgeht: lädt gerade, nichts da, nicht angemeldet, Fehler. Einmal richtig +gebaut, kostet jedes weitere Widget danach fast nichts. + +Muss in **beiden Betriebsarten** funktionieren — im Desktop als Fenster, im +Terminal als Kachel. + +--- + +## 2 · Erste Widgets + +Eines bauen, benutzen, dann entscheiden. + +- **Letzte Dateien** (Aether) — die naheliegendste; braucht nur 1.2 +- **Speicherplatz** (Aether) — eine Zahl, ein Balken, billig zu bauen +- **Letzte Notizen** (InkNote) — braucht 1.3, kommt also später + +→ Anfangen mit **letzte Dateien**. Wenn du danach merkst, dass du morgens +wirklich draufschaust, lohnt der Rest. Wenn nicht, war es ein Abend. + +--- + +## 3 · Ausbau + +- Welche Widgets wo liegen, **pro Nutzer im Server** merken — die Einstellungen + liegen ohnehin schon dort, das ist eine Erweiterung, kein Neubau +- Widgets im Terminal-Modus +- Suche über alle Apps hinweg (erst sinnvoll, wenn mehrere APIs angebunden sind) +- Symbole frei auf dem Schreibtisch ablegen statt in einer Spalte +- Fensterpositionen überleben den Moduswechsel + +--- + +## Offene Entscheidungen + +### Token-Schlüssel behalten oder löschen? + +**Empfehlung: löschen.** Gründe: + +1. Er wirkt nur an einer von zwei Stellen — in der Leiste ja, auf dem Desktop + nie. Das ist schwer zu erklären und noch schwerer zu merken. +2. Er bringt allein die Namensanzeige. Kein Funktionsunterschied. +3. Sobald 1.3 gebaut ist, ist er ohnehin überflüssig. +4. **Scharfe Kante:** Das Feld „Wer-bin-ich" darf auch eine vollständige fremde + Adresse sein. Steht dort etwas Fremdes *und* ein Token-Schlüssel, schickt die + Leiste den InkNote-Token dorthin. Das setzt voraus, dass jemand Angemeldetes + das selbst einträgt — bei einer Ein-Personen-Instanz also kein akuter + Notstand, aber eine Falle, die niemand braucht. + +Wird er doch behalten, gehört mindestens eingebaut: **mit Token-Schlüssel nur +relative Pfade zulassen**, damit ein Ausweis nie an einen fremden Ursprung geht. +Drei Zeilen. + +### Ideen hier oder als Gitea-Issues? + +Vorerst hier. Issues erst, wenn etwas konkret als Nächstes drankommt und der +Fortschritt verfolgt werden soll — dann eines pro Punkt, mit Verweis hierher. + +--- + +## Bewusst nicht geplant + +Damit es nicht alle paar Monate neu diskutiert wird: + +- **Apps in iframes einbetten.** Aether (`X-Frame-Options: DENY`) und InkNote + (`helmet()`) verbieten es beide von sich aus, und das aus gutem Grund. Es + würde Clickjacking-Schutz, PWA-Installierbarkeit und InkNotes Offline-Betrieb + kosten. Widgets zeigen **Daten**, die Apps bleiben in ihrem eigenen Tab. +- **Der Weg aufs Handy bleibt ein normaler Link.** Android öffnet die + installierte PWA, wenn die Adresse in ihren Bereich fällt — das funktioniert + heute und darf nicht durch JavaScript-Navigation oder Rahmen kaputtgemacht + werden. +- **HoneyOS speichert keine Inhalte.** Keine Dateien, keine Notizen, keine + Kopien. Es zeigt, was die Apps hergeben, und hört da auf. +- **Keine Rechteverwaltung.** Die App-Liste gilt für alle Angemeldeten. Für eine + Handvoll eigene Konten gewollt; wäre es je mehr, müsste das neu gedacht werden.