Aether/IDEAS.md

# Ideen

Was noch kommen könnte. **Nichts davon ist beschlossen** — beschlossen ist,
was im [README](README.md) und in den Plänen steht
([cloud-projekt-plan.md](cloud-projekt-plan.md), [kalender-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.