Support decoding matrix URI scheme

[MayeulC]

MSC2312: Matrix URI scheme proposal matrix-org/matrix-spec-proposals#2312 is nearing completion.

As such, we can expect apps to progressively switch from https://matrix.to links to the matrix: scheme.

Describe the solution you'd like
In order to provide a smooth transition, as well as a fallback when no client is installed, I would like matrix.to to implement support for parsing matrix: URI as input, and work as usual with the decoded information:

• define a way for matrix.to to receive matrix URIs, it could be something like https://matrix.to/#/url/%s (percent-encoded of course)
• Implement parsing for it as specified in MSC2312
• modify web browsers to add matrix.to as a default handler for these links
  • For Firefox the magic happens here with the tests there
  • Unsure if Chromium has something similar
• ask visitors if they want to register matrix.to as a protocol handler for matrix: links (can also ease the transition)

Describe alternatives you've considered
Falling back to Element.io is another possibility that can be examined, I am not sure which one brings the best onboarding experience. Both are not exclusive.
However, Element.io is a lot less neutral, so it would make it a harder sell to browsers, does not educate users as well, and is already quite well emphasized in matrix.to.

Additional Context
Users might want to copy-paste a URL from the address bar? In that case, maybe rewrite them to regular matrix.to format?

---

Firefox includes default handlers, as linked above, and from the following screenshot of a web browser that has never been on yahoo nor gmail:

[MayeulC]

May I humbly ask if you think this could be ready soon?

Ideally I would like browsers to set matrix.to as a default handler at the same time they whitelist the scheme.

[bwindels]

I think supporting a route that will take a percent-encoded matrix: uri makes sense, to support Firefox having a default handler for matrix.to, and to use registerProtocolHandler on matrix.to, both of which use a %s placeholder which will be replaced with the whole URI, including the scheme.

I would suggest https://matrix.to/#/uri/%s, to be in line with MSC 2312 (which calls it uris rather than urls, although they can be both depending on the via params)/

[bwindels]

Given that only Firefox seems to offer adding a default handler for matrix:, I don't think it's realistic for clients (or at least Element) to share matrix: links rather than matrix.to. The whole onboarding would just be too broken. This is also why competing services like telegram and whatsapp have their website like matrix.to. The biggest value of the matrix: scheme for now is IMO that we can skip the client list on matrix.to if you already have a client installed.

[bwindels]

After parsing the percent-encoded url, we can also rewrite the hash to our canonical url format (see #205 as well)

[bwindels]

Thinking more about this, even if all browsers support matrix: for registerProtocolHandler, I wonder if it won't be confusing to have matrix.to show up in the list with options to open a matrix link with if you have a real matrix client installed alongside. It will also be hard to avoid a redirect loop with the automatic matrix: redirect we're implementing to skip client selection if possible. I don't think we can detect whether the page can open matrix: links after having called registerProtocolHandler previously.

Furthermore, the browser prompts the user for permission when calling registerProtocolHandler, and AFAICT you can't tell whether they agreed or not. So actually registering would need a specific UI action from the user to have enough context for the prompt to make sense, so much less likely for people to actually use it. We can assume that power users (people who will understand what Click here to allow matrix: links to open with matrix.to does) will have a matrix: capable client installed anyway, so I don't really see who we'd be adding this option for.

[KitsuneRal]

As I see it, this is to make the first exposure to matrix: links a bit smoother, with the flow being something like the below.

If the user has already defined a matrix: association in its desktop environment (e.g. XDG), the browser is (usually) able to determine that by trying to open it via xdg-open or an equivalent mechanism, before its own registry kicks in (correct me if I'm wrong here). If there's no desktop association defined, the browser does a lookup in its registry. One of two things may happen at this point: if the user already associated a (web or desktop) client with the matrix: scheme, this client is invoked/navigated to; what is suggested in this issue is the behaviour when no association has been made:

0. Pre-reqs: matrix: links are not explicitly associated with any desktop or web-application but a browser (e.g., Firefox, as on the screenshot above) ships its own default (NB: we'll have to work with web-browser developers on that); a user clicked on a matrix: link.
1. The browser rewrites the URL to https://matrix.to/#/url/<encoded MSC2312 URI>
2. matrix.to offers a choice of native and web clients to open the link.
3. The user picks a client; native clients will have to be downloaded and installed; web clients will be navigated to, with the URI being passed according to conventions supported by those clients (ideally - passing the Matrix URI in the web client's URL fragment).

This specifically helps to alleviate the first encounter of matrix: URIs and is supposed to stand out of the way once the association is set up (e.g. by confirming a request from a client application to always open matrix: links). If matrix.to is explicitly opened with a Matrix URI as a parameter, matrix.to doesn't assume or probe the current association - it just suggests the list of clients again.