Calendar backend

The calendar family is backend-calendar-http.

Current state

implemented and active
served through frontend-http
multi-instance and multi-vhost
one dedicated versioned-storage store per instance
Everlock-user HTTP authentication
Everlock access control on http/calendar/<instance>
multiple calendars per instance
writable CalDAV collections and event resources
readable .ics event files in versioned storage
recurrence-aware calendar-query
calendar-multiget
sync-collection with commit-id sync tokens
free-busy-query

URL shape

/.well-known/caldav
/dav/
/dav/principals/me/
/dav/calendars/
/dav/calendars/<calendar>/
/dav/calendars/<calendar>/<event>.ics

Storage shape

Each calendar instance uses one dedicated versioned-storage store.

default/
  config.toml
  team-meeting.ics
work/
  config.toml
  customer-review.ics

Like contacts, calendar resources use readable slug-based filenames, minimal normalization, and injected UID when missing. Collection sync uses the real versioned-storage commit id as the sync token.

Event validation

require one VCALENDAR
require one primary VEVENT
require VERSION:2.0
require DTSTART
preserve UID or inject one if missing
prefer SUMMARY for filenames, but fall back to UID if needed

That stays intentionally permissive because Android and Apple calendar clients do not always emit identical event shapes.

Query behavior

recurrence fields such as RRULE and EXDATE are preserved
recurring events are expanded at query time for range-based views
free/busy answers are derived from the stored events
sync uses commit history instead of a second sync database

Intended role

provide calendar behavior over HTTP-facing protocols such as CalDAV
stay separate from transport and auth mechanics handled by the frontend