I’ve (had Claude) built out the a working Google calendar fork. Before I open a client PR: does this collide with work you already have in flight?
Four components from the Bundle: Calendar roadmap topic:
- RSVP — accept/decline/tentative from the invitation email and the calendar grid, writing PARTSTAT and sending a real iTIP REPLY to the organizer.
- Issuing invites, including “propose a new time” via iTIP COUNTER.
- Create/edit/delete — double-click, drag to move/resize, context menu, editor.
- Ownership — DAV:owner resolves which calendar is actually yours, so writes land in the right place and shared/resource calendars aren’t written to.
It also drops the preview banner and moves Calendar from the Developer to the Window menu — the graduation you described. Your call, and a one-commit revert.
Attendees can no longer edit meetings they don’t organize (RFC 5546 §2.1.4). Correct per spec, but a big visible shift: on my account 22 events are mine, ~565 have no ORGANIZER and stay editable, and ~180 organized by colleagues became read-only.
Verified, against a live Google Workspace CalDAV account: accepting an emailed invitation works end to end (right calendar, PARTSTAT written, METHOD stripped, PUT accepted, REPLY delivered, SEQUENCE correctly 0). The v10 migration runs clean on a real 316MB / 841-event database. 1809 tests, lint and tsc --noEmit all clean.
Not verified: only Google has been exercised live — Fastmail, iCloud, Exchange and Nextcloud shape DAV:owner and principal URLs differently, and Google’s /user suffix already needed a special case. And macOS/Windows are audited, not built — the C++ has only seen GCC.
The ask
Four PRs are open with no review yet. The first two stand alone even if you don’t want the calendar work:
- Mailspring#2829 — fixes the type errors that make npm run typecheck exit 2 on master, so the Test workflow fails on every PR. Worth landing first: it’s what makes CI a real signal for the rest.
- Mailspring#2827 — report mailsync startup failures instead of “an unknown error has occurred.”
- Mailspring-Sync#122 — engine hardening (null-logger crash guards, href XML escaping, log redaction). - - Mailspring-Sync#123 — the calendar engine changes. #122 was extracted from it, so land #122 first and I’ll rebase to drop the duplicates.▎
The client PR isn’t open — that’s what I’m asking about. Ordering matters one way: the client sends METHOD:COUNTER, which any engine older than #123 hard-rejects, so “propose a new time” is dead until the engine side lands.
Please let me know if this is something I should create PR for vs just posting a huge commit.