We’re running Stalwart 0.16.8 and absolutely love the email experience. We’re trying to get our team to love using the calendar as much as Google Calendar, and some users are getting tripped up by the incomplete attendee status sync:
As an invitee I can see my own RSVP and the organizer’s, but never anyone else’s. On a meeting with five people I have no idea who else has accepted unless I’m the organizer.
When an attendee replies, the reply is correctly applied to the organizer’s event, so the organizer sees everyone’s status. But those updated statuses are never sent to the other attendees, so each attendee’s copy only ever reflects their own reply plus whatever was in the original invitation.
I confirmed it by looking at the same event across three accounts: the organizer and two attendees who had both accepted. The organizer’s copy has everyone as accepted, including the external attendee who replied over iMIP. But each attendee only sees themselves.
RFC 6638 §4.2 describes exactly this situation. After the server updates the organizer’s copy from a reply, it should “send scheduling messages to all the other ‘Attendees’ indicating the change in participation status of the ‘Attendee’ replying.” Stalwart does the first half but not the second, which is why it works for the organizer but not for attendees.
I went looking in the v0.16.8 source to understand where this would live. In crates/groupware/src/scheduling/inbound.rs, handle_reply applies the replying attendee’s PARTSTAT/RSVP to the organizer’s stored copy and returns local merge actions only — nothing gets re-sent to the other attendees. The one inbound path that does emit outbound REQUESTs (organizer_request_full) is the Refresh handler, and it only replies to the requester.
The feature request: when a REPLY lands on a locally-organized event, also fan the updated attendee statuses back out to the other attendees — a fresh REQUEST, or a targeted PARTSTAT update — as in §4.2. That would let everyone see the full RSVP list and close the gap with Google/Exchange. Some coalescing is probably worth it so a flurry of replies doesn’t turn into a storm of update messages.
Happy to test a build if this gets picked up. Thanks for all the work on this awesome stack.
RFC 6638 §4.2: https://www.rfc-editor.org/rfc/rfc6638.html#section-4.2