MSC4496: Calendar Events, Invites, and Availability in Matrix by MTRNord · Pull Request #4496 · matrix-org/matrix-spec-proposals

MTRNord · 2026-06-26T11:15:12Z

Rendered

Implementations:

Client: none
Server: none
Bridge: none
SDK: none

Signed-off-by: MTRNord support@midnightthoughts.space

Signed-off-by: MTRNord <MTRNord@users.noreply.github.com>

turt2live · 2026-06-26T14:16:31Z

Implementation requirements:

Client (ideally multiple)

Server

thetayloredman · 2026-06-27T00:30:21Z

+- [MSC1767](https://github.com/matrix-org/matrix-spec-proposals/pull/1767) – Extensible events
+  (required for `m.text` fallback blocks in all event types).
+- [MSC2674](https://github.com/matrix-org/matrix-spec-proposals/pull/2674) – Event
+  relationships (required for recurrence overrides and RSVP threading).
+- [MSC2676](https://github.com/matrix-org/matrix-spec-proposals/pull/2676) – Message edits
+  (required for cancellation and event updates).


These MSCs are all accepted into the spec. Typically these are not listed as "hard dependencies."

Will update that. It has been a while since I wrote an MSC and much less so one of this size :)

thetayloredman · 2026-06-27T00:31:19Z

+- [MSC1840](https://github.com/matrix-org/matrix-spec-proposals/pull/1840) – Typed rooms /
+  `m.room.type` (required for the `m.calendar` room type).


This MSC was rejected. The type field was introduced in MSC1772, which is, again, accepted.

thetayloredman · 2026-06-27T00:32:53Z

+Matrix currently has no first-class representation of calendar data. Users who wish to schedule
+events with others over Matrix must either use an out-of-band calendar system and paste details
+into chat, or rely on bespoke application-layer solutions that do not interoperate. This creates
+friction, breaks privacy (invites often travel via corporate email even when both parties use
+Matrix), and prevents Matrix from serving as a complete communication stack for organisations. A
+general, privacy-respecting, federated calendaring primitive in Matrix would fill this gap while
+also enabling transparent interop with the iCalendar/CalDAV ecosystem that the majority of the
+world already uses.


I still do not understand the use case for this feature. A more fleshed-out rationale (there is interesting value here in e.g. federation and E2EE) would be useful besides just "it's not Matrix."

Will update that in the next days.

The gist is this perspective I am coming from:

I want something I can use at work that replaces Teams entirely -> Calendaring is missing currently

Calendaring in Teams/Outlook is also deeply integrated and not just CalDAV bolted on.

I want to be able to share events in a group, invite someone via matrix where I don't know their email and I want proper RVSP

I do recognize that the internet mainly will use CalDAV or CalDAV adjacent protocols. There will be no time where everyone is using Matrix. Therefor I want a solution that is compatible with that and allows easy conversion in either direction (hence the appendix)

Additionally in an enterprise setting you likely still have to use email invites so having a bridge possibility here is useful.

As probably is obvious I am coming a lot from the Teams/Enterprise usecase and much less so from a personal usecase here. I don't think it is something everyone wants or needs in their client and that's perfectly reasonable. I can also see partial implementations like event calendars like discourse features for example.

E2EE is "free" in matrix. So that section for the most part exists just for clarity that it is possible to be used without too much effort.

The endpoints for availability are so that there is less information leak. Sure you could do this client side as well but then you cant easily make the homeserver hide hidden events from the other side. This way it is a bit easier to preserve privacy which imho is very important for a calendar. However, I did not want to implement all of CalDAV in matrix. That feels like the wrong direction. Hence historically matrix used bridges to map to third party networks. CalDAV I consider a third party network here. So I kept the API surface in matrix to the absolute bare minimum and instead tried to do as much as possible just using events.

That all being said I will bring this properly into the MSC itself as soon as I get the time :)

Johennes · 2026-07-06T06:27:50Z

+_This proposal introduces a general-purpose calendaring system for Matrix, covering event
+creation and sharing, invite/RSVP flows, attendee tracking, location and video conference
+attachments, recurrence, and user availability. It is intended to supersede the earlier
+attempt in MSC1116 and to incorporate the community feedback that drove that proposal toward
+an iCalendar-compatible semantic model. It deliberately avoids a meetings-specific scope so
+that higher-level applications (including video conferencing schedulers) can build on top._


Linkifying might help readability here.

Suggested change

_This proposal introduces a general-purpose calendaring system for Matrix, covering event

creation and sharing, invite/RSVP flows, attendee tracking, location and video conference

attachments, recurrence, and user availability. It is intended to supersede the earlier

attempt in MSC1116 and to incorporate the community feedback that drove that proposal toward

an iCalendar-compatible semantic model. It deliberately avoids a meetings-specific scope so

that higher-level applications (including video conferencing schedulers) can build on top._

_This proposal introduces a general-purpose calendaring system for Matrix, covering event

creation and sharing, invite/RSVP flows, attendee tracking, location and video conference

attachments, recurrence, and user availability. It is intended to supersede the earlier

attempt in [MSC1116] and to incorporate the community feedback that drove that proposal toward

an iCalendar-compatible semantic model. It deliberately avoids a meetings-specific scope so

that higher-level applications (including video conferencing schedulers) can build on top._

[MSC1116]: https://github.com/matrix-org/matrix-spec-proposals/pull/1116

Johennes · 2026-07-06T06:32:44Z

+2. **Extensible events throughout.** All event types defined here use the content-block model
+   from [MSC1767](https://github.com/matrix-org/matrix-spec-proposals/pull/1767). Clients
+   without calendar support can render a meaningful `m.text` fallback. The relationship between
+   this MSC and encryption is discussed in §7.


Given that extensible events are still unreleased, this fallback will only work in future clients while current clients would probably just not display the events at all?

Johennes · 2026-07-06T06:34:50Z

+  "state_key": "",
+  "content": {
+    "m.text": [{ "body": "Personal calendar", "mimetype": "text/plain" }],
+    "org.matrix.msc4496.calendar_info": {


I think for readability, the snippets shouldn't include the unstable prefixes. The section at the very end can just provide the mapping.

Johennes · 2026-07-06T06:37:04Z

+    "m.text": [{ "body": "Personal calendar", "mimetype": "text/plain" }],
+    "org.matrix.msc4496.calendar_info": {
+      "color": "#3c82f6",
+      "timezone": "Europe/Berlin"


What are the semantics of timezone, especially for shared / group calendars?

Johennes · 2026-07-06T06:38:22Z

+  "content": {
+    "m.text": [{ "body": "Personal calendar", "mimetype": "text/plain" }],
+    "org.matrix.msc4496.calendar_info": {
+      "color": "#3c82f6",


Would color not rather be something to be determined on the displaying client? What if I display two calendars that happened to pick the same color value?

Johennes · 2026-07-06T06:43:04Z

+For virtual locations, `uri` is a plain HTTPS URL rather than a `geo:` URI. Clients SHOULD
+display virtual locations as clickable links.


I think the spec may not have to be concerned with how clients display the content. A CLI client may not even be able to display clickable links.

Johennes · 2026-07-06T06:46:05Z

+at least one `via` entry when constructing this block; a `conference` block without a `via`
+array SHOULD be treated as unresolvable and clients SHOULD disable the join button rather
+than silently failing. The call room is managed independently of the calendar event; this
+MSC does not specify how it is created. Clients SHOULD display the room name with a fallback to the room ID and


What does "display the room name with a fallback to the room ID" mean?

Johennes · 2026-07-06T06:50:23Z

+"conference": {
+  "type": "m.call",
+  "room_id": "!callroom:example.com",
+  "via": ["example.com", "matrix.org"],
+  "label": "Join call"
+}


MatrixRTC can have several slots per room. Maybe we should include the slot_id from m.rtc.slot here, too? Also, since MatrixRTC has its own m.call application type and will probably have further application types in future, maybe the type here should be something more generic such as m.rtc?

Propose Matrix Calendar Features

0119e9f

Signed-off-by: MTRNord <MTRNord@users.noreply.github.com>

MTRNord changed the title ~~MSC 4496: Calendar Events, Invites, and Availability in Matrix~~ MSC4496: Calendar Events, Invites, and Availability in Matrix Jun 26, 2026

turt2live reviewed Jun 26, 2026

View reviewed changes

Comment thread proposals/4496-matrix-caldav.md

turt2live Jun 26, 2026

Copy link
Copy Markdown

Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Implementation requirements:

Client (ideally multiple)

Server

thetayloredman reviewed Jun 27, 2026

View reviewed changes

Johennes reviewed Jul 6, 2026

View reviewed changes

		- [MSC1840](https://github.com/matrix-org/matrix-spec-proposals/pull/1840) – Typed rooms /
		`m.room.type` (required for the `m.calendar` room type).

		For virtual locations, `uri` is a plain HTTPS URL rather than a `geo:` URI. Clients SHOULD
		display virtual locations as clickable links.

Uh oh!

Conversation

MTRNord commented Jun 26, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants