Aether/IDEAS.md

Ideen

Was noch kommen könnte. Nichts davon ist beschlossen — beschlossen ist, was im README und in den Plänen steht (cloud-projekt-plan.md, kalender-plan.md).

Hier landet, was einen guten Grund hat, aber gerade keinen Anlass. Der Unterschied ist wichtig: Eine Funktion ohne Anlass zu bauen ist der Weg, auf dem eine Anwendung unübersichtlich wird.

---

Kalender

Öffentlicher Abo-Link — vertagt (12.09.2026)

Ein Nur-Lese-Link auf einen Kalender, den jemand ohne Konto abonnieren kann. Nicht dasselbe wie die Freigabe an ein Konto (die steht seit dem 12.09.2026): Dort ist der Empfänger bekannt, hier ist er es nicht.

Warum vertagt: kein Anlass. Marc ist der einzige Nutzer seiner Cloud, und für den eigenen Gebrauch gibt es bereits zwei Wege an dieselben Termine — die Weboberfläche und CalDAV mit App-Passwort.

Wofür es gut wäre, wenn der Anlass kommt:

• Den eigenen Kalender in einer fremden Anwendung einblenden, die kein CalDAV mit Anmeldung kann, sondern nur eine .ics-Adresse frisst — etwa ein Kalender auf der Arbeit.
• Einen Terminplan an Familie oder Verein geben, ohne für jeden ein Konto anzulegen.

Wie es gebaut würde (damit die Überlegung nicht verloren geht):

Aether hat die Freigabelinks für Dateien schon, samt Token, optionalem Passwort, Ablaufdatum und dem Zähler. Ein Kalender-Abo ist dieselbe Sache mit einer anderen Ausgabe: GET /share/kalender/{token}.ics liefert den Export, den es schon gibt (api.go, Export).

Drei Dinge wären dabei zu entscheiden, und sie sind der eigentliche Inhalt:

1. Nur lesend, ohne Ausnahme. Ein schreibbarer Link wäre ein Konto ohne Passwort.
2. Was steht drin? Ein Abo zeigt Titel, Ort und Beschreibung jedes Termins. Wer „Arzttermin, Dr. Müller" im Kalender stehen hat und den Link weitergibt, gibt das mit weiter. Ein Schalter „nur Belegt/Frei" (Titel durch „Belegt" ersetzen) wäre deshalb kein Zierrat, sondern der Grund, warum man den Link überhaupt zu teilen wagt.
3. Ein Abo wird regelmäßig abgerufen, nicht einmal. Ein Kalenderprogramm fragt alle paar Minuten nach. Der Zähler der Freigabelinks zählte dann Maschinen statt Menschen, und die Sperre nach zehn Fehlversuchen träfe einen Client, der bloß ein falsch gespeichertes Passwort wiederholt. Beides müsste für diesen Linktyp anders sein.

Aufgabenansicht (VTODO) — vertagt (12.09.2026)

Aether nimmt Aufgaben bereits an, speichert sie und gleicht sie ab; die Spalte component in cal_objects unterscheidet sie von Terminen. Es fehlt nur die Ansicht in der Weboberfläche.

Warum vertagt: Auf Marcs Telefon gibt es nichts, was sie zeigen würde.

Android hat von Haus aus keinen Speicher für Aufgaben. Für Termine gibt es einen Systemanbieter — den füllt DAVx5, und Samsung Kalender liest daraus. Für Aufgaben gibt es das nicht. DAVx5 kann Aufgabenlisten deshalb nur abgleichen, wenn eine App installiert ist, die selbst den Speicher mitbringt: tasks.org, OpenTasks oder jtx Board.

Samsungs „Erinnerungen" gehört nicht dazu. Der Bereich „Erinnerungen" im Samsung Kalender ist kein Teil des Kalenders, sondern ein Fenster in die Samsung-Erinnerungen-App; die hängt am Samsung-Konto (bzw. an Microsoft To Do), nicht an CalDAV. Der Unterschied ist am Gerät ablesbar: Beim Anlegen eines Termins fragt Samsung Kalender, in welchen Kalender — dort steht Aether zur Auswahl. Beim Anlegen einer Erinnerung fragt es das nicht, weil es nur einen Ort gibt, an den sie gehen kann.

Eine Ansicht in Aether wäre heute also eine reine Weboberflächen-Aufgabenliste – ohne Weg, vom Telefon aus etwas hineinzuschreiben. Das ist ein eigenes Vorhaben, kein Nebenprodukt des Kalenders.

Der Anlass wäre: tasks.org. Kostenlos, quelloffen, arbeitet mit DAVx5 zusammen und bringt den Aufgabenspeicher mit, der Android fehlt. Ist die App installiert und das Aether-Konto in DAVx5 für Aufgabenlisten eingeschaltet, landen Aufgaben vom Telefon in Aether — und dann hat die Ansicht in der Weboberfläche einen Anlass. Der Unterbau steht bereits: Aether meldet seinen Kalendern VTODO als unterstützt, nimmt sie an, speichert sie und gleicht sie über sync-collection ab. Zu bauen bliebe die Ansicht selbst — eine Liste mit Häkchen, Fälligkeit und Priorität, sinnvollerweise als vierte Ansicht neben Monat, Woche und Liste.

Was beim Bauen zu bedenken wäre: Eine Aufgabe hat kein Pflichtdatum. Alle drei heutigen Ansichten ordnen nach Zeit — eine Aufgabe ohne Fälligkeit hätte darin keinen Platz. Das ist der Grund, warum es eine eigene Ansicht braucht und kein Einstreuen in den Monat.

Gegentest, falls die Einschätzung falsch ist: DAVx5 öffnen, Aether-Konto antippen. Gibt es dort einen Reiter „Aufgabenlisten" mit Einträgen, ohne dass eine der genannten Apps installiert ist, stimmt das oben nicht.

---

Eine Android-App — notiert (15.09.2026)

Eine einfache eigene App fürs Telefon, statt der installierten Weboberfläche.

Warum das nicht offensichtlich ist: Die Weboberfläche ist am Telefon schon installierbar, hat ein eigenes Symbol, läuft ohne Adressleiste und kennt die sicheren Bereiche neben Uhr und Wischbalken. Eine App, die nur dasselbe in einem Rahmen zeigt, wäre Arbeit ohne Gewinn.

Was eine echte App kann, was die Weboberfläche nicht kann — und nur dafür lohnt sie sich:

• Fotos automatisch hochladen. Der eigentliche Grund, warum Leute die Nextcloud-App installieren. Der Browser darf im Hintergrund nicht auf die Galerie, eine App schon.
• „Teilen mit → Aether" aus jeder anderen App heraus. Ein Anhang aus dem Mailprogramm landet in einem Tippen in der Cloud.
• Hochladen, das weiterläuft, wenn der Schirm aus ist. Ein Browser-Tab wird nach Sekunden angehalten; ein großer Upload bricht deshalb ab.
• Dateien im Android-Dateimanager über einen Storage Access Provider.

Was es kosten würde: Ein zweiter Stapel (Kotlin oder Flutter), eine zweite Veröffentlichungskette, und jede Serveränderung ist ab dann an zwei Stellen nachzuziehen. Die bestehende REST-Schnittstelle plus App-Passwörter genügen als Unterbau, ein neues Backend wäre es nicht.

Der Anlass wäre: automatischer Fotoupload. Solange das nicht gebraucht wird, ist die installierte Weboberfläche der bessere Weg — sie ist da, sie ist gepflegt, und sie ist genau eine Codebasis.

---

Mehrsprachigkeit — notiert (18.09.2026)

Die Oberfläche spricht seit dem 18.09.2026 durchgehend Englisch. Deutsch (oder irgendeine weitere Sprache) daneben wäre eine eigene Baustelle.

Der Umfang, gemessen statt geschätzt:

~986 sichtbare Zeichenketten   in 55 Frontend-Dateien
 144 Fehlermeldungen           im Backend

Der Punkt, den man dabei vergisst: Es sind zwei Übersetzungen, nicht eine.

Die 144 Meldungen des Servers landen seit dieser Woche in den Toasts – „You only have read access to this file" kommt aus Go, nicht aus React. Wer nur das Frontend übersetzt, bekommt eine deutsche Oberfläche, die bei jedem Fehler auf Englisch umschaltet. Das wirkt kaputter als durchgehend Englisch.

Der saubere Weg: Der Server schickt keinen fertigen Satz mehr, sondern einen Schlüssel samt Werten ({"error":"file.read_only"}); übersetzt wird vorne, wo der Katalog ohnehin liegt. Das ist eine Protokolländerung an 144 Stellen, kein Wörterbuch.

Wie es gebaut würde:

• Jede Zeichenkette wird ein Schlüssel (t('calendar.new')). Rund 1000 Stellen – stumpfe Arbeit, gut mit Werkzeug zu machen.
• react-i18next statt Eigenbau. Eigenbau scheitert an den Pluralformen: „1 Datei" / „5 Dateien", und andere Sprachen haben mehr als zwei Formen.
• Die Sprache kommt aus navigator.language, ist im Profil überschreibbar und liegt in der Datenbank – damit sie am Telefon dieselbe ist wie am Rechner. Dieselbe Entscheidung wie bei den Favoriten.

Warum vertagt: Marc ist der einzige Nutzer und liest Englisch. Der Preis ist nicht die einmalige Umstellung, sondern dass ab dann jeder neue Text zwei Änderungen kostet – für immer. Der Anlass wäre eine zweite Person, die kein Englisch mag.

Unabhängig davon lohnend: Intl

Aether pflegt sechs handgeschriebene Arrays mit Wochentagen und Monatsnamen (CalendarPage, DayDialog, EventDialog), und Intl wird im ganzen Projekt nirgends benutzt. Dabei kann der Browser das seit Jahren:

new Intl.DateTimeFormat(sprache, { weekday: 'short' })

Das ersetzt alle sechs, kostet keine Abhängigkeit und entschärft eine Falle, die beim Übersetzen auffiel: DayDialog beginnt seine Woche am Sonntag, die anderen am Montag – jeweils passend zu ihrer Indizierung. Heute korrekt, aber wer eines dieser Arrays kopiert, baut sich einen Off-by-one-Fehler.

Lohnt sich auch ohne jede Übersetzung, und wäre die Vorarbeit, falls sie kommt.