* Details for testing the redesign of Riot (https://riot.im/experimental)
* A teaser of fan-out routing
* The potential roadmap options for 2019
* The endgame for E2E encryption, Matrix 1.0 and a whole lot more.
Any questions welcome :)
Vector.im vs Riot.im vs Modular.im ? The FAQ of modular.im asks you to accept a TOS from riot.im . The website demo is on riot.im, but the hosted product is modular.im .
And when you write in to modular.im support, you get a reply from an @matrix.org person. Jobs are applied for on vector.im ...however riot.im twitter page says "formerly vector.im". Modular.im (your hosted slack alternative) page has NO feature list. People are expected to go to riot.im to understand features and play with the demo. In fact your hosted product modular.im has no links to even download the mobile/desktop clients.
People get surprised when I tell them about riot/matrix having a hosted slack alternative that is significantly cheaper and is open-source+E2E. I believe one of the reasons is that have 4 websites rather than one.
Not sure why this situation exists. It doesn't help when making a case for it in the community or company. Gitlab does this well. Please fix.
I don't think you should be uncomfortable with the idea of mixing your open-source products with closed source code (for e.g. modular.im migration tools are closed source) - confusion is the bigger problem.
You made the right choice in focusing on Synapse and letting Dendrite stall. You can build one reference implementation well and let others do as they please. You should do the same on the desktop client.
For Matrix, the naming is actually pretty simple:
Matrix is a protocol curated by the Matrix.org Foundation.
Riot is a matrix client (which is just one of many in the Matrix ecosystem, hence not calling it “Matrix client” for the same reason that Firefox isn’t called “Web browser”.
Modular is a matrix hosting service, which can support any Matrix client, and isn’t tied specifically to Riot, and should be one of many in future, hence not calling it “Matrix Hosting Services”, just as AWS don’t call themselves “Web Services”.
As it happens, Riot and Modular are made by a startup called New Vector, which also hires most of the core Matrix team. We don’t expect anyone to know the name New Vector though, any more that we expect people to know that Slack’s legal entity was called Tiny Speck for years. It generally only comes up when hiring.
So: yes, it’s surprising that there are 4 brands flying around here - and many many more if you consider the wider Matrix ecosystem of clients and servers etc. But it is completely inevitable. This is the primary difference between Matrix and (say) Rocket.Chat or Mattermost or Slack or Discord. The power and flexibility of an open ecosystem comes at the expense of needing to give the different parts different names, just like the Web does.
For example, Runner is an open source project that is used to run CI jobs. https://docs.gitlab.com/runner/ . Omnibus is packaging tool (https://docs.gitlab.com/omnibus/README.html) and Gitlab is the git tool itself. If you peek at the top right corner of the documentation site, you will see these three big headings.
Here are your gitlab clients - https://about.gitlab.com/partners/ (including all the native apps)
Gitlab CE is the open source software. This is similar to you having riot. Gitlab.com is the hosting service - similar to you having modular. There is no difference in intent or licensing... im talking about brand. For the end-user, the benefit in incalculable - one website (and Google search keyword) to find out all the options and all the information. I send people to Gitlab.com if they want to run it themselves OR if they want to buy the hosting service. In fact, Gitlab had org vs com domains for open source vs paid software .. when they then merged (https://about.gitlab.com/2014/03/07/moved-to-dot-com/)
There is no reason for you to identify Vector.im as separate from Riot.im as separate from Modular.im . For me as an end-user, it doesnt matter - Riot.im could have a link to download and a link to host and a link for about us.
It is not about inevitability - you are outwardly branding stuff separately that is not needed and can be unified under a single umbrella to reduce confusion.
Vector is the name of their company and modular is the name of their hosting service. So the argument about representation doesn't stand. The brand theory still holds.
>"Why are you called Matrix?"
>"We are called Matrix because we provide a structure in which all communication can be matrixed together."
>"No, it’s nothing to do with the film (although you could go and build virtual worlds on top of Matrix if you wanted :)"
Am kind of surprised there is no mention of William Gibson there.
I didn't see Fractal being mentioned. IIRX they have received some founding from Puri.sm recently. Sorry if I messed it as I didn't read the entire article.
The youtube video at the end shows an alternative C2S and S2S transport being used - similar to the one described at https://fosdem.org/2019/schedule/event/matrix/. Atm it's experimental and only works in closed networks and isn't yet released, but the plan is to add it as an official alt transport once we've got it working nicely in open networks. It's about 30-50x more bandwidth efficient than the default HTTP/1.1+TLS+JSON transport.
One thing about this roadmap post that is confusing to me is that the mobile client work, specifically iOS, seems under-prioritized. I'm assuming the focus on UX the last half of the year has been intended to put matrix in a position to compete with the mainstream apps for adoption, so having solid mobile UX seems just as important. Is there a reason matrix expects users to be desktop-centric or that the mobile UX is already good enough to compete with Slack, Discord, etc?
Also, for better or worse, we have entirely separate codebases currently on Web, iOS and Android. The reason we do this is to ensure that other app developers can use the same proper native matrix SDK in their apps rather than be forced to use a device abstraction approach like React Native. However, it means that typically the web SDK leads the way (as it’s the easiest test bed for new features, and several of the core spec team work on Riot/Web, so new stuff happens there). However, we’re starting to see the balance shift: the new Android SDK and app is more advanced than the JS SDK, and we might even experiment with using Kotlin Native as a way to share that code to other platforms.
Eitherway: we’re aware that mobile needs more love and investment and we’re trying to fix it :)
 The Matrix bridge model fundamentally doesn’t map to how IRC works in reality, and causes massive headaches for IRC network and channel operators.
Freenode is also not the entirety of IRC.
In terms of privacy concerns: yes, Matrix.org is currently provided by a UK legal entity, just as many IRC servers are too. But if you want privacy from a malicious server admin or government or whoever then you should be using end-to-end encryption, and you shouldn't be using IRC. I'm not sure the legal jurisdiction makes much difference (unless the UK outlaws E2E, which then becomes a whole new can of worms).
If you're worried about the fact that Matrix rooms contain scrollback, then it's (again) unfortunate that nobody has cared enough about this to file a bug on https://github.com/matrix-org/matrix-appservice-irc/issues to request configurable retention per bridge. Meanwhile, https://github.com/matrix-org/matrix-doc/issues/447 i s the general spec issue if you'd like to upvote or comment on it. But in the end, Matrix is FOSS, and we kinda hope that folks will contribute stuff like this that we simply haven't got to yet.
While I agree that many communications should go over e2e chat, there are a number of low-real-risk channels on IRC that occasionally discuss drugs and similar, and adding the additional risk vector that ten years down the line some prosecutor decides to dig the logs up through Matrix.org when everyone else has long since lost them isn’t really cool. My understanding from last time I went through the codebase is that logs will not be deleted even if all Matrix users leave the room.
My point is that if you have requirements for a bridge (eg configurable scrollback retention), you should submit a feature req to let us know about it at the time rather than ragequitting and telling people that matrix is broken.
Anyway, point taken that we need to make scrollback retention configurable (whether for bridging or in general); have bumped it up the todo list.
You're right that there's a fundamental difference between IRC and Matrix. In Matrix, the room history and state is represented by a single datastructure replicated across the participating servers. In IRC, each user effectively sees their own version of the room history - for instance the only rule for whether you can see messages in a room is whether the server considers your client joined to that room (given lack of scrollback in IRC). Similarly, poweruser IRC features such as the ability for chanops to send messages in a channel which are only visible to specific users are hard to map to Matrix's model. Matrix expects it to be consistent and well-defined as to who is in a room at a given time, and who can see what message.
I think the actual bug you're talking about is https://github.com/matrix-org/matrix-appservice-irc/issues/2..., which boils down to the fact there is a race when the bridge starts up during which messages are synced between Matrix and IRC without yet knowing whether the Matrix participants in the room have yet joined the IRC side of the bridge. Now, in practice this hasn't been a major problem because: a) the bridge starts up fast, b) nowadays the bridges are stable and are rarely restarted, c) the chances of the membership changing on the IRC side whilst the bridge restarts and racing with the Matrix-side membership are fairly slim.
Possible fixes include:
* Making the bridge refuse to join traffic until it's fully started up. This ends up being a usability v. privacy tradeoff, but would be trivial to implement.
* Implementing per-msg ACLs in Matrix, so that different users in a room get to see precisely the messages which correspond to the points where their IRC client was connected to the network.
* Bridging each IRC channel into a separate Matrix room (horrid, because it means the Matrix users would only be able to interact with each other by wormholing via IRC).
Now, as you can tell from the comment history on the bug, it's simply not got to the top of the todo list to address. It occasionally comes up in conversation with Freenode, but given that the bridge has been pretty much solid for the last 6 months, it's not been a big consideration.
We had NO IDEA that this was a problem for Hackint, and were shocked at https://hackint.org/#20181028_Matrix_Bridging_Sunset given nobody (as far as we know) had discussed the issue with us until after they'd already made a decision. I am also unconvinced that this creates 'massive headaches for IRC network and chanops', and I wonder if historical perf issues with Synapse or similar were more of a contributing factor here.
The biggest issues we've actually seen on IRC bridging are a) handling the floods of spam coming in from IRC; and b) the risk of some twit using Matrix to bridge together disparate rooms on different networks. Both of these are effectively social/reputation problems that we're working on.
TL;DR: if you're having problems with a particular bit of Matrix, please file a bug or upvote/comment an existing bug, and if necessary yell at us until it's fixed. We're unlikely to fix things which we don't realise are problems for people.
[edited for typo & clarity]
Still need to have methods for moderators and admins to have permissions to view details about other people in the chat rooms.
Things like ip address, server they are federated from(?), client used, etc.
Having run public chat rooms for more than a decade, I've found the need to give some people moderator powers to inspect suspicious users, log info, and ban via subnets and cidr being very important to lessen the flow of many issues.
It only takes one troll to ruin your chat room, and that troll can connect from dozens of ips from dozens of vpns in little time.
The more info we can provide to a few trusted people, the easier it is to detect these things and ban people / networks.
I know this is not a magic pill to fix all the problems with all the people. A combo method with things like having regular users move to a room that takes a certain level to join, and only gaining access to those levels if you've been a known member for x months for example can make a big difference in situations like that as well.
Other moderation tools would be nice too, but without the ip info and such the others are moot in my experiences.
While I'm sure it's a great option for people using GNOME-based desktops, I don't think it'd be a good idea to bet on Fractal as the Matrix native client, I don't think its authors see it that way either.
PTO is abandoned; matrix-ircd (https://github.com/matrix-org/matrix-ircd) works but needs contributions and polish to be useful; AgentSmith is brand new and looks promising but haven’t tried it.