diff --git a/IDEAS.md b/IDEAS.md new file mode 100644 index 0000000..dfe5f71 --- /dev/null +++ b/IDEAS.md @@ -0,0 +1,71 @@ +# 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; DAVx5 kann +Aufgabenlisten nur abgleichen, wenn `tasks.org`, OpenTasks oder jtx Board +installiert ist. **Samsungs „Erinnerungen" gehört nicht dazu** — die hängt am +Samsung-Konto, nicht an CalDAV, und wird Aether-Aufgaben nie sehen. + +Eine Ansicht in Aether wäre heute also eine reine Weboberflächen-Aufgabenliste. +Das ist ein eigenes Vorhaben, kein Nebenprodukt des Kalenders. + +**Der Anlass wäre:** Marc probiert `tasks.org` aus und benutzt es. Dann ist die +Ansicht einen Nachmittag Arbeit, und der Unterbau steht schon. diff --git a/kalender-plan.md b/kalender-plan.md index 30e7edb..7efb57d 100644 --- a/kalender-plan.md +++ b/kalender-plan.md @@ -86,7 +86,7 @@ Die abgeleiteten Spalten sind nur zum Vorsortieren da. | **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. | ✅ | | **2** | Mehrere Kalender, Farbe, Umbenennen, Löschen. Export als `.ics`, Import einer bestehenden Datei. | ✅ | | **3** | Weboberfläche in Aether: Monat, Woche, Liste; Termin anlegen, ändern, löschen. Der Teil, der Spaß macht – und dessen Fehler man **sieht**. | ✅ | -| **4** | `sync-collection` ✅, Teilen mit anderen Nutzern ✅, Aufgabenansicht (vertagt), öffentlicher Abo-Link, Kalender in der HoneyOS-Leiste. | läuft | +| **4** | `sync-collection` ✅, Teilen mit anderen Nutzern ✅. Aufgabenansicht und Abo-Link vertagt → [IDEAS.md](IDEAS.md). Kalender in der HoneyOS-Leiste: **widerspricht einer Entscheidung in HoneyOS**, siehe unten. | im Wesentlichen erledigt | | **5** | Kontakte (CardDAV). Dieselbe Maschinerie, dieselbe Bibliothek – und **einfacher**, weil es dort keine Wiederholungen gibt. | später entscheiden | Über die Phasen hinaus dazugekommen, weil es sich beim Prüfen als nötig @@ -193,12 +193,37 @@ Fall, auf den es ankommt: *ohne Änderung kommt nichts zurück*. vorher nichts sieht – ohne diesen Anfang beweist der Rest nichts. 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.** + Aether hat die Freigabelinks schon. **Vertagt am 12.09.2026** – kein Anlass, + solange es nur ein Konto gibt. Die Überlegung samt der drei Dinge, die daran + nicht trivial sind, steht in [IDEAS.md](IDEAS.md). 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. +## Kalender in der HoneyOS-Leiste – steht im Widerspruch + +Der Punkt steht seit dem ersten Entwurf in Phase 4. Beim Nachsehen am +12.09.2026 stellte sich heraus: **HoneyOS hat sich am 29.08.2026 dagegen +entschieden.** In `honey-os/IDEAS.md`, Abschnitt „Bewusst nicht geplant": + +> **Keine Widgets, die Daten aus Aether oder InkNote holen** (gestrichen +> 29.08.2026). […] der Weg über den HoneyBar-Proxy zeigt HoneyOS in den Apps, +> statt die Apps in HoneyOS nachzubauen. + +Dazu die Grenze, die dort gezogen wurde: *„Nichts, was in einer App lebt, darf +hier ein zweites Zuhause bekommen."* + +Zwei Pläne, zwei Richtungen – das gehört entschieden, nicht gebaut. Zur +Vollständigkeit, was sich seither geändert hat: Der **technische** Grund ist +weg. Seit dem 29.08.2026 liegen Aether und HoneyOS unter derselben Domain, die +Sitzung wird also mitgeschickt; die Leiste läuft ohnehin *in* Aethers Seite und +könnte den Kalender dort gleichursprünglich abfragen, ohne CORS und ohne einen +zweiten Schlüssel. Übrig bleibt der **inhaltliche** Grund, und der ist der +eigentliche: Soll der Schreibtisch Inhalte der Apps zeigen oder nicht? + +Solange das offen ist, bleibt der Punkt hier stehen und wird nicht gebaut. + ## Felder – was ein Termin mitbringt Alles aus RFC 5545, und wir müssen dafür nichts „unterstützen": Wir speichern