MatrixRTC native support checklist

nex commented

2026-02-21 13:12:32 +00:00

Owner

Tip

While this checklist details things that are necessary for full native support for MatrixRTC, MatrixRTC works fine without any server-side co-operation at the time of writing.

MatrixRTC: MSC4143 (rendered)

MSC4354: Sticky Events (rendered)
MSC4140: Cancellable delayed events (rendered)
Ideally a native livekit JWT service (integrating jwt-service-rs into the server directly)

> [!TIP] > While this checklist details things that are necessary for *full native support* for MatrixRTC, **MatrixRTC works fine without any server-side co-operation** at the time of writing. MatrixRTC: [MSC4143](https://github.com/matrix-org/matrix-spec-proposals/pull/4143) [(rendered)](https://github.com/matrix-org/matrix-spec-proposals/blob/toger5/matrixRTC/proposals/4143-matrix-rtc.md) - [ ] [MSC4354: Sticky Events](https://github.com/matrix-org/matrix-spec-proposals/pull/4354) [(rendered)](https://github.com/matrix-org/matrix-spec-proposals/blob/kegan/persist-edu/proposals/4354-sticky-events.md) - [ ] [MSC4140: Cancellable delayed events](https://github.com/matrix-org/matrix-spec-proposals/pull/4140) [(rendered)](https://github.com/matrix-org/matrix-spec-proposals/blob/toger5/expiring-events-keep-alive/proposals/4140-delayed-events-futures.md) - [ ] Ideally a native livekit JWT service (integrating [jwt-service-rs](https://github.com/JadedBlueEyes/jwt-service-rs) into the server directly)

nex added the

labels

2026-02-21 13:12:32 +00:00

benbot commented

2026-02-21 15:34:48 +00:00

Contributor

I could at least help getting some confit options in to populate the .well-known responses with the rtc info :)

Henry-Hiles commented

2026-02-21 15:37:38 +00:00

Member

I think .well-known isn't meant to be used for MatrixRTC anymore, though Element Call still uses it? So the new endpoint needs to be implemented also?

👍 1

benbot commented

2026-02-21 16:24:12 +00:00

Contributor

@Henry-Hiles wrote in #1432 (comment):

I think .well-known isn't meant to be used for MatrixRTC anymore, though Element Call still uses it? So the new endpoint needs to be implemented also?

Then what’s the endpoint for the application info?
I thought that was still going to be in the well-known somewhere.

I couldn’t find it from skimming the MSC

@Henry-Hiles wrote in https://forgejo.ellis.link/continuwuation/continuwuity/issues/1432#issuecomment-24730: > I think .well-known isn't meant to be used for MatrixRTC anymore, though Element Call still uses it? So the new endpoint needs to be implemented also? Then what’s the endpoint for the application info? I thought that was still going to be in the well-known somewhere. I couldn’t find it from skimming the MSC

Henry-Hiles commented

2026-02-21 16:25:57 +00:00

Member

@benbot wrote in #1432 (comment):

@Henry-Hiles wrote in #1432 (comment):

I think .well-known isn't meant to be used for MatrixRTC anymore, though Element Call still uses it? So the new endpoint needs to be implemented also?

Then what’s the endpoint for the application info? I thought that was still going to be in the well-known somewhere.

I couldn’t find it from skimming the MSC

Looks like /_matrix/client/v1/rtc/transports

@benbot wrote in https://forgejo.ellis.link/continuwuation/continuwuity/issues/1432#issuecomment-24731: > @Henry-Hiles wrote in #1432 (comment): > > > I think .well-known isn't meant to be used for MatrixRTC anymore, though Element Call still uses it? So the new endpoint needs to be implemented also? > > Then what’s the endpoint for the application info? I thought that was still going to be in the well-known somewhere. > > I couldn’t find it from skimming the MSC Looks like `/_matrix/client/v1/rtc/transports`

Jade commented

2026-02-21 16:26:34 +00:00

Owner

https://github.com/matrix-org/matrix-spec-proposals/blob/toger5/matrixRTC/proposals/4143-matrix-rtc.md#discovery-of-rtc-transports

benbot commented

2026-02-21 16:38:47 +00:00

Contributor

That’s for the RTC transports, not the RTC application types.

github.com/matrix-org/matrix-spec-proposals@7907635a54/proposals/4143-matrix-rtc.md (matrixrtc-application-types)

That’s for the RTC transports, not the RTC application types. https://github.com/matrix-org/matrix-spec-proposals/blob/7907635a54080fd35739910818e26f5d6edbe8c3/proposals/4143-matrix-rtc.md#matrixrtc-application-types

Beanie commented

2026-03-06 16:51:47 +00:00

There's also MSC4407: Sticky Events (widget-api), used by services like https://github.com/SultanAlburaq/matrix-element-call-musicbot

There's also [MSC4407: Sticky Events (widget-api)](https://github.com/matrix-org/matrix-spec-proposals/pull/4407), used by services like https://github.com/SultanAlburaq/matrix-element-call-musicbot

Jade commented

2026-03-06 16:57:58 +00:00

Owner

@benbot RTC application types are client controlled, the server has nothing to do with them.

@Beanie That's in the widget spec, which should be implemented by clients and widget SDKs, not servers.

@benbot RTC application types are client controlled, the server has nothing to do with them. @Beanie That's in the widget spec, which should be implemented by clients and widget SDKs, not servers.

👍 1

Crazy_Nicc commented

2026-06-22 15:19:30 +00:00

MatrixRTC works fine without any server-side co-operation at the time of writing

As announced in https://matrix.org/blog/2026/06/19/this-week-in-matrix-2026-06-19, Element Call will soon default to using the Multi-SFU approach, which as far as I can tell needs Sticky Events to work.

This change would mean that any users on a c10y homeserver could no longer join other's calls by default (the people already in the call would need to "downgrade" the call). This would be a rather big annoyance.

While I`d love to send patches for Sticky Events, I have no idea about rust. That's why I'm asking if anyone could look into implementing Sticky Events in c10y (and look at the PRs for Delayed Events #1799 and #1840).

> MatrixRTC works fine without any server-side co-operation at the time of writing As announced in https://matrix.org/blog/2026/06/19/this-week-in-matrix-2026-06-19, Element Call will soon default to using the Multi-SFU approach, which as far as I can tell needs Sticky Events to work. This change would mean that any users on a c10y homeserver could no longer join other's calls by default (the people already in the call would need to "downgrade" the call). This would be a rather big annoyance. While I`d love to send patches for Sticky Events, I have no idea about rust. That's why I'm asking if anyone could look into implementing Sticky Events in c10y (and look at the PRs for Delayed Events #1799 and #1840).

Henry-Hiles commented

2026-06-22 15:21:57 +00:00

Member

@Crazy_Nicc wrote in #1432 (comment):

MatrixRTC works fine without any server-side co-operation at the time of writing

As announced in https://matrix.org/blog/2026/06/19/this-week-in-matrix-2026-06-19, Element Call will soon default to using the Multi-SFU approach, which as far as I can tell needs Sticky Events to work.

This change would mean that any users on a c10y homeserver could no longer join other's calls by default (the people already in the call would need to "downgrade" the call). This would be a rather big annoyance.

While I`d love to send patches for Sticky Events, I have no idea about rust. That's why I'm asking if anyone could look into implementing Sticky Events in c10y (and look at the PRs for Delayed Events #1799 and #1840).

~~Sticky Events are implemented client-side, not server-side AFAIK. No support should be needed from Continuwuity.~~

EDIT: Nevermind, I got confused by MSC4407 vs MSC4354.

@Crazy_Nicc wrote in https://forgejo.ellis.link/continuwuation/continuwuity/issues/1432#issuecomment-30517: > > MatrixRTC works fine without any server-side co-operation at the time of writing > > As announced in https://matrix.org/blog/2026/06/19/this-week-in-matrix-2026-06-19, Element Call will soon default to using the Multi-SFU approach, which as far as I can tell needs Sticky Events to work. > > This change would mean that any users on a c10y homeserver could no longer join other's calls by default (the people already in the call would need to "downgrade" the call). This would be a rather big annoyance. > > While I`d love to send patches for Sticky Events, I have no idea about rust. That's why I'm asking if anyone could look into implementing Sticky Events in c10y (and look at the PRs for Delayed Events #1799 and #1840). ~~Sticky Events are implemented client-side, not server-side AFAIK. No support should be needed from Continuwuity.~~ EDIT: Nevermind, I got confused by MSC4407 vs MSC4354.

Crazy_Nicc commented

2026-06-22 15:31:28 +00:00

@Henry-Hiles wrote in #1432 (comment):

Sticky Events are implemented client-side, not server-side AFAIK. No support should be needed from Continuwuity.

Sticky Events definitely need Server Support, see the Proposal and also the Synapse PR

@Henry-Hiles wrote in https://forgejo.ellis.link/continuwuation/continuwuity/issues/1432#issuecomment-30520: > Sticky Events are implemented client-side, not server-side AFAIK. No support should be needed from Continuwuity. Sticky Events definitely need Server Support, see the [Proposal](https://github.com/matrix-org/matrix-spec-proposals/blob/kegan/persist-edu/proposals/4354-sticky-events.md#federation-behaviour) and also [the Synapse PR](https://github.com/element-hq/synapse/pull/19365)

nex commented

2026-06-22 21:42:30 +00:00

Author

Owner

Element forcing unstable and nowhere near close to FCP proposals into production yet again, what a surprise. I've seen this one play out before.

Even if we start implementing it now, it probably won't be ready by the time they make their next release. We're also on a feature freeze for 0.5.X, which means everyone would be forced to use the new alpha releases, which bring huge changes that we're still testing in our own right (and many servers aren't comfortable using non-release versions anyway).

Element forcing unstable and nowhere near close to FCP proposals into production yet again, what a surprise. I've [seen this](https://github.com/matrix-org/matrix-spec-proposals/pull/4186) one play out [before](https://github.com/matrix-org/matrix-spec-proposals/pull/3575). Even if we start implementing it now, it probably won't be ready by the time they make their next release. We're also on a feature freeze for 0.5.X, which means everyone would be forced to use the new alpha releases, which bring huge changes that we're still testing in our own right (and many servers aren't comfortable using non-release versions anyway).

nex commented

2026-06-22 22:26:13 +00:00

Author

Owner

After re-reading the sticky events proposal, it probably won't be too difficult to actually implement them locally, but sending them over federation will depend on the federation sender rewrite, which is currently still in the planning phase and has no ETA.

Crazy_Nicc commented

2026-06-26 10:39:19 +00:00

I asked in the Element-Call repo (see here: https://github.com/element-hq/element-call/pull/4066#discussion_r3480011546)

The Multi-SFU change will therefore not require Sticky Events.

I asked in the Element-Call repo (see here: https://github.com/element-hq/element-call/pull/4066#discussion_r3480011546) The Multi-SFU change will therefore not require Sticky Events.

Crazy_Nicc commented

2026-06-27 12:30:24 +00:00

There was now clarification in the newest TWIM-Post (https://matrix.org/blog/2026/06/26/this-week-in-matrix-2026-06-26/)

Next up: Transition to full Matrix 2.0 sticky events (impl on Synapse and EC are ready; we want to give the ecosystem more time to adapt to sticky events — this will probably happen after merging the Matrix 2.0 spec)

There was now clarification in the newest TWIM-Post (https://matrix.org/blog/2026/06/26/this-week-in-matrix-2026-06-26/) > Next up: Transition to full Matrix 2.0 sticky events (impl on Synapse and EC are ready; we want to give the ecosystem more time to adapt to sticky events — this will probably happen after merging the Matrix 2.0 spec)

Rows
Columns

MatrixRTC native support checklist #1432