# Server work the mobile Calendar & Contacts apps need **From:** the mobile side, 2026-08-04. **About:** `platform/docs/mobile-dav-provisioning.md`, which we have now built against. The mobile apps are written and typecheck. Two screens read your JSON door, and a third does the provisioning flow from §2 of your document. This is the list of what is **yours**, in the order it unblocks us — nothing here is a complaint about the doc, which was accurate everywhere we could check it. --- ## 1. `POST /api/dav/provision/ios` — the one real blocker Your §3.4 specifies this endpoint and marks it as unwritten. It is the only thing standing between the iOS app and one-tap setup; everything else on our side is done and waiting. **What we already call, exactly as specified:** ``` POST /api/dav/provision/ios Authorization: Bearer { "deviceLabel": "iPhone — Officer app" } → 200 { "url": "https:///dav/provision/.mobileconfig", "expiresAt": "" } ``` We open `url` with `Linking.openURL`, which is Safari. We do not use a WebView — your §3.6 is right that it silently does nothing. **What we do today without it:** `provisionIos()` turns a 404 or a 501 into a typed `DavProvisionUnavailable`, and the screen falls back to showing the host, username and a freshly-minted password with copy buttons, plus the §1.6 warning about giving the CardDAV account an explicit collection URL. So the feature degrades rather than breaking — but it is exactly the hand-typing the document exists to eliminate. **Three things we would ask you to hold to**, all from your own §3–§5: - `Content-Type: application/x-apple-aspen-config`. Served as `application/octet-stream` the file downloads and iOS ignores it. - Single use, ≤5 minute TTL, deleted on first fetch. It is an unauthenticated URL with a live password in it. - One profile containing **both** the CalDAV and CardDAV payloads, and a stable `PayloadIdentifier`. That is what makes re-running setup replace the profile instead of stacking a second account, and it is what sidesteps the account-merge trap in §1.6 entirely. **Signing:** your §3.5's note about re-signing on certificate renewal is the part most likely to be forgotten six months from now, since nothing fails until someone installs a profile. If the renewal hook is not wired at the same time as the endpoint, it is worth an alarm rather than a comment. **A 501 would help.** If the endpoint is going to exist before it works, please answer `501` rather than `404` — we treat both as "fall back", but 501 tells us the server knows about the feature, and it is the difference between "this Officer is too old" and "this Officer is broken" in a support conversation. --- ## 2. Confirm the DAV user id, or give us a way to ask §1.4 says the principal is `/dav//` and that `` is "the numeric account id — `1` on a single-user instance, which every Officer instance is." We do **not** hardcode 1. We derive it from the collection paths `/api/caldav/_officer/collections` returns, and fall back to the authenticated user's `id` from `/auth/me`. That works, and it needs nothing from you — but two questions we could not answer from the code: 1. **Is the DAV `` always the same integer as the platform user id?** They are equal on the reference deployment. If they are the same field by construction, say so in §1.4 and we will simplify; if they could ever diverge, the collections list is the only safe source and §1.4 should warn against the obvious shortcut. 2. **Can a collection ever live outside `/dav//`?** The sidecar rejects a `collection` query parameter that does not start with `/dav//`, so we assume no. --- ## 3. Optional, and we are not asking for it yet: writes The JSON door is read-only, which we think is right, and our screens are read-only to match. Editing happens in the phone's native Calendar and Contacts apps over the DAV account, which already handle recurrence, invitations, reminders and offline edits. We raise it only so the boundary is deliberate on both sides: **if in-app editing is ever wanted, it needs the sidecar to grow a write path.** We will not reach around it and PUT iCalendar at `/dav` from the app — that door authenticates with a DAV app password, and §5.5 says the app must not keep one. If you do build it, the minimum useful surface is create/update/delete for a VEVENT and a VCARD, by collection path and UID, with the sidecar owning the iCalendar generation exactly as it owns the parsing today. --- ## 4. Two smaller things **`lastUsedAt` throttling.** §6 says it is written at most once a minute, and we honour that: after provisioning we poll `GET /api/dav/passwords` every 5 s for 2 minutes before showing anything discouraging. If that throttle ever changes, it changes our timeout — worth a line in §6. **Revocation is in the app**, per §5.7, including revoking the previous credential with the same device label when setup is re-run (your §8's suggestion, answered the way you suggested). Nothing needed from you; noted so you know the app can create _and_ destroy these rows. --- ## 5. What we built, so you can see the shape - `packages/core/src/services/caldav.ts` — the JSON door client. Reads `/_officer/{collections,events,contacts}` and nothing else. - `packages/core/src/services/dav.ts` — app passwords, endpoint derivation, the iOS profile call, the DAVx⁵ hand-off. - `packages/core/src/screens/{calendar,contacts}/` — an agenda and an A–Z list, both read-only. - `packages/core/src/screens/dav/DavSyncScreen.tsx` — §2's screen. Two details from your sidecar we deliberately preserved, because both would be easy to get wrong in a UI: `rrule` is displayed as a "repeats" badge and never expanded into occurrences, and all-day dates are grouped without being parsed as a `Date` — `20260805` through `new Date()` is midnight UTC, which lands on the previous day for anyone west of it. --- ## Summary | | Needed from you | Blocks | | --- | ------------------------------------------------------------------------------------------ | ----------------------------------------------- | | 1 | `POST /api/dav/provision/ios` + token-gated `.mobileconfig`, signed, with the renewal hook | one-tap iOS setup | | 2 | Confirm `` semantics in §1.4 | nothing — a simplification | | 3 | Sidecar write path | nothing — only if in-app editing is ever wanted | | 4 | Tell us if the `lastUsedAt` throttle changes | nothing today | Only row 1 is a blocker. Everything else is us writing down what we assumed, so that if an assumption is wrong it fails in a review rather than on someone's phone.