hckrnws
> Therefore to use Element X, you need to be running a homeserver with Sliding Sync support, which (for now) means running a sliding-sync proxy which bolts Sliding Sync support on to existing homeservers.
I am excited to try out Element X, but I do not want to administer yet another service, namely the Sliding Sync proxy. From a practical perspective, Sliding Sync (MSC3575) is still on the level of a proposal/experiment and I wish that we would be having this conversation about Element X after it becomes usable with any spec-compliant server.
Matrix evolves as a protocol by folks proposing new APIs (e.g. MSC3575), implementing them, showing that they work, and making the case that they should be merged into the main spec.
Sliding Sync is an interesting case in that it clearly does work, and it kicks ass - but it turns out to be unnecessarily complicated for the subset of features that you actually need when implementing something like Element X (which is my fault entirely, fwiw). However, should we hold off on putting it in people's hands while we sort that? Nope. Is it a pain to temporarily run a proxy shim service while the protocol stabilises? Yes. It's like running a SPDY or QUIC-aware reverse proxy in front of a webapp that only speaks HTTP/1.1 while waiting for SPDY to be ratified as HTTP/2. Sure, it's another moving part to look after, but the spectacular improvement is likely worth the pain. YMMV though :)
> Matrix evolves as a protocol by folks proposing new APIs (e.g. MSC3575), implementing them, showing that they work, and making the case that they should be merged into the main spec.
Yes, it is just unfortunate that it is not clear enough to more people (such as the_common_man below) that Sliding Sync is only at the MSC stage at the moment and not part of the Matrix spec.
I am glad that at least Element X allows this MSC to improve and for those nits you have mentioned to be resolved.
Sliding Sync is just your old bouncer with lip service and a fancy name, because the Matrix protocol is now officially deemed hopeless to be implemented efficiently on the client side, hence the need for a proxy to maintain your "client state" i.e. your client running on the server.
I'm really tired of the litany of buzzwords and excuses that the Matrix team comes up to cover-up this large sunk cost fallacy of a protocol. Nobody needs a distributed graph database and state resolution to prop-up a chat system. It has not proven to have any real-world benefit nor served to build a niche in which Matrix is in any way better than the competition. It's been a failed experiment for about 10 years with no end in sight. At what point does the community wake up to all the nonsense?
I 100% agree with this. I wanted to like Matrix, and I ran synapse for a while, but the operational aspects of it are an order of magnitude more complex than XMPP.
Perhaps the problem they're trying to solve warrants that complexity, but my particular use case doesn't. I just run XMPP now.
This comment makes no sense. The database replication has nothing to do with sliding sync. Sliding sync is about replacing the client to server protocol, and database replication is the server to server protocol.
Its flat wrong to say that it can't be efficiently implemented on the client side, the server side of the Api is the problem, not the client.
I just set it up. Wasn't that difficult:
1. Added a new postgres db and user 2. Added a new dns name 3. Added a new cert for the new dns name 4. Added a new vhost to nginx to proxy to a new port using the new dns name and cert 5. Added a simple docker-compose to my config 6. Added a snippet to my .well-known/matrix/client
Don't imagine it will take much maintenance. Container will be updated along with the rest of my containers, and the existence of the service doesn't change anything for any existing clients that don't support sliding sync.
The most important thing is to keep it updated, as we're fairly rapidly iterating on it, and most of the Element X bugs we've seen have actually turned out to be a stale Sliding Sync proxy deployment. Glad it was fairly straightforward.
Agree... i don't think there's a time i have "docker compose pull" and a new version hasn't come up.
The fact that this is independent of any server implementation (read Synapse) means you can release much more frequent.
Choosing to use a proxy here was the right decision.
FWIW, if you use matrix-docker-ansible-deploy, enabling the Sliding Sync proxy involves just adding one line to your configuration (for the most common setup).
https://github.com/spantaleev/matrix-docker-ansible-deploy/b...
Why is sliding sync a separate service and not just part of synapse itself?
Because the API is still evolving, and it's also useful that it supports other homeservers than Synapse. It's also written by an entirely different bunch of people (it's effectively written by the Dendrite team rather than the Synapse team).
Once the API is stable I'm sure all the homeservers will implement it natively. Until then, think of it like a reverse-proxy that lets an HTTP/1 webapp talk HTTP/2 to the outside world.
> it's effectively written by the Dendrite team rather than the Synapse team
I would then ask why it isn’t integrated into Dendrite
...because then Synapse wouldn't be able to use it?
I would guess it's so the same functionality can be used with other Matrix servers without having to rewrite the whole thing
It's currently still a proposal to the spec, and it is not yet part of the Matrix protocol.
Well you can just wait. But the proxy is really lightweight and doesn't require maintenance.
Until there's an incompatibility, upgrade, exposure, memory overflow, or some other security issue/exploit. Unless you're saying that it's immune to everything and will never experience a change or issue.
I'm pretty sure that all those issues will affect sliding sync whether or not it's integrated in Synapse. In fact, some people might actually prefer the fact they can operate it separately and restart/maintain it separately from their homeserver :)
> I'm pretty sure that all those issues will affect sliding sync whether or not it's integrated in Synapse.
Of course.
My argument isn't that it won't happen, it's exactly the opposite, that it will. My point is that, now you need to manage 2 things vs 1.
> In fact, some people might actually prefer the fact they can operate it separately and restart/maintain it separately from their homeserver :)
Of course. But it's misleading to say that it won't require maintenance (which is what I replied to).
I'm sorry. I don't really do maintenance on my synapse either (few users, no problems), so I should have figured that usually you do, and then also for the proxy.
Techy friend group of mine migrated from Discord to a self-hosted private Matrix server a few months back. No complaints so far, although we didn't use Discord's voice/video/screen-sharing features (which I hear that Matrix intends to support eventually).
UX-wise, it made me appreciate the distinction between Discord's "everyone is subscribed to every channel in a server by default" stance, and IRC/Matrix's opposite approach. The latter certainly scales better, but the former is so, so much better for discoverability, so it's probably the better default for small servers.
And if you're looking for a Matrix client with a Discord-like UI, try Cinny.
The plan on Discord-style voice/video/screensharing features is Element Call (https://call.element.io) which is built to be embeddable into Matrix clients. It’s already in Element X, and is in Element Web/Desktop behind a labs flag. Meanwhile you can always embed Jitsi.
As far as I'm able to tell most call functionality is built into the JS SDK (is this true), so what will embedding Element Call actually gain me? The (beautiful!) UI?
It will gain you:
* The ability to use the end-to-end encryption identity & verification from your normal Matrix account, by piggybacking on the 'host' matrix client. Whereas call.element.io is not remotely designed (at all) to work with your normal Matrix account, and doesn't have any of the E2EE UI hooked up, and instead relies on a shared secret to access E2EE rooms
* The ability to place VoIP calls inside existing Matrix rooms from your normal Matrix account.
* The ability to reliably background the app & lock the phone when on a call.
* The ability to receive inbound calls via push notifications and CallKit/ConnectionService - i.e. presenting the calls in the native dialer UI of the phone, and treating Element X like a VoIP dialer.
You get the same beautiful UI whether you use call.element.io directly or embed it inside another Matrix client like Element X :P
How did your friend convince your friend group to migrate over to Matrix? I’ve thought about setting up one but my group isn’t so much into the “do it yourself techies” or privacy conscious crowd.
As mentioned, this group is composed of techies who have an innate distrust of proprietary platforms, and the Reddit debacle (following so close on the heels of Twitter's ongoing debacles) was enough to tip the scales against continuing to operate the Discord. For groups of non-techies who care about convenience over all else, sadly I just think you're going to have to wait (or contribute yourself!) until Element/Matrix adds more UX polish.
That said, one thing that did help a lot was having the server host a default client. Anyone can still connect to the server using any client they want, but now they can also go to the server's URL and get a good client without any hassle. We chose Cinny as the default client because it's solid and extremely familiar to any Discord users.
The tech skill requirements are fairly low if someone hosts a homeserver everyone joins, or everyone joins a public.
It's quite disappointing that there's huge ongoing work around reinventing clients from scratch where the basic functionality of not ringing all my devices while I'm using only one of them [1] is still not there (bug open for years), despite it being a pretty simple fix.
The team rewriting Element as Element X is completely different to the folks who would need to make the change in Synapse to not send push to devices who are currently syncing. Agreed we should have fixed this years ago, especially as it's actually a feature in our pre-Matrix system back in 2012. There's basically a blindspot on long-lived missing serverside features like this; i've added it to a new hitlist we're experimenting with for trying to clear these up.
I offered a simple fix: delay notifications on all except the active client for 30 seconds, if a read reciept gets triggered from the active client then cancel the timer. I couldn't even get anyone in the team to even look at my solution 3 years ago.
Not sure why this feature keeps getting defered for "just about to land and things might be better after" server-side features (see how it has 7 out of 9 "dependencies" resolved) when none are needed.
I've had a couple of friend actually give up on matrix due to this. I also have to keep my phone on silent or else I can't be chatting on matrix without the constant bzzzing.
I'm also amused about the ever growing (currently at $760) bounty on this feature.
> I've had a couple of friend actually give up on matrix due to this.
I and several others have also given up and just stay with Signal and WhatsApp.
Well, that doesn't exactly inspire confidence in the project for me.
The project is a mess, which is obvious if one follows it. There is only slow progress. Instead of focusing everyone on one thing to do it right, they focus on multiple things that remain half-baked forever, e.g. multiple concurrent implementations like Synapse and Dendrite, Element and Hydrogen, Element and Element X, etc. pp. They seem to have organizational challenges, stemming from technical founders who didn’t know that it takes more than technical knowledge to build a great product. I believe they’ve learned somethings, e.g. that Element’s UI has always been crap hence Element X now, which they’ve denied for a long time. But they are surely still learning, e.g. how to be a focused and decisive leader, etc.
A project is always in large a reflection of the leaders. It’s the messy hackathon type project - not the clear and polished corporate project.
The reason historically for multiple concurrent implementations is because we're building a protocol, and multiple implementations dogfoods that - plus the different implementations service different segments. In practice, Hydrogen and Dendrite are currently deprioritised in favour of focusing on polishing Element X and Synapse. And Element Mobile is in security-maintenance mode only in favour of Element X.
Meanwhile, we massively fixed Element Mobile's UI a year ago: https://element.io/blog/an-unrecognisable-improvement-elemen... - and Element X is essentially the same UI... but on a different engine. So I'd argue that we were very aware that Element's UI was crap, which is why we fixed it. Rewriting the Element mobile apps as Element X is unquestionably the right thing to do in terms of sharing the same rust codebase between the two platforms and letting the app layer focus on UI.
Agreed that our progress has been slow, and our focus been has very broad at points. But we got there in the end, and certainly have learned from the journey (and built Matrix to be a much broader and successful heterogenous ecosystem as a result).
I'm sure your projects are all much more successful though - I'm jealous! :D
As a very longtime user, I can say that the progress has been noticeable to me, especially in the last year or two.
Having had a look at Element X (Android), it actually feels to me like that responsiveness is pretty much the last thing I was missing.
Oh, and the call bug already mentioned in the thread.
I'm really happy with Element and thankful for all the work you guys put into it.
>Element’s UI has always been crap
I use Element after switching from Google Hangouts/Chat/$LATEST_NAME$ a long time ago.
What, specifically, are you saying has always been crap about it?
Personally, I have no complaints about Element's UI. It works great IMO.
And I consider myself pretty hard to please and easy to irritate.
Actually, thinking about it now, the one thing I would prefer is if you could, in a 2-person room, have one participant's messages come up on the left while your own were on the right, or vice versa.
Then it would be more obvious who said what.
I like the honesty; oddly it has the opposite effect on me.
There are quite a few issues that they've stopped fixing in the Element app in favor of doing it in Element X, the one I've been following is where the iOS app causes a breakage in E2EE when you use the share extension, so they just disabled the share extension entirely and said they'd fix in X - https://github.com/vector-im/element-ios/issues/7618
But X requires Sliding Sync on the server, which is still a separate service to run alongside the homeserver and doesn't have a stable API. I am increasingly disappointed with how centralized Matrix is becoming, since AFAIK there isn't really an alternate client close to the same level of quality as Element.
I probably would've made all of the same decisions myself though, so I don't blame them I'm just a bit disappointed in how it's shaking out.
You just can't have the newest fancy client without also having the new fancy server. That seem to make sense to me.
Multiple accounts also https://github.com/vector-im/element-android/issues/26 and they closed the issue for it in the Element X https://github.com/vector-im/element-x-android/issues/190
A pretty basic functionality which even Messenger supports....
Is it really that simple though? Jabber tried to be smart about which device to ring, and sometimes someone ended up with a missed notification. I always felt gutting that complexity and ring all instead would have been the more robust way.
So you consider your phone vibrating loudly on your desk for every recieved message while you're actively chatting and reading the same message on your desktop a correct implementation?
Well slack doesn't even send me the messages to my desktop continuing to send to my phone (which continues to buzz) despite me writing on the desktop, just because I send a message on my phone 10min ago.
So it might not be that easy (if even slack with their funding can't get it right).
It's "good enough", especially if the alternative is my phone not vibrating when I get a message and I'm not at my desktop.
Yes, I don't want any clever tricks from my chat clients. I dislike this kind of under-the-hood magic. Client should just receive the message and send a notification if it's not silenced.
Well, it's not great, but could be a viable solution until a scheme is devised that is guaranteed not to lose any notifications, which would be worse.
What about P2P multicasting between devices? Delay for 1 second, if you get an "I did the beep for message hash X" notice in that time from a higher priority device that is currently being looked at, don't.
A bit of a privacy leak on shared networks revealing which IP is doing messaging, but it should be fast and reliable.
Just a question, I haven't been paying attention, but where is Matrix on resolving the Nebuchadnezzar vulnerabilities, and is the project still tracking towards switching to MLS instead of Olm/Megolm?
The main remaining Nebuchadnezzar issue is mitigating server-controlled group membership. The first step has been to kill off the 1st gen E2EE implementations, which were responsible for the implementation vulns found by RHUL - and we should hopefully conclude that next week by moving everything into the matrix-rust-sdk crypto crate implmentation: https://github.com/vector-im/element-web/issues/21972#issuec... is the tracker.
Then, we can address the harder server-controlled group membership issue in one place. First step will be to improve device verification & trust so that trust is the default, not the exception, to make it easier to spot and warn about unexpected devices in the room. The full solution is then either MSC3917 (https://github.com/matrix-org/matrix-spec-proposals/blob/fay...) - or potentially to switch everything to MLS.
We're working on MLS anyway in parallel to RHUL mitigation work; you can see the progress at https://arewemlsyet.com, and it's looking good.
I'm guessing you're not interested in doing a podcast on "yay we converged our crypto implementations on a single robust Rust implementation so we can fix the remaining bugs in one place", but as soon as the server-controlled group membership thing is solved we'll be in touch. Work has also gone much slower than hoped on this, thanks to the joys of funding open source.
INCORRECT. The messier your situation is, the better the podcast will be. You're still in my top 3 subjects for us to do an episode on. I'm rooting for you! But also for sound messaging cryptography. So I'm one of your most complicated supporters. :)
> Outside of Matrix 2.0 work, other big items on the horizon include:
- Adding Rust matrix-sdk-crypto to matrix-js-sdk, at which point all the official Matrix.org client SDKs will (at last!) be using the same stable performant E2EE implementation
- Continuing to contribute Matrix input to the MIMI working group in IETF for > Digital Markets Act interoperability
- Working on MLS for next-generation E2EE
IIRC, the rust matrix-sdk-crypto was their intended fix for the vulnerabilities.
I love matrix - I've been running a Synapse homeserver for over 2 years now for friends and family. We love it. Despite minor problems (upgrading postgres for example) it has been smooth sailing. I really want to stay up to date but they don't make it easy! I'd love to add sliding-sync to my existing docker stack, but I feel like I'm in way over my head!
I love the idea of matrix (synapse + element + mobile apps) and I have started moving my family there too but we had so many problems with notifications not being sent to the phone unless you actively open the app.
There is a huge discussion about that on git and some can't reproduce, some can't get a single notification even though the apps notification checkmarks were all green.
So it had a very very low WAF [1] and I scrapped it sadly. This was a few years ago, any signs of these problems still existing?
If any of those are android users, it may be down to the non-android standards friendly battery optimisation the manufacturer ship their devices with (e.g. Samsung, Huawei, OnePlus, Xiamoi, etc.)
I've had more issues with missing notifications on my OnePlus than I ever had on my Pixel (I have list of reasons why I'll never buy Google hardware again, mostly coming down to their support). Most issues get fixed by me persuading OnePlus to stop applying their secret sauce to power control
Not disagreeing you, just adding a point...I self-host Conduit and use FluffyChat on my phone, with ntfy for push notifications. While that works great most of the time, I occasionally have to restrict ntfy because it'll get into some state where it destroys my battery... And push notifications obviously don't work at all in that state.
It's very unfortunate there isn't a privacy-friendly push notification mechanism built into Android that doesn't ruin battery life. Or iOS for that matter; that might actually be a feature that would get me to switch.
Hmm… we haven’t had notification problems like that in many years, from memory. Any idea if this was trying to deliver push notifs to Android without using Google? (Which historically has been painful thanks to Android OS versions terminating the app in the bg).
Element X has totally rewritten notification code (given it’s moved from Kotlin to Rust) and should be much more robust for bugs like this.
Sorry you got bitten by it.
Communicating via Apple or Google is sadly required these days. How does that work with matrix? Does the protocol specify how to trigger those notifications? Do I need to register for a Google API key when setting up the server? I can't recall seeing anything about that in the configuration file.
https://thomask.sdf.org/blog/2016/12/11/riots-magical-push-n... is a great blog (back when Element was called Riot) explaining how it works :)
The gist of it seems to be that Synapse/Dendrite calls home to the Matrix Company, which in turn pays Google to send a notification. That's awfully nice of them, but does not really leave any room for success. I take it larger clients with security requirements roll their own clients, and this is part of the business case?
It’s more that “whoever built your client has the keys to send push to it, so your synapse calls home to them.” And yes, that means that paranoid types need their own clients, and that is indeed a service that Element offers.
Doesn't the use of ntfy change this (Android only, I think)? Homeserver pushes to an ntfy topic, app on phone is listening to that topic. Of course, this just moves the intermediary to ntfy but you can also host a different ntfy server which I hope element supports.
It does. I use ntfy with a ntfy server on one of my VPSs, and I use the official ntfy account on GMS as an intermediary.
It works fine, but I'll probably switch back to Matrix's push server at some point.
Edit: With Synapse + Element, obviously.
Thanks for sharing. Are you switching back because of pricing, or reliability issues?
Just to clarify that... I'm pretty sure the notification doesn't actually contain any of the message though, it's just a notification to check the server for new messages.
>Communicating via Apple or Google is sadly required these days.
The copy of Signal installed on my GrapheneOS Pixel (with no Google anything installed) begs to differ; notifications have been both low-latency and rock-solid.
So it absolutely _can_ be done, and done well.
Element supports UnifiedPush. My Prosody server forwards my notifications to me via the Cheogram app.
I had this problem 2 years ago and it ended getting fixed. Recently I seen it again and the problem was that my container running synapse did not have working DNS which caused all notifications to stop working. Once I fixed up resolv.conf all was working.
I am not suggesting that was your issue but it might help somebody.
You probably just need to change the settings to battery saver - no restrictions for Element. Your OS is probably killing the app aggressively (I've seen this with telegram a lot as well with many people).
> There is a huge discussion about that on git
Git doesn’t have discussions??
It might be difficult to switch at this point, but I highly recommend matrix-docker-ansible-deploy[0]. Enabling sliding-sync is one config entry.
[0] https://github.com/spantaleev/matrix-docker-ansible-deploy
Oh wow congrats to the entire team for this amazing achievement! And the cake under the cherry is… Element X is open-source as well[1][2]!
I really can't wait for Beeper[3] to rebuild their fork on top of Element X (it's currently based on Element, formerly called Riot). When this happens it will be an absolute game-changer for the messaging ecosystem.
————
[1] https://github.com/vector-im/element-x-ios
Beeper don't seem to like Sliding Sync, for whatever reason, so I wouldn't hold your breath on it ;)
From what I understand, the Beeper team has invested a lot of time and effort (and code!) into their own "make matrix go vroom" solution which also benefits their complex bridging system, and I imagine it would take some significant engineering time to unravel it for sliding sync.
Honestly what's the point given XMPP? Tried setting up Matrix, was a pain, went for ejabberd and it was a breeze. Gajim and c0nnecteasy work perfectly. Can't help but feel like if half the efforts of building Matrix went into XEPs or something we would have a rock solid IM alternative and clients by now. And tbf, can Matrix do group video calls? That's the only really useful feature missing from XMPP now, for which there's actually a XEP that recently went into a Deferred state, for a lack of participation/experiment. So, what's the point?
the original post has a full section about Matrix’s support for E2EE group video calls, which you can play with at https://call.element.io. This, and much more, is the point.
Dino the XMPP client can do group video calls.
I always get so confused by the naming between Matrix and Element. I get that Element is the client, but I honestly thought that the name Matrix for the server (or is it just the standard for the protocol?) was sunset.
Great service though and hope if gets UX improvements too, as Discord and Slack keep getting more clutter.
As much as I love the fact that I have my choice of server and client I have to say that it does make me wonder if it affects adoption. When the Mastodon growth spikes happened the complaint that I heard most often was from people that couldn't figure out which client to use or which instance to use. Too much choice tends to paralyze people and they default to proprietary services because they don't know what choices to make.
Maybe you are confused because the old client name, Riot, was sunset in favor of Element?
AIUI the protocol was and is called Matrix. There seems to be no intention to depart from that name.
They renamed Riot to Element in the wake of the George Floyd protests in the United States. It's the same code base.
Matrix is a protocol. Synapse is the primary server implementation of Matrix written in Python.
(We actually renamed Riot to Element because the nice people at Riot Games sent us a cease & desist :)
I still remember when that happened. I was really bummed because Riot is just such a fun name. Didn't help that that particular company was the reason.
I bet you were even more bummed though.
It's interesting seeing a myth build around your reasons for the name change already, with the blog post still up. Makes me wonder though how native speakers would have felt about the name after the protests.
I'm not a native speaker, so I don't feel the connotations of the name.
Here's their blog post at a time: https://element.io/blog/the-world-is-changing/?ref=itsfoss.c...
It's worth nothing that the conflict with Riot Games over trademark rights was also a motivating factor.
Element is to matrix what chrome is to http. The most used client for that protocol.
Element is the trading name of a company, of three clients with mostly-independent codebases written by that company (web, android, iOS; not counting the two Element X rewrites), and of a hosting service (EMS).
Yes New Vector Ltd
I just feel like the use of linear algebra terminology pollutes search results. Maybe they should have named it Passta/Meetball or some unique dumb name, and continued the naming scheme after satirical religions (Church of the Subgenius -> Slack, Discordianism -> Discord, Pastafarianism -> Meetball), like name the protocol Passta (maybe figure out a backronym for it), and the client software "Meetball".
The use of math terms is intentional.
Matrix = email. Element = Thunderbird, Outlook, etc.
The Matrix name has never budged since the beginning of the project. One of the Matrix servers is called Synapse. Others include Conduit or Dendrite (see https://matrix.org/ecosystem/servers/).
So yes, Matrix is the protocol, not the/a server.
Yeah. I still think that the Matrix.org Foundation should have a branded client, simply called “Matrix”, available in all the major app stores.
Lock it to the matrix.org server and offer membership in the foundation as an in-app purchase. Could help with some of their recent funding issues.
Growth in revenue-free end users might not be fantastic news for the Matrix team. As I understand it they make money from b2b integrations (eg French government) and supporting a horde of WhatsApp transplants is only ever going to be a net negative cost centre for them.
There aren’t exactly many so it’s a bit hard to generalise but free, large scale chat apps are the side projects of tech companies with existing revenue streams.
The fact that the group in control of the spec, the reference server, the most popular client, & the biggest server is the same entity is problem enough as it is for control/decentralization. Branding it top to bottom as Matrix would be the beginning of the end to me.
Matrix federation is inherently too centralized to my taste. You always rely on a server and a domain name. HN geeks can run their own server but still depend on ICANN down the line.
Username checks out :)
Do you think email should have a branded client, simply called "email" available in all the major app stores? Or XMPP have a branded client, simply called "XMPP" etc.?
Align on a protocol, experiment and compete with clients is a good way to make progress.
If email was a new thing trying to break into a crowded space, then yes.
Notice how WhatsApp took off while XMPP fragmented.
A matrix is made up of elements :)
Thoughts on how this will get us towards when libre software privacy&security type people are ready to advise friends to move to Matrix for personal communication?
(To be clear, the platform has to be all open source and open standards, actually decentralized, guided by those principles -- not an effectively proprietary play even if nominally open. For example, you should be able to get all the same functionality with Element, Fluffychat, Thunderbird, and other user agents, and with any home server, both now and on an ongoing basis. And the user agent implementation difficulty should become tractable enough, in terms of size&complexity and specification, that one person could write a new one -- not like Web browsers have become, where there's mainly only one, that company has been funding the runner-up, and that company can pretty much dictate 'standards'.)
Matrix 2.0 is a major step towards getting friends & family on Matrix.
Firstly, it's not introducing new features - it's just making the current featureset work super-efficiently (while retaining compatibility with today's Matrix). So there should be no fragmentation between Element/Fluffychat/Thunderbird, with the possible exception of the new scalable encrypted VoIP conferencing (but then very few Matrix clients implemented the old VoIP conferencing, plus you can always just embed an Element Call instance to get at it now - as Element X does today).
Secondly, we're explicitly working to protect Matrix from the commercial interests from Element (the company set up by the team who created Matrix, of which I'm ceo/cto as well as Matrix project lead). We already have The Matrix.org Foundation (https://matrix.org/foundation) as an independent non-profit to hold the Matrix IP and maintain its neutrality - but we also just hired Josh Simmons (former President of the OSI) as its independent Managing Director (https://matrix.org/blog/2023/09/introducing-josh-simmons-man...).
So: going forwards, the Foundation increasingly does not have to depend on Element not being evil, but instead has its own independent management to ensure the protocol exists to support everyone in the ecosystem, without fragmentation, as per the guiding principles at https://matrix.org/foundation - under its own autonomy.
I'd say this is is good news for libre software privacy & security type people, but then again I'm biased. Practically, the only thing getting in the way of getting friends & family on Matrix is that Element X requires fancy OIDC-native homeservers for registration, so newbies won't be able to use Element X to join Matrix yet. But the app itself should be an excellent way to get folks on board in the very near future.
element still has serious usability issues that need to be fixed before i can get friends or family on board.
the way threads are displayed in the browser versions makes them hard to follow. in our hackerspace, where many are tech minded people, i see regular complaints about that.
scrollback to unread messages often fails. i have never had another chat application where that was a problem. this should just work.
the handling of encryption keys is very confusing. there are to many moving parts, it's not clear what i must save so that i can restore the keys in a new client.
private rooms are also confusing. i want to have a private room be the name of my chat partner, and they want it to carry my name. being able to do that would be very helpful.
i am also missing the ability to use a different nickname in every room. different groups know me under different nicknames. discord and wechat can do it. it would be great if matrix/element could do that too.
Sounds like you’re talking about Element Web or Desktop here. On Mobile, we just rewrote the app as Element X and it addresses almost all your concerns (other than per-room nicks, although ironically Element Web does have that today - try the /roomname command).
Having got Element X out the door, my attention at least is going to swing back to Element Web. In terms of encryption disasters, we are about to switch Element Web’s crypto to the same rust implementation as Element X, hopefully next week - you can track the progress at https://github.com/vector-im/element-web/issues/21972#issuec.... Hopefully this will make a much-needed massive improvement on encryption, while also speeding it up 5x or so. On Element X, encryption failures are almost unheard of (other than when talking to Element Web).
Element X is great except for the lack of history, once that's added it'll change to my daily driver. I very often search my chat history and reference things going back months
Encryption in Matrix is a nightmare. I set up Synapse and pulled half a dozen or so people onto it. We have a few chat rooms. Randomly different users clients are unable to decrypt the messages of other users clients. You click some button about syncing encryption keys, and nothing happens. Then randomly a week later you can start reading each others messages again. shrug This has been going on for years now.
This alone makes Matrix the worse chat platform out there from a users perspective IMO. I invested too much effort in getting things up and running and using it now though, so I'm just hoping that this gets fixed one day, or something better comes along that I can migrate to.
Sorry. As per the sibling comment to yours, we made a decision on Element Web/Desktop to rip out the old encryption implementation and replace it with matrix-rust-sdk’s crypto implementation about a year ago, and while it’s due to land next week, it means that some folks have had a miserable time in the interim.
I'm curious and extremely skeptical as to how the UX is going to be made better regarding the terrible UX surrounding encryption. I used Matrix with a non-technical family member for about six months before giving up and going back to SMS because she frequently got messages about encryption that she was in no way equipped to deal with, and did not even begin to understand (yes, the "user-friendly" key fingerprint screen is one of those pain points) and I had to handhold her through the process, every time she got a new device or similar.
One time I had to manually export and import my own keys to be able to read old messages, which was a task that would have been too technical for most of the people I'd like to chat with, and was supremely annoying for me.
It's just a non-starter. I have a community I've been considering moving to Matrix for literal _years_ now and there are just so many sharp edges.
I've been confused about Matrix's priorities for a long, long time. I am not getting any less confused, to be honest.
Well, just as folks might be skeptical about Matrix clients ever being as performant as WhatsApp/iMessage/Telegram, and yet we eventually got there with Element X... I'm expecting a similar outcome with E2EE UX.
The high level plan is:
* Fix all the bugs which cause random undecryptable messages, which was the main thing causing frustration. This is (hopefully) done now by converging on the new Rust implementation.
* Generate a recovery key, rather than confuse the user by asking them to pick two passwords (one for their account, one for their encryption). Impress on the user that if they ever want to recover their history, they'll need it. Expect that most users will lose it.
* When logging in on a new device, scan a QR code on an existing device to transfer over the keys (and thus history). Users are used to this now thanks to WhatsApp and Discord, and empirically they can do it fine. The recovery key is used only as a worst-case scenario if the user has no other devices. The act of logging in (either via scanning another device, or via recovery key) signs that device as owned by you.
* Only accept messages from devices that a given user has signed (i.e. trust on first use for users). If you want to verify that user out of band, they get an green tick too, purely to help you keep track of which users you're sure are legit and which users you've assumed are legit.
* At any given point, encryption is either enabled on your device (i.e. you've signed that device; it can access your encrypted message history; it can store keys for your encrypted message history) or it's not (and you can't do any E2EE). There are no halfway states.
This may sound simple and obvious when written out like this, but each point is a major change from the supremely confusing system we have today. The thing stopping us from having implemented it sooner is the huge amount of effort which went into reimplementing the engine in Rust. But having now (almost) finished that project, next thing up is fixing the UX, at last. The rough timeline is hopefully end-of-year, but, again, timings are contingent on funding pressure.
that sounds promising. looking forward to it.
so one hand says they are making things better for friends and family, and the other is ripping out things to make peoples lives miserable? and then letting them float in that misery for some period of time?
A lot of the problems were caused by the legacy crypto implementations. The misery is not caused by ripping them out and replacing them with matrix-rust-sdk crypto, but by it (unavoidably) taking a while.
Thank you for the comments. I'll keep my fingers crossed that this plays out well.
> plus you can always just embed an Element Call instance
That sounds like potentially a commercial embrace&extend&extinguish situation, which we need to avoid.
Yup, good call point, which is why we deliberately implemented two different independent group VoIP implementations - the one in Element Call (based on matrix-js-sdk) and the one in Hydrogen (based on hydrogen-web-sdk).
Admittedly the new livekit-based implementation takes us back down to a single implementation for now, but in its defense it’s only a few weeks old (with e2ee). Hopefully others will spin up independent implementations rapidly - although right now it does introduce a potential commercial EEE situation… but from on LiveKit rather than Element.
Eitherway, it’s something we’re painfully aware of… while also trying to ensure we find enough $ to pay for dev on Matrix (and Element) otherwise the whole thing collapses.
One of the big problems as I see it is that all notifications on iOS must be proxied via APNS and those can only be sent by the app publisher, so all home servers must send their iOS notifications to Vector (the Element publishers) to be sent to APNS and on to an iPhone or iPad.
This is a centralized point for surveillance of metadata. I also do not know how much information is actually contained in the notification itself. In any case Vector has knowledge of every home server with an iOS client, and their approximate traffic levels.
Then everyone should just roll out their own app… this seems like an EU-regulation-needed situation.
This requires paying about $10/month to Apple and doxxing yourself with a lot of PII.
It also requires that you as a homeserver sysadmin a) have a Mac, b) install Xcode, c) know how to modify and compile iOS applications, d) want to deal with rebuilding and reuploading and re-seeking app approval on major API changes because long-un-updated apps are not allowed in the App Store, etc...
Security, Convenience, and Speed will always be in constant tension.
If you start by assuming that a perfect solution will always be unattainable, deciding on what tradeoffs are acceptable becomes easier.
Imho it almost always going to be worth trading the large PITA of self-managing APNS infra for the small surface area that routing push notifications through Elements systems.
This comment makes it seem like Apple's anticompetitive stance on sideloading is a basic force of nature instead of something dreamed up by control freak hippies and implemented deliberately in code.
The problem is iOS's privacy-hostile design (in service of their locked down revenue model), not some unbreakable iron triangle.
On Android, messaging apps can run in the background and periodically talk to their homeserver without an intermediary.
Agree 100% about Apple being anti-consumer, but the Android thing is not quite that simple.
Background tasks on Android can pretty much be killed at any time. I believe only apps with a persistent notification and the native google notification service can remain active at all times. But yes, they can connect to any server while they are running.
> Imho it almost always going to be worth trading the large PITA of self-managing APNS infra for the small surface area that routing push notifications through Elements systems.
Once you're going to push encrypted data through a centralized service, you might as well just run Signal and skip running the homeserver too.
Push in Matrix doesn’t contain data; it’s just a wakeup to tell the client to sync a given room & message id.
FWIW my partner and mother are using it. We have had the occasional key synchronization issue with Element but has been mostly smooth sailing. I did walk them both through the setup but they probably could have managed. However they have some basic tech skills. I suspect that others in my family with little tech literacy would need to have it set up for them but would probably be fine after that.
Comment was deleted :(
> Rather than exposing a kitchen sink of features and settings, we’re keeping Element X truly focused: doing one job and absolutely nailing it - all while harnessing the power of Matrix for secure, interoperable, open-standard communication.
does this mean the Element X is more for the mainstream user and regular Element is better suited for power users?
Element X also is geared up for powerusers (e.g. as project lead, I consider myself a poweruser) and i've been absolutely loving it as my daily driver for the last few months on mobile. For instance, my account is in around 4,000 chatrooms, and Element iOS was taking ~10s to launch and sync, and could easily take minutes to sync in the morning (heaven forbid the app was offline for more than overnight). Meanwhile, Element X launches in around 100ms, no matter how long it's been offline, and syncs in around a second.
The model that we're going for is similar to iOS or macOS: something which is incredibly simple for normal users, but can also scale up seamlessly for crazy powerusers.
In terms of specific poweruser features: I suspect the strategy will be to see if we can provide the same end result without actually adding the feature - and failing that, add the feature very strategically via progressive disclosure... or perhaps not at all, and rely on other Matrix apps to pick it up.
The intention is to fairly rapidly replace regular Element on mobile with Element X, eitherway.
I'm really glad you're aware and trying to get in control of the UX paper cuts that sum up quickly.
Telegram has been adding a ton of features during the last 5 years, all while keeping the core experience pretty much the same (fast and seamless). Whatsapp is also doing this.
With some UX Design chops, you should be able to do it.
Yup, we're doing our best to nail it this time - and there's a lot of UX design chops involved. Hopefully the Ignition release of Element X shows that we've headed in the right direction at last :)
Ok, I understand... one last thing I ask every year - custom emojis when? :)
And thank you for your the hard work!
But we just entirely rewrote both mobile clients to get out of having to implement custom emojis! :D Joking aside, it's easily one of the biggest features missing from Element/Element X, and I for one can't wait for it to land. Unfortunately we also don't have any paying Element customers asking for it, though, which is why it keeps getting deprioritised in favour of other stuff.
How Matrix decentralisation is an improvement over Jabber's decentralisation?
(disclaimer: I have no knowledge about neither spec, I'm not suggesting Jabber was better)
It's more that Matrix is different to Jabber/XMPP.
In Matrix, your chatrooms synchronise chat history between servers (rather than passing messages around), and that history is replicated equally over the participating servers, a bit like Git.
In XMPP, you pass messages between clients on different servers using a given server as a hub, and clients can choose to back up their message history on their local server.
Which architecture you prefer probably depends on whether you think instant messaging should be about passing messages or archiving chat history.
> In Matrix, your chatrooms synchronise chat history between servers (rather than passing messages around), and that history is replicated equally over the participating servers, a bit like Git.
XMPP had FMUC (Federated Multi-User Chats) about 5 years before Matrix was even invented. It didn't see broader adoption in the XMPP world because the community figured that this isn't a problem worth solving, and/or that the incurred complexity isn't worth it.
And worse, Matrix even hasn't found an adequate and scalable solution for this "proud" ambition (and probably never will). I don't expect that you could demonstrate in good faith that distributed state and its resolution are a net positive for Matrix, its community, its ecosystem, nor that it has opened new possibilities for the practical cases and users. We are back from the blockchain hype/hangover already, and I can't wait for the same thing to happen to Matrix: this was the wrong tool for the job. Just let it go.
Jabber core protocol (XMPP) is kinda like SMTP. It deals with transmission of messages between two peers. Just like with SMTP, you can federate servers, so they can exchange messages between each other.
And the similarities don't end here. XMPP doesn't have built-in support for encryption (apart from the basic TLS encryption for the transport layer), it doesn't have support for message archiving and chat history syncing, there is no support for group chats, and so on.
A lot of this functionality is added as extensions (e.g. group chats are XEP-045), but this simply caused a lot of fragmentation in the ecosystem. So you could never rely on your client (or server) interoperating with other clients properly.
Audio calls and video also never really worked well. Google tried to push them by releasing libjingle in 2006 (!!!) but it was kinda ignored by everyone.
Most of criticism of XMPP with regards to fragmentation and extensions can be applied to Matrix as well. In fact, the sliding sync itself already fragments the ecosystem by not being supported out of the box by many server implementations and therefore homeservers. Encryption often has to be enabled with some machinations as well if we're talking about clients other than Element (and electron-based).
On the other hand, XMPP desktop clients certainly work better and faster than Element, although some of them look quite old, which doesn't take away from their functionality.
IMO it's being heavily overstated how Matrix is better than XMPP.
Also a nice read: https://telegra.ph/why-not-matrix-08-07
And the answer https://lobste.rs/s/wvi9xw/why_not_matrix#c_erbsnb
This criticism kinda misses the point. E2EE, especially for group chats, is _the_ reason to use Matrix. It's an extremely hard problem, and you'll basically need to replicate what Matrix does if you want to solve it.
Doubly so when you add federation.
It required more than one iteration of Matrix to get it right, which I (personally) totally expected to happen. I don't think XMPP will _ever_ get it right.
Regarding clients, I don't think Element is worse than most (all?) XMPP clients when you look at the functionality past simple 1-to-1 messaging. And forget about mobile apps, XMPP just sucks on mobile.
> E2EE, especially for group chats, is _the_ reason to use Matrix. It's an extremely hard problem, and you'll basically need to replicate what Matrix does if you want to solve it.
I would be inclined to call this FUD. XMPP had E2EE before Signal and Matrix even were released. Current XMPP uses a flavour of double ratchet encryption (OMEMO) that puts it in par with those two, while working on MLS (just like Matrix).
> And forget about mobile apps, XMPP just sucks on mobile.
And yet, Conversations uses a fraction of the energy and resources Element requires. And does audio/video calls more reliably. And works well for 1:1 to large chat groups with thousands of participants.
I am actively using E2EE in matrix group chats daily. It is absolutely horrible. Matrix has not gotten it right.
It is a typical situation to observe "Failed to decrypt message" across the whole chat history. It is typical to observe reordering or even lack of messages, which make reading the chat unbearable. It is typical to have problems with session validation.
On one account I have even lost the validated status of another member's sessions, even though we have validated each other before and the only thing that changed is that they logged in with a different client. Since we live in different countries far away from each other, we just have to look at the red shield every time we open the chat and keep in mind that it's not a MITM but just a Matrix failure.
> XMPP just sucks on mobile
So does Element. I have <10 chats joined, and every time I open the Element app I have to wait for 10+ secs before I can start reading new messages. This will surely be fixed by sliding sync, but it's a problem of its own.
Could you elaborate on how XMPP sucks on mobile for you? I mostly use it on mobile
IIUC Jabber never really had decentralized group chats? It had MUC but these were federated, so if the server hosting the room went down the chat also died.
Matrix rooms are fully decentralized and can survive any servers failing.
(Although note that not much else in the protocol is decentralized, much of it is only federated.)
> IIUC Jabber never really had decentralized group chats?
Jaber had something like that 5 years before Matrix: https://xmpp.org/extensions/xep-0289.html but decided it wasn't an avenue worth pursuing, as a non-issue in practice. This is further proven by WhatsApp (which is based on XMPP/ejabberd) and its billion active users: you don't have to shove this complexity into the protocol level when it runs natively on a distributed/federated infrastructure (the erlang VM in this case).
> Matrix rooms are fully decentralized and can survive any servers failing.
In practice the room survives in a "split brain" mode where different users see different participants, the room isn't available to the users whose instance went dark as its no longer hosting their identity, and messages are popping mid history while the state resolution is working hard to reach consensus. When the servers finally come back online, there is a risk of never catching up fully, or worse, for the rooms to remain split forever.
And I adventure a hot take there: this property of staying seemingly online (in a frankenbizarre way) came handy way fewer times in the history of Matrix than for all the incurred complexity reflected in daily bugs, privacy, security, performance issues and inconsistencies.
> but decided it wasn't an avenue worth pursuing
To add some colour - there are commercial implementations of that (e.g. https://www.isode.com/whitepapers/federated-muc.html ). But from my perspective as a server developer, I've seen minimal interest in this for the public network. Probably because server failures are rare enough events in the general case.
That's not to say there aren't use cases where it is more valuable to have this functionality.
> you don't have to shove this complexity into the protocol level when it runs natively on a distributed/federated infrastructure
But I don't want to trust my community to someone providing me infrastructure. Lots of projects, communities or whatever start small on third-party hosting. Many open source projects right now have rooms on gitter.im or matrix.org. I don't think they made a "bad" choice and I don't think they should need to scramble to find new rooms if their provider goes offline.
> In practice the room survives in a "split brain" mode where different users see different participants
Even if this is true (I haven't see it when servers go offline) this sounds like a bug that can be improved over time. Not a reason to give up.
But also do you have any evidence of this? Matrix rooms don't have a "home server" so if this was a bug that occurred it would occur for any member of a chat going temporarily offline, and for large chats that happens often. So it seems like if this is an issue it only happens in very niche circumstances.
> isn't available to the users whose instance went dark as its no longer hosting their identity
This is true, as I said users are federated and suffer if their homeserver goes down. But it is a huge difference to be able to set up a second account on a second server and continue participating rather than needing to convince a large group of people to switch to a different room.
Look at freenode for example. It was fairly organized as far as shifting a massive group of communities goes but still quite messy. In the matrix scenario rooms could have moved by simply adding new admin accounts on different homeservers and kicking or demoting all admin accounts on freenode. The users wouldn't have to do anything (except moving away from freenode accounts if they prefer).
>> you don't have to shove this complexity into the protocol level when it runs natively on a distributed/federated infrastructure
> But I don't want to trust my community to someone providing me infrastructure.
I mean, that's always the case in the end, isn't it? Your identity is tied to your server, and that's pretty much what defines the whole thing as being a federation and not P2P (that applies equally for XMPP as for Matrix). As long as migrating from provider to provider is easy and convenient (which amounts to acknowledging that all providers eventually come and go, what centralized service users are in denial about), I don't see it as being a fundamental issue.
It's also easier to mitigate this aspect in XMPP-world where being your own provider is orders of magnitude easier and cheaper compared to running a matrix homeserver and federating at scale.
Also, talking about infrastructure, the situation is quite worrisome in the case of Matrix, I'd say: only one entity is competent enough (or has enough cash committed) to running large-scale: new vector. And it runs that of matrix.org, kde.org, fedora.org, mozilla.org, …. It also happens to be the one specifying and implementing the (incompletely documented) protocol, conveniently.
>> In practice the room survives in a "split brain" mode where different users see different participants
> Even if this is true (I haven't see it when servers go offline) this sounds like a bug that can be improved over time. Not a reason to give up.
It's a very very hard problem to crack. They've been at it for 10 years across many iterations of the protocol: https://telegra.ph/why-not-matrix-08-07 . I like to think that it can be solved the same way I want to have closure about P=NP, but I also challenge that this is a meaningful and practical approach in this context.
> This is true, as I said users are federated and suffer if their homeserver goes down. But it is a huge difference to be able to set up a second account on a second server and continue participating rather than needing to convince a large group of people to switch to a different room.
Yup, and that's all pretty and neat in theory. In practice it happens every so often that rooms just break for inexplicable reasons, and that people must migrate anyway. Not all members do, because for some, everything still looks like business as usual (happened again few months ago with the 3D Printing space), and trust me, this is much more eventful and disruptive than freenode committing seppuku once every quarter century, or with large XMPP networks going under.
This is an amazing step in the right direction. I host a small conduit server for a friend group and I can't wait for the improvements this will bring as a whole!
Good work.
There's no web version of element X though? It's what I use most of the time. I'll try the Android app anyway, I've been having a really annoying bug with the normal one anyway that hasn't been fixed for a year. So perhaps X doesn't have it.
Element X works pretty well on macOS as a desktop client if you have an Apple Silicon Mac. Otherwise, the big Element Web rework is yet to happen.
On Android, I can almost guarantee your bug will be fixed: Element X Android doesn’t share any code with Element Android at all, as far as I know (given the former is mainly written in Rust, and the latter is all Kotlin)
This is the second time you've rewritten the Android app with Riot -> RiotX/Element -> ElementX. Just wondering why you throw it away rather than improve it, and if you're at risk of replacing one set of bugs with another?
Probably from too many mistakes and/or new maintainer and/or better ways to do it. Same as it ever was.
The reason for Riot->RiotX (aka Element) on Android was to both move to a modern Android UI idiom, move to Kotlin, and have a well defined storage interface and switch to Rx patterns, whereas the original app had been built somewhat organically. And yes, the maintainer had changed.
The reason for Element -> Element X is in order to share precisely the same Rust SDK between iOS and Android (and maybe other platforms in future), so all the heavylifting happens in one single audited codebase, rather than doubling up all the development between iOS and Android, doubling the bug count, etc. It’s also a good opportunity to simplify the data flows, which are surprisingly subtle and performant in a messaging app; I’m not sure how much Rx remains. In this instance, the maintaining team remained the same.
Unfortunately it won't connect. I have a home server that I connect to through VPN (not reachable online and with a self signed certificate). The old element asked me to allow the self signed CA but element X says it can't connect. I wonder if this is by design?
Getting a let's encrypt cert is very difficult because my server can't get reached from the public internet. I have it that way because I use this one only for bridging and I'd like to keep it safe.
Right, we haven’t done TLS cert pinning or TOFU yet. Filed as https://github.com/vector-im/element-meta/issues/2073
Thanks! I wouldn't have found that myself. I'll keep an eye on that ticket.
Ah ok no I don't have a Mac, I use FreeBSD :)
And thanks I'll try that out!! I really hope it fixes that sync bug. Thanks for all your work on it. It's a great platform.
Yes, I was also surprised that the new features are only for phones. I guess aiming to be "better" than other chat apps (with the others nowadays being Whatsapp and co) means to be "mobile first"... sigh
I'm curious if someone could build a discord replacement on top of matrix, most importantly with voice chat and video streaming functionality. Discord is clearly focused on monetization at this point, the only changes happening now are ones that make your experience objectively worse. I've also been on Linux for a few years now and discord still doesn't support streaming game audio.
And before someone suggests it, I tried Revolt, and it's not there yet. The latest client (as of a few months ago) couldn't find my audio devices at all, and came with a big warning about how their audio backend was being completely rewritten, and what I was using was now legacy.
Absolutely. Element is already quite close to that, and once Element Call and native Matrix group VoIP matures more, hopefully it'll be even easier to converge on Discord's featureset.
I wrote a summary of the post: https://twitter.com/infogulch/status/1704933396508553385
Is Matrix simple enough now that I can invite my grandpa/grandma and they will be able to join?
How does ease up sign up and use compare to discord?
Assume that I make the choice of which client to direct them to.
Matrix itself is a protocol, so is as hard or easy to use as the client that you use to access it.
Matrix 2.0 is all about demonstrating that a really really fast, mainstream-grade app can be built on Matrix, in the form of Element X: https://element.io/blog/element-x-ignition/. However, right now Element X is intended for existing Matrix users - so unless you have a bleeding edge homeserver, sign-up doesn't work yet. So it's not quite in grandma/grandpa territory yet... but once you're in, it most certainly is.
It may not be easier than other proprietary stuff, but it is easy enough and probably the easiest you can get from the free software side.
Just install Element on iPhone or Android and make a matrix account from there, then add each other by the selected username.
You will only have to help your grandpa when you start to add secondary devices that need to be authenticated the first time with a QR code (for decryption purposes).
I have been using Element to text my wife for around 6 months (Android to iOS). I took the opportunity when she was getting notification issues with a proprietary app to convince her to use it. She loves it now. Clean interface, no ads, and voice call works just fine for us.
It is less simple than discord and I does not have good audio rooms. I setup family accounts and store their security key for them. Then I help them setup their app in a few minutes and paste them their security key once they are on my matrix server.
In the past I left sign up and setup to family and the element app and it has never worked smoothly. They don't understand the security key purpose or verifying clients.
So to answer your first question, yeah you can invite grandma and grandpa but they probably will need some hand holding at the start. Once they are in, it just works™**. YMMV
My octogenarian mother uses it.
Did she set it up herself?
No, but that's true of all the software she uses.
my biggest struggle with matrix, is that, at least in element-ios, messages keep transpositioning, i.e. at some random time a message that is 2 days old is pushed all the way down to the new messages. also the aop frequently crashes with some media.
but apart from that I of course love the idea of an „SMTP approach“ to instant messaging :)
this is literally why we rewrote element-ios in rust, in the form of Element X iOS :) https://element.io/labs/element-x
Why not fix the issues with the current implementation as well as rewriting it?
time and money?
oh that‘s so cool. will give it a try now! :) really looking forward to the search feature btw hehe.
Synapse already eats up lots of space, adding sliding sync will boost it up and will be difficult to self-host it.
Yup, it's true that sliding sync proxy increases disk space further, although it's not so bad. A big advantage once it's stable and merged into a native homeserver will be reducing the storage duplication between the proxy and the HS.
Meanwhile, we really need to get https://github.com/matrix-org/rust-synapse-compress-state/pu... hooked up in Synapse so that it automatically compresses state; I don't know why this never landed when it was written in in 2021 :(
I just went through a HUGE pain in the ass with my homeserver. I was on the Hetzner cloud plan and at the highest storage tier already. I had about 80 GB free, and setup sliding sync. It filled up the remaining space (unbeknownst to me) and my homeserver stopped working. Fortunately I was still able to login, but no disk space was available for the Postgres vacuum. I wound up having to rsync everything over to my desktop, setting up Docker on my desktop, running the compression tools on my desktop, and re-uploading. I now have a 20GB dummy file on that server.
Running out of disk space (or inodes!) is probably how everyone running a server learns about monitoring and alerts
Do they also plan to ditch the desktop Electron version for the users to enjoy similar performance improvements?
Element X actually runs really well on macOS already on Apple Silicon; I regularly use it as my desktop app whenever Element Web is having... issues. It would be amazing to plonk matrix-rust-sdk into Element Web and switch Electron for Tauri or something... but one thing at a time.
It would be nice to provide first class support for state of the art web clients (both desktop and mobile). That would fit your opening stance of "Matrix has been going for over 9 years now, providing an open standard for secure, decentralised communication for the open Web" more than apps tied to the iOS/Android app ecosystems.
I’ve wondered about this for a long time: Why not Flutter? Should give you one codebase for all platforms, while being significantly faster than webtech-based solutions.
I guess we just prefer to use the platform’s native UI (SwiftUI/UIKit, Jetpack Compose, HTML) on each respective platform, rather than an abstraction like Flutter. All the heavy lifting is done by matrix-rust-sdk now anyway.
As someone who works for a company thats developed their own end to end conferencing stack (utilizing webrtc stack on the client side and all custom conference servers and sfu on the backend), what would be the benefits of adding Matrix support and how exactly would that be done (at a high level)? What would the benefits to users be? Trying to understand what all the hype is about here, and whether or not this would be a venture to pursue and what the business justification would be.
Using Matrix would mean:
* You get best practice audited (in the near future) end-to-end encryption
* You get decentralisation if your users want to host the stack themselves
* You get bridges to other systems (although not many FOSS voip bridges for Matrix exist today, admittedly)
* Similarly, you get an open standard API on which you and others can write bots/apps and other extensions to add new functionality, and benefit from the wider ecosystem
* You get some preexisting clients like Element Call to build on.
Well, we dont want e2ee because then we cant decode audio and transcribe, or record meetings. All of which are high demand user requirements. We dont want decentralisation either for the same reason. We dont interop with other video conference systems other than asterisk for dial in/out. And the ones that we might consider doing that for dont support matrix either. We want a fully integrated system for our users so i dont see external clients being a thing. An open standard api is a plus but in my experience there's always something they fall short on requiring something custom. This is why i find it difficult to see where matrix could improve anything for us. Trying to find some benefit but I really don't think there is one other than maybe marketing and saying we play nice with open source or open standards.
Looks like there's an open protocol and an open source client implementation for video calls. https://github.com/vector-im/element-call
This is great! Jitsi has never clicked for me. I tried it a few times, and read about it, and was never excited about it. I just tried Element Call, albeit an empty room, and the UI feels right.
Comment was deleted :(
Awesome! I've been using matrix on and off for around 3 years and I absolutely love it.
exciting to hear! I only wish i had more time to contribute.
Has there been any movement on migrating away from long polling (#475)? I didn't see anything about it in the announcements or comments despite such a big milestone
Low Bandwidth Matrix is the answer to that, and it’s currently on hold unless it gets funded: https://matrix.org/blog/2021/06/10/low-bandwidth-matrix-an-i...
It might also get changed as part of Sliding Sync refinement.
Hopefully it will be the default once implemented. Everyone will benefit from compact protocol in the long run. Should have been done from the very beginning.
Is there going to be a way to have very simple clients, perhaps with a helper in the server side?
It'd be nice to bring matrix to microcontrollers and "retro" computer platforms.
the API already is super simple, and low bandwidth could already work on retro machines (I had 6809 in mind when experimenting with it). The problem is e2ee, but we have the Pantalaimon e2ee proxy to convert unencrypted Matrix traffic into E2EE traffic for precisely this sort of thing :)
That's promising :)
I had 68000, 8086/88 and 6502 in mind.
Being a user of E2EE video chat tools and calling apps, - I've been following this, especially more closely ever since Jitsi disabled anonymous video calling on thier main instance /Jitsi Meet
(Yes, there is a the Jitsi Meet Community Instances that are still with the original full functionality that people can access- If they search for Jitsi alternative community instances on a search engine, which isn't something most will be aware of for your average user...)
Having been a user of the Jitsi Meet Electron App even on Linux and Windows(along with the web accessible variant)- and having followed closely the efforts by Firefox on RTCRtpScriptTransform (formerly webrtc insertable streams) mainly to support Jitsi E2EE calls- has been interesting to watch.
Though now with the new Google/Meta/Microsoft account requirement/non anonymous aspect, all of that minus the community instances web interface sites are of use to me now.
If i follow fully, Element Call in a way replaces Jitsi Meet's original capability- though E2EE encryption doesn't have to be "Turned On " in a Chromium based browser - and Element Call isn't yet something that can be launched from a desktop app on Windows or Linux in a similar user-friendly way (I see the Vector IM client is a thing)
- The main difference being for using Element/Element X, one new from the Jitsi Meet ecosystem /usecases i've mentioned, will have to make an account- and for your average user who cannot easily learn about and deploy a server and how to host that on their own- but is looking for privacy- it is trickier to judge and will be more steps , to achieve anonymity from a privacy perspective.
I see the P2P effort is another step towards this as well
I'll likely try to use Element Call and point those I know who use tools like this towards it due to Jitsi's recent changes - as Element Call's web interface is user-friendly enough, and that is the main challenge. What Element is outside of that- and how it integrates into everything and how to use it in the same way in it's other forms- will be interesting to introduce, as those are developed further.
Comment was deleted :(
Does anyone use Matrix/Element for a serious workplace, instead of something like Slack?
I work at a 25 person startup and we've been using Element as our main chat platform for the past 6 months (paid hosting), however we're now in the process of migrating away. I really wanted to like it because it supports good encryption and is open source, but unfortunately it's just too buggy. The main pain points are:
- Stuck notifications [1]
- Being unable to decrypt messages (from certain users sending from certain devices; some people can read them, others can't)
- No proper notifications for old threads
- Various GUI instability bugs: chats that are suddenly empty, text suddenly randomly overlaid on other text, randomly missing scroll bars, etc.
We use Matrix (mostly via Element) at Mozilla alongside Slack. It's mainly public stuff on Matrix, and the usage pattern varies between teams: some teams are mainly Slack and barely pay attention to Matrix rooms, other teams (like mine) kick and scream if they're forced to use Slack for anything but internal corporate purposes. New hires in such teams tend to assume Slack initially and gradually notice that they get very slow responses on Slack, and then switch mainly over to Matrix to talk to the rest of us.
It's been good to us. Note that our primary comparison point is IRC, not Slack, mainly because of our project roots of openness and widely distributed contributors. So it's a serious workplace, but an atypical one. Encryption has periodically caused problems. Leaving the company and maintaining access to your communication seems to be a bit painful. Search is not great. Threads are tolerable. Inviting outside people in works well. Abuse is vastly more manageable than it was on IRC. Performance is mostly good. Both Element Web and Element on Android are very usable. Notifications are a little wonky, but I don't rely on them much so I can't really gauge whether they're good enough if you do.
> Abuse is vastly more manageable than it was on IRC.
You're comparing a Matrix server operated by someone else (Element) with an IRC network that Mozilla operated themselves. How does your Matrix setup compare to an IRC network operated by a dedicated team like Libera.Chat or OFTC?
Comment was deleted :(
Does anyone know how to integrate chats into a web app using Matrix. Rather than writing a messaging web app from scratch, can I hook into matrix?
That's a use-case where XMPP shines, historically. There are embeddable/lightweight clients doing that job well without all the matrix fuss.
https://github.com/vector-im/hydrogen-web/blob/master/doc/SD... is the best option currently.
You could use the matrix-js-sdk or matrix-rust-sdk if you want to deal with wasm
Once more, Kudos to Arathorn/Matthew (the head of Matrix/Element) taking the time to answer most Hacker News comments, as he mostly does for all Matrix-related HN threads.
It's really nice to see him answer in a calm and mostly objective tone while people are blaming him for shortcomings and problems of all the different Matrix-related software projects. Admitting to failures and problems that Matrix definitely has, while still defending the overall project and giving insight into the status of MSCs/projects is admirable.
Thank you Matthew. I wish you an endless amount of patience for the future.
thanks :) sorry for monopolising the thread, but it's too tempting when I have the answers to hand, for better or worse...
Looking forward to your talk tomorrow in Berlin.
if I get there; my flight just got cancelled…
Which talk? Is there a link?
This one: https://summit2023.matrixmeetup.de/conference/talk/AXGMEA/
Don’t think there’s a live stream. But there might be a recording afterwards.
There should be a live stream. (And I might even make it there in time to give the talk).
The livestream/recording ended up at https://youtu.be/3DhyZZjyn9c for anyone following this mini adventure :)
Comment was deleted :(
Matrix is great but when is the tech industry going to deal with the fact that many, if not all, bridges are against the respective services' ToS and subsequently put the developers of those bridges under legal risk? Whatsapp has already sent legal threats to multiple bridge-component level project maintainers without any recourse.
The EU just designated Whatsapp as a gatekeeper under the Digital Markets Act: https://ec.europa.eu/commission/presscorner/detail/en/ip_23_... following the "full list of do's and don'ts" link on that page:
> Gatekeeper platforms will have to:
> - allow third parties to inter-operate with the gatekeeper’s own services in certain specific situations
> - allow their business users to access the data that they generate in their use of the gatekeeper’s platform
This is likely also the sole reason[1] that Meta is considering connecting Threads to the fediverse.
There's a fair amount of silly legislation that gets passed in the EU, but forward-thinking (or maybe just here-thinking?) laws like these (and the GDPR!) make me glad I live here.
Yeah this is exactly what’s needed. At least in EU the driver is awake at the wheel. As the politicians slowly get more technically competent we’re seeing more effective regulation. As long as EU has influence, everyone else will also benefit since companies often stop doing the shitty thing globally, not just in the EU.
Lack of interop has been a huge problem that’s also gotten worse over time. To address such a broad and complex issue with general legislation is not easy, we still have to wait and see if it works as intended.
A double edged sword[1] for sure.
[1] https://edri.org/our-work/why-chat-control-is-so-dangerous/
Yes, those are the silly bits, sadly.
I'm aware of DMAs regs but it forces Whatsapp within 6 months to start enabling interoperability. However it doesn't provide protection for these existing bridge projects.
open-wa, Baileys, invidious devs are all in the dark as to whether or not they're Scott free from their respective C&Ds due to this legislation.
The EU interoperability mandate for messaging services will surely improve this situation.
My Facebook bridge constantly locks up my account. [1]
I strongly believe users should be able to automate and interact with their accounts through whatever clients they wish however I think blocks/bans/technical countermeasures is fair game.
Count yourself lucky for not having an undeterminable, unfightable legal threat over your head from a $800bn mega corp.
You should use your bridge off of a residential IP in the same city as your other devices, or else Facebook finds the activity suspicious.
Comment was deleted :(
Rip matrix p2p.
I wonder if they were serious about it, or if it was just vaporware (a la Musk) to get more funding. It has been announced years ago, they raised millions and they have big governments contracts. WTF is going on?
wtf is going on is that:
a) p2p matrix works pretty well as a proof of concept - you can try it from https://arewep2pyet.com; it’s not remotely vapourware.
b) funding has been spent on core Matrix dev and making Element kick ass (cf Element X)
c) an awful lot of very large Matrix + Element deployments (eg LuxChat in Luxembourg, Merkury 2.0 in the Polish MOD, many German local authorities) decide to run Matrix deployments without routing a single $ to support development at either the Matrix Foundation or Element, such are the joys of the Apache license.
As a result, we’ve had to pause some of the longer-term R&D. I very much hope that P2P will resume (especially if someone explicitly funds it) and the team is still at Element (but working on sliding sync and account portability). But right now we’re focusing exclusively on fixing the core problems in both Matrix and Element which others in this thread are complaining about. Hence Matrix 2.0, and Element X.
Just poking around matrix.org, it's not clear exactly how one would "route [some] $[s] to support development" other than paying someone else for a hosted server. Our open-source project just switched to using Matrix from IRC; we're not really big enough to warrant hosting our own Matrix server, so most of us are just using matrix.org. We have some industry funding, and try to support other open source projects when we can; but not on the order of $250/mo (which if I'm reading it right, looks like the cheapest product on element.io -- $5/user/mo, min 50 users). If matrix.org accepts donations, it's not at all clear from your website.
Well, we need to fix that then. https://matrix.org/membership/ and https://matrix.org/blog/2023/06/membership-program/ is the way to donate.
I see now that somewhere most of the way down the front page there's a button-type link to "Support Matrix", which leads to a page which points either to membership or to a handful of ways to donate:
I'd suggest you make sure there's a link to that page 1) somewhere in the menus 2) somewhere in the footer. I'd also make a link to the membership page from the "About" page, and a link to the "Support Matrix" page from the "Membership" page, so that people who manage to find the Membership page but aren't ready to become members can support via patreon / whatever.
Thanks for all your work on Matrix! Looking forward to seeing the improvements coming down the line!
Its probably the right choice if yo don't have the funds. But it s great that that team is working on account portability. That would be useful in a p2p world anyway.
Really hoping Full Matrix p2p will happen. Its would be such a cool capability.
Governments wasting so much time and money on so much nonsense software but we can't support and open communication tool.
Makes me sad that billions got poured into cryptocurrency-sphere projects but classic p2p barely scrapes by.
(I mean by society not new vector)
money flows to where it can be multiplied, not where it can be sunk into some social good
You probably don't understand the enormous world-corrupting problem with fiat currencies.
Thanks Matthew, I always appreciate your comments.
I also do appreciate the Apache license.
Sorry for the vapourware comment. It's hard to tell these days. Was the Google self-driving car thing vapourware? It never went anywhere.
I know that pinecone worked as a PoC. I ran a node for years, for fun. It's just that it always felt like the progress was crazy slow. The yggdrasil demo was what, 4 years ago? How fucked up will the world be in 4 years? Not that it's your fault.
And I care about matrix. I was the one who suggested arewep2pyet.com, I made 1-2 friends use it (matrix), I made 1-2 coworkers use it.
Also, zulip threads now or I riot.
The best way to get P2P Matrix back on track is to find someone to fund it, and point them at funding@matrix.org. Unfortunately it's as simple as that.
> Was the Google self-driving car thing vapourware? It never went anywhere.
Well, it goes somewhere: people are actually being driven around Pheonix, Arizona [0] using those cars. It's just that it is not named "Google self-driving cars" any more: it was spun into its own company, Waymo [1].
[0]: https://waymo.com/waymo-one-phoenix/
[1]: https://waymo.com/
Zulip threads are killer.
Shame you can't categorise Zulip streams like you can with channels on Discord though (something that's also related to the IRC/Matrix vs. Discord conversation/content discoverability thing mentioned elsewhere here).
>eg LuxChat in Luxembourg, Merkury 2.0 in the Polish MOD, many German local authorities
This is extremely sad. They're large tax-funded organizations and should definitely contribute to priorize the needs they definitely have.
Ironically, there might be voices pushing for a move to a proprietary solution they would actually have to pay to use, and have much less control over.
Matrix folks have been constantly over-promising and under-delivering for almost a decade now. If you've been following long enough, that should be of no surprise.
Sorry for the bashing, but I got bitten once, and I see that nothing has changed in substance, so take this as a friendly word of advice: study the history of Matrix, its protocol, its implementations before committing to it seriously or for your org.
Hey, sorry that you got bitten; it must have been a catastrophic problem judging by how upset your comments are. If XMPP does what you need then I’m genuinely glad for you :)
"upset" isn't perhaps the best word, "bitter" would come closer, and not for my sake necessarily but for those who are still new to this.
You and I exchanged 1:1 around 8 years ago on MatrixHQ, when this whole thing was still somewhat new but the cracks were already apparent. Then, the room was crumbling, federation wasn't reliable at all, the overall performance for basic use cases was terrible and self hosting on affordable hardware would mean not federating with matrix.org. When I brought those observations up, you (kindly and approachably) promised that a new design was in the works and weeks away (something about fanning out, or whatever). Fast forward to today, all the points above still hold true in 2023. From a distance, Matrix has had synapse, dendrite, better synapse with workers, conduit, new components added left and right (sliding sync being the latest), and I'm not even talking about the community at large, taken hostage of the uninterrupted pace of breakage. And I couldn't resist laughing out loud at fosdem when hearing this year once again that we are weeks away from what we were promised 10 years ago.
I am sorry to be blunt, but I've never seen a project of this magnitude lacking so much in structure and focus. I admit that I regressed to being a complete outsider, and from my perspective on the sidelines it looks like this has no end in sight: Matrix is getting more and more complex and hard for hobbyists to deploy at a small scale/local level, New Vector's hosted instances have a de facto quasi monopoly on the user base and on the protocol implementation. I'd be curious to know how this dissonance fits in your mental model, because this insane technical complexity was sold as the price to pay for not letting servers hold too much network power.
Anyways, I don't doubt that this message will be met with a well written and kind reply, listing a bunch of fringe projects and ongoing initiatives to tackle this or that aspect of the same old problem. See you again in 10 years, maybe :)
Yup, "bitter" sounds about right.
I'd be first to agree that Matrix hasn't evolved as rapidly as it should, and we (specifically me) could and should have been more focused. Building out future-looking projects like P2P Matrix or Low Bandwidth or Third Room has helped inspire folks to build on Matrix, but it's come at the expense of focus on the core spec & implementations. And that's one of the main reasons (besides funding) that we've shelved them for now. It's also true that 8 years ago, everything was flakey as hell.
However, whether you like it or not, we fixed it. The federation problems were resolved before the time of Matrix 1.0 back in 2019, and since then we've focused on making everything go fast too - e.g. Faster Room Joins in Matrix 2.0. We experimented with fan-out routing back in 2015 or so (as yet another future-looking experiment), saw it had potential, but at the same time saw that empirically full-mesh federation was good enough for the vast majority of cases. So we focused on fixing things like consensus bugs and lazy-loading joins rather than premature optimisation on full-mesh routing. Meanwhile P2P Matrix took over better-than-full-mesh routing, but practically speaking it simply doesn't buy enough to prioritise it relative to other stuff, and it certainly makes Matrix (even) more complicated.
> Fast forward to today, all the points above still hold true in 2023
This is demonstrably false, and it's particularly obtuse to be whining about it in the comments on a post on Matrix 2.0 which is literally dedicated to spelling out how Matrix has improved. Your complaint seems to be simultaneously that we've improved both the implementations (e.g. scalable Synapse) and the spec (e.g. sliding sync, removing Matrix authentication in favour of OIDC)... while complaining that the project hasn't improved since 2015. Personally, I think it's an extremely good thing that the new APIs start off as separate projects, which can evolve and release as rapidly as possible and benefit all homeservers, before being embedded into Synapse or whatever once they're stable. But it's also easy to spin this as "new components added left and right" as if it were a bad thing.
> New Vector's hosted instances have a de facto quasi monopoly on the user base and on the protocol implementation. I'd be curious to know how this dissonance fits in your mental model, because this insane technical complexity was sold as the price to pay for not letting servers hold too much network power.
There are >65k servers on the public network, of which about 2000 are run by Element (New Vector). All the biggest deployments (100K+ users) aren't run by Element (other than the matrix.org server), given the most people who pick Matrix do so because they want to run it themselves. Community services like Mozilla/KDE/GNOME are tiny by comparison, and they only end up hosted by Element because those projects don't care about self-hosting and would rather someone else runs it for them. They could equally well host with providers like https://etke.cc/ or https://ungleich.ch/u/products/hosted-matrix-chat/ or https://federated.computer or whoever; nobody's forcing them to use Element.
> Anyways, I don't doubt that this message will be met with a well written and kind reply
I'm sure you're a lovely person, but you come across as a complete asshole here, imo. Sorry you feel let down by Matrix; meanwhile most other people on the thread seem to think it has some merit. shrug
Hi, back after few days. I had quite a lot going on, and the "you sound angry" hint probably meant that I was better-off not responding straight away :)
First of all, thanks for acknowledging the lack of focus of the project. I am happy to read that this is something being addressed, less so that the prime motivator for this is a lack of funds.
To me (and, I guess, to most), something like Matrix, which aims to become the broker of all our messaging needs, has an implied mandate to put reliability and consistency before all else. Your users' relationships, and sometimes, life? can be put at risk because of unreliable message delivery. Chasing new features and niche use-cases before the basics are covered by a sound theory and a stable implementation has always struck me as short-sighted: you can be sure that users burnt by over-promise and marketing hyperboles will never return. Enthusiasts and early-adopters who attempt to embark their circles onto the non-proprietary protocols exactly have one shot at it and a very high bar to pass. Contributors like yourself should also be aware that this "overly-optimistic attitude" insulates yourselves from potential contributors, in particular among the "theory/hard-problems loving" crowds, who are generally more suspicious about the kind or projects they engage with. That same crowd that could come to help with the interminable reliability issues.
> However, whether you like it or not, we fixed it. The federation problems were resolved before the time of Matrix 1.0 back in 2019
> This is demonstrably false, and it's particularly obtuse to be whining about it in the comments on a post on Matrix 2.0
You see, this is the kind of attitude that gives me little hope for the future success and adoption of Matrix amongst the general public. No later than a few days ago, using Element X on the client side, from a New Vector-managed account, sending a message to a(n up to date) federated server took 9 hours. I could top that up with many other issues with threads, spaces, client glitches, … but that's not the point. This is simply unacceptable for something branded as a mature product/protocol on par with the commercial offerings. I am not the only one reporting such issues and their reoccurrence. Every week, people on self-hosting forums give-up on Matrix for this or other reasons. Things are not going nearly as well as you make them to be, and whether you are honest and in denial, or malicious for the sake of protecting your business/career doesn't matter to me. What matters is that there is an end in sight to this and Matrix 2.0 isn't it.
> There are >65k servers on the public network, of which about 2000 are run by Element (New Vector).
I'm curious about the fraction of active users whose account is hosted by a NV-operated server vs the rest (as defined by the active users of servers federating with those). A vast majority of the Matrix accounts I see in the wild are hosted by NV (and I admit that my perception is skewed due to my involvement revolving around the opensource communities).
> I'm sure you're a lovely person, but you come across as a complete asshole here
I am critical of a work of love of yours, to which you dedicated a decade+ of your life, I can relate to the feeling. But for the record, my admiration for your dedication and availability answering messages here is legitimate.
It's still in development[1]. Seems like p2p will depend on dendrite so until dendrite is stable, p2p will not be available.
Comment was deleted :(
[dead]
The future of Matrix is robots and people as batteries.
I see Decentrilised and I see secure and I see a scam
Can this perennial scam get off the front page already. ffs.
> The European Union’s Digital Markets Act (DMA) is a huge step in that direction - regulation that mandates that if the large centralised messaging providers are to operate in the EU, they must interoperate.
Wow. Not interested in winning the war this way.
Maybe you're not but I know a few people (myself included) who will take any win on the privacy front we can get.
Requiring protocols for interoperation results in more competition in implementations, which is often the better scenario as far as users are concerned.
Regular reminder Matrix/Element work closely with law-enforcement to provide encrypted comms for them. It's a sector Matrix/Element actively markets to and deals with. My personal view is I'm not using a chat platform designed/developed by an organization so eager to partner with governments and law enforcement agencies.
There's Element's Chief Product Officer & Managing Director presenting at the European Police Congress[0]: https://mastodon.matrix.org/@element/110310853505977058
And a quick post about their excitement at participating in this conference: https://mastodon.matrix.org/@element/110304013472307767
I mean, whatever, it's just doing business, right? When someone criticized this, they gave a snarky, surprisingly unprofessional response: https://mastodon.matrix.org/@matrix/110334695988903649
Dunno about anyone else but my trust in them is just gone. I'm not saying you have to care (and I don't care if you do). I'm sharing this for the people who do care, and don't want to use "secure messaging" made by people who actively market to and collaborate closely with law enforcement and governments.
I don't really see the problem here, I would prefer my local government use open standards that are secure. If they are weakening the crypto to help the police and government come after me then I would have a problem.
Fair enough to share the information but I take the opposite tack: if it's good enough for LEOs, good enough for me.
I would also be excited to find paying customers when trying to build free software.
In any case I get the feeling if I were to avoid technology built by companies with government contracts I would be left with my retro 8bit machines. Lets be pragmatic.
Really strange Point of View. Governments adopting open standards rather then paying money to US tech companies is a good thing.
What's the problem with e2e encryption for those organizations?
The problem is if they give those orgs a backdoor
Oh yeah, I actually asked them about that. They said there aren't any backdoors[0]. We're all good, no worries! :) :)
Its open source and the crypto library is also 3rd party verified. I don't get your problem.
It's one of the most significant open source messaging systems that exist today. Anyone can audit it at any time.
What more do you want?
How do you know the matrix.org server or the element.io web client is running the same code as the source posted publicly? How exactly do you, personally, audit a hosted service? The answer to both questions is: you don't.
So host it yourself. It's literally designed to do that.
Yeah, that's great for me, but doesn't help me when everyone else is using the hosted stuff :)
Ok, I'll bite, what even could be the alternative here then? You want something without big funders, totally OSS, and extremely friendly for grandmas? Feels like one of those "you can only pick two" type things to me, but would love to learn that's not the case.
Also: 1. Mainstream enough for grandma. 2. No public hosts, you are required to self host it. Totally reasonable I don't see why this is so hard. /s
Its fashionable in the leftist world to compete to take the most radical position you can.
You described the goal, yeah, that would be pretty wonderful, like unicorns, flying pixie dust and other things that don't seem to exist as of yet.
Comment was deleted :(
I really don't think that is fashionable. Why would people want to do that?
>How do you know the matrix.org server or the element.io web client is running the same code as the source posted publicly? How exactly do you, personally, audit a hosted service? The answer to both questions is: you don't.
And I don't use them. I grab the posted sources and use them on hardware I physically control. If (I'm not, but I do care about my privacy) I was someone that was being pursued by one or more governments/well-funded private actors, I wouldn't use any communication platforms hosted by others.
As the old saw goes: "Three can keep a secret. If two are dead."
I find no issue that the company is working with law-enforcement to provide secure communications. In fact this makes me feel better about the security of those communications as they are trusted by these governments (not that this is a huge mark of quality, but I would consider it positive).
I your distrust of law-enforcement so strong that any company that they purchase from must be untrustworthy? Or is there another reason that this bothers you?
My concern is in the opposite direction of what everyone appears to be interpreting, despite what I thought was clear wording in my initial post.
It's not that govt/LE uses Matrix. It's that Matrix/Element actively seeks out partnership with govt/LE (to the extent of presenting on stage at a police conference), suggesting they are particularly interested in a relationship with authorities and personally sympathetic to these authorities, at the management/director level.
This is not a position I expect from an organization that is determined to build secure communications potentially used by activists, people living in oppressive/authoritarian regimes, etc... If I was a member of such a high-risk group, I don't think I would be putting my faith in this org to produce something I can actually consider truly secure.
I would guess the reason for that would be that those platforms are willing to pony up real cash and the actual communication protocol itself is no less secure when they use it. See also: Tor, famously developed/funded by the government
>If I was a member of such a high-risk group, I don't think I would be putting my faith in this org to produce something I can actually consider truly secure.
If I were in such a high-risk group, I wouldn't be putting my "faith" in anyone. Rather, I'd personally make damn sure my sensitive communications couldn't be spied upon.
I'd also point out that repressive/authoritarian regimes don't care about the rule of law and/or personal privacy, so they can just come to your house and take you away without any proof that you're working against the state.
What's more, they can also confiscate any systems/devices you (or others) may have in an attempt to discover the identities of your "co-conspirators." And they can torture you to give up those names, even if the names you give up aren't actually involved at all.
You seem to believe that there's some sort of magical software that can keep someone safe if a government or well-funded private actor wants to get you. News flash: there is no such animal.
From a personal perspective, I do share some of your misgivings about the appearance of sympathies with LE / authorities. It doesn't -feel- all that great to see. But at the end of the day to me it boils down to what another commenter said. If it's good enough for them, it is probably good enough for me. Someone has to pay the bills so the show can go on.
If the problem is that we're not trusting $LE_GOV_AGENCY to use the technology because it may hide abuses of authority, the root problem is that we can't trust $LE_GOV_AGENCY for reasons external to their choice of communication tooling. And that's not a problem I think we can solve with technology alone.
Plus, 'We can't allow X/Y/Z to use encrypted chat because they could do awful things' is a bit of a double-edged sword I personally don't feel comfortable wielding lest it be wielded against my own 'high-risk group'.
Disclaimer: SRE at Element, but I've been running a Matrix homeserver of my own since before I joined the company
The reason we "actively seek out partnership with govt/LE" is simply because they are by far the primary customer segment who actually have an clear need for self-hosted interoperable end-to-end encrypted communication and are willing to pay for it. If we don't find organisations who are willing to pay Element for services, then quite simply we can't pay people to work on Matrix and Element as their dayjob, and the whole thing would switch into best-effort volunteer run activity (although I'd presume most of the team would feel pretty burnt if that happened and go spend their freetime on something else). About 80% of Element's revenue comes from public sector, and without it the project simply wouldn't exist.
Hopefully, eventually, the rest of the world will wake up to the fact that sleepwalking into using Teams and Slack (or WhatsApp) is a catastrophe in the making. It's only a matter of time before someone publishes a torrent of every line of Teams scrollback or Slack scrollback for some high-profile organisation; the breach has probably already happened; the breacher is just waiting for the best strategic moment to drop the information bomb.
But until then, Element makes payroll by selling to folks like the French and German Governments, the United Nations, etc. They pick Element because it is high trust, and they can audit it and run it themselves. And there is categorically no way that I or other senior management at Element would destroy the company (let alone Matrix) by breaking that trust by letting someone undermine its privacy.
Which is why we're in the surreal situation of on one hand selling to the UK Government, while also frantically criticising them for the catastrophic idiocy of the Online Safety Bill: https://element.io/blog/the-online-safety-bill-an-attack-on-....
Separately: I'm literally years overdue in publishing Element's internal ethics guidelines publicly, which spells out precisely who we do and don't do business with. For what it's worth, the high level summary is:
* We don't sell to criminals (under UK/US/EU law)
* We don't sell to sanctioned (by UK/US/EU) or abusive govts or organisations
* We don't sell to orgs who explicitly encourage use which goes against our terms of service.
Most western governments (including their police forces) do not fall into this bracket.
>Regular reminder Matrix/Element work closely with law-enforcement to provide encrypted comms for them.
Thank you for the reminder. Based on that, are you claiming that Matrix servers/clients are insecure or have government back doors?
If so, what evidence do you have that supports such a claim?
If not, why should I care? I'm not a fan of many organizations/individuals. Should I survey them all to create a database of software those folks use and refuse to use any software they use? What value would I derive from such actions?
Unless you're claiming the former (evidence please), what difference does it make? I use Matrix servers/clients only on hardware that's under my physical control. And I use free (libre and beer) versions of Matrix implementations, so I'm not even giving the developers any money.
Or are you making the argument that LEOs shouldn't have access to secure communications protocols?
I guess I'm confused because I don't understand what the issue might be. If you'd elucidate, I'd much appreciate it!
I didn't claim/assert anything other than what I linked to already in my original post.
You don't have to care, and like I said, I don't care if you care or not. I'm just making people aware, because some people _do_ care.
It's nice that you personally use matrix on hardware under your physical control. That's rare. The vast vast majority of matrix users have their account on matrix.org and are using Element. I'm glad to hear you are using alternative server and client software.
I addressed the other questions at https://news.ycombinator.com/item?id=37602089
Since you didn't actually answer the question "why should I care?", perhaps you might deign to answer these instead:
>>I'm not a fan of many organizations/individuals. Should I survey them all to create a database of software those folks use and refuse to use any software they use? What value would I derive from such actions?
Why are those useful questions? Pick some software -- any software in wide use -- and you'll find that someone you find objectionable is using such software.
That includes OS's, browsers, databases, web/application servers, BIOS firmware, chat clients/servers, etc., etc., etc.
If using software that's also used by someone whose actions and/or rhetoric are objectionable to you is "capitulation" to those with whom you oppose/disagree, then you should power off all your electronic devices, smash them into little pieces and never look back.
But (IMHO, at least) taking such a position takes "guilt by association" to ridiculous extremes, especially when talking about open source software that can be audited and modified to suit your purposes.
Don't want your sensitive information shared? Don't share it on platforms not under your control. Full stop.
I'll say it again[0], "three can keep a secret. If two are dead." Food for thought, no?
When someone asks "why should I care," the implication is that they want to know why you care. Dodging the question here is an interesting way to respond
People who want to work closely with authorities probably shouldn't be trusted to provide your secure communication software.
But that doesn’t mean Matrix makes backdoors. So you can use it too.
What’s wrong with helping organizations including law enforcement encrypt their communications?
Because they are public servants and We the Public should have ways to be able to decrypt those communications.
Secret meetings and intelligence agencies are what leads to totally avoidable wars.
https://community.qbix.com/t/transparency-in-government/234/...
You are mad that they took money away from someone you don’t like?
And moreover that they used this money for something that you do like?
"Taking money" is a very poor description of a trade, which both parties chose to enter into because they both expect to derive benefit from it. What the parent objects to is presumably the "government/police/military expects to derive benefit" part, not the "taking money" part per se.
Crafted by Rajat
Source Code