Page MenuHomePhabricator

Evaluate Matrix /
Open, MediumPublic


Real-time communication is somewhat of a pain point for the Wikimedia movement. There is a large contingent of IRC users with highly specialized workflows (various notifications, highlights, personal scripts, helper bots, vandalism tracking bots etc) for whom moving to a different chat system is probably a no-go. There is also a large contingent of less technical users for whom the cost of learning IRC (with all that setting up a convenient environment involves - cloaking, a bouncer, notifications etc) is prohibitive. Using a different system for them creates a rift in the community, and is often contentious (as the most popular options are not free software). Matrix / (backend and default client for the same chat system) has the promise of fixing this problem - it is backwards-compatible with IRC on a low level and aims to provide a modern UI with all the bells and whistles people have come to expect from a chat system.

We what it would take for Matrix to be the offical chat system recommended for Wikimedia community members (IRC users could stay on IRC if they wanted, the two systems are fully interoperable) and see if we can help them get there. As a first step we should evaluate whether there are any features / UI improvements we'd want and whether those are must-haves or nice-to-haves. is federated so there is probably not too much value in setting up our own instance. To evaluate, follow the steps on the Meta-Wiki page.

See also:

Server (Matrix/Synapse) roadmap / client (Riot) roadmap

Event Timeline

Tgr triaged this task as Medium priority.Jan 30 2018, 10:05 PM
Tgr created this task.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 30 2018, 10:05 PM
Tgr updated the task description. (Show Details)Jan 30 2018, 10:06 PM

jfyi @GWicke has been an early adopter of Matrix.

Qgil moved this task from To triage to Team radar on the Developer-Advocacy board.
jrbs added a subscriber: jrbs.Feb 1 2018, 6:39 PM
Johan added a subscriber: Johan.Feb 28 2018, 6:42 AM
This comment was removed by Johan.
Johan added a comment.Feb 28 2018, 6:47 AM

@Tgr Do you feel like setting this up?

Tgr added a comment.EditedFeb 28 2018, 7:04 AM

Do we want a hosted version? We don't seem to have a problem with using Freenode's servers, and this would be roughly comparable.

Johan added a comment.Feb 28 2018, 7:08 AM

I had just assumed that we would, but if we don't, then everything gets easier, of course.

Tgr added a comment.Feb 28 2018, 8:53 AM

At the very least for evaluating the usability, the official network should be fine IMO. It's bridged with Freenode, so not too dissimilar with how a local setup would work.

At the very least for evaluating the usability, the official network should be fine IMO

(Regarding usability, also see my remarks on when testing a few weeks ago.)

Joe added a subscriber: Joe.Mar 16 2018, 12:00 AM

I'm going to ping @cwdent as he helped set up a test for fr-tech. He might have feedback here.

At the very least for evaluating the usability, the official network should be fine IMO. It's bridged with Freenode, so not too dissimilar with how a local setup would work.

One of the complaints I've heard about IRC is lack of truly private channels (besides 1:1 OTR) and while this may be a misconception regarding Slack it does seem like a reasonable thing to want. Hosting our own is an unknown quantity of work but it seems achievable if WMF decides to put resources into it. Not to put the cart before the horse, I agree that the public servers are fine for at least evaluation.

I used matrix/riot quite a bit when Yuvi was into it and set up a server but it was buggy and undocumented at the time. I'll be very interested to take another look.

FWIW I think one of the biggest things we stand to lose is the Freenode community/ecosystem so I hope whatever we do can bridge the gap effectively. The IRC bot for was pretty bad at the time (cwd[m] was ghosting for like 6 months after I shut down the server)

One of the complaints I've heard about IRC is lack of truly private channels (besides 1:1 OTR)

Agreed. There are (at least) 2 aspects to this:

  • It is fairly hard to set-up private group chats that are permanent, e.g. for remote team-mates who want somewhere to socialize off the record. -- Hard because we cannot just re-use an existing channel's white-list/exemption-list (afaik).
  • It is fairly technical/cumbersome to set up temporary small group chats, e.g. 3 or 4 colleagues wanting to talk about something specific and private/sensitive, at length. -- Technical because it requires knowing that you can type the commands "/j ##examplechannelfoobarbang" at any time, and then dealing with the options of either using "/invite $user" or manually explaining to people how to join your new channel.

and while this may be a misconception regarding Slack

I think you might be referring to this recent news:

Tgr added a comment.Mar 29 2018, 7:49 PM

Matrix supports end-to-end encryption these days so there is no need to host our own instance for truly private channels. No idea how the user experience is for E2E encryption, though.

IRC bridging is definitely the main reason we are looking at Matrix (as AFAIK no other software even has that option). I think it works pretty well these days, only used it a few times though.

Tgr added a comment.Mar 30 2018, 10:16 AM

If anyone is interested in testing the Matrix-IRC bridge, Mark has set one up between #mediawiki and

Tgr added a comment.Apr 7 2018, 11:07 AM

We are collecting issues in (and the Matrix ppl have kindly triaged them and explained the ones that were misunderstandings).

The IRC bridge is pretty decent in my experience; there are some small annoyances (such as long usernames getting truncated) and it's a bit laggy (which we could probably solve by running our own instance) but I'd definitely recommend it over normal web IRC interfaces like You need to register first so it's maybe no replacement to the "click here to join" IRC links we currently have (although if we run our own instance we could provide one-click login with Wikimedia SSO).

Clicking the link toward respond me that the channel doesn't exists. Maybe I need some additional configuration though. I already accepted a spontaneous request by Freenode to join what I guess was a bridge, maybe on my laptop client (Fractal), but I guess that anyway it's synchronized in the browser client and it's not the problem.

Tgr added a comment.Aug 29 2018, 11:14 AM

Clicking the link toward respond me that the channel doesn't exists.

Sorry, not sure where I got that from. The room is

Tgr moved this task from Backlog to Next on the User-Tgr board.Feb 23 2019, 7:16 AM
grin added a subscriber: grin.Mar 14 2019, 3:18 PM
Arkanosis added a subscriber: Arkanosis.
Tgr updated the task description. (Show Details)May 6 2019, 3:57 AM
813gan added a subscriber: 813gan.EditedMay 15 2019, 6:16 PM

Matrix supports end-to-end encryption these days so there is no need to host our own instance for truly private channels. No idea how the user experience is for E2E encryption, though.

E2E is in late beta, there are some minor issues with key management if you are clearing cookies/storage.
Keep in mind that E2E works only inside Matrix. Bridge have to be able to decrypt communication to be usable.

Also, exist only to help community grow and will not be running forever.

IRC bridge is nearly transparent. Both private and group chat works without client-side configuration.
General user experience of Riot is, in my opinion, very good both on desktop-web and mobile.

JJMC89 added a subscriber: JJMC89.May 16 2019, 6:40 AM
greg added a subscriber: greg.May 19 2019, 9:40 AM
Tgr mentioned this in Matrix.May 19 2019, 1:43 PM
Tgr added a comment.May 20 2019, 2:06 PM

TL;DR of the Matrix moderation guide:

  • room moderation:
    • three power levels by default (normal, moderator, admin)
      • moderators can delete messages (also all users can self-delete), kick or ban users, and set server ACLs (currently only available via developer toolbar)
      • admins control channel behavior (enable integrations etc)
      • users can promote others to a lesser or equal power level than their own, and demote others who have a lesser power level than their own
    • kick/ban targeting is limited to Matrix IDs (no IP bans as IP is only known to the user's homeserver) and entire homeservers (server ACL) -> this seems to imply you can't have sane moderation if you allow guest accounts
    • bridges typically do not transfer moderation actions (exceptions exist, e.g. kicks are transferred to/from IRC, and IRC bans are honored on Matrix (but not the other way around))
  • server moderation
    • server admins can send global notices, delete/erase users, delete rooms and groups, hide room directory entries and delete room aliases, reset passwords (not really clear which of these apply to users/rooms local to the homeserver, and which to all)
    • server admins can remove content (not clear what that means for users whose client has already synced that content)
    • server admins can see the IP of local users (there is no IP banning though, that would have to be done on the network level)
    • there's no GUI for most of these
  • users can flag/report content (seems like this is available on the Riot phone apps but not Riot web?)
  • users can add other users to an ignore list
  • the entire Matrix protocol is a huge JSON REST API, so creating tooling for moderation is easy
grin added a comment.May 20 2019, 3:47 PM
  1. If one's running a real room then "power levels" ought to be used a bit differently to prevent problems later: one shall use "admin" as level 90, and "owner" as level 100, and there may be used a level between admin and normal to let people to invite others or to change the topic of the room. The main reason is that equivalent level users cannot change one another, so without the admin+ level admins cannot be demoted, either by request ("I have lost the client keys please remove me") or due to loss of trust.
  1. Bridges are only good to connect the text body chat part; generally no special features get through without problems, including encryption, room and user state changes, and various "rich" content posts.
  1. Server admin actions are all local. They can fiddle with local users, local public posts (unless encrypted) and server connections. They can "remove" content by forcibly *redact* a locally generated message, which will be redacted on other servers (which in fact causes the message to be replaced by a redaction status, so gateways which transfer in real time have no way to do it later). It only have a real meaning in the room history. Server admin UI is in the works, until then it's done by REST calls.
  • Full history is kept for everything. ...unless the homeserver admin decides to purge otherwise. Since it's SQL there's also useable searching available. I found it pretty convenient to find and retrieve posted content.
  • Encryption is "proper", so right now it requires full mutual verification of device keys for all the participants.
  • Encrypion is also secure so
    • one cannot read messages created before joining,
    • one cannot read messages with session keys one's lost,
    • which means that care should be taken to keep the keys safe and secure.
  • Encryption generally works well, but I haven't seen large rooms using it yet.
  • Right now homeserver is python-based synapse, which is not pretty optimal but easy for rapid development. It can use workers to spread parts of the system on several servers, but generally suffers from one-threadedness. Some server implementations are in the works, written in C++ or Rust, but they're not ready yet. Db is psql.
  • There are lots of protocol development in the background (with no breaking changes in the majority case), like "groups", "message feedback" ("like"), and various security related stuff. It's handled on github as "requests for comments" (MSCs,
Kelson added a subscriber: Kelson.Aug 1 2019, 4:44 PM
Tgr updated the task description. (Show Details)Aug 15 2019, 9:59 AM

Moved the trial plans (still not clear if that will be a WMF-only or WMF-mostly trial) to T230531: Run Matrix trial using the instance.