Matrix at FOSDEM 2019
matrix.org
matrix.org
While there are still some things that need improving, they're mostly just rough edges. All of my coworkers are at least semi-technical, so that makes things a little easier for us. At times, the key verification can be frustrating, but I think this is just a hard problem to solve in general.
As I began to use Matrix more, I realized that there's potential for Matrix to be much, much more than just a Slack/Mattermost/Rocket Chat killer. I could see this replacing texting, what's app, group chat for business and outside of work. I haven't tested much of the video chat or phone calling features, but if support for those become robust, I could see Matrix replacing almost every form of communication I currently have. That would be really excellent considering most of the communication channels I currently use are controlled by corporations I don't like and don't trust.
Following that line of thought, your Matrix address could become a universal point of contact. A Matrix address seems so much simpler than a phone number, and you don't have to worry about the fact that you may not be able to transfer numbers between carriers or something like that.
I have so much hope for this project. We need an open-source, encrypted, decentralized communications standard. This is the best and broadest attempt I've seen at this so far.
The old chaps around here had exactly the same hope for XMPP that you're having right now. It had it all, except, crucially, marketing.
Here is where I am after jumping around the docs for 15 minutes. Can someone with more Matrix experience help?
So as of right now:
* Can I have one app on my iOS device that allows me to seamlessly message people on platforms like messenger and whatsapp and email? (Is there even one 30-60s video clip demo'ing Matrix?)
* Do I need to run my own server to get going? (Public servers are discouraged for auth'ing with my private messages, or that's not even implemented.)
* Can I just plop the docker onto a server and I'm done? I suspect I have to do something with the bridges, but how much?
* Overall, how long will it take me to get running and have satisfaction?
One an end note, I think this project has so much potential, and is potentially killing itself with its super-dev-focused information layout and messaging. We need to get non-technical end-users excited about this project!
Okay I'm going to gripe in my postscripts now:
p.s. This blog post makes the common release announcement mistake of not even telling you what the software does in the first few paragraphs.
p.p.s. "If you want to… Just get started! Then read… [Getting Involved [link]" Really? There's no end-user getting started page? It's a getting involved page where one option is to write my own server?
Whatever you plan to use it for, those projects should have communities of people to help.
You can also set up some very simple bridging from within the client that will connect a Matrix room to a room in Slack, Gitter, and IRC. It will basically mirror the contents of (say) a Slack room into a Matrix room and vice versa. This process is pretty much just point-and-click.
The less-simple case is if you want to do "puppet" bridging, where you can control your own Slack, Discord, iMessage, Hangouts, etc. user via Matrix. The people you talk to using those services won't actually know that you're using Matrix; it just sends messages as if they're coming from your account. To do that, you will need your own server and you'll need to run bridge servers. I didn't find it particularly hard to get Synapse (the reference server) up and running, and I don't have much experience with that kind of thing. The time consuming part for me was just learning how to get a TLS certificate and how to set up a reverse proxy in Apache.
Setting up the bridge servers is more of a mixed bag. They're all developed by the community and have differing levels of stability and polish. It will really depend on which ones you want to have set up.
Build matrix-synapse server from source: https://github.com/matrix-org/synapse
Install matrix-synapse server on a DO droplet (the smallest/cheapest droplet or excess resources on an existing one should be plenty): https://www.digitalocean.com/community/tutorials/how-to-inst...
I hope this project gets more traction because it's a fantastic, secure, self-hosted, full-featured, (inhales), open-source version of slack/telegram/kind of discord. Not perfect yet, but really great so far. Even pretty easy to set up e2e-encrypted voice and video calling through your server.
Or use a distro that has a binary package, e.g. https://www.archlinux.org/packages/community/any/matrix-syna...
Being able to see and respond to all my messages from all those services while I'm ssh'd into a weechat client is surreal and amazing. Going back to tapping out messages on my phone in iMessage or opening up the god-awful hangouts web client that shows my chat in a phone-sized window even on my 43 inch monitor feels like a joke at this point.
For now, that kind of setup isn't really accessible to a non-technical user, but even so it's the killer feature. Matrix has a few rough edges, but it genuinely feels like it's growing into something that is objectively better than all the other proprietary services out there.
The only rough edge I have with this setup is that I lose video playback in client compared to say Messenger or TG. Maybe one day...
The docs could be better, but I didn't find them too terribly hard to set up. If you decide to try it out and need any help feel free to ask around in #matrix-puppet-bridge:matrix.org
...turns you back into a first class iMessage citizen. Meaning better security, more features, and a special color for the messages to signal all that to your recipients with an iphone.
If I'm understanding you correctly, are you suggesting that iMessages has a superior security protocol than Matrix?
* OP has an iphone and some kind of non-iphone messaging interface accessed through ssh which can somehow send messages to iphone users through iMessage
* OP prefers to use the non-iphone messaging interface to send messages to iMessage recipients (I'm assuming both OP and recipients are using a modern generation of the iphone)
I'm saying that-- as it stands today-- OP is accepting a decrease in security by sending to the iMessage recipients from the non-iphone setup instead of from OP's iphone.
Regardless of the security protocol of Matrix and regardless of which client OP is using, what I'm claiming will be true.
It's also trivial to refute-- if I'm wrong then the messages OP is sending from their custom box should show up with a blue background in iMessage on the recipient's iphone. Is that the case or not?
The distinction that the iOS messaging app uses to set the color of the message bubbles is whether messages are sent over SMS/MMS or iMessage. Since they're sent over iMessage, the message bubbles will be blue.
But yes, adding Matrix to the mix does add more potential failure points, since there are now two messaging protocols involved instead of one. That's just the nature of bridging messaging protocols though.
There are some wrinkles, but in the main I think the project is making significant progress on making the whole thing work well for both admins of the hosted server and riot-web, and people signing up to and using the network with Riot.
Key management and verification needs the most work in Riot (even the redesigned client), especially for secure channels. That’s the biggest point of friction for me and my friends so far.
I’m very much looking forward to what Matrix can do as a network, and what both rich clients like Riot, combined with esoteric clients that do strange and wonderful things, can enable.
Meanwhile we also have cross-signing on the horizon, as demo'd in the OP: (https://github.com/matrix-org/matrix-doc/pull/1756) so you only have to verify a user once and then transitively trust all their other devices automatically (assuming that user verified them when they logged in).
This was a massive amount of work, but tantalising close.
https://youtu.be/C2eE7rCUKlE?t=2836 is the bit of the talk from FOSDEM which shows this being demo'd and (almost) working :)
Edit: NFC would be cute, but it's not ideal from an evil maid perspective, and you'd have to tap to confirm that you verified the right user ID anyway. So personally QR codes ftw.
What's the main difference with matrix? Is Keybase something you were aware of and decided against for some reason?
Now, Keybase is cool - particularly how it's effectively a key management system which drives a collaboration tool. We hoped originally they would provide it as a decentralised identity management system that we could hook into Matrix to replace our identity service. But in practice it seems to be centralised, and whilst the client is FOSS (https://github.com/keybase/client) the server isn't. So, it's more an E2EE-capable centralised collaboration tool built on a cool key management system. I believe their E2EE is based on shared keys rather than a cryptographic ratchet (Matrix uses inspired-by-Signal Double Ratchet with extensions), which is a simpler approach, but doesn't give you the option of PFS. I'm also not sure if their crypto has been audited (whereas we have a slightly ageing audit of Matrix's implementation over at https://matrix.org/blog/2016/11/21/matrixs-olm-end-to-end-en...).
[disclaimer: I'm project lead of Matrix and the author of the OP]
And with that any chances an easier way of having an ID/username? @<user>:matrix.org seems extremely easy and convenient for me but may not be the same for my friends and family without whom any messaging platform is useless.
PS. Totally rooting for you guys! I wish Signal was federated though.
Matrix emphasizes the use of third-party IDs (3PIDs) via dedicated identity servers. The idea is to link your Matrix ID (@user:server) to other identifiers like your email or phone number. Then you can use those to log in and other users can find you using them too.
https://matrix.org/docs/guides/faq#which-matrix-clients-supp...
* Riot webpage claims their E2EE support is still in beta
* nheko links to a github repo that is apparently no longer maintained
Not sure about the SDK links. But I'd strongly suggest changing the text to a simple, "None yet." At least until you have stable, default E2EE in at least one client for a few releases.
https://github.com/Nheko-Reborn/nheko
I'll reach out to the matrix folks and ask about getting the website updated.
Someone on reddit gathered some data [1] about E2EE support a few months ago, and Debian maintain a wiki page [2] about their progress packaging Matrix-implementing applications.
[1] https://www.reddit.com/r/privacy/comments/9avyen/sad_state_o...
Now, there’s a long tail of other random clients which don’t do E2EE, which is inevitable given doing a good secure job of an independent E2EE implementation is obviously tough. But is that actually a problem, given the most usable mainstream clients do have it?
It’s a bit like declaring that the Web is in a disastrous sad state because of the number of HTTP clients out there which don’t have a CSS engine in them...
Well, given that decentralisation is the primary differentiator from Signal (as far as I can see), everybody having to use the same client to get it is a bummer. I would even go as far as to say that it's a clear example of the problems Moxie sees with making Signal decentralised.
So yes: Moxie has a point that the more implementations you have, the more bugs and security holes you may have, and the slower the project can evolve. But for us, freedom to control your own data and conversations and provide an open network & platform to build on is more important.
True, but here is the repo:
"Note regarding End-to-End encryption - Currently the implementation is at best a proof of concept and it should only be used for testing purposes."
and:
"No longer maintained - Desktop client for the Matrix protocol"
On the other hand a number of us are puzzled by a leading cryptographer and security expert actively recommending WhatsApp after all the tricks Facebook has been trying to play since they bought it, e.g default opt in to new amd wildly different terms.
Signal? Sure. Feels reasonable. Bjt as long as you keep recommending WhatsApp while lashing out against everyone else I really don't see why I should trust you.
There's more to security than bullet proof e2e delivery of tbe content, you see.
I'll keep pressuring everyone I know to migrate to federated replacements for monolithic proprietary alternatives.
It probably won't be docker itself, but if you start deploy your stuff as docker containers now there will probably be a migration path to whatever it will be.
https://gitlab.com/ma1uta/mxtoot is a basic ActivityPub <-> Matrix crossposting bot tho.
Fast enough for us and it's nice to be able to save all the pictures your family sends in full quality. They stream straight to my S3 buckets. Run this on a 5$/month digital ocean droplet and it could probably support hundreds of users.
The mobile and desktop apps are easy enough for mid-60s parents to figure out, a huge shortcoming to all the other OSS chat solutions I know of
there has been time to fix all this but it has happened. at this point I'm not sure if the api is simply hard to implement or if the go-lang server will help.
i've even looked at the ircv3 spec for innovation. thats how desperate ive become for some kind of advancement (grin). I enjoy writing chatbots and new features are hindered by irc's lack of per-message ID. I've run a synapse server and an irc bridge and was disappointed in the complexity and resource usage. so i stay in 1992 with good ol' irc and freenode.
in terms of perf: yup, synapse is still nothing like as performant as it should be. as the talk in the OP explains, we opted to focus on getting a 1.0 which is 'correct' (in terms of stability and bugs and no design flaws) rather than fast. Fast comes next, and it should be more than noticeable.
There are also native clients like Fractal and Quaternion that use GTK / Qt UIs that are just as fast as any other native app.
I've heard a lot on both sides of the fence as far as adopting python 3 exclusive language features for optimizations as well as using Cython everywhere but I'm not really sure where consensus lands. Kudos to you however, this is one of my favorite projects and will continue to be!
We've seen significant perf improvements anyway however - both due to switching to UTF8 for string encoding and some dict operations getting much faster.
https://matrix.org/blog/2018/12/21/porting-synapse-to-python... has all the gory details :)
While picking apart the Synapse database, I noticed some design choices that would cause very significant performance hits, particularly the use of string keys everywhere.
I found Ricochet IM (https://ricochet.im/) to be much more to my taste. Your Ricochet ID is just a Tor hidden service, and when someone wants to chat to you their client connects to your Tor hidden service.
Using Tor gets you encryption and onion-routing for free. That means anyone MITM'ing your network traffic can't tell who you're speaking to or what you're saying.
It also gets NAT-traversal as a happy side effect.
Most people are happy that we actually spent the time & effort to explain what happens to their data in Matrix (especially given it's unusual relative to a centralised service), and to do so in non-legalese. https://github.com/vector-im/policies/blob/master/docs/matri... is the doc in question fwiw.
But not end-to-end encryption ... (unless Tor changed that?)
It's not encrypted between the Ricochet process and the Tor process (which is a point for potential improvement), but if you don't trust your local machine you've already lost.
https://www.techrepublic.com/article/tor-users-do-not-expect...
While Matrix is very impressive in its ambition, in the end we went with rocket chat because it's more mature, and frankly a simpler stack is easier to wrap your head around and start making meaningful changes.
That said, I really hope this ends up being a useful protocol for interoperation between services. The potential is huge.
I really wish though that instead of rewriting Synapse in Python 3 that they would adopt Status' new favourite language: Nim :)
There's also a next-gen performance-oriented server in C++ here: https://github.com/matrix-construct/construct
tl;dr: Synapse is getting (much) better; i wouldn't wait for Dendrite but give Synapse a go on Py3 instead for now.
that said, once Dendrite lands, it should be 1-2 orders of magnitude more efficient by most metrics :)
Whether that's a good or bad thing remains to be seen, but I'm a bit skeptic towards complicating things from the get-go.
Is there anything matrix/signal etc do better?
Telegram's "secret chats" don't solve anything because you need to convince everybody involved in secret chats to give up cross-device sync. The existence of the option doesn't solve anything if it isn't the default and comes at the cost of convenience. How many of your own chats are actually "secret"?
But I think the product will need to be radically better to go down this road. Not tech...but product. And yes I have evaluated the new experimental release very closely (we were about to purchase a 300 seat license for a Hipchat replacement).
Personally I think that the infrastructure can be simplified and corrected - I think that instead of a python based server with a react based reference client (riot), it would be simpler to have the reference server and client in Typescript. The packaging and development is simpler and you also get type safety (which would be very important for innovation at the cryptographic protocols level).
I'm seeing a bunch of type safety bugs crop up periodically (e.g. https://github.com/matrix-org/synapse/issues/3191 and https://github.com/matrix-org/synapse/issues/4112). I think there is also Dendrite in golang which is a higher performance and typesafe server in golang. Personally i think since the reference client in react is unavoidable (and that's where the product innovation really happens), it is probably more efficient for the org to have everything in typescript and make life easy for engineers/contributors.
I have my startup founder hat on when I say this.