Context
Backend 0.7.65 adds add-to-calendar links to the loan emails: a Google Calendar link and a tokenized per-loan .ics download. That is a one-shot import — if a loan is renewed or returned early, the event the borrower saved does not update.
Goal
A subscribable per-user ICS feed so a borrower's loan due dates stay in sync in any calendar app — multi-calendar (Google, Apple, Outlook, Proton…), no account linking, no OAuth. This is the "real synchronisation" option discussed for the calendar feature.
Approach
- Backend endpoint (Pinakes):
GET /calendar/{token}.ics returning a VCALENDAR with one VEVENT per active loan for that borrower (title, due date, UID/SEQUENCE so updates replace, optional VALARM reminder). Reuses the existing IcsGenerator VEVENT builder.
- Per-user token: a revocable secret (same scheme as the existing per-loan
.ics HMAC token), so the feed is private and can be regenerated.
- Client (this app): a "Subscribe to calendar" action that hands the OS a
webcal://…/calendar/{token}.ics URL; also surface it in the profile screen. The one-shot per-loan .ics from the emails stays available for a single due date.
Trade-off
The refresh cadence of a subscribed feed is decided by the client (Google ~12–24h, Apple more often) — fine for due dates that move by days, and the price for staying OAuth-free and multi-calendar versus the Google Calendar API (instant but Google-only + per-user token custody).
Split
The endpoint + token live in the backend repo (Pinakes); this issue tracks the client "subscribe" affordance and is blocked on that endpoint.
Context
Backend 0.7.65 adds add-to-calendar links to the loan emails: a Google Calendar link and a tokenized per-loan
.icsdownload. That is a one-shot import — if a loan is renewed or returned early, the event the borrower saved does not update.Goal
A subscribable per-user ICS feed so a borrower's loan due dates stay in sync in any calendar app — multi-calendar (Google, Apple, Outlook, Proton…), no account linking, no OAuth. This is the "real synchronisation" option discussed for the calendar feature.
Approach
GET /calendar/{token}.icsreturning aVCALENDARwith oneVEVENTper active loan for that borrower (title, due date,UID/SEQUENCEso updates replace, optionalVALARMreminder). Reuses the existingIcsGeneratorVEVENT builder..icsHMAC token), so the feed is private and can be regenerated.webcal://…/calendar/{token}.icsURL; also surface it in the profile screen. The one-shot per-loan.icsfrom the emails stays available for a single due date.Trade-off
The refresh cadence of a subscribed feed is decided by the client (Google ~12–24h, Apple more often) — fine for due dates that move by days, and the price for staying OAuth-free and multi-calendar versus the Google Calendar API (instant but Google-only + per-user token custody).
Split
The endpoint + token live in the backend repo (Pinakes); this issue tracks the client "subscribe" affordance and is blocked on that endpoint.