marcandClaude Opus 5
6f0efc8e7b
Teilen war in der ersten Fassung zu pauschal abgeräumt. Es meint drei Dinge: dasselbe Konto auf mehreren Geräten (ab Phase 1), ein Kalender für einen anderen Nutzer (Tabelle plus Bedingung in ListCalendars, keine Protokollarbeit) und ein öffentlicher Abo-Link (Aether hat Freigabelinks schon). Nur Einladungen per E-Mail bleiben draußen. Dazu Marcs Festlegungen: mehrere Kalender und VTODO von Anfang an, Anhänge kein Ziel, Erinnerungen weckt die App auf dem Telefon. Und die Einschränkung, die sonst später überrascht: Androids Kalenderspeicher kennt keine Aufgaben. Ohne Tasks.org o. ä. bietet DAVx5 sie nicht an, und Samsung Kalender zeigt sie nie. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
171 lines
8.6 KiB
Markdown
171 lines
8.6 KiB
Markdown
# 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).
|
||
|
||
## Festgelegt (02.09.2026)
|
||
|
||
- **Mehrere Kalender** von Anfang an. Nicht weil es heute drei sein müssen,
|
||
sondern weil es jetzt eine Spalte ist und später ein Umbau.
|
||
- **Aufgaben (VTODO)** werden von Anfang an gespeichert und über CalDAV
|
||
angeboten; die Ansicht in Aether kommt später. Muss vorher feststehen, weil
|
||
jeder Kalender dem Client meldet, was er kann – nachträglich richten die
|
||
Clients ihre Konten neu ein.
|
||
- **Ändern statt neu erzeugen**, sobald unsere eigene Oberfläche schreibt.
|
||
- Anhänge sind kein Ziel. Falls doch, dann als Verweis in Aethers Dateien –
|
||
nie als eingebettete Datei in der `.ics`.
|
||
- Erinnerungen weckt die App auf dem Telefon. Browser-Benachrichtigungen in
|
||
der Weboberfläche: nett für später, kein Drang.
|
||
|
||
## 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, Aufgabenansicht, Teilen mit anderen Nutzern, öffentlicher Abo-Link, Kalender in der HoneyOS-Leiste. | offen |
|
||
| **5** | Kontakte (CardDAV). Dieselbe Maschinerie, dieselbe Bibliothek – und **einfacher**, weil es dort keine Wiederholungen gibt. | später entscheiden |
|
||
|
||
## Teilen – drei Bedeutungen, zwei davon gehen
|
||
|
||
„Geteilter Kalender" meint je nach Person etwas anderes:
|
||
|
||
1. **Derselbe Kalender auf mehreren Geräten.** Das ist der Sinn der Sache und
|
||
ab Phase 1 da.
|
||
2. **Ein Kalender, den ein anderer Nutzer sieht** – lesend oder schreibend, wie
|
||
das Teilen in Nextcloud. Geht, und es ist keine Protokollarbeit: Wir kennen
|
||
unsere Nutzer und unsere Kalender, also ist es eine Tabelle
|
||
(`kalender × nutzer × recht`) und eine Bedingung in `ListCalendars`. Der
|
||
Client sieht danach schlicht einen Kalender mehr in seiner Liste. **Phase 4.**
|
||
3. **Ein Kalender an der Adresse eines Links**, den jemand ohne Konto
|
||
abonnieren kann – nur lesend, wie ein Freigabelink für Dateien. Klein, und
|
||
Aether hat die Freigabelinks schon. **Phase 4.**
|
||
|
||
Was **nicht** kommt: Einladungen per E-Mail (iMIP/iTIP) und Frei/Belegt-Abfragen
|
||
über Serviergrenzen hinweg. Das ist der Teil, an dem Groupware groß und
|
||
kompliziert wird – und der einzige, der wirklich wehtut.
|
||
|
||
## Felder – was ein Termin mitbringt
|
||
|
||
Alles aus RFC 5545, und wir müssen dafür nichts „unterstützen": Wir speichern
|
||
die Datei unverändert, also überleben auch Felder, die wir nicht kennen.
|
||
|
||
RRULE/EXDATE Wiederholung · DESCRIPTION Notiz · LOCATION Ort
|
||
VALARM Erinnerung · CATEGORIES · CLASS privat/öffentlich
|
||
ATTENDEE Teilnehmer (gespeichert, aber niemand wird eingeladen)
|
||
DTSTART ohne Uhrzeit = ganztägig
|
||
|
||
**Die Regel, die Daten rettet:** Sobald unsere Oberfläche einen Termin ändert,
|
||
wird die vorhandene Datei eingelesen, die angefassten Felder ersetzt und der
|
||
Rest unberührt zurückgeschrieben. Nie neu erzeugen. Sonst verschiebt man am
|
||
Rechner einen Termin um eine Stunde und die Erinnerung, die das Telefon
|
||
angelegt hatte, ist weg – und das fällt erst Wochen später auf.
|
||
|
||
## Clients, gegen die geprüft wird
|
||
|
||
| Client | Prüft |
|
||
|---|---|
|
||
| **DAVx5 → Samsung Kalender** | der Hauptweg. DAVx5 schreibt in Androids Kalenderspeicher, Samsung Kalender liest daraus. In der App unter „Kalender verwalten" einmal sichtbar schalten, und DAVx5 von der Akkuoptimierung ausnehmen. |
|
||
| **Tasks.org** | Aufgaben. Androids Kalenderspeicher kennt keine – ohne so eine App bietet DAVx5 die Aufgabenlisten gar nicht erst an, und **Samsung Kalender zeigt sie nie**. |
|
||
| **Thunderbird** | der gutmütige Prüfstein am Rechner, Termine und Aufgaben nebeneinander. |
|
||
| **Vivaldi** | Marcs Browser bringt einen CalDAV-Kalender mit. Wie eigenwillig er ist, wissen wir noch nicht. |
|
||
| **HoneyOS** | braucht **kein** CalDAV: Kachel und Leiste fragen Aethers eigene JSON-Schnittstelle. CalDAV ist für fremde Programme. |
|
||
|
||
## Standards und Vorbild
|
||
|
||
RFC 5545 das .ics-Format
|
||
RFC 4791 CalDAV (PUT, REPORT, calendar-query)
|
||
RFC 6764 /.well-known/caldav – damit reicht dem Client der Hostname
|
||
RFC 5397 current-user-principal: „wer bin ich, wo liegen meine Kalender"
|
||
RFC 6578 sync-collection: nur Änderungen holen
|
||
RFC 6352 CardDAV, falls Kontakte dazukommen
|
||
|
||
Wo der Standard Spielraum lässt, halten wir es wie **SabreDAV**: Nextcloud und
|
||
Baïkal stehen beide darauf, das ist also das Verhalten, an das die Clients
|
||
gewöhnt sind. Radicale ist zum Nachlesen gut – kurzer Code –, aber es ist nicht
|
||
die Fassung, gegen die getestet wurde.
|
||
|
||
## 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.
|