Difference between revisions of "Matrix"
(Created page with "==Full Title== Matrix[[ was designed as an instant messaging protocol, but is works more like a distributed database. ==Context== This is proposed as an addition to Chromium...")
Revision as of 10:22, 19 May 2021
[[Matrix[[ was designed as an instant messaging protocol, but is works more like a distributed database.
This is proposed as an addition to Chromium which generated this thread:
The Gecko signal should be: Shipped/Shipping. +1. I am also intent on updating the MDN docs, as was suggested to me. > But we weren't sure where the request was ultimately coming from I am the requester, but just a contributor to the open source Matrix ecosystem in my spare time. The requester should probably be the Matrix foundation, I am doing this with tacit approval of the other contributors: https://matrix.org/blog/category/this-week-in-matrix#closing-words > A short (maybe even inline :D) explainer outlining what > this new scheme is and what it does would be helpful > here when evaluating if this is something we want to add > to the platform. > It sounds kind of abstract to me, so maybe i should ask for another TLDR As the original reporter and the whatwg PR author, I would have been happy to give you a bit more context. I did try to do so in the whatwg PR, but the curse of knowledge made me feel this was unnecessary on the chromium bugtracker. So, in a few words: Matrix was designed as an instant messaging protocol. Like xmpp or e-mail, it is built on a federation of servers. It is actually closer to a distributed database, or a CRDT conceptually. Here's how it works: A user from a server sends a message to a "room" on their server, and other servers that participate in that room will receive the message. Matrix builds on this, and specifies how to merge diverging histories, as well as access control. More info is available on https://matrix.org/ Here's why this scheme is needed: Users need to refer to given rooms, messages, or other users, in a client-agnostic way. Given that multiple clients exist, I would like to share a link to a message that the recipient can open in their own client, that's what URIs are designed for. About registerProtocolHandler: Multiple clients are actually web apps, and would need to register as protocol handlers to be able to open links to a given user, chatroom or message. Examples of such clients are https://app.element.io/ (formerly Riot), https://hydrogen.element.io/ (experimental) and https://fluffychat.im/web/ What was done until now: A linking service, matrix.to, could redirect users to various clients, like so: https://matrix.to/#/!pJwzQQUCraoWtdHmYE:matrix.org/$16214172765dJDbp:mayeul.net?via=matrix.org&via=neko.dev&via=mayeul.net While the solution isn't perfect, especially as it requires a round-trip trough the web browser, it also provides a nicer first-time user experience if a user doesn't have a Matrix client installed, and doesn't know what Matrix is. That's actually the reason I asked if chromium could have some default handlers: https://bugs.chromium.org/p/chromium/issues/detail?id=1169258#c5 Falling back to matrix.to when a user opens a matrix: URI and doesn't have a client installed would allow to make a broader use of the scheme. If that's not implemented, it is unlikely that users will ressort to using the new scheme, and clients will continue generating matrix.to links, as pointed out in https://github.com/matrix-org/matrix.to/issues/191#issuecomment-825671129 Matrix.to is a relatively neutral party, though matrix-specific. I imagine the same issue is playing for most other protocols as well (including ftp with its deprecation), so adding default protocol handlers or a landing website could help first-time users for any of these. Anyway, thank you for moving this forward. May I ask which Chromium version this is expected to land in? Best wishes, Mayeul Cantan