-
Notifications
You must be signed in to change notification settings - Fork 380
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
MSC2312: Matrix URI scheme proposal #2312
Conversation
A remake of MSC455.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Action plan:
The following steps are required to bootstrap the ecosystem once the proposal has been accepted:
- Declare the
matrix:
protocol to the IANA as per BCP35. Thematrix:
scheme is now registered as provisional in the schemes list - Add
matrix:
to the safelisted schemes list to allow websites registering themselves as protocol handlers. PR- Make sure Chromium safelists it: bug, feature status
- Make sure Firefox does so too: bug, patch
SafariDoes not support custom handlers
- matrix.to improvements:
- add a parser for
matrix:
urls - add a
matrix:
scheme generator - Add matrix.to as a default handler for
matrix:
URLs- Mozilla Firefox
- Chromium
- Various desktop environments
- Open issues for proprietary browsers
- add a parser for
- Update various clients to handle the new scheme
- libQuotient-based Clients (MR): Quaternion, NeoChat
- Fluffychat
- Nheko
- gomuks (contains info on how to register the protocol on Linux)
- Element for Nextcloud (contains info about web browsers protocol whitelist)
- Element
Original comment:
This looks like a solid MSC to me, with good self-consistency. I am still not sold on the type specifier, though maybe the way to go is to have a first version out and iterate on it (with all the complexity due to backwards compatibility).
I would put a lot more real-life examples in the spec, as advised in the RFCs. Has this been trough a lot of verification, or does it need further analysis (like fuzzing) to check that no ambiguous situation might arise?
I would like to see someone from the IETF review this MSC once it is approved on the Matrix side, before accepting this, as they are likely to have a lot more experience on that topic.
Here are my previous notes on the subject (sigil-based)
The most relevant stuff from those notes is probably the action plan I wrote above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like "smart quotes" have been used throughout this doc (except in one or two places), even in the BNF. Is that intentional?
Co-Authored-By: David Vo <[email protected]>
Not exactly, it's just a result of copy-pasting from the older Google doc. If that causes problems, I can revert to ASCII quotes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
overall seems to be well on the right track.
I'm just passing by, but I wonder if anyone has put any thought into the use of English terms in the URI? Does it matter? |
@nogweii: yes they have: search for "English" in the earlier comments. |
TODO: Check if this is a good idea, Matrix URIs aren't even standardized yet: matrix-org/matrix-spec-proposals#2312 Might be best to drop the icons and show this information textually.
- Authority part semantics are no more prescribed; authority part has defined syntax but reserved for future use. - Moved away non-normative parts to "Discussion" and/or "Alternatives" - Added `action=chat` - Extended `via=` applicability to non-roomid cases to compensate dropping the authority part semantics. - Added a reference algorithm to parse a URI. - Closed outstanding questions/discussion points. - Added more cases for future evolution. - Added "minimal syntax" options to the discussion of possible alternatives
The proposal is out of WIP - all feedback is welcome. There's also a working implementation of the URI / Matrix identifier encapsulation at quotient-im/libQuotient#407 (nevermind the failing Travis CI); most relevant parts are in |
MainWindow now derives from UriResolverBase, and former openResource(), obtainIdentifier() and joinRoom() are entirely reimplemented as openResource() and openUserInput() using this framework - streamlining the overall "opening" logic along the way. In support of matrix-org/matrix-spec-proposals#2312
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this update. I have highlighted a couple of nitpicks and questions, though not all are really important.
I would include an appendix with a bunch of examples for client authors to check their parsers against without them having to hunt them in the MSC body.
A few other questions:
- are clients "allowed" to extend action with client-specific action classes?
- Is
mxc:
completely out of scope for this proposal? On the other hand, the current mxc architecture could use a few overhauls: content-based addressing, for starters.
Responding to points not mentioned inline with the proposal:
That's a good point. Probably it makes sense to have an extension point here, although I'd really hate to prepend the current actions with
Yes, it is completely out of scope here. Basically, it's good enough to be working here and now, and it's used in contexts entirely orthogonal to those of |
The matrix scheme has recently been finalized and is documented at [1]. Matrix is an open and secure communication protocol, designed for an open federation of servers, much like e-mail or xmpp. The Matrix.org foundation [2] is the custodian of the matrix specification, including the scheme linked above. As a neutral party, it will ensure that future iteration of the matrix scheme will remain in line with its stated goals. The federated (possibly later distributed) nature of the Matrix network calls for an URI scheme, which multiple software programs already implement (namely, Matrix clients Fluffychat, Quaternion, and Nheko among others). Multiple web clients (Element, Hydrogen, Fluffychat again) have expressed their interest in registering as matrix protocol handlers. This commits adds the provisional matrix scheme, as provisionally registered at [3]. The Matrix network currently hosts a few million accounts[4], as well as being the instant communication platform of choice for the KDE and Mozilla communities. [1]: matrix-org/matrix-spec-proposals#2312 [2]: https://matrix.org/foundation/ [3]: https://www.iana.org/assignments/uri-schemes/prov/matrix [4]: https://matrix.org/faq/#what-is-the-current-project-status
MSC2312: Matrix URI scheme proposal
MSC2312: Matrix URI scheme proposal
New spec PR: #3608 |
Merged 🎉 |
When a user clicks on a chat room link, we reply with a redirect to the user's web client. Somewhen around matrix-synapse v1.50 the path `/_matrix/client` stopped returning a redirect to the site-local web client. Thus we maintain a manual list of Matrix web clients until either MSC2312 [1] is supported or a suitable redirect is published again (see [2]). See #793 [1] matrix-org/matrix-spec-proposals#2312 [2] matrix-org/synapse#14722
This is a remake of #455 - now in Markdown, and greatly extended.
Rendered
Implementation
Matrix room for interim discussions - to keep lower traffic in the pull request, please discuss in the Matrix room if you just need a clarification or would like to discuss a possible change before proposing. If you have what you see as specific feedback, please comment on the specific line in the proposal rather than leave a comment to the whole PR.