Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Do we want to specify a matrix:// URI scheme for rooms? (SPEC-5) #455
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.
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:
...which i think sadly may limit us to matrix://matrix.org/#matrix and matrix://matrix.org/@matthew - as sad as that is :/
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.
referenced this issue
Nov 15, 2016
added a commit
Apr 19, 2017
added a commit
Apr 20, 2017
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
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.
referenced this issue
Oct 21, 2017
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:
We could also perform a search by full display name instead of the "#"hashtag:
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:
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:
Without the specific resolver specified, these are just:
On a specific resolver that has its local own user accounts with their prefered services;
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:
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.