Server compatibility

Cyrus and Stalwart are the two servers calendaring-jmap’s integration tests run against. This page collects every confirmed difference between them in one place; each row links to the how-to page that covers it in context.

Behavior	Cyrus	Stalwart	See
PushSubscription/get//set	Not implemented at all (unknownMethod)	Fully implemented	Push notifications
Attachment rel: "enclosure" persistence	Accepts the write, doesn’t reliably persist it on read-back	Persists correctly	Work with attachments, Work with events
search_events’s participant_role="attendee" filter	Server drops the attendee role from roles, so this misses matches	Same gap	Work with events
Contact search by text against the card’s name	Matches as a substring against the name	Matches only the email address, never the name	Work with contacts
get_availability with show_details=True	Returns event details by default	Needs the account to support returning details at all; event comes back None otherwise	Check free/busy
Participant sendTo on CalendarEvent/set	Rejected outright with invalidProperties; calendarAddress required instead	Accepts the calendarAddress-only form too	Design
JMAP Tasks (urn:ietf:params:jmap:tasks)	Not implemented	Not implemented	Use tasks

Counter-proposals (iTIP COUNTER) have no distinct method on either server: a non-origin participant can write start/duration directly as a plain update, through the server’s own rights model, on both Cyrus and Stalwart. See Scheduling and invitations.