Implementation requirements:

• Product teams from clients supporting this behaviour

What does this have to do with product teams? 🤔 It's an entirely internal technical detail that shouldn't be visible to users at all

I don't think this needs any implementation, since the spec already allows using matrix URIs, there are already multiple clients that correctly handle matrix: URIs in <a> tags, and this is just a deprecation rather than a removal.

While I get where "Product teams" comes from I just wanted to mention that this feels a bit weird as a term considering a lot of clients are not done by companies in matrix ecosystem. So lots of them don't have such a team. This term feels almost a bit out of touch with the reality of matrix ecosystem. Sorry for being nitpicky. This isn't meant to be rude. I just wanted to mention this for next time maybe.

Indeed, the MSC is deliberately very conservative in that regard.

What does this have to do with product teams? 🤔 It's an entirely internal technical detail that shouldn't be visible to users at all

Clients expose matrix.to in several places to users and this proposal requires that those clients don't do that. Why those clients haven't already made the switch is essentially the product decision to be made here.

The implementation requirements for a deprecation is typically evidence that it's safe to queue for removal. Because clients still actively use matrix.to by choice, we cannot queue this for removal.

If the proposal's purpose is to discourage use without targeting removal then it should not be using deprecation.

Clients expose matrix.to in several places to users and this proposal requires that those clients don't do that.

No. The proposal says

unless breaking user intent, i.e. manually pasted links would not convert while tab-completed IDs would.

Features such as "share room by link" or a generic "right click to copy link" remain unchanged

It should probably be reworded to be even more explicit that only non-user-visible features are changing, maybe even explicitly say only user and room @mentions aka pills are covered (are there any other cases of matrix.to links than pills and share links?)

We'd then need implementations of all of that to show it's feasible to rewrite matrix: URIs to matrix.to URLs.

• Client (modern desktop)
• Client (modern browser)
• Client (iOS)
• Client (Android)

Was confused by why clients would need to rewrite matrix: URIs to matrix.to URLs, but apparently it's because at least Element X decided that pills need a "copy link" context menu option. It's technically an existing spec compliance issue (the spec already allows using matrix: for pills), but it's fair to consider those before having the spec recommend actively switching to matrix: URIs over matrix.to URLs, as such a recommendation will cause clients to hit the spec compliance issues a lot more.

It's probably also better to start with having the spec just recommend matrix: URIs ("Clients SHOULD use matrix: URIs when sending user and room mentions") before a formal deprecation of matrix.to in pills.

From a client developer perspective (so-called product team 😂), I can confirm : Every major client supports the Matrix URI scheme. With the acceptance of matrix: as standardized scheme, even web-clients can register to handle incoming Matrix URLs simple as by including it into the web app manifest.

Matrix URIs are easier to handle since they tend to be less buggy. E.g., many Matrix clients as well as users manually writing links tend to fail at the URI component encoding of the sigils that's required according to the matrix.to scheme. With standardized Matrix URIs this issue is solved.

Imho, the following should be the way to go :

• Clients MUST NOT try to handle incoming matrix.to links
• Clients SHOULD for a transition period internally convert matrix.to links to Matrix URLs
• Clients MUST NOT send any matrix.to links via Matrix
• Clients SHOULD offer an option to share a matrix.to link to 3rd party applications (e.g. by email, share intent etc.)
• Matrix.to MUST convert incorrectly encoded sigils on the fly to show the correct matrix.to URL in the User Agent address bar
• Matrix.to MUST by default fallback on opening the User Agent's preferred client using a Matrix URL

pills need a "copy link" context menu option

Sure, per the MSC that is reasonable and even implied as intended.

However, I can't help but feel like asking for POC implementations on no less than 4 platforms is chicanery for something that is obviously™️ a trivial find-replace. Why would this be necessary? I would even argue it's so trivial that it doesn't need an implementation.

Anyway, here's an implementation in bash:

#!/usr/bin/env bash

function convert {
	id="$1"
	if [[ "${id:7:7}" == "roomid/" ]]; then
		id="${id//roomid\//!}"
	elif [[ "${id:7:2}" == "r/" ]]; then
		id="${id//r\//%23}"
	elif [[ "${id:7:2}" == "u/" ]]; then
		id="${id//u\//@}"
	fi
	if [[ "$id" == *"/e/"* ]]; then
		id="${id//\/e\///$}"
	fi
	id="${id//matrix:/https://matrix.to/#/}"
	echo "$id"
}

room_alias='matrix:r/somewhere:example.org'
room_v12='matrix:roomid/somewhere?via=elsewhere.ca'
room_v11='matrix:roomid/somewhere:example.org?via=elsewhere.ca'
user='matrix:u/alice:example.org?action=chat'
alias_event='matrix:r/somewhere:example.org/e/event?via=elsewhere.ca'
v12_event='matrix:roomid/somewhere/e/event?via=elsewhere.ca'

convert "$room_alias"
# https://matrix.to/#/%23somewhere:example.org
convert "$room_v12"
# https://matrix.to/#/!somewhere?via=elsewhere.ca
convert "$room_v11"
# https://matrix.to/#/!somewhere:example.org?via=elsewhere.ca
convert "$user"
# https://matrix.to/#/@alice:example.org?action=chat
convert "$alias_event"
# https://matrix.to/#/%23somewhere:example.org/$event?via=elsewhere.ca
convert "$v12_event"
# https://matrix.to/#/!somewhere/$event?via=elsewhere.ca

Note that while the examples in the spec for matrix.to percent-encode ALL special chars, aiui this isn't required by RFC 3986.

matrix URI (room alias) client support:

• Nheko 0.12.1-1f083e25: supports both plain text and html formatted
• Element web 1.12.20: plain text does not pillify and opens matrix.to instead (wtf??? this regressed from 1.11.112), HTML link pillifies and routes internally
• fractal 13: supports both plain text and html formatted with pillification
• SchildiNext 0.11.3-test3 (based on Element X 26.05.2) with message renderer rewrite enabled: plain text does not pillify nor linkify properly, HTML link does not pillify but offers to "open with" any installed Matrix client that registered the scheme, including itself
• Element X Android 26.05.2: plain text does not pillify nor linkify properly, HTML link pillifies
• Fluffychat 2.6.0: ?
• Cinny v4.12.2: neither are supported
• Polycule $current: ?
• Tammy 2.0.6: supports both plain text and html formatted with pillification

FWIW SchildiChat Revenge recently got matrix URI (plaintext) linkification and deeplinking support (to be released soon), just need to bump the message formatting library on Next to get linkification and in-app navigation on that as well

Element X 26.05.2: plain text does not pillify nor linkify properly, HTML link pillifies

There might be a discrepancy between iOS and Android here - plain-text URIs will link & pillify as expected on iOS.

Thanks, I clarified Android above!