# Kalender in Aether – Plan

Stand 02.09.2026. Ausgangspunkt: Radicale ist für einen einfachen selbst
gehosteten Kalender überraschend umständlich (Konfigurationsdateien, dünne
Doku, keine OIDC-Anbindung).

## Entscheidung: ein Modul in Aether, kein eigener Dienst

Der Grund ist genau das, was bei Radicale gefehlt hat.

**Ein CalDAV-Client kann kein OIDC.** DAVx5, Thunderbird und die Kalender-App
melden sich mit Benutzername und Passwort an – ein Anmeldefenster im Browser
gibt es dort nicht. Wer OIDC für CalDAV sucht, sucht etwas, das es so nicht
gibt. Die richtige Antwort sind **App-Passwörter**, und die hat Aether schon:
Das WebDAV unter `/dav/` läuft bereits darüber.

Damit ist die Rechnung einfach:

| | Radicale o. ä. | Modul in Aether |
|---|---|---|
| Anmeldung Oberfläche | eigenes Konzept, kein OIDC | PocketID, schon da |
| Anmeldung DAVx5 | eigene Nutzerdatei | App-Passwörter, schon da |
| Reverse Proxy, TLS | zusätzlicher Eintrag | schon da |
| Sicherung | zweiter Datenbestand | dieselbe Datenbank |
| Oberfläche | im Grunde keine | die, die wir bauen |

## Was die Bibliothek abnimmt

`github.com/emersion/go-webdav` (v0.7.0, Oktober 2025) bringt einen
CalDAV-Handler mit. Nachgesehen, nicht angenommen:

- Der Handler beantwortet `PROPFIND`, `OPTIONS` und `REPORT` selbst und liest
  `calendar-query` wie `calendar-multiget`.
- `caldav.Filter()` wendet die Filter der Anfrage auf die Termine an.
- **Der Zeitraumfilter löst Wiederholungen auf:** `matchCompTimeRange` ruft
  `comp.RecurrenceSet(loc)`, und go-ical stützt sich dafür auf
  `teambition/rrule-go`. Genau der Teil, vor dem ich gewarnt hatte – „jeden
  zweiten Dienstag, über die Zeitumstellung hinweg" – steckt in der Bibliothek
  und nicht in unserem Code.

Zu erfüllen ist eine Schnittstelle mit **neun Methoden** plus dem
Nutzer-Principal:

    CalendarHomeSetPath · CreateCalendar · ListCalendars · GetCalendar
    GetCalendarObject · ListCalendarObjects · QueryCalendarObjects
    PutCalendarObject · DeleteCalendarObject

Das ist Speicherarbeit, keine Protokollarbeit. Die Einschätzung „zwei Wochen
bis DAVx5 läuft, danach ein halbes Jahr Kleinkram" gilt für einen Server von
Grund auf – hier nicht.

## Datenmodell

Zwei Tabellen, mehr braucht es nicht:

- `calendars` – Besitzer, Name, Farbe, Zeitzone, `ctag` (ändert sich bei jeder
  Änderung, daran erkennt der Client, dass es etwas Neues gibt).
- `calendar_objects` – Kalender, UID, **das `.ics` roh und unverändert**,
  `etag`, dazu abgeleitet `dtstart`/`dtend` und ein Kennzeichen, ob eine
  Wiederholung dranhängt.

**Die wichtigste Regel: das `.ics` byte-genau speichern, wie der Client es
geschickt hat.** Nicht zerlegen und neu zusammensetzen – sonst gehen
Eigenschaften verloren, die wir nicht kennen (Anhänge, Teilnehmerstatus,
Herstellerfelder), und beim nächsten Abgleich fehlt etwas, das vorher da war.
Die abgeleiteten Spalten sind nur zum Vorsortieren da.

## Phasen

| | Inhalt | Aufwand |
|---|---|---|
| **1** | CalDAV lesend und schreibend, ein Kalender, Anmeldung über App-Passwörter, Auffindpfade (`/.well-known/caldav`, `current-user-principal`, `calendar-home-set`). Ziel: DAVx5 gleicht ab. | 1–2 Abende |
| **2** | Mehrere Kalender, Farbe, Umbenennen, Löschen. Export als `.ics`, Import einer bestehenden Datei. | 1 Abend |
| **3** | Weboberfläche in Aether: Monat, Woche, Liste; Termin anlegen, ändern, löschen. Der Teil, der Spaß macht – und dessen Fehler man **sieht**. | 2–3 Abende |
| **4** | `sync-collection` statt Vollabgleich, Aufgaben (VTODO), Kalender in der HoneyOS-Leiste. | offen |
| **5** | Kontakte (CardDAV). Dieselbe Maschinerie, dieselbe Bibliothek – und **einfacher**, weil es dort keine Wiederholungen gibt. | später entscheiden |

## Was es ausdrücklich nicht wird

Keine Einladungen an andere Leute (iMIP/Scheduling), keine Frei/Belegt-Abfragen
über Häuser hinweg, kein Teilen zwischen Nutzern. Das ist der Teil, an dem
Groupware-Server groß und kompliziert werden. Ein Kalender für dich, auf allen
deinen Geräten – das ist das Ziel.

## Die Notausfahrt

Ein Kalender, der lautlos einen Termin verschluckt, ist schlimmer als einer,
der ausfällt. Deshalb:

- **Export als `.ics` je Kalender ist Teil von Phase 2, nicht später.** Solange
  du deine Termine jederzeit herausbekommst, ist keine Entscheidung endgültig.
- Auf Wunsch zusätzlich als Verzeichnis mit einer Datei je Termin – das ist der
  Aufbau, den Radicale liest. Umziehen wäre dann ein Kopiervorgang.
- Tests mit echten Anfragen, die DAVx5 stellt (mitgeschnitten, nicht erfunden),
  und eine Prüfliste in `TESTING.md` fürs Telefon.

## Offene Fragen

1. Wie viele Kalender – einer, oder getrennt nach Privat/Arbeit/Geburtstage?
2. Aufgaben mit dazu (VTODO), oder reine Termine?
3. Der Kalender in der HoneyOS-Leiste: nur der nächste Termin, oder eine
   eigene Kachel?
4. Kontakte: ernsthaft geplant oder erst mal offenlassen? Es ändert nichts an
   Phase 1–3, nur an der Benennung der Pakete.