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 HoneyBar trägt deine Röhre — ✅ erledigt (24.08.2026)

Die HoneyBar 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 HoneyBar 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 HoneyBar die Farbe des
Standardnutzers, weil ihr über die Site-Grenze niemand sagen kann, wer da
gerade schaut.

### 1.2 Systemmenü im Logo — ✅ gebaut (29.08.2026)

**Steht**, in beiden Leisten mit denselben Punkten (siehe [README](README.md)).
Der Abmeldeknopf in der Menüleiste des Schreibtischs ist dafür weggefallen — er
stand sonst zweimal da, und die HoneyBar hat ihn nie gehabt.

Eine Annahme von damals hat sich nicht gehalten: „ohne sie zu verlassen"
**geht nicht**, jedenfalls nicht für Einstellungen und Abmelden. Beides
schreibt, und die HoneyBar darf in einer fremden App nicht schreiben — die
Sitzung kommt über die Site-Grenze nicht mit, und selbst unter einer Domain
liegt das CSRF-Prüfwort in einem Cookie, das nur HoneyOS' eigene Seiten lesen.
Also reicht die HoneyBar die Frage als `?einstellungen=1` an den Schreibtisch
weiter. Ein Klick, ein Seitenwechsel — dort, wo man angemeldet ist.

**Abmelden ist ganz aus den Leisten verschwunden** und steht unten in den
Einstellungen (Marcs Entscheidung, 29.08.2026). Aus fremden Apps war es ohnehin
nur ein Link auf den Schreibtisch gewesen; als einzige Schaltfläche, die eine
Sitzung beendet, gehört es an eine Stelle statt an drei. Im selben Zug ist das
Zahnrad aus der Menüleiste des Schreibtischs gefallen und durch den Pfeil mit
der App-Liste ersetzt worden — damit tragen beide Leisten wirklich dieselben
vier Dinge: Logo, Apps, Wetter/Uhr, Aufklappmenü.

**Was ohne Seitenwechsel ginge, wenn es je stört:** die reinen Aussehensschalter
(Röhre, Leuchten, Scanlines) direkt im Menü. Sie kämen ohne Prüfwort aus, wenn
der Server stattdessen den `Origin` der Anfrage gegen die eingetragenen Apps
hält — dieselbe Liste, die heute schon die CORS-Freigabe steuert. Das ist eine
Sicherheitsentscheidung und keine Kleinigkeit; erst bauen, wenn der Umweg über
den Schreibtisch wirklich nervt.

### 1.3 App-Schublade mit Symbolen — ✅ halb gebaut (29.08.2026)

**Gebaut: die geteilte Symbolquelle.** Die Raster liegen in `web/glyphs.json`,
der Schreibtisch lädt sie, die HoneyBar bekommt sie mit der App-Liste mit
(siehe [README](README.md)). Damit tragen beide Leisten dieselben Symbole neben
den App-Namen, und die doppelt abgetippten Wettersymbole sind weg.

Dazu ein Schalter *Einstellungen → HoneyBar*: Symbole im App-Streifen an oder
aus, für beide Leisten zugleich. In den Aufklappmenüs und auf den Kacheln
stehen sie immer — dort ist Platz, und dort sucht man eine App, statt sie im
Vorbeigehen wiederzuerkennen.

**Offen bleibt die Schublade selbst:** ein Raster aus Symbolen statt einer
Liste, wenn es viele Apps werden. Heute reicht der Streifen samt Menü; das ist
erst ab sechs, sieben Apps eine echte Frage.

**Ebenfalls offen: eigene Logos hochladen** (beschlossen als Planung,
25.08.2026). Je App ein Bild in HoneyOS, die Pixelglyphe als Rückfall, wenn
keins da ist. Das Logo gehört ausdrücklich auch in die HoneyBar — dort ist die
Unterscheidung am nötigsten, weil die Knöpfe klein sind und nebeneinanderstehen.
Der Weg dorthin ist durch die geteilte Quelle jetzt kurz: Beide Seiten holen
ihre Symbole schon aus derselben Antwort, es müsste nur ein Bild an die Stelle
des Rasters treten können.

Was daran zu bauen ist, in dieser Reihenfolge:

1. **Hochladen und ablegen** — HoneyOS speichert heute nur eine JSON-Datei.
   Bilder heißt: ein Ordner unter `/data`, eine Größenbegrenzung, erlaubte
   Typen (PNG, SVG, WebP), und SVG ist heikel — es kann Skripte enthalten und
   darf deshalb nicht einfach durchgereicht werden.
2. **Ausliefern** — unter einer Adresse je App, mit einem Versionsanteil, damit
   ein Austausch nicht im Cache hängen bleibt (Aether macht das beim Logo
   schon so).
3. **In der HoneyBar anzeigen** — über die Site-Grenze hinweg ein `<img>` von
   HoneyOS. Das geht ohne Sitzung, Bilder unterliegen der CORS-Regel nicht.

**Vorher zu klären:** Sollen Bilder in den Retro-Look eingepasst werden
(auf wenige Farben reduziert, hart gerastert) oder bunt bleiben? Ein
Original-Logo mit Farbverlauf neben Pixelglyphen sieht schnell nach Fremdkörper
aus. Ein Filter in der HoneyBar wäre billig zu haben und ließe sich abschalten.

### 1.3b Reihenfolge der Apps

Heute stehen die Apps in der Reihenfolge, in der sie eingetragen wurden. Bei
zwei Stück ist das keine Frage; ab vier oder fünf schon, und in der HoneyBar
zuerst — dort ist der Platz am knappsten und die Reihenfolge entscheidet, was
man am Handy noch sieht.

Möglichkeiten:

| | Aufwand | taugt für |
|---|---|---|
| von Hand sortieren (ziehen oder Pfeile) | klein | wenige Apps, feste Meinung |
| alphabetisch | fast keiner | wenn die Namen gut gewählt sind |
| nach Häufigkeit der Nutzung | mittel, braucht Zählung | viele Apps |
| feste Reihenfolge + Rest alphabetisch | mittel | Mischung |

→ **Vorschlag: von Hand sortieren**, dieselbe Reihenfolge auf Schreibtisch und
HoneyBar. Zählen, wie oft etwas benutzt wird, heißt Nutzungsdaten speichern —
dafür ist der Nutzen hier zu klein. **Zu entscheiden, sobald die vierte App
dazukommt**, nicht vorher.

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


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

### Wetter in der HoneyBar, neben der Uhr — ✅ gebaut (25.08.2026)

**Steht.** Zwei Schalter in den Einstellungen, unabhängig voneinander: auf dem
Schreibtisch, in der HoneyBar, beides oder keins. Die Stadt wird einmal gesucht
und mit ihren Koordinaten gespeichert; der Server holt das Wetter und legt es
zehn Minuten beiseite, die Oberflächen zeigen nur, was er hergibt.

Offen geblieben ist eines mit Absicht: **Die Stadt lässt sich nur auf dem
Schreibtisch ändern, nicht aus der HoneyBar heraus.** Ein Klick auf das Symbol
führt dorthin. Der Grund ist derselbe wie bei allem anderen in der HoneyBar: Sie
liest über den Schlüssel und darf nichts schreiben — und über eine Site-Grenze
wüsste sie nicht, für wen sie es täte. Liegt alles unter einer Domain, wäre es
nachrüstbar.

Die ursprüngliche Notiz, zur Nachvollziehbarkeit:

#### Wie es geplant war

Ein Pixelsymbol neben der Uhrzeit, dazu die Temperatur. Ein Klick öffnet ein
kleines Feld, in dem die Stadt eingestellt wird. Alles im Röhren-Look: Sonne,
Wolke, Regen, Schnee als 12×12-Raster wie die App-Symbole, keine bunten
Fremdbilder.

**Das ist der beste Kandidat für das erste Widget überhaupt**, vor „letzte
Dateien" — und zwar aus einem Grund, der von aussen nicht sichtbar ist: Wetter
braucht **keine** der Voraussetzungen, an denen die anderen Widgets hängen. Kein
CORS in Aether, keine Sitzung von InkNote, keine App-API. Es hängt an nichts,
was sich noch ändern kann, und lässt sich an einem Abend fertig bauen. Damit
beantwortet es die eigentliche Frage — schaut man überhaupt hin? — ohne dass
vorher das halbe Fundament stehen muss.

Und es ist das erste Widget, das **in der HoneyBar** lebt statt auf dem
Schreibtisch. Es ist damit zugleich der Probelauf für den Rahmen weiter unten.

**Die Abfrage gehört auf den Server, nicht in den Browser.** Open-Meteo braucht
keinen Schlüssel und kostet nichts, aber wenn jede App-Seite selbst dort
anfragt, geht bei jedem Seitenaufruf aus jeder App eine Anfrage samt IP an einen
Fremden hinaus — und die CSP jeder App müsste den Wetterdienst erlauben. Holt
HoneyOS es selbst und gibt es über `/api/apps` mit heraus (oder über einen
eigenen kleinen Endpunkt), sieht der Dienst genau einen Server, die Apps bleiben
unberührt, und ein Zwischenspeicher von zehn bis fünfzehn Minuten reicht
vollkommen: Das Wetter ändert sich langsamer als eine Seite neu geladen wird.

Zu klären, wenn es soweit ist:

- **Stadt → Koordinaten.** Open-Meteo hat eine Suche dafür; das Ergebnis
  einmal speichern statt bei jeder Abfrage neu suchen.
- **Wo die Stadt liegt.** Zu den Einstellungen im Server, wie Röhre und
  Effekte — dann gilt sie auf jedem Gerät.
- **Am Handy wird es eng.** Uhr und Wetter nebeneinander in 32 px: Wahrscheinlich
  nur das Symbol, Temperatur erst ab einer gewissen Breite.
- **Kein Netz, kein Wetter.** Dann verschwindet das Symbol, statt eine Zahl von
  gestern als heutige auszugeben.

### Zwei Leisten, zwei Stilsätze

Die HoneyBar in fremden Apps (`honeybar.js`, eigenes CSS im Shadow DOM) und die
Menüleiste des Schreibtischs (`.menubar` in `style.css`) sehen gleich aus, sind
aber getrennter Code — rund 19 Regeln hier, 30 dort, alle von Hand
gleichgehalten.

**Das ist bereits einmal auseinandergelaufen:** Das Wetter stand zuerst nur in
`honeybar.js`, und der Schalter „in der honeybar" schien auf dem Schreibtisch
wirkungslos (25.08.2026). Es wird wieder passieren.

Zwei Auswege:

- **Die Schreibtisch-Menüleiste durch `honeybar.js` ersetzen.** Ein Stilsatz,
  eine Anatomie, und was die HoneyBar kann, kann der Schreibtisch automatisch
  auch. Kostet: Die Menüleiste hat Dinge, die die HoneyBar nicht hat
  (Einstellungsknopf, Abmelden, Avatar) — die müssten hinein, und die HoneyBar
  ist bewusst schlank.
- **Die Farb- und Maßangaben in eine gemeinsame Datei ziehen**, die beide
  einbinden. Kleiner Eingriff, löst aber nur die Hälfte: Aufbau und Verhalten
  bleiben doppelt.

→ Ersteres ist das Richtige, sobald die HoneyBar mehr kann als heute (Widgets,
Systemmenü). Vorher lohnt der Umbau nicht.

### Die HoneyBar ohne `unsafe-inline`

Fremde Apps bekommen die HoneyBar über den Reverse Proxy (siehe README). Dabei
muss deren CSP heute `style-src 'unsafe-inline'` erlauben, weil die HoneyBar ihre
Stile im Shadow DOM mitbringt — ohne das erscheint sie schwarz auf schwarz.
Gemessen am 28.08.2026 an einer nachgebauten fremden App.

**Auflösbar:** Die Stile als eigene Datei neben `honeybar.js` ausliefern und im
Shadow DOM per `<link>` einbinden. Dann genügt `style-src 'self' https://honeyos…`,
und die CSP der fremden App bleibt streng. Kostet eine zweite Anfrage, die
zwischengespeichert wird.

Zu prüfen ist dabei, was sonst noch inline gesetzt wird: die Lage der HoneyBar
selbst und der Innenabstand, den sie der Seite verpasst. Über die CSSOM gesetzte
Stile (`el.style.x = …`) fallen nicht unter die CSP — was im Markup steht, schon.

### Bild-Widget — Marcs Idee (29.08.2026)

Ein Widget, das ein Bild zeigt: hochgeladen oder als Adresse eingetragen. Genau
**eines je Nutzer**; ein neues ersetzt das alte, ohne Verwaltung und ohne Liste.

Reizvoll daran ist, dass es das erste Widget wäre, das nichts abfragt, sondern
etwas *ist* — der Schreibtisch bekommt damit einen persönlichen Zug, den keine
Datenanzeige liefert.

Zu klären, wenn es soweit ist:

- **Ablegen.** HoneyOS speichert bisher nur eine JSON-Datei. Ein Bild heisst:
  Ordner unter `/data`, Grössengrenze, erlaubte Typen. SVG ist heikel — es kann
  Skripte enthalten und darf nicht einfach durchgereicht werden.
- **Ausliefern** mit Versionsanteil in der Adresse, sonst bleibt beim Austausch
  das alte im Zwischenspeicher hängen.
- **Adresse statt Upload** ist billiger zu bauen, holt aber eine fremde Anfrage
  auf jede Seite mit HoneyBar. Für den Schreibtisch unkritisch; sollte das Bild
  je in die HoneyBar wandern, wäre es eine Anfrage aus jeder App.
- **Zuschneiden?** Ein Bild in einem festen Rahmen ist entweder verzerrt oder
  beschnitten. `object-fit: cover` und gut — Zuschneiden von Hand ist ein
  eigenes Stück Arbeit.
- Passt zum Aufnehmen eigener App-Logos (1.3): dieselbe Ablage, dasselbe
  Ausliefern. Zusammen bauen spart die Hälfte.

### Widgets verschieben, Reihenfolge im Server — Marcs Idee (29.08.2026)

Widgets per Ziehen umsortieren, die Reihenfolge liegt beim Nutzer auf dem
Server — also auf jedem Gerät gleich.

**Der Haken ist nicht das Ziehen, sondern die zwei Betriebsarten.** Im
Terminal-Modus stehen die Widgets in einer Spalte (eine Reihenfolge), im
Desktop-Modus als Schilder auf der Fläche (dort wären Koordinaten das
Natürliche). Eine gemeinsame Liste für beides ist die einfachere Zusage: eine
Reihenfolge, in beiden Ansichten dieselbe. Freie Plätze auf dem Schreibtisch
wären das schönere Ziel, aber dann liegen zwei Anordnungen im Server, und beim
Wechsel muss man sich entscheiden, welche gilt.

→ **Vorschlag: eine Liste, beide Ansichten folgen ihr.** Freie Plätze später,
falls sie je fehlen.

Am Handy: **Ziehen ist dort kein Standard** — HTML5-Drag löst per Berührung
nicht aus. Entweder Zeigerereignisse selbst behandeln (wie beim Fensterziehen
schon gebaut) oder am Handy Pfeiltasten statt Ziehen anbieten. Nicht vergessen:
Ohne das ist die Funktion am Handy schlicht nicht da.

Voraussetzung ist ein Widget-Verzeichnis — heute stehen Benutzer und Wetter
fest im HTML. Sinnvoll zusammen mit dem Widget-Rahmen (1.6) zu bauen, nicht
davor.

### Widgets in der HoneyBar selbst

Bisher sind Widgets als Fenster auf dem Schreibtisch gedacht. Der Schreibtisch
ist aber die Seite, die man am seltensten offen hat — die HoneyBar dagegen ist
überall. Naheliegend also: ein Knopf in der HoneyBar 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 HoneyBar läuft in einer fremden App. Ein
Aether-Widget in der HoneyBar **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 HoneyBar) 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 HoneyBar 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 HoneyBar
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 HoneyBar 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 HoneyBar | 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 HoneyBar mehr |
| `data-push="none"` (liegt darüber) | 0 im Layout | verdeckt die Kopfzeile der App |
| ganz aus | 0 | schon eingebaut („honeybar ausblenden") |

→ **Vorschlag: am Rechner die volle HoneyBar, 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 HoneyBar 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? — ✅ gelöscht (29.08.2026)

Mitsamt dem Feld „Wer-bin-ich". Die Begründung von damals hat sich gehalten: Es
brachte allein den Anzeigenamen, wirkte an zwei Stellen unterschiedlich, und ein
Token an eine fremde Adresse zu schicken war eine Falle, die niemand braucht.

Den Namen zeigt jetzt das Benutzer-Widget auf dem Schreibtisch, aus der
HoneyOS-Anmeldung — dort, wo er hingehört, und ohne dass eine App etwas dafür
tun muss.


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

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