HoneyOS/IDEAS.md

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 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.