a calendar of a few hundred events and an address book of a few hundred cards are
both lists you scroll until you give up. one box on each header narrows them.
CLIENT SIDE, because the data is already here: both screens fetch a whole
collection in one request and hold it, so filtering is a string comparison over
what is in hand. a round trip per keystroke would be slower, would need a search
endpoint on the sidecar, and would put a spinner where a person expects a list to
narrow as they type.
ACCENT-INSENSITIVE, and that is the half that decides whether this is usable
here: these contacts are portuguese, and a box where "jose" does not find "José"
is a box nobody uses twice. NFD splits the letter from its accent and the range
strips what is left, so it matches in both directions — "josé" finds "Jose" too.
every term must match somewhere, not all in one field, so "ana lisboa" finds the
ana whose address is in lisbon. events match on their start as well, which is an
ISO string, so "2026-08-29" narrows to a day without anything having to parse it.
the count in the header becomes "12 of 340" while filtering, and a filter that
matches nothing says so by name — otherwise it reads as a calendar that lost its
events.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043
everything since .01: edit and delete on both screens, create an event and a
contact, PATCH one item's fields, ?collection=<name> instead of an escaped dav
path, and the agent skill rewritten off hand-written iCalendar onto the routes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
first dated version. plugins were all sitting on 1.0.0, which said nothing about
when a build was made or which of two copies is newer — the platform already
uses YYYY.MM.DD.NN and this follows it.
the version lives in manifest.ts because a plugin has no package.json; that is
the field the marketplace publishes and the installer compares.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
tags are how the marketplace is browsed rather than scrolled: a list of them on
the left, the plugins that carry one on the right. a closed vocabulary
(PLUGIN_TAGS in the platform) because free text becomes homelab, home-lab, Home
Lab and selfhosted inside a month, and a filter list of synonyms is worse than
no filter at all.
declared here rather than curated in the catalogue, so a plugin can say what it
is and nobody edits a table when one ships. the marketplace caches it on sync,
exactly as it already does for label and summary.
one sidecar, one permission, one install — and two screens, because Calendar and
Contacts are two places you go rather than two sections of one page. the first
plugin to declare `screens`, which the platform gained for this.
what moved: the radicale sidecar, the four routers, the panel apps, the
app-password table and the settings form. the form became a modal on the
calendar screen — a plugin ships panels and cannot contribute a settings
section, which is the same wall the email plugin hit and the same answer.
the routes are /calendar and /contacts, not /caldav/calendar. they were core
routes and keeping them is not cosmetic: a bookmark, a dock tile someone
arranged, and a persisted layout all address them. only a first-party plugin may
choose its own segment; a third-party one is confined to /p/<publisher>/.
four paths outside /api come with it, above the account gate, because phones are
not browsers: DAVx5, iOS and thunderbird send HTTP basic on every request and
have nowhere to put a JWT. that is not "open" — the sync door demands a scoped
app password and resolves it to one user before radicale sees anything.
two things deliberately unchanged. the table is still dav_app_passwords, not
caldav_app_passwords: installs hold real rows and a naming convention is not
worth a data migration on a live machine. and the panel names still resolve
through the platform's catalogs, so the six locales they had as core screens
survive rather than dropping to english to make the refactor tidier.
per-user was already true and is worth writing down because the config said
otherwise: the sync door resolves an app password to an account, tells radicale
that id is the principal, and owner_only does the rest. the comment claiming
"the owner is the only principal that exists" had been stale since multi-user
landed on 2026-08-07.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043
pastilhasandClaude Opus 5