I’d be very interested to see the Matrix.org team’s list of Big Issues. Here’s mine.
(As someone who runs my own homeserver but otherwise not closely involved with Matrix development. A very sketchy first draft, totally uncomprehensive and unauthoritative.)
Kill off Matrix.org (the server)
The existence of a “central” or “default” server works utterly against the goal of a decentralized system. Some important benefits are obtained from it in the short term, such as building an initial community and real-life testing of the server. However, to ensure the community prioritizes solving the problems of decentralization, there needs to be a goal of killing it off.
Some specific issues:
- identity decoupling
- Matrix spec issues: Decentralised user accounts #915 and others referenced from it.
- I should be able to create an identity that is not tied to a particular homeserver, as that server may not remain suitable for my use, or even survive at all, for as long as I want my identity. The most obvious alternative would be to have my identity tied to a DNS name. DNS is a global identity system on which I can register and control an address, and set up automatic responses to arbitrary queries to that address.
- Portable identity: Having let one homeserver handle the “account” for my identity, I need to be able to transfer that account to another homeserver. And not just directly; I need to be able to make a backup of that account, and upload that backup to a new homeserver if the previous one becomes unusable.
- homeserver discovery
- Matrix spec issue: Consider options for discovering homeservers on a local network #1444
- A matrix client should be able to discover a local homeserver when a user is not logged in and has not given a user-id. The client should suggest that the user can register or log in to that homeserver(s) by default instead of matrix.org.
- To be effective, need to standardize across Matrix ecosystem a mechanism for configuring something on the local network, using maybe DNS-SD or zeroconf/bonjour, to advertise the local homeserver(s).
- (With Riot-web, local site admin can easily provide it hosted on their own domain and customized to prefer their own homeserver. But for traditional clients distributed via app stores etc that’s not possible.)
-
Note that a “local” homeserver need not be running on a local machine: in many cases it would be running as SaaS somewhere else, but using the domain name of the local network, with the existing .well-known and/or DNS SRV mechanisms to locate it.
URLs for Matrix entities
Matrix spec issue: Do we want to specify a matrix:// URI scheme for rooms? (SPEC-5) #455
It should be possible to address any Matrix user (like “mailto:”), room (to view or join the room), and message (to view a certain message in the channel history) using some sort of URL (or URI or similar).
The scheme MUST identify the entity, at least these:
- user
- room
- message
The scheme MUST provide some way for the entity to be found by Matrix-aware client software, and SHOULD also provide for the entity to be found and displayed by non-aware client software such as a generic web browser.
The scheme SHOULD support requesting an action on the entity.
- the actioning software would not be obliged to support all actions and should fall back to simply “finding” and displaying some interface to the given entity;
- examples:
- join a given room as “myself” (if user following the link is already logged in to Matrix)
- view a given room’s history
- send a given message (to given user/room)
- start composing a new message (to given user/room)
- invite a given user to join a given room
- invite the (unspecified) actioning user to register to join a given room
- invite (given/actioning) user to start a new conversation with given originator
AFAIK such a scheme is in very early “ideas” stage.
“matrix.to“, a clumsy work-around, gives some idea of the “problem space”.
Riot
It’s important to have a glossy, popular, widely available client app that competes directly with the likes of WhatsApp and Slack.
- Looks to me like Riot’s 98% done and has sufficient momentum. Success!
A Non-Messenger Application
To ensure Matrix does not get stuck as just an instant messenger, there should be a concerted effort to have at least one other application domain well served.
For comparison, see how email has evolved into a system that is only really suitable for human-readable messages. It could alternatively have evolved into a system in which automated responders are common and well supported. A few examples exist, for example the “mailman” mailing list server responds automatically to a few simple command messages, but that is far from a world where users routinely plug automation apps in to their email accounts.
Message Format (Mark-Up, etc.)
I am not sure what Matrix messaging should be doing with regard to message formatting.
I’m concerned about the state of mark-up in software systems in general. It’s so …
- fragmented: umpteen different markup formats at different levels of capability. Every word processor, wiki, instant messaging system, has its own variant. HTML, Open Document, variants of markdown, and mostly unspecified proprietary.
- incompatible: many systems have partial compatibility at a trivial level (like bold and italics) while completely incompatible at higher levels (e.g. displaying a table, or linking sub-pages into a main page)
- many conversions, e.g. implemented when you copy and paste, attempt to perform a conversion but exactly what they do is partial, undocumented and unpredictable.
- open-ended: HTML for example, no limit to the richness it can express, but in the same way it does not express much semantics itself, it is a lower level formatting system, despite the “semantic” emphasis of HTML5. At the same time there are limits to the HTML richness the system will heed, but the limits are seldom stated.
In Matrix / Riot, we seem to have in each message a “plain text” and a “formatted text”, much like email containing both plain text and HTML. In email, we see huge variation in the quality of conversion between plain and HTML, usually poor, and sometimes a plain text that says “If you see this please check the web version instead”.