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. 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 — als Erstes, weil es sofort trägt.

Beschlossen als Planung (25.08.2026): eigene Logos hochladen. Je App ein Bild in HoneyOS hinterlegen, statt nur aus den eingebauten Glyphen zu wählen. Nicht als Ersatz für die Pixelglyphen, sondern daneben: Glyphe als Rückfall, wenn kein Bild da ist.

Das Logo gehört ausdrücklich auch in die Leiste, nicht nur auf den Schreibtisch — dort ist die Unterscheidung am nötigsten, weil die Knöpfe klein sind und nebeneinanderstehen. Damit ist die geteilte Symbolquelle aus 1.3 Voraussetzung: Beide Seiten müssen dasselbe Bild bekommen, sonst pflegt man es zweimal.

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

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 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 Leiste, neben der Uhr — ✅ gebaut (25.08.2026)

Steht. Zwei Schalter in den Einstellungen, unabhängig voneinander: auf dem Schreibtisch, in der Leiste, 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 Leiste heraus. Ein Klick auf das Symbol führt dorthin. Der Grund ist derselbe wie bei allem anderen in der Leiste: 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 Leiste 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.

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

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