In other words, a fully open source (and open standardised) alternative continues to exist in the form of Matrix.
[disclaimer: project lead for Matrix]
In other words, a fully open source (and open standardised) alternative continues to exist in the form of Matrix.
[disclaimer: project lead for Matrix]
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.
Thanks for your work!
Thanks to you and the team for all the hard work!
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 have a feeling you may be going off outdated impressions here; we've been desperately trying to improve UI/UX (as per https://blog.riot.im/e2e-encryption-by-default-cross-signing... and https://blog.riot.im/e2e-encryption-by-default-cross-signing...).
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...
And noted, in terms of the version number being in the wrong place on Riot/Web.
never used that /join command, the GUI works fine for me
(Congrats on the cross-signing release though, it's been a long time coming and it's been working really well!)
https://github.com/matrix-org/synapse/blob/master/docs/messa... has the details.
>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.
However I'm not aware of any client that opens conversations in different windows.
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.
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 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.
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.
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.
* 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.
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)
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.
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 is 100% Free Software and you can run a server yourself.