New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do we want to specify a matrix:// URI scheme for rooms? (SPEC-5) #455

Open
matrixbot opened this Issue Sep 15, 2014 · 16 comments

Comments

Projects
None yet
10 participants
@matrixbot
Copy link
Member

matrixbot commented Sep 15, 2014

@matrixbot

This comment has been minimized.

Copy link
Member Author

matrixbot commented Sep 15, 2014

Jira watchers: @Kegsay @NegativeMjark @ara4n

@matrixbot

This comment has been minimized.

Copy link
Member Author

matrixbot commented Sep 15, 2014

Links exported from Jira:

relates to ORG-26

@matrixbot

This comment has been minimized.

Copy link
Member Author

matrixbot commented Sep 16, 2014

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

@matrixbot

This comment has been minimized.

Copy link
Member Author

matrixbot commented Sep 16, 2014

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

-- @NegativeMjark

@matrixbot

This comment has been minimized.

Copy link
Member Author

matrixbot commented Sep 16, 2014

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".

-- @NegativeMjark

@matrixbot

This comment has been minimized.

Copy link
Member Author

matrixbot commented Sep 16, 2014

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

@matrixbot

This comment has been minimized.

Copy link
Member Author

matrixbot commented Sep 16, 2014

They should be hierachical. However "mailto:" and "sip:" URIs are obvious counter examples.

-- @NegativeMjark

@matrixbot

This comment has been minimized.

Copy link
Member Author

matrixbot commented Jan 18, 2015

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

@matrixbot

This comment has been minimized.

Copy link
Member Author

matrixbot commented Sep 22, 2015

In practice this isn't good enough as iOS doesn't let multiple apps register for the same scheme. Instead a workaround is as per ORG-26

-- @ara4n

@matrixbot matrixbot changed the title Do we want to specify a matrix:// URI scheme for rooms? Do we want to specify a matrix:// URI scheme for rooms? (SPEC-5) Oct 31, 2016

@matrixbot matrixbot added the feature label Nov 7, 2016

her001 added a commit to her001/steamlug.org that referenced this issue Apr 19, 2017

Add Matrix information to the irc chat page
If/When Matrix has a URI scheme, we can add that and remove the matrix.to link. Status of the URI is tracked in this issue: matrix-org/matrix-doc#455

her001 added a commit to her001/steamlug.org that referenced this issue Apr 20, 2017

Add Matrix information to the irc chat page
If/When Matrix has a URI scheme, we can add that and remove the matrix.to link. Status of the URI is tracked in this issue: matrix-org/matrix-doc#455
@VShell

This comment has been minimized.

Copy link

VShell commented Apr 24, 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).

@MurzNN

This comment has been minimized.

Copy link
Contributor

MurzNN commented Sep 21, 2017

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.

@MurzNN

This comment has been minimized.

Copy link
Contributor

MurzNN commented Sep 21, 2017

Lets start to vote for select one recommended Matrix protocol prefix here via reactions on comments?

@MurzNN

This comment has been minimized.

Copy link
Contributor

MurzNN commented Sep 21, 2017

mx:

@MurzNN

This comment has been minimized.

Copy link
Contributor

MurzNN commented Sep 21, 2017

matrix:

@verdy-p

This comment has been minimized.

Copy link

verdy-p commented Oct 28, 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:
{/"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.

@Matrixcoffee

This comment has been minimized.

Copy link
Contributor

Matrixcoffee commented Dec 19, 2018

People interested in this issue may also be interested in the matrix room: #uri-scheme-proposal:matrix.org

@turt2live turt2live added the T-Core label Dec 24, 2018

@anoadragon453 anoadragon453 removed the T-Core label Jan 4, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment