Sharing links to Matrix users or rooms or messages is broken. The “matrix.to” service currently does not “cut it” for federated use.
A standard matrix: URI scheme is proposed as a superior solution, but that is far from ready and we need a usable interim solution.
Where are we with having links like https://matrix.to/#/@nukeador:mozilla.org to suggest chat.mozilla.org? …
Rubén Martín (nukeador)
To make this interim matrix.to
service work satisfactorily with a federated matrix network, while it lives at a centralized URL, we need to make it support decentralized use cases as far as possible.
Current problems
Problems, in terms of design issues:
- users can’t customize it
- e.g. hide unwanted options, add custom options, set a default
- federated server admins can’t customize it
- e.g. completely replace it, or customizations as for user
- always points to riot.im
- should point to user’s or federated server’s preferred Riot-like web client
- can’t click through to any other client the user has installed
- where client registered a URI scheme handler on the device
- doesn’t remember the user’s choice and get out of their way
- it could redirect automatically on future visits
- the UI is not simple, clean, helpful
- compare with Telegram’s
http://t.me/<channel>
for example
- compare with Telegram’s
- doesn’t offer the proposed standard matrix: URI scheme
- should offer
matrix:
scheme links, initially as an advanced option, for those who are starting to test or use them
- should offer
Many of these issues can be improved by changes to the central “matrix.to” web site.
I propose the following changes to the matrix.to
service:
- Allow adding custom Riot URL(s)
- Remember my preference and go straight there next time (in this browser)
- Redirect to another matrix.to service
- Simplify the UX
- Show preview/info of room/user
- Output the proposed “matrix:” URI scheme
Together, these might address the most pressing of the usability issues.
(The last item, adding “matrix:” URIs, is important in a different way. Rather than solving an immediate user need, it promotes development of the matrix ecosystem towards replacing this interim system with a better one.)
One issue remains. The fact that federated server admins can’t customize the experience is hard to avoid. Some options are:
- The page could let the user redirect to their preferred “matrix.to” replacement page, and remember the preference. That works for power users on a repeat visit, not for casual or first-time users. Better than nothing so I’m starting here.
- The page could perform a client-local search for config settings, that’s wider scope than browser-local; some kind of Zero-configuration networking, perhaps; I haven’t looked into it.
- An admin could set local DNS (within an organization’s internal network, or a home user’s router) to point the DNS name “matrix.to” to a local page. Only useful for users sitting on such a network; may be useful in offices etc.
Mock-ups
I am trying out these ideas. I will make source code and a demo available when I get around to it. I will update this post below, as and when I do so. I will listen to your feedback (in the Matrix room #matrix.to:matrix.org
please, rather than blog comments) and incorporate your suggestions where they make sense to me.
Some early draft mock-ups:
Please join myself and others discussing this in the Matrix room #matrix.to:matrix.org
.