MSC4519: MatrixRTC Transports Registry by turt2live · Pull Request #4519 · matrix-org/matrix-spec-proposals

turt2live · 2026-07-28T06:07:44Z

SCT Stuff:

turt2live · 2026-07-28T06:08:58Z

Implementation requirements:

Transports endpoint: client

Transports endpoint: server

This is effectively implemented by Synapse via MatrixRTC.

Server: Add MatrixRTC backend/services discovery endpoint element-hq/synapse#18967

JS SDK: Implement _unstable_getRTCTransports for MSC4143 matrix-js-sdk#5104

Element Call: RtcTransportAutoDiscovery.ts

Element Web: CallStore.fetchTransports

Note
When ran in widget mode, Element Call cannot yet use the /transports endpoint because the widget API doesn't expose access to it. This is covered by #4515.

robintown · 2026-07-30T11:50:42Z

+
+A new "MatrixRTC Transports" registry is created with the following information:
+
+* A transport `type`. MUST be an [Opaque Identifier](https://spec.matrix.org/v1.19/appendices/#opaque-identifiers).


Currently this proposal says, "Types not in the registry are not permitted," but I hope that the spec could eventually make room for unregistered, proprietary transports which might not be suitable for making public. This seems easiest to manage if we recommend the Common Namespaced Identifier Grammar.

Previously we were recommending CNIG without the namespacing requirements so that we could still have an un-namespaced livekit as in this MSC, but I & others on the Element VoIP team would be interested in your judgement on whether it would be preferable to keep the namespacing requirement, if we say type uses CNIG.

Explicitly supporting proprietary transports doesn't really fit the Guiding Principles in my opinion. We can support namespacing, but I would still probably keep the limitation that only registered types can be used, at least until Matrix itself has a transport type that's part of the core specification.

Without a core transport type in the spec we run the risk of only having proprietary transports, which defeats the purpose of this registry.

A later MSC can remove the condition easily enough without it being a breaking change.

(leaving open for further opinions, but mentally considering resolved for now)

would using m.livekit really be that bad?

m.livekit is fine in isolation, but opening up the registry to have unregistered custom types I feel would be a mistake.

I think we should switch to m.livekit because we already use the namespacing elsewhere in MatrixRTC (e.g. m.per_member) and we would probably want to allow extensibility at some point.

#4195 has switch to m.livekit now.

turt2live · 2026-08-03T16:55:07Z

turt2live · 2026-08-03T16:56:20Z

@mscbot fcp merge
@mscbot concern Dependency - Registries
@mscbot concern Coordinate FCP with MatrixRTC

mscbot · 2026-08-03T16:56:24Z

richvdh · 2026-08-04T15:53:22Z

+
+A new "MatrixRTC Transports" registry is created with the following information:
+
+* A transport `type`. MUST be an [Opaque Identifier](https://spec.matrix.org/v1.19/appendices/#opaque-identifiers).


would using m.livekit really be that bad?

Johennes · 2026-08-19T13:45:14Z

+added when a new proposal is opened which introduce a transport. They by default have a `type` of `msc0000.{stable_type}`,
+but MAY be extended upon per the MSC's "Unstable Prefix" section provided they maintain the `msc0000`
+prefix. For example, if a proposal changes substantially after the registration was made, the proposal 
+might suggest using `msc0000.livekit.v2`.


Is there a benefit to customizing the prefixing rules like this other than making identifiers a little shorter? I would have expected that we'd just use the existing prefixing rules.

Johennes · 2026-08-19T13:57:33Z

+* The author opens a spec PR to register the `msc4195.livekit` unstable type, using the MSC URL as
+  the specification reference (specifically the "Unstable Prefix" section/components).


The unstable transport is registered manually via a spec PR here but further up it says

[...] unstable transports are automatically added when a new proposal is opened which introduce a transport.

Having the registry change automatically as MSCs are opened worries me a little. I also wonder if we actually need to register unstable types in the registry at all? It feels like while something is not stable, it shouldn't land in the registry just like normal MSCs don't land in the spec either without being accepted?

That would also avoid the clean-up step 12 months after the transport became stable.

Registries are outside of the spec, so they need their own mechanisms to track unstable prefixes.

Johennes · 2026-08-19T14:05:40Z

+  **Note**: If the MSC is detailed enough, a link to the rendered Markdown in the spec proposals repo
+  is probably suitable too.


Linking by SHA would be ok but linking by branch name (which is normally done for the [Rendered] links) would allow for further changes to the registry-spec without new MSCs. I think for stable transports, I'd prefer the registry to just contain the required spec text – just like the normal spec.

I'm not following the concern here, sorry - linking to a branch name to get live updates is the desired behaviour.

My concern is that the registry itself should be stable. It shouldn't change unexpectedly without a release. Anything that aims to enter the registry requires an MSC. While the MSC is unstable / unmerged, the MSC alone is sufficient to coordinate any early implementations. We don't need to track unstable transports in the registry – just like we don't track unstable features in the Matrix spec itself.

Johennes · 2026-08-19T14:12:31Z

+### Exception: MSC4195
+
+Because MSC4195 has been used to test the unstable implementation of MSC4143 and has no unstable
+prefixes itself, `livekit` is registered as an unstable type instead of `msc4195.livekit`. When
+MSC4195 becomes accepted, its type is to be upgraded to `stable` with relevant changes to the spec
+link. No implementation changes would be required outside what they'd need to do to support MSC4143
+becoming stable itself.


Should this rather move into #4195? Otherwise both MSCs mutually depend on each other?

This MSC is better positioned to state the namespacing requirements. Stating them in this way doesn't create a dependency on MSC4195 - it's just saying "if/when MSC4195 enters the registry, it uses this type".

clokep

@mscbot concern Unclear why this needs a registry instead of the normal spec process

clokep · 2026-08-19T20:22:20Z

+The primary motivation for a registry is to allow transports such as [MSC4195](https://github.com/matrix-org/matrix-spec-proposals/pull/4195)
+to land with relative stability, but without placing a dependency on LiveKit into the core spec.


The spec has some optional modules, this sentence along with the potential issue of there not being many RTC transports makes this feel like overkill to have this be a registry?

Yeah, I think we need to improve the motivation a little. The concrete advantages of the registry I can currently think of are:

Releasing transports is not dependent on the spec release cycle
This proposal doesn't currently clarify whether the registry will be released together with the spec or not though. See also https://github.com/matrix-org/matrix-spec-proposals/pull/4519/changes#r3813858452.

Transports can more easily be removed from the registry than from the main spec
Homeservers declare support for entire spec versions. Even if a feature is removed, servers often retain their implementations to be able to declare support for older spec versions. This came up as a concern when discussing the integration of the LiveKit transport with the Synapse team.

Having said that, I acknowledge the concern that we may not have a lot of transports, however. The transports the VoIP team at Element can foresee right now are:

LiveKit (MSC4195)
This is the only one we have today.

A cascading SFU transport where users connect to their local SFU only and SFUs federate
@fkwp has made some explorations on this. It'll require a dedicated SFU implementation. If proven worthwhile, this would be an alternative (if not a full replacement) for the LiveKit transport. Currently, it seems likely that we'll work on this after Matrix 2.0.

A full-mesh transport where members connect to each other directly as in legacy VoIP
This would be an alternative for small calls without LiveKit. Currently, it does not seem overly likely that we'll work on this in the near future unless somebody sponsors it.

It's difficult to predict what transports other people might come up with though.

Transports can more easily be removed from the registry than from the main spec
Homeservers declare support for entire spec versions.

I don't buy this. If we add a capability for them then just rip it out and mark it as unsupported via the capability.

@erikjohnston is the main proponent for not putting LiveKit into the spec, so I'd appreciate talking points from him that can be included in this MSC.

clokep · 2026-08-20T12:30:48Z

@mscbot concern Unclear why this needs a registry instead of the normal spec process

dbkr · 2026-08-26T10:01:20Z

+# MSC4519: MatrixRTC Transports Registry
+
+[MSC4143](https://github.com/matrix-org/matrix-spec-proposals/pull/4143) describes the framework for
+Real-Time Communication (RTC) applications to operate over Matrix. The MSC also allows for alternate


Not really 'alternate': it needs a transport to work at all.

…which does somewhat conflict with the registry msc's requirement that only optional functionality be in registries… I suppose it's optional in that you don't have to implement all of them, even if you have to implement one?

"alternate" is in contrast to the specified transport itself, if any. We don't currently have that, so this might be confusing.

dbkr · 2026-08-26T10:18:27Z

+## Security considerations
+
+Individual transports are expected to have their own security considerations. The presence of a
+registry does not carry inherent security challenges, per MSC4518.


I would argue that they very much do since they offer a way for protocol to become spec with little or no review.

The review requirements are the same as any other MSC, so I'm not sure that holds true. It's also not a Security Consideration, but would rather be a Potential Issue.

If a transport is added to the registry as soon as an MSC is created for it, doesn't that mean it's fair game to start using it as soon as you've created an MSC, regardless of whether anyone has looked at the MSC?

dbkr · 2026-08-26T10:21:55Z

+* Stability (`stable` or `unstable`).
+* A link to the specification for that transport, per MSC4143.
+
+`stable` transports are added/changed/removed through normal MSCs. `unstable` transports are automatically


I have to admit I'm somewhat struggling with what the MSC really achieves since clients could implement an open MSC today, so this feels like just a way to bypass the review process, but then isn't that process there for a reason?

With the idea that registries exist outside of the spec, we need to define the process by which the registry is updated/used. This includes defining how unstable types are reflected in the proposed endpoint and how experimental implementations are worked on. Without automatic registration, we'd need 2 MSCs before implementations could start using a new transport: one to define the transport (already required) and another to add that to the registry.

Well my point is that if there was no registry, you could just create the MSC and then start using it unstable-prefixed as we do now?

turt2live · 2026-08-26T17:42:04Z

For documentation: #4518 is no longer part of Matrix 2.0, but this MSC remains in scope (currently). Dependencies on MSC4518 will be removed in a later editorial pass, pending the outcome of further conversations around registries as a concept.

Johennes · 2026-08-31T11:40:32Z

+// GET /_matrix/client/v1/rtc/transports
+// 200 OK
+{
+  "rtc_transports": [


We should rename this to just transports for parity with the m.rtc.member events from #4143.

turt2live · 2026-09-01T18:32:38Z

This MSC is being removed from the Matrix 2.0 scope, so is being removed from FCP too.

@Johennes - the /transports endpoint will need to be returned to the original MSC it came from. This MSC can be left to bitrot.

@mscbot fcp cancel

See this post in the SCT Office for more information.

MSC4519: MatrixRTC Transports Registry

ad4ae90

turt2live added this to Spec Core Team Workflow Jul 28, 2026

github-project-automation Bot moved this to Tracking for review in Spec Core Team Workflow Jul 28, 2026

turt2live moved this from Tracking for review to Ready for general review in Spec Core Team Workflow Jul 28, 2026

turt2live marked this pull request as ready for review July 28, 2026 06:08

turt2live commented Jul 28, 2026

View reviewed changes

Add an exception for MSC4195

db488fa

turt2live mentioned this pull request Jul 28, 2026

MSC4518: Registries #4518

Open

turt2live added the A-VOIP Any VoIP or MatrixRTC related proposals label Jul 28, 2026

turt2live mentioned this pull request Jul 28, 2026

MSC4515: RTC Transports discovery for widgets #4515

Open

robintown reviewed Jul 30, 2026

View reviewed changes

This was referenced Jul 30, 2026

MSC4143: MatrixRTC – Real-time communication over Matrix #4143

Open

Move transport types out of MSC4143 and into MSC4519 #4520

Merged

mscbot added proposed-final-comment-period Currently awaiting signoff of a majority of team members in order to enter the FCP. Process state. disposition-merge Process state. unresolved-concerns This proposal has at least one outstanding concern. Process state. labels Aug 3, 2026

turt2live moved this from Ready for general review to Ready for FCP ticks in Spec Core Team Workflow Aug 3, 2026

turt2live added 00-weekly-pings Tracking for weekly pings in the SCT office. 00 to make it first in the labels list. and removed needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. labels Aug 3, 2026

richvdh reviewed Aug 4, 2026

View reviewed changes

timedoutuk reviewed Aug 8, 2026

View reviewed changes

Comment thread proposals/4519-rtc-transports-registry.md

Comment thread proposals/4519-rtc-transports-registry.md

Comment thread proposals/4519-rtc-transports-registry.md

turt2live added 3 commits August 10, 2026 18:48

Clarify stability and namespacing

df0c115

Clarify why authenticated

f0f4bf7

Clarify "none available" behaviour

34f78fb

Johennes reviewed Aug 19, 2026

View reviewed changes

Comment thread proposals/4519-rtc-transports-registry.md

Johennes mentioned this pull request Aug 19, 2026

MSC4195: LiveKit transport for MatrixRTC #4195

Open

clokep reviewed Aug 19, 2026

View reviewed changes

dbkr reviewed Aug 26, 2026

View reviewed changes

Comment thread proposals/4519-rtc-transports-registry.md

dbkr reviewed Aug 26, 2026

View reviewed changes

Johennes reviewed Aug 31, 2026

View reviewed changes

mscbot added proposal-in-review Process state. and removed proposed-final-comment-period Currently awaiting signoff of a majority of team members in order to enter the FCP. Process state. disposition-merge Process state. labels Sep 1, 2026

turt2live removed matrix-2.0 Required for Matrix 2.0 (note: do not rename - used in reports/links) 00-weekly-pings Tracking for weekly pings in the SCT office. 00 to make it first in the labels list. labels Sep 1, 2026

turt2live removed this from Spec Core Team Workflow Sep 1, 2026


		A new "MatrixRTC Transports" registry is created with the following information:

		* A transport `type`. MUST be an [Opaque Identifier](https://spec.matrix.org/v1.19/appendices/#opaque-identifiers).

		* The author opens a spec PR to register the `msc4195.livekit` unstable type, using the MSC URL as
		the specification reference (specifically the "Unstable Prefix" section/components).

		Note: If the MSC is detailed enough, a link to the rendered Markdown in the spec proposals repo
		is probably suitable too.

		The primary motivation for a registry is to allow transports such as [MSC4195](https://github.com/matrix-org/matrix-spec-proposals/pull/4195)
		to land with relative stability, but without placing a dependency on LiveKit into the core spec.

Uh oh!

Conversation

turt2live commented Jul 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

turt2live Jul 28, 2026 • edited by Johennes Loading Uh oh! There was an error while loading. Please reload this page.

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!

turt2live commented Aug 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

turt2live commented Aug 3, 2026

Uh oh!

mscbot commented Aug 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Johennes Aug 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

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!

Uh oh!

clokep left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Johennes Aug 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

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!

clokep commented Aug 20, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

turt2live commented Jul 28, 2026 •

edited

Loading

turt2live Jul 28, 2026 •

edited by Johennes

Loading

turt2live commented Aug 3, 2026 •

edited

Loading

mscbot commented Aug 3, 2026 •

edited

Loading

Johennes Aug 19, 2026 •

edited

Loading

Johennes Aug 20, 2026 •

edited

Loading