Matrix at FOSDEM 2019(matrix.org)
matrix.org
Matrix at FOSDEM 2019
https://matrix.org/blog/2019/02/04/matrix-at-fosdem-2019/
96 comments
It's also ridiculously easy to use. When his friend left their matrix riot chatroom for lent, this guy made a textgenrnn chatbot out of his friends chat history on Matrix. For the people looking for a demo, it's a pretty good start.
https://m.youtube.com/watch?v=hRVVn-8CzXE
https://m.youtube.com/watch?v=hRVVn-8CzXE
> 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.
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.
And let's not forget the mess that is push support - this murders it on mobile and therefore more or less the biggest messaging market.
Did you get around if this works?
https://github.com/exul/matrix-rocketchat
https://github.com/exul/matrix-rocketchat
Okay, so this project sounds exciting. But it's really hard to figure out what is currently possible and how to get started. (I find this ironic for a project that is focused on improving communication.)
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?
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?
The simple case, if you just want to use it, is that you go to https://riot.im/app and sign yourself up as a new user. You can talk to other Matrix users, join rooms, and in general use it like any other chat service. Riot is the reference client and you can use it via web, install it as a desktop (electron) app, or install the iOS or Android apps. There are other clients you can use, but for the most part they're all very much in beta.
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.
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.
The other comments already gave you some great info, but I'll just link some good documentation for anyone looking to get started. I discovered Matrix the other day and decided to set up a toy matrix-synapse server, which took less than two days' worth of free time for someone with a programming background and no serious IT expertise.
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.
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.
> Build matrix-synapse server from source: https://github.com/matrix-org/synapse
Or use a distro that has a binary package, e.g. https://www.archlinux.org/packages/community/any/matrix-syna...
Or use a distro that has a binary package, e.g. https://www.archlinux.org/packages/community/any/matrix-syna...
Ah, I probably should've mentioned that the DigitalOcean article I linked shows how to install/configure a synapse binary with apt-get.
Matrix is only a protocol. There are some clients listed for it on this page: https://matrix.org/docs/projects/try-matrix-now.html
Whatever you plan to use it for, those projects should have communities of people to help.
Whatever you plan to use it for, those projects should have communities of people to help.
I have a Matrix homeserver running on an Odroid XU4 that sits under my TV. I also have bridge servers running for iMessage, Slack, and Hangouts (which includes Google Voice) that connect those services into Matrix.
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.
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.
I have made a similar setup with IRC. I have set up bitlbee with Facebook, Telegram, Hangouts and Steam plugins, bitlbee is connected to quassel-core and I use native Quassel clients on all my platforms to connect to the core (trough VPN if needed).
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 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...
How well does the Steam integration work? I haven't tried setting up a bridge yet, but even on the web client I constantly get logged out.
Ironically the native client constantly logs me in, even when I don't want to. I've never wanted to be Online or Available, but ever since they shipped the new "Friends" thing it's made quite difficult.
Video playback for quasseldroid is actually something I'm working on right now :)
What bridges do you use for iMessage, slack, and Hangouts?
All three are the puppet bridges from here: https://github.com/matrix-hacks. The Hangouts and Slack bridges run on the odroid, same as synapse, and iMessage runs on an old mac mini I bought off of ebay.
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
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
> Going back to tapping out messages on my phone in iMessage
...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.
...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.
> Meaning better security, more features
If I'm understanding you correctly, are you suggesting that iMessages has a superior security protocol than Matrix?
If I'm understanding you correctly, are you suggesting that iMessages has a superior security protocol than Matrix?
It has nothing to do with the protocol of 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?
* 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?
>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.
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.
I’ve learned about, installed, and configured both Synapse (official Python server implementation) and riot-web (browser version of Riot, the official client) recently, to give me and some friends a post-IRC means of modern, secured chat.
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.
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.
Yes Riot really needs a way to swap keys using NFC, so you only have to tap phones together when you meet. We actually did get an encrypted chatroom going at the last KVM Forum in Edinburgh, but it was insanely tedious to do all the key verification.
so, in riot.im/develop we now do verification by Short Authentication Strings (similar to ZRTP: https://github.com/matrix-org/matrix-doc/issues/1267) and have QR codes on the horizon too (https://github.com/matrix-org/matrix-doc/pull/1544).
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.
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.
Do you have an idea how this compares to Keybase.io and their team based chat?
What's the main difference with matrix? Is Keybase something you were aware of and decided against for some reason?
What's the main difference with matrix? Is Keybase something you were aware of and decided against for some reason?
Matrix is an open standard protocol (https://matrix.org/docs/spec) and an open network like the Web, but for realtime comms. Anyone can spin up a server and start participating in the network, and in Matrix the conversations are replicated over all the servers whose users participate in that conversation, so there is no single point of failure or control: the conversations are owned by the users. All the implementations we release as matrix.org are Apache licensed FOSS.
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]
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]
Thanks for the detailed explanation - I know Keybase recently implemented PFS, but I don’t know the implementation details.
Any plans to focus on Riot as a, let's say, WhatsApp/Signal alternative too from what it actually seems as of now which is just being Slack/IRC alternative?
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.
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.
Riot is already a pretty servicable Signal / WhatsApp alternative. You can start conversations by username or email in one on one rooms that you can encrypt and they show up as separate entries besides the groupchats in Riots UI.
> 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.
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.
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.
AFAIK Keybase is centralized while Matrix is federated, so you can set up and run your own Matrix server without worry of a central point of failure (or surveillance).
I might sound dismissive, but in my views Keybase is entirely focused on being an identity provider; all the other tools they've been developing on the side are nice to play with and will probably be the ones bringing in money to them, but at the core they're not really reinventing the wheel, and wouldn't have any value without the powerful and simple-as-dirt reliable identification platform they provide. I might be completely off but I'm sure their dream would be that any new protocol would care about the exchange of data, and leave authentication and identity checking to them.
Matrix people-- please update your section on E2EE:
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://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.
There's a fork of nheko that's under active development:
https://github.com/Nheko-Reborn/nheko
I'll reach out to the matrix folks and ask about getting the website updated.
https://github.com/Nheko-Reborn/nheko
I'll reach out to the matrix folks and ask about getting the website updated.
While I'm very excited about the prospects for Matrix in 2019, the reality of client choice for end-to-end encrypted Matrix chat is currently disappointing compared to the potential it has.
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...
[2] https://wiki.debian.org/Matrix
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...
[2] https://wiki.debian.org/Matrix
I bear no ill-will towards the Matrix project, but this fact pattern (I knew about it in the abstract but hadn't seen it laid out like this) makes me actually angry about the people who have recommended Matrix as a replacement for the Signal Protocol messengers like Signal, WhatsApp, and Wire. Telling people to switch to Matrix from those is simply malpractice.
Signal is a proprietary service. As it is security-oriented, for me it looks like a clear honeypot, so I would never use it. Matrix is much better approach. While I don't like that they use flashy languages for their leading implementations instead of platform-native C/C#/Objective C/Java, it doesn't matter in the long run, what matter is standards and implementations will come.
This kind of analysis will reliably lead you to services that will get your data compromised. Cryptocat was a non-proprietary, open-source messenger with "end-to-end" encryption, and Snowden and Greenwald used it to communicate. And it was grievously broken.
> makes me actually angry about the people who have recommended Matrix as a replacement for the Signal Protocol messengers like Signal, WhatsApp, and Wire.
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.
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.
tptacek: the reddit article there is a bit flawed (as uhoreg tries to gently point out in the response). the reality is that we provide decent E2EE stacks on web, iOS and Android which get used in the flagship client (Riot) that most people use. These are pretty solid and getting better, as per the SAS verif and cross-signing work. Other clients like Seaglass which build on the same SDKs obviously get the same experience. I would argue that these provide a decent decentralised alternative to Signal, WA or Wire, especially if you run your own server (given we don’t do log minimisation on matrix.org).
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...
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...
> 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?
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.
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.
But they don't have to use the same client? The web, iOS/macOS & Android SDKs are completely independent, and have different clients written on them. Riot may be the main one, but Seaglass (on the macOS SDK) has full E2E support, and there are loads of projects building on the matrix-js-sdk which inherit its E2E support. Meanwhile the nheko project has an independent from-scratch implementation of the E2E stack, Fractal is adding it too (thanks to funding from Purism), and even Pidgin has it (albeit read-only currently). (N.B. that the reddit post gets almost all of this wrong :|)
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.
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.
> Meanwhile the nheko project has an independent from-scratch implementation of the E2E stack
True, but here is the repo:
https://github.com/mujx/nheko
"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"
True, but here is the repo:
https://github.com/mujx/nheko
"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"
Sure, not exactly the same client, but at least you should make sure that none of the participants use one of the long tail of non-mainstream clients. Being able to do so would be one of the main selling points of decentralisation for me.
Those other "random clients" (as you call them) exist because your desktop client is bad. And I am being nice by just calling it "bad", it is the least performant client I have ever come across, even counting other electron-based software.
yup, the electron app sucks :) we are very very glad folks are writing native clients, and can't wait to kill it off. meanwhile we're working on its perf anyway, and if you look at the client redesign in the OP (riot.im/develop) you'll see it's actually getting better.
How does an encrypted client interoperate with a non encrypted client?
encryption is configured per conversation. if you try to participate in an encrypted conversation on a client which doesn't support encryption, you simply won't see the messages.
There is a bright future where individual users can trivially (like one click deployment trivial) spin up a Mastodon and Matrix container and have their own social network and IM server running in minutes that federates with all the others in a giant decentralized web. Again.
I'll keep pressuring everyone I know to migrate to federated replacements for monolithic proprietary alternatives.
I'll keep pressuring everyone I know to migrate to federated replacements for monolithic proprietary alternatives.
What are you using for "one click deployment" of Mastodon and Matrix?
Have you ever heard about docker, cr-io (not sure if this one can be used standalone), buildah, podman?
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.
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.
I was only aware of docker. Thanks for the list.
Is it possible to connect Mastodon and Matrix somehow? For example, can one start a chat on Matrix with a friend they have on Mastodon in a convenient way?
Nobody seems to have written an ActivityPub bridge for Matrix yet, which is a shame as it'd be quite easy and really fun. (For instance, it could be implemented as a backend for https://github.com/matrix-org/matrix-bifrost - our next-gen bridge framework).
https://gitlab.com/ma1uta/mxtoot is a basic ActivityPub <-> Matrix crossposting bot tho.
https://gitlab.com/ma1uta/mxtoot is a basic ActivityPub <-> Matrix crossposting bot tho.
Running Matrix + Riot.im for my "family chat" server since Hangouts is going away. Bit hokey to setup but highly recommended.
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
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
the matrix is the great irc replacement that never was. i wanted to like the matrix, i still do, yet every time I use it, the list of terrible user experiences remains the same. its slow. its so slow. the riot design/layout is klunky. its slow. the federation is confusing. for example searching or browsing the list of channels 'works' maybe 5% of the time and its not clear how broad the search is attempting to be. its slow. I've got an invite that cannot be accepted or declined, so its there forever. its slow. the distinction between a person to person chat vs a room is confusing. i cant get the freenode bridge bot to change my nick. it says the bridge bot is offline when im talking to it and its responding.
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.
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.
have you tried riot.im/develop for a less clunky riot?
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.
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.
thanks for the tip on riot.im/develop. looks like progress.
Independent Matrix Server developer here. You might be interested in a community-driven implementation that I work on which aims to address these issues. I'm delighted to read from you here that we share a goal for a great IRC replacement: https://github.com/matrix-construct/construct
thanks for the link. do you have a sense of whether the slowness is more in the web client or in the server response times?
It's really a confluence of factors. There are even elements rooted from the specification itself that contribute, for example requiring many round trips in network interactions with a lot of different servers; requiring large amounts of random disk access to implement core features... These things tend to shape the experience born out of client and server implementations even after a fair amount of performance work. I hope that Matrix-org makes an effort to consolidate the specification into something more streamlined for any upcoming versions.
Synapse, the reference impl server, was always pretty slow. It got a lot faster with its Python 3 transition and there is a Go server in development that I think the core team means to focus on once 1.0 is out.
There are also native clients like Fractal and Quaternion that use GTK / Qt UIs that are just as fast as any other native app.
There are also native clients like Fractal and Quaternion that use GTK / Qt UIs that are just as fast as any other native app.
When rewriting Synapse in Python 3, did you use new language level features and optimizations? And what was your experience in doing so?
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!
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!
Synapse currently runs on both Python 2 and 3, so we're not using any of the Python 3 specific language level features yet. We're considering dropping Python 2 support around April however to open up all the Py3 specific stuff.
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 :)
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 :)
Has performance been looked at on the database side at all?
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.
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.
not yet, frankly. with 1.0 we've focused exclusively on the correctness of the protocol and the implementation. next up is making it fast (at last).
I watched "Breaking the 100 bits per second barrier with Matrix". Great work! This is the type of thing I hoped a messaging protocol would be considering, I am really impressed.
I tried to use Matrix a while back, but I got put off when it asked me to agree to its Terms of Service... what kind of decentralised system has a terms of service? It's meant to serve the user, not the developer.
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.
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.
The Matirx ToS is for using (or federating to) their servers. You can setup your own homeserver and there is no ToS.
Unfortunately it's illegal under GDPR to run a web service without telling users how their data is used and getting them to confirm they understand. We hate it too, but we have no choice. In future as Matrix becomes more P2P (like Ricochet) then this will go away, unless you choose to store your data on someone else's server.
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.
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.
"Using Tor gets you encryption and onion-routing for free."
But not end-to-end encryption ... (unless Tor changed that?)
But not end-to-end encryption ... (unless Tor changed that?)
Tor is and has always been end-to-end encrypted. What do you mean?
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.
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.
That would be news to me. Since when is the traffic leaving the exit node encrypted?
(how could it be?)
https://www.techrepublic.com/article/tor-users-do-not-expect...
https://www.techrepublic.com/article/tor-users-do-not-expect...
I spent some time looking into this recently. My vs was rocket chat.
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.
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 was at Matthew's talk. Great energy and highly informative talk.
I really wish though that instead of rewriting Synapse in Python 3 that they would adopt Status' new favourite language: Nim :)
I really wish though that instead of rewriting Synapse in Python 3 that they would adopt Status' new favourite language: Nim :)
the Synapse port to Python 3 is complete :D However, the next-gen one we're working on (https://github.com/matrix-org/dendrite) is in Go. Nim rocks though, and it'd be wonderful for someone to write a Nim homeserver (especially as we finally have a stable release of the server-server API at last!!)
> the next-gen one we're working on (https://github.com/matrix-org/dendrite) is in Go.
There's also a next-gen performance-oriented server in C++ here: https://github.com/matrix-construct/construct
There's also a next-gen performance-oriented server in C++ here: https://github.com/matrix-construct/construct
Can you give a rough idea about how long it will take for Dendrite to be ready? I want to run a homeserver for friends, but I'd like to go straight to Dendrite and not have to deal with Synapse if possible.
it'll be a while yet. we've been focusing on hitting Matrix 1.0 by iterating on the Python codebase (Synapse) rather than diluting the effort by doing it on Dendrite in parallel. Once 1.0 is safely out the door and the first wave of post-1.0 features and perf have landed in Synapse then I suspect Dendrite will see more love.
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 :)
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 :)
Thanks. I think you're doing the right thing.
Note that Dendrite is doing a bit more fancy architecture. https://github.com/matrix-org/dendrite/blob/master/DESIGN.md -- there's a bunch of readers and writers, with Kafka in-between to mediate flow of messages.
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.
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.
FWIW, I'm running Synapse on a 1/1 instance (1 core, 1 GiB RAM) alongside a bunch of other services, with 4 active (as in: daily) users, and it works reasonably well as long as people don't join large channels (cough #matrix:matrix.org cough). That said, I'm definitely looking forward to Dendrite.
IMO, for something that promises to be (and needs to be!) so foundational, it would be best to go with a mature implementation stack, and Go fits that better than Nim.
Was also at the talk. The room was packed!
Can someone give me a benefit of matrix over telegram? I not 'shilling' for tg but I hear a lot about their weakness being "rolling out their own crypto" and I don't buy that argument. One downside to tg as I see is that if their key can be compromised by comprising the server then chats can be read. They have secret chat for that.
Is there anything matrix/signal etc do better?
Is there anything matrix/signal etc do better?
End to end encryption of all your chats by default. Telegram has you cross-device chats stored on their servers. This is not the case for Matrix (when they finally enable this) and e.g. Wire.
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"?
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"?
So I see a lot of conversation about how matrix is a IRC replacement. But I think, it could be a powerful Slack replacement as well.
A federated chat self-hosted infrastructure could theoretically be more scalable than a centralised product.
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).
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).
How is moving everything to Typescript a "product" decision, that's like the worst technical decision possible (complete rewrite for very little benefit).
I didn't downvote you, but let me explain.
The product improvement point was separate from this point and in all honesty is just my personal opinion.
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.
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.
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.