Open MayeulC opened 3 years ago
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.
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)/
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.
After parsing the percent-encoded url, we can also rewrite the hash to our canonical url format (see https://github.com/matrix-org/matrix.to/issues/205 as well)
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.
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:
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.https://matrix.to/#/url/<encoded MSC2312 URI>
matrix.to
offers a choice of native and web clients to open the link.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.
MSC2312: Matrix URI scheme proposal https://github.com/matrix-org/matrix-doc/pull/2312 is nearing completion.
As such, we can expect apps to progressively switch from
https://matrix.to
links to thematrix:
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:matrix.to
to receivematrix
URIs, it could be something likehttps://matrix.to/#/url/%s
(percent-encoded of course)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:![image](https://user-images.githubusercontent.com/3952726/115261703-23725980-a134-11eb-904e-895d46500a36.png)