MSC4481: Non-sigil matrix.to

[HarHarLinks]

Rendered

I am at the time of writing employed by Nordeck, Matrix community member, and Member of The Matrix.org Foundation Governing Board. This proposal is written and published with my role as a community member at Matrix Community Summit 2026.

Implementations:

• Implement MSC4481 matrix.to#410

[turt2live]

Implementation requirements:

• Client (parsing)

[HarHarLinks]

please clarify if matrix-org/matrix.to#410 is sufficient as a parsing implementation :)

[turt2live]

I was expecting a fuller Matrix client doing the parsing.

[turt2live]

There's a good chance that a client encountering one of this proposal's new URIs will break too. Testing will be necessary, especially to ensure backwards compatibility.

[tulir]

IMO we shouldn't have this syntax hit clients at all, except maybe when a user manually sends a link as plain text.

This would be a good time to deprecate using matrix.to links and forbid this new syntax entirely in user and room mentions

[HarHarLinks]

• Element Desktop Nightly version: 2026053001: opens the link in a browser, does not pillify it
• Nheko 0.12.1-90ff9c6f: opens the link in a browser, generally no pill support
• fractal 13: opens the link in a browser, does not pillify it
• SchildiNext 0.11.2-test3 (based on Element X 26.05.1): opens the link in a browser, does not pillify it
• Element X 26.05.1: opens the link in a browser, does not pillify it
• Fluffychat 2.6.0: fails to handle the link
• Cinny v4.12.2: opens the link in a browser, does not pillify it
• Polycule $current: opens the link in a browser, does not pillify it
• Tammy 2.0.6: opens the link in a browser, does not pillify it

This would be a good time to deprecate using matrix.to links and forbid this new syntax entirely in user and room mentions

Yup it would be great if clients preferred the more native matrix: or even simply the plain IDs internally. However I think this belongs in a separate MSC: MSC4487.