Do we want to specify a matrix:// URI scheme for rooms? (SPEC-5)
matrixbot opened this issue · 17 comments
Documentation: https://docs.google.com/document/d/18A3ZRgGR-GLlPXF_VIHxywWiX1vpMvNfAU6JCnNMVuQ/edit
Author: @KitsuneRal
(Imported from https://matrix.org/jira/browse/SPEC-5)
(Reported by @ara4n)
Jira watchers: @kegsay @NegativeMjark @ara4n
Wasn't the whole point to represent rooms as room aliases? If this isn't representing a room alias, why use URI schemes for just that and not room IDs as well? This would make designing parsers easier since there are URI parsers out there, which is better than yet-another-custom-id-scheme.
-- @kegsay
A "matrix:" URI scheme might be nice for providing clickable links. We might not want to use URIs as human readable/writeable ids though. In the same way that email addresses aren't typically written as:mailto:foo@​bar
matrix:@​bob:example.org
Is a URI with a scheme of "matrix" and a path of "@bob.example.org"
matrix:#room:example.org
Is a URI with a scheme of "matrix" and a fragment of "room:example.org".
My reason for proposing a URI scheme is so that things which implement URI handlers (e.g. web browsers, operating systems, etc) can click through into your favourite matrix client.
It's worth noting that according to timbl in rfc3986, URIs are meant to be hierarchical:
The following are two example URIs and their component parts:
foo://example.com:8042/over/there?name=ferret#nose
\_/ \______________/\_________/ \_________/ \__/
| | | | |
scheme authority path query fragment
| _____________________|__
/ \ / \
urn:example:animal:ferret:nose
...which i think sadly may limit us to matrix://matrix.org/#matrix and matrix://matrix.org/@matthew - as sad as that is :/
-- @ara4n
They should be hierachical. However "mailto:" and "sip:" URIs are obvious counter examples.
Having been thinking about this some more in the context of 3PIDs and AS API, I reckon we should go with:
mx://server/entity where entity is @user or #alias or !room.
This is also useful given that we're expressing 3PIDs everywhere as URIs, so also having matrix URIs around for symmetry is a Good Thing.
-- @ara4n
matrix.to isn't a good enough solution, as desktop systems and web applications can't register URL handlers for a specific domain, only a specific URL scheme.
Matrix therefore needs a protocol handler (i.e. matrix://), and for matrix.to to use e.g. this to attempt to open that protocol. Matrix clients should then register this handler, though generated permalinks should still link to matrix.to, as that would allow non-Matrix-users to see a useful suggestion on how to get Matrix (i.e. the current matrix.to page).
At now in most OS and browsers we can implement and register any custom protocol, that opens specific app, here is some examples: http://kb.mozillazine.org/Register_protocol
So there are not too hard to manually register mx:// or matrix:// protocol in local system and configure browser to auto-open specific desktop app (Riot for example) on click for all urls with this protocol.
Lets select and fix one recommended variation of Matrix protocol prefix in Matrix docs and provide link to it in matrix.to website, with short description how to configure it manually on local system.
This will be good start for officially registering Matrix protocol prefix by default in browsers / OS. And next small step will be provide browser extensions with implementation of this protocol.
Lets start to vote for select one recommended Matrix protocol prefix here via reactions on comments?
mx:
matrix:
If you want a protocol handler (such as "mx:" but more probably and more descriptively "matrix:") and want a choice of clients, why do you require an "authority" part (i.e. "//server") ? Note that we don't need that for old NNTP newsgroups, where only the group name is needed.
And not only we would be able to open the choice of clients (including IRC ones) but also the server (by using only URNs via resolvers that would find relevant servers and where users could select their prefered server, or would be offered a choice of servers like for NNTP, or emails)
So the only relevant thing would be the channel name (or "#hashtag"), possibly with a hierarchical suffix (such as ":matrix.org").
This would be then only "matrix:#info" and the indication of an autority would be optional to select only the resolver service that will perform the connection or will offer a choice of servers (matrix://server.domain.name:8080#info).
To be really complete, when a resolver retuns a list of servers, instead of conneting to it, the return value should have another format indicating a list of instances to choose from, possibly with an order of preferences according to the server, and some additional description/recommendations (using basic HTML5 in its "safe" unscripted profile and not needing any html root tag, i.e. an HTML fragment only)
How to format this list? possibly as a JSON array, or a JSON object containing some properties and the same array in one of these properties. The array would contain one item by server found to host the channel ("#info" may then map to a query string "?q=info" or path "/info" or a subdomain, and there could be several protocols such as "http:", "https:", "irc:", "nntp:", "mailto:") each one being a simple object with "url", "name" (limited to only a small inline HTML encoded as UTF-8 only), and an optional description" property (can be one or several blocks of HTML, but no scripts, and possibly with links or images hosted on the same base URL as the given URL or at least in the same domain; note that some image/video formats may embed internal links and may be dangerous to render).
So "matrix:#info" would be resolved first by the client using its prefered list of URN resolvers, and could return:
{/"some optional properties":"here",/
"instances":[
{"url": "https://matrix.org/#/#info", "name": "#info", "description": "on Matrix.org"},
{"url": "https://twitter.com/matrixinfo", "name": "@matrixinfo", "description": "on Twitter"},
{"url": "irc://irc.net/matrix.info", "name": "#matrixinfo", "description": "on IRC.net"},
{"url": "news:info.matrix.org", "name": "info.matrix.org", "description": "newsgroup"},
/* and so on... */
]}
We could also perform a search by full display name instead of the "#"hashtag:
"matrix:Display name"
The Display name has a default leading path equal to "/", it also does not specify the resolver to use (this is an URN, not an URL). The client selects the resolvers it wants. But if a specific resolver is needed you can also use:
"matrix://matrix.to/Display name"
All resolvers are supposed to support HTTP. For using HTTPS, the alternate protocol "matrixs:" can be used.
A local-only resolver (on the client host) may also be used:
"matrix://.:8911/Display name"
or
"matrix://.:8911/#hashtag"
or
"matrix://.:8911/@user:domain.org"
or even (but note this is not an email address)
"matrix://.:8911/user@domain.org"
Without the specific resolver specified, these are just:
"matrix:Display name"
or
"matrix:#hashtag"
or
"matrix:@user:domain.org"
or even (but note this is not an email address)
"matrix:user@domain.org"
On a specific resolver that has its local own user accounts with their prefered services;
"matrix:@user"
should also work just like this one on the local host only
"matrix://.:8911/@user
or on the "http[s]://matrix.to" instance:
"matrix://matrix.to/@user
Ideally the resolvers should have a default prefered port number, the same as for HTTP or HTTPS, so for "matrix:" it would also be port 80, and for "matrixs:" it should be also 443.
Such a resolver could be "http://matrix.to/" (on port 80) as it is now. But it could also be "https://matrix.to/" (on port 443). All is left open for the resolver to be accessed on IPv4 or IPv6 (it is left to the domain name registration using standard DNS queries), unless you use an IPv4 or IPv6 address in the resolver address, where no DNS request will be needed to perform a matrix URN resolution:
"matrix://127.0.0.1:8911/Display name"
"matrix://[[::1]]:8911/Display name"
In my opinion, HTTPS should be expected by default when opening the resolver, and could fallback to HTTP after alerting the client that his query will not be secure (I support the "HTTPS Everywhere" initiative).
To allow the server hosting the resolver to distinguish URN resolution queries in JSON format from web accesses returning an HTML page, the resolver would use a distinctive "Accept": MIME header in the HTTP GET request to specify that it prefers this JSON-formatted list instead of the default HTML web page.
People interested in this issue may also be interested in the matrix room: #uri-scheme-proposal:matrix.org