CalDAV behavior and storage reference

This page covers Everlock's CalDAV behavior and storage model.

What it supports

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 underlying store commit id as the sync token.

Event validation

require one VCALENDAR
require one master VEVENT; related recurrence overrides may share the same resource and UID
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
IANA timezones, floating times, daylight-saving transitions, recurrence exclusions, additional dates, and detached instance overrides are applied during expansion
free/busy answers are derived from the stored events
sync uses commit history instead of a second sync database