It's kinda ironic that Keybase disappears into Zoom the day after Matrix/Riot enabled end-to-end encryption by default, with cross-signed device verification similar to Keybase's concept of connected keys - see https://blog.riot.im/e2e-encryption-by-default-cross-signing....
In other words, a fully open source (and open standardised) alternative continues to exist in the form of Matrix.
It's funny, but I think I get most of my Riot/Matrix news from your comments scattered about hacker news.
Anyway, I run a matrix server for my family (and we all use the Riot client) and the number one issue is encryption and mysterious "Unable to Decrypt" messages. (Closely followed by how rough the Android client is.) This fixes all of that (well, once RiotX replaces the standard Android client) and I think it will remove a lot of friction.
Holy crap, the Matrix/Riot teams have been busy! Congrats on the progress, it's very exciting to watch. Although I have a Matrix account I have had trouble getting friends/family to switch with me (mostly non-technical folks, and Signal was much stickier for them), it might be time to convince them to try again.
Interesting. I've turned quite a number of non-technical friends/family into Signal users, just by telling them, "Here's the messaging app I'm using if you want to talk to me..." without mention of encryption until they're already hooked. Uniformly comments have been favourable concerning ease-of-use and quality of voice/video calls (at least compared to what they're already used to -- generally Zoom or Skype), and several of them have pushed it out to their networks in turn.
Ease of use is the big elephant-in-the-room issue for Matrix.
The only way I've found to join a room is the `/join` command. There's a GUI search, but it doesn't work.
Users have to pick their identity provider, their home server, etc. Lots of choices, scary messages, and generally annoying to set up. Services that depend on someone who is technically inclined setting things up never become widespread outside technical communities.
If users pick an unreliable server to connect to, or there's a network split, things break, just like IRC does.
There are several clients, all slightly different. It's up to the user to pick which one they want, when they've never used any of them and just want something to work.
It's better than IRC, but that bar is so low you'd have to bury it to get any lower.
It's true you have to pick a server to use, but we try to provide decent defaults (although it's true matrix.org has been overloaded recently).
We're trying to simplify onboarding via P2P Matrix - by default, you'd start off entirely P2P, and only pick a server if you want to 'anchor' your account somewhere.
I last used it for the recent (Thursday, April 30th) Rust Zurich meetup. I've got it installed via apt, and updated to
riot-web version: 1.6.0
olm version: 3.1.3
Search didn't find the room. /join did.
Also it just took me over a minute to find the version number, because the client settings are hidden in a dropdown menu under my user name, not in the gear icon (tooltip "settings") on the upper left or the hamburger menu that says explore, and even in the right dropdown it's under "settings->help & about" instead of just under "help" where the "about" box has lived in every single program since the '90s...
Well, if search didn't find the room, it sounds like a plain old bug. (Or was the room marked ex-directory?) If you can file details at https://github.com/matrix-org/synapse/issues we'll dig into it.
And noted, in terms of the version number being in the wrong place on Riot/Web.
Oh definitely, my experience is similar. Sorry if I was unclear: by Signal being "stickier" than Matrix I meant that I've had better luck getting friends to continue using Signal than continue using Matrix. So far, anyway.
Hi! I use Matrix a lot, but a privacy-sensitive group of my friends recently switched to Keybase largely due to the per-room/per-message retention policies. This might be a good opportunity to convince them to jump ship, and I know something similar has been in the works for Matrix, but do you know where it is on the list of priorities?
(Congrats on the cross-signing release though, it's been a long time coming and it's been working really well!)
We've had per-room/per-message retention policies in Matrix for months now (although Riot hasn't exposed UX to configure them yet, as we were drowning in cross-signing work).
Hmm, that document seems to indicate they're disabled by default in synapse though?
>Note that over every server in the room, only the ones with support for message retention policies will actually remove expired events. This support is currently not enabled by default in Synapse.
Hijacking this: Does anyone know if there’s a Matrix client (out or in dev) that has the UI/UX of old 1on1 messengers (ICQ, MSN) and not chatrooms (IRC, Slack)? Specifically not the weird list of bubbles on the side, but instead a list of accounts/rooms and a window per chat.
I guess Pidgin has that UI, although its Matrix support is alpha sadly. Not aware of anyone else who's done that sort of UI yet, but it's only a matter of time.
I'm not sure I understand, because neither IRC nor Slack have the bubbles thing, that's something you'll see in Facebook Messenger or Whatsapp. Also, Riot doesn't have those bubbles, and has the list of accounts/rooms on the side.
However I'm not aware of any client that opens conversations in different windows.
The thing I like about Keybase is that keys are always generated client-side and never leave the client, and all of the functionality associated with adding/removing devices is done in a way so that there's no way for a server to tamper with it (aside from denying service).
Is that true in Matrix? Several services advertise themselves as "end-to-end" encrypted, but then when you poke harder it turns out either there is some sort of TOFU (so an opportunity for the server to insert itself) or else there is no device continuity (which means in the case of e.g. Whatsapp that keys are reprovisioned almost promiscuously to avoid bad UX). Whatsapp is a particularly bad example because (a) I lose chat history when I move devices, and yet (b) the UX does not require an old device to authenticate the new one, so I can compromise conversations (at least moving forward) if I can compromise a server.
How end-to-end is Matrix really, and how similar is the new support to Keybase's key management flow?
All keys are stored clientside, with the exception of if you enable serverside key backup, when they are then encrypted and optionally stored serverside to allow you to recover your history if you lose all your devices.
Just to confirm, if I turn off backup, does anything stop working aside from needing at least one device to be operational at any given time?
Edit: Specifically, is key backup tied to the ability to recover account history on a new device, or can I still get that with key backup disabled as long as I have at least one other device active?
Edit 2: Can you address this paragraph:
> One point for super-paranoid users: currently the private key used to sign your own devices and the private key used to sign other users are encrypted by your recovery passphrase/key and stored on the server to allow recovery if you lose all your devices. We also allow signing keys to be shared (gossiped) between devices, but right now the implementation also stores them encrypted on the server too. This restriction will be fixed in future, but for now if you don’t trust your server with encrypted keys, you may want to hold off on using cross-signing.
If I understand correctly, sounds like security is based on the complexity of your recovery passphrase and an implicit assumption that the passphrase doesn't get transmitted to the server... is that correct?
If you turn off message key backup, all it means is that if you lose all your devices (and thus your keys), you will lose your history. Otherwise, if you have at least one device active on your account, it will receive your message keys and gossip them (if needed) with your other devices. You can always do a manual offline backup too for safekeeping as a workaround.
> If I understand correctly, sounds like security is based on the complexity of your recovery passphrase and an implicit assumption that the passphrase doesn't get transmitted to the server... is that correct?
If you use cross-signing, then yes - your signing keys are stored protected by the recovery passphrase on the server. We also support gossiping them between devices (same as message keys), and there's no reason for them to have to persist on the server. We just need to hook up the UI to expose that as an option and we ran out of time to do that before shipping the initial release. It will follow shortly.
I was about to complain about your desktop Electron app but it seems that spectral[0] is already usable without any hassle (build from source, ...) at least on Fedora, time to reactivate my Matrix account, keep up with the great work
I've been looking into Matrix as a "personal IM bridge" and I'm thinking this could be a way for Matrix to get traction.
Let's say you're in a position that I think may here are: You would prefer to use IM in a secure way. Let me qualify "secure" for this purpose meaning: Encryption of communication in rest and transit; not relying on a single infra/network/service provider; being able to communicate with new peers easily without having to sign up with new providers; not requiring sign-ups leaking PIIs such as phone numbers; being able to sync message history across devices; all of this should hold for group conversations.
matrix.org seems to be on the right track towards that. Feature-wise there's some missing pieces in terms of federation but the roadmap looks like the ambition is right.
But in practice, it's realistically years until you can meet a random person in a bar and ask to join you on matrix to stay in touch, so many of us will still keep our accounts on the not-as-great platforms such as FB, Skype, WhatsApp, Signal.
Given that, wouldn't it be nice to facilitate using those platforms in a way that 1) absolves you from the behavioral tracking that comes with most of the first-party web- and smartphone apps and 2) integrates them in the same UI?
There are, of course, solutions to this end. Bitblbee (IRC gateway), libpurple (pidgin, finch), third-party clients like franz. I'm sure there are many here who have or are using libpurple or bitlbee for this.
But matrix also has bridges!
I'm thinking one potential way that matrix could really get traction and seed the network infrastructure would be just that. Given stable gateways for the IM networks people already use, it's suddenly a much easier sell to get enthusiasts and power-users to self-host matrix servers just to solve their own bridging needs and get a unified flow for disparate protocols.
As that grows, eventually there's a large spread-out flora of matrix servers that can become part of something larger.
I think if there's one thing that can make matrix succeed in it's mission, it's stable, feature-complete (or at least ticking the important boxes for the majority) bridges to mainstream services such as Facebook, Whatsapp, Signal, LINE, Skype, Google and Keybase.
I think this should be a focus for Matrix, and amazing it would be to have these be the fruit of voluntary contributors, some funding is likely required if it's to be sustainable as proprietary protocols and endpoints will inevitably break.
What's your take on that? I realize it's a long comment and I'm in a bit of a rush, but I'd be really curious to hear how you think about these things.
We're working on making bridges better integrated in Matrix to help with this use case - it's certainly a good way to drive uptake.
On the other hand, bridges are always an impedance mismatch - you have to keep up with new features on both side of the bridge, and the system you're bridging into doesn't always want to be bridged.
So, we think bridges are a key thing for Matrix (it's where the name comes from - matrixing together different comms platforms!) - but it'd be wrong to predicate the success of the protocol on bridges. They're useful, they have their place, but they're not the sole reason to use Matrix.
On feature-mismatch, I don't think it has to be that big of a deal - as long as
* delivering messages and file/image attachments work reliably in both directions
* stickers and other native attachments (location, audio clips, etc) can be received, not necessarily sent
, that's absolutely Good Enough for daily use for me and I imagine many others.
Reactions and sending of stickers etc optional, but if that's there, that's basically full parity of what anyone in the target audience mentioned above could expect. Actual parsing of non-plaintext data is obviously up to clients and should be approachable for the average casual contributor.
> the system you're bridging into doesn't always want to be bridged.
This should be the crucial and challenging part to maintain.
> This should be the crucial and challenging part to maintain.
More than that, some of the system explicitely _don't_ want to be bridged, because retaining users in their silos brings in more money than maintaining a window to the world outside the silo. It's tolerated at best today, but you can be sure that if a bridge ever get traction, the Whatsapps/Facebooks/Wechats will do what they can to block you.
Rather than betting on the bridges in the long term, I believe it's in your interest (as a Matrix user) to host a bridge to Whatsapp, and tell your Whatsapp friends that it kinda works but it's gonna fail at some point, so they better have a second account for the future. Install the account for them even, that removes some of the friction. But ultimately you have to realize that Whatsapp doesn't want to talk to Matrix (the situation is completely different for an open protocol of course, like IRC or XMPP)
I'm not Arathorn (and not even a Matrix user yet, barely ever on Signal too), but the problem with bridges to 3rd-parties is that you're effectively allowing these non-Matrix users to keep doing what they're doing, instead of incentivising them to switch. The walled gardens know this very well - that's why they've discontinued their XMPP gateways.
Matrix isn’t a company, it’s a non-profit foundation, expressly set up to protect its users: see https://matrix.org/foundation for details.
Riot is a Matrix client made by New Vector (https://vector.im), the company started by the team who originally created Matrix. The endgame there is to sell Matrix hosting (https://modular.im), support and other value-added services for Matrix. We are categorically not going to sell out our userbase - and we have no reason to; if we did, they’d just move to a different Matrix service provider.
I think a key difference here is fully open and collaborative specs, with Apache-licensed reference implementations for server and client that they dogfood themselves. It's also getting federated. So protocol, tech and network can live on regardless of who's running the servers people are using or driving the development of implementations.
Until one day the foundation decides federation is not in the best interest of the community, the standards and reference implementation start to reflect closely the interests of the leading player[s] with other implementations having to play catchup. It would have been a very cynical take if it wasn't business as usual in our industry.
That would be like the W3C declaring that interoperable hypertext is not in the best interest of the Web community. Or the Linux Foundation declaring that the Linux being open source is not in the best interest of the community.
It would be utterly sabotaging, and in the case of the Matrix Foundation, the Foundation is independently regulated by the UK Government as a Community Interest Company - and so anyone would be welcome to complain to the regulator (via https://www.gov.uk/government/organisations/office-of-the-re...) that the Foundation was breaking its charter, and the Directors would face fines and/or legal action.
This is why Matrix is in a fundamentally different situation to Keybase, or Zoom, or pretty much any other communication project out there, and why we spent so much time (and money) setting it up properly as a non-profit Foundation.
Matrix and Keybase have entirely different goals and functionalities. There's barely any feature overlap besides end-to-end encrypted messaging, but it's not like XMPP hasn't had that for years. I think it's silly to even compare the two
In other words, a fully open source (and open standardised) alternative continues to exist in the form of Matrix.
[disclaimer: project lead for Matrix]