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](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. Reihenfolge nach dem
Verhältnis von Aufwand zu spürbarer Wirkung.

### 1.1 Die Leiste trägt deine Röhre — ✅ erledigt (24.08.2026)

Die Leiste liest ihre Farben nicht mehr fest, sondern aus derselben Antwort, mit
der sie die App-Liste holt. Röhre in HoneyOS auf grün → die Leiste in Aether ist
grün, ohne dass Aether angefasst wird. `glow` und `scanlines` gelten dort ebenso.

**Ging entgegen der ersten Einschätzung auch über Site-Grenzen hinweg.** Ich
hatte notiert, das scheitere daran, dass der Browser die Sitzung nicht mitschickt
— stimmt, aber der Schlüssel für die App-Liste löst es: dieselbe Anfrage bringt
das Aussehen gleich mit. Deshalb liefert `/api/apps` jetzt `{apps, settings}`
statt nur einer Liste.

Offen bleibt: Bei mehreren Nutzern trägt die Leiste die Farbe des
Standardnutzers, weil ihr über die Site-Grenze niemand sagen kann, wer da
gerade schaut.

### 1.2 Systemmenü im Logo

Das `■ HONEYOS` links ist heute nur ein Link zum Schreibtisch. Wie ein
Apfel-Menü gehören darunter: Schreibtisch · Einstellungen · Abmelden. Dann sind
die HoneyOS-Sachen aus jeder App heraus erreichbar, ohne sie zu verlassen.

Die Einstellungen sind derselbe Inhalt wie auf dem Schreibtisch — sie liegen im
Server, also stimmt beides automatisch überein.

### 1.3 App-Schublade mit Symbolen

**Die Idee:** ein Knopf, der eine Übersicht aller Apps aufklappt — mit Symbol.
Die Liste kommt aus HoneyOS. Eine neue App trägt man einmal ein und sie taucht
überall auf, ohne dass eine App angefasst wird.

**Stand:** Die Hälfte steht. `honeybar.js` holt die Liste aus `/api/apps`, bringt
seine Sitzung mit und hat ein Aufklappmenü. Es fehlt die Darstellung als Raster
mit Symbolen — heute sind es Textknöpfe. Bei zwei Apps geht das noch, ab vier
wird es eng, am Handy sofort.

**Der eigentliche Punkt: die Symbole.** Das Pixelraster lebt in `os.js`
(`GLYPHS`), die Leiste kennt es nicht. 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.** Bilder später nachrüsten, falls je eine
App dabei ist, für die kein Symbol passt.

### 1.4 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.5 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 PWA und Offline-Betrieb unangetastet sind.

Erledigt zugleich den Token-Schlüssel (siehe „Offene Entscheidungen").

### 1.6 Widget-Rahmen

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

### Widgets in der Leiste selbst

Bisher sind Widgets als Fenster auf dem Schreibtisch gedacht. Der Schreibtisch
ist aber die Seite, die man am seltensten offen hat — die Leiste dagegen ist
überall. Naheliegend also: ein Knopf in der Leiste klappt dasselbe Widget als
kleines Feld auf, ohne die App zu verlassen.

Technisch ist das dieselbe Sache wie 1.6, nur ein zweites Zuhause für denselben
Inhalt: Der Rahmen muss dann drei Formen können — Fenster, Kachel, Aufklappfeld.
Das ist beim **Bauen** von 1.6 zu bedenken, hinterher wird es teuer.

**Eine Einschränkung vorweg:** Die Leiste läuft in einer fremden App. Ein
Aether-Widget in der Leiste **von InkNote aus** braucht deshalb dasselbe, was
1.4 für den Schreibtisch regelt, nur für einen weiteren Ursprung. In der App
selbst (Aether-Widget in Aethers eigener Leiste) ist es geschenkt.

→ 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

### Wie sichtbar darf die Leiste sein?

**Teilweise beantwortet:** „ausblenden" heißt seit dem 24.08. „einklappen" — es
bleibt ein 3 px hoher Strich am oberen Rand stehen, ein Klick holt die Leiste
zurück. Vorher war das eine Einbahnstraße: wer einmal ausgeblendet hatte, kam
nur über die Entwicklerkonsole wieder heran. `?honeybar=1` an der Adresse
funktioniert als Notausgang.

Damit ist der schmale Streifen technisch schon da. Offen bleibt, ob er am Handy
der **Standard** sein soll.


**Der Zwiespalt:** Die App lädt die Leiste bei *jedem* Aufruf nach, also ist sie
immer da — auch wenn man die Cloud einfach direkt öffnet und mit
HoneyOS gerade nichts zu tun hat. 32 px, dauerhaft, in einer App, die man auch
für sich allein benutzt. Am Handy in einer installierten PWA wiegt das schwerer
als am großen Schirm.

Möglichkeiten, von viel nach wenig Platz:

| | Platz | Gefühl |
|---|---|---|
| volle Leiste | 32 px immer | am ehesten „OS" |
| schmaler Streifen, klappt bei Berührung auf | 4 px | immer erreichbar, nie im Weg |
| nur ein Eckknopf | ~0 | praktisch, aber keine Leiste mehr |
| `data-push="none"` (liegt darüber) | 0 im Layout | verdeckt die Kopfzeile der App |
| ganz aus | 0 | schon eingebaut („leiste ausblenden") |

→ **Vorschlag: am Rechner die volle Leiste, am Handy der schmale Streifen.**
Als Einstellung, nicht fest verdrahtet — dann lässt sich die Meinung ändern,
ohne etwas neu zu bauen.

**Wichtig für die Entscheidung:** Das ist keine Einbahnstraße. In den Apps steht
nur ein Ursprung in der `.env`; das Verhalten der Leiste liegt zentral in HoneyOS. Aussehen,
Höhe, Auto-Verstecken, Abschaffen — alles eine Änderung an einer Stelle, ohne
Aether oder InkNote neu zu bauen.

→ **Erst in einer App einbauen, eine Woche benutzen, dann entscheiden.** Nicht
in beide gleichzeitig.

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

### Persönliche Apps je Nutzer?

Heute gilt die App-Liste für alle — bewusst so, siehe „Bewusst nicht geplant".
Denkbar wäre daneben eine kleine eigene Liste je Konto.

**Was dagegen spricht, ist nicht der Aufwand, sondern eine harte Grenze:** Auf
dem Schreibtisch ginge es sofort (dort ist man angemeldet). In der Leiste einer
fremden App ginge es **nicht**, solange HoneyOS auf einer anderen Site liegt als
die App — der Browser schickt die HoneyOS-Sitzung dann nicht mit, und der
Schlüssel für die App-Liste weiß nicht, wer schaut. Die Leiste zeigte also die
gemeinsamen Apps, der Schreibtisch zusätzlich die eigenen. Zwei verschiedene
Listen an zwei Stellen ist schlechter als eine.

**Liegt alles unter derselben Domain** (`os.beispiel.duckdns.org` +
`cloud.beispiel.duckdns.org`), fällt die Grenze weg: die Sitzung wird
mitgeschickt, die Leiste weiß, wer da ist. Seit dem Umzug auf
`os.asianxpolish.duckdns.org` ist genau das der Fall — persönliche Apps sind
damit machbar geworden.

→ **Vorschlag: zurückstellen, bis es mehr als ein Konto gibt.** Bei einer
Person ist „persönlich" und „für alle" dasselbe. Der Weg ist aber offen und
sollte es bleiben: nichts einbauen, was von einer einzigen gemeinsamen Liste
ausgeht.

### Wie weit soll das Aussehen der Leiste einstellbar sein?

Röhre, Leuchten und Scanlines kommen schon aus HoneyOS (1.1). Offen ist, was
darüber hinaus in die Einstellungen gehört: Höhe, Schriftgröße, Position (oben
oder unten), ob der Name der App danebensteht.

**Die Versuchung ist, alles einstellbar zu machen.** Jede Einstellung ist aber
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).

### 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.
- **Nichts über die Leiste wird beim Bauen der Apps eingebacken.** Die Adresse
  stand einmal fest in Aethers `index.html`. Das war aus zwei Gründen falsch:
  Ein fertiges Abbild lässt sich dann nicht über die `.env` umziehen, und der
  Service Worker der PWA hält die alte `index.html` im Cache, so dass eine
  Änderung selbst nach dem Neubau noch nicht ankommt. Ursprung und Schlüssel
  holt sich die App deshalb zur Laufzeit vom eigenen Server und hängt das
  Skript selbst ein.
- **Das Skript wird mit `defer` eingebunden.** Ohne wartet der Seitenaufbau der
  App darauf. Ist HoneyOS langsam oder aus, dürfte eine Zierleiste den Start von
  Aether nicht verzögern.
- **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.