117 lines
3.8 KiB
Plaintext
117 lines
3.8 KiB
Plaintext
---
|
|
summary: Do we want to specify a matrix:// URI scheme for rooms?
|
|
---
|
|
created: 2014-09-16 00:37:12.0
|
|
creator: matthew
|
|
description: ''
|
|
id: '10039'
|
|
key: SPEC-5
|
|
number: '5'
|
|
priority: '3'
|
|
project: '10001'
|
|
reporter: matthew
|
|
status: '1'
|
|
type: '2'
|
|
updated: 2016-10-28 16:26:39.0
|
|
votes: '0'
|
|
watches: '4'
|
|
workflowId: '10325'
|
|
---
|
|
actions:
|
|
- author: kegan
|
|
body: 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.
|
|
created: 2014-09-16 09:35:07.0
|
|
id: '10108'
|
|
issue: '10039'
|
|
type: comment
|
|
updateauthor: kegan
|
|
updated: 2014-09-16 09:35:07.0
|
|
- author: markjh
|
|
body: '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: {code}mailto:foo@bar{code}'
|
|
created: 2014-09-16 11:15:47.0
|
|
id: '10201'
|
|
issue: '10039'
|
|
type: comment
|
|
updateauthor: markjh
|
|
updated: 2014-09-16 11:16:57.0
|
|
- author: markjh
|
|
body: |-
|
|
{code}
|
|
matrix:@bob:example.org
|
|
{code}
|
|
|
|
Is a URI with a scheme of "matrix" and a path of "@bob.example.org"
|
|
|
|
{code}
|
|
matrix:#room:example.org
|
|
{code}
|
|
|
|
Is a URI with a scheme of "matrix" and a fragment of "room:example.org".
|
|
created: 2014-09-16 11:21:21.0
|
|
id: '10202'
|
|
issue: '10039'
|
|
type: comment
|
|
updateauthor: markjh
|
|
updated: 2014-09-16 11:21:21.0
|
|
- author: matthew
|
|
body: |-
|
|
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:
|
|
{code}
|
|
foo://example.com:8042/over/there?name=ferret#nose
|
|
\_/ \______________/\_________/ \_________/ \__/
|
|
| | | | |
|
|
scheme authority path query fragment
|
|
| _____________________|__
|
|
/ \ / \
|
|
urn:example:animal:ferret:nose
|
|
{code}
|
|
|
|
...which i think sadly may limit us to matrix://matrix.org/#matrix and matrix://matrix.org/@matthew - as sad as that is :/
|
|
created: 2014-09-16 11:26:09.0
|
|
id: '10203'
|
|
issue: '10039'
|
|
type: comment
|
|
updateauthor: matthew
|
|
updated: 2014-09-16 11:26:09.0
|
|
- author: markjh
|
|
body: They *should* be hierachical. However "mailto:" and "sip:" URIs are obvious counter examples.
|
|
created: 2014-09-16 16:01:44.0
|
|
id: '10301'
|
|
issue: '10039'
|
|
type: comment
|
|
updateauthor: markjh
|
|
updated: 2014-09-16 16:01:44.0
|
|
- author: matthew
|
|
body: |-
|
|
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.
|
|
created: 2015-01-18 21:33:02.0
|
|
id: '11147'
|
|
issue: '10039'
|
|
type: comment
|
|
updateauthor: matthew
|
|
updated: 2015-01-18 21:33:02.0
|
|
- author: matthew
|
|
body: 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
|
|
created: 2015-09-22 18:32:36.0
|
|
id: '12149'
|
|
issue: '10039'
|
|
type: comment
|
|
updateauthor: matthew
|
|
updated: 2015-09-22 18:32:36.0
|
|
- author: richvdh
|
|
body: 'Migrated to github: https://github.com/matrix-org/matrix-doc/issues/455'
|
|
created: 2016-10-28 16:26:39.0
|
|
id: '13228'
|
|
issue: '10039'
|
|
type: comment
|
|
updateauthor: richvdh
|
|
updated: 2016-10-28 16:26:39.0
|