A few key differences with other OSS companies that IMHO are positive:
1) Element or other matrix components do not require a copy right transfer. That means Element is hard to re-license under another license than its current one.
2) The license for Element is Apache 2.0. A fine choice for any OSS project looking to maintain a healthy ecosystem of contributors for decades to come.
3) The ecosystem has a diversity of stakeholders and contributors outside of Element the company maintaining various components, integrations, etc. It's an ecosystem that already serves many millions of users.
4) Not all the Matrix components are under the Element umbrella (see 3). Element is probably dominant in this community but it's based on merit rather than ownership. E.g. the Matrix foundation is mostly run by people outside of Element. Even the Element apps have contributions from outside Element the company (see 1).
5) Decentralization is at the core of the Element sales pitch. They are unlikely to want to walk back on that; or even be able to do that without damaging their credibility. For better or worse, that's what they are selling and stuck with. And they seem successful with it too. Hence the investment.
> 1) Element or other matrix components do not require a copy right transfer. That means Element is hard to re-license under another license than its current one.
That helps a lot with future-proofing the openness of an open-source project [1], and it's a critical detail often overlooked, mainly because it's a technicality of copyright licensing and most people understandably just want to know if something is open-source or not, without getting into the details.
The simplistic gist of it (not getting into differences between Licenses) is that if you contribute to an open source project that requires copyright assignments, then its only promise is that current versions of the code will remain with the same (open-source) license. Future versions might as well become proprietary while benefiting from your code. So depending on your willingness to accept that, it's an important factor to consider. Sometimes you just don't care, then all right just go ahead. Other times you might have a stronger position on this, then step back and think about it.
On the other hand if you contribute to a project that won't ask you for any copyright assignment, then your contribution is yours, its license cannot change in the future without asking for your explicit permission (or dropping your code altogether). This is, if your contribution was a significant enough work; I don't know where the line is drawn legally, but I know (from reading here in HN) that trivial enough contributions might not need permission to be relicensed.
[1]: On the other hand, it might hinder the ability to commercialize it, which might end up meaning that there are no devs pouring serious work into it, which in turn might end up meaning there is no project at all :-) "pick your poison", I guess.
If you contribute to a project under a non-copyleft license (MIT, BSD, APLv2), even without copyright assignment anyone can use your code for proprietary, closed-source projects without asking for permission. There's no need to relicense since the original license is permissive enough. So your argument only applies to copyleft licenses.
Yep, I went for a coffee and realized that. But this is a consequence of the simplistic summary, as I warned. As everything, the devil is in the details!
If we look closer, I believe (not an expert, though) that without a copyright assignment your contribution would have to be kept with the same license. We'd be just getting into the fact that non-copyleft licenses typically allow to use the code for building proprietary software. But AFAIK the contributed code itself would need to be kept with the original license? (that's where my knowledge is lacking)
The contributed code under Apache would be like any other permissively-licensed third party dependencies used in any proprietary product; you add a copyright notice and possibly link to a copy (a courtesy, not even necessary), done.
There’s no devil in the details. The entire codebase can be taken proprietary right now and there’s not a thing you can do. You’re free to extend the last permissively licensed version.
If you make a MIT project "Foo", not protected by a CLA and I contribute to it, then if your company uses Foo in a proprietary product they still have to give the attribution for my code as required by the MIT license, as my code will still remain MIT even if embedded in a larger non-MIT project.
OTOH if I had signed a CLA, then your company would be within its right to entirely strip any attribution to give whatever license they see fit to the code I wrote.
Yeah, they'll have to attribute the code to you - the MIT license will always apply - but they'll only need to attribute you - they can make as many modifications as they like.
The proprietary+forked code would become a mix of closed and open source license, but just never get released so you’d never be able to get ahold of it.
Some of us prefer permissive licenses, or choose between permissive and copyleft depending on the nature of the application.
But here's something you can't do with my MIT licensed code: change the license to copyleft.
Point being, if one is contributing to a project with a permissive license, that should imply being a-ok with it getting rolled into some binary in a form you don't have access to.
You can't just change the license to a copyleft license, but you can make changes to it that are licensed under a copyleft license. If your fork/derivative project gets enough attention, you've practically changed the license anyway.
If one is contributing to a project with a permissive license, that should also imply being a-ok with it getting rolled into a copyleft project too.
LibreOffice comes to mind immediately as the most high-profile one I can think of.
That aside, any permissively licensed library used in a GPL program would technically fall under this situation, as it ends up distributed under the terms of the GPL. It just so happens that usually the libraries aren't modified by the application developer, so you can typically go find the original source.
If they are, those changes may be under the GPL, depending on whether the application developer kept the derivative version of the library explicitly under its original license, or licensed their changes under the application's license.
> if you contribute to an open source project that requires copyright assignments, then its only promise is that current versions of the code will remain with the same (open-source) license. Future versions might as well become proprietary
That depends. I don't know the current paperwork, but I assume assignments for GNU software still involve a contract promising to maintain a substantially similar free software licence.
There is no such thing as a GPL compatible license. The GPL is only compatible with GPL.
When a license is "compatible", it allows you to relicense that code as GPL, sometimes with additional conditions.
This means that if you link it GPL code into a MPL code base, the GPL requires that entire code base to now be GPL. And as such all other code linked against it also must become GPL.
> There is no such thing as a GPL compatible license
On the contrary, you can use MIT, BSD, MPL, LGPL code in a GPL codebase without any issue. You can dynamically link LGPL in any codebase. You can statically link GPL in another GPL codebase.
> All GNU GPL versions permit such combinations privately
IE, the copyright holder can permit anything they want, as they own the copyright
> they also permit distribution of such combinations provided the combination is released under the same GNU GPL version. The other license is compatible with the GPL if it permits this too.
IE the license grants the ability to add the GPL license that code.
> means either the GNU General Public License, Version 2.0, the GNU Lesser General Public License, Version 2.1, the GNU Affero General Public License, Version 3.0, or any later versions of those licenses.
> 3.3. Distribution of a Larger Work
> ... If the Larger Work is a combination of Covered Software with a work governed by one or more Secondary Licenses, and the Covered Software is not Incompatible With Secondary Licenses, this License permits You to additionally distribute such Covered Software under the terms of such Secondary License(s), so that the recipient of the Larger Work may, at their option, further distribute the Covered Software under the terms of either this License or such Secondary License(s).
---
The MPL 2.0 is compatible with GPL because it explicitly grants the right to release MPL code as GPL. All the copyright holders of MPL 2.0 code have authorized this secondary licensing because the license they released it as says so.
This means that in cases where compatibility matters, then the MPL2.0 code base has all the additional restrictions that the GPL has. And the GPL is _all_ code, which means it spreads out from there. If you are using GPL-2.1, MPL-2.0, and APACHE-2.0 code in the same code base, there is a violation.
I took the pint as saying that Apache/MIT/BSD/MPL code that is distributed as part of a GPL project is actually under GPL. To obtain the original Apache/MIT/BSD/MPL code you need to get it from upstream.
So that if project A originally licensed as MIT is statically linked inside a project B licensed under the GPL then in the event that all copies of project A source code are destroied except those distributed via project B (a more likely scenario before mirror servers) then project A is now only available under GPL.
I believe that GP relies on the fact that GPL source code can only be statically linked with other GPL code and so "compatibile with GPL" means "can be relicensed under GPL" rather than "can be included as is in GPL works"
My original comment and point has not changed. The GPL is only compatible with the GPL. The only way for a license to be compatible with the GPL is to have the ability to license under the GPL. We have proven that is the case.
There is a lack of awareness and understanding of how this can transitively affect things accidentally.
For the record I am all for GPL code. I think the GPL is a fantastic license that has enabled great good in the world. But there are reasons why a company may not want to release code that is compatible with it.
Well, the bundle is GPL, the particular code is still MPL, so that you can still take that portion away from the bundle and do anything that the MPL allows.
I don’t think you can ever rellicense or sublicense someone else’s code without consent or prior arrangements.
Like if I said this comment is licensed under GFDL 12.34 and you thought GFDL 10.01 is “compatible” with it, it’s still mine to decide under what license it is licensed.
A popular phrasing found on many GPL projects are “Version 2 or later”, but that doesn’t mean you get to rewrite it to “AGPL 3 or stricter”. That’ll be a copyright violation.
Together with the lack of copyright transfers, it just guarantees the code will always be available under the same license. There can't be any re-licensing of existing code without twisting the arms of every single copyright holder. No more, no less. It gives nobody an exclusive control point. It gives nobody exclusive rights to exploit.
So, yes, Amazon can spin up as many matrix servers as they want. And so can MS. And so can Google. Maybe that wouldn't be such a horrible idea as they have mutually incompatible products that loosely overlap with the matrix feature set; those things interconnecting would be progress. Email is doing pretty OK decades after MS tried to embrace and extend via outlook and exchange. Federated communication networks are nice.
The way you wrote it makes it sound like someone can make the project proprietary over night.
They cannot and I wish GPL people would stop pretending.
Whoever has a copy of the repo or even a snapshot of the source can continue using and developing it under the original license.
What one, strong contributor can do is make a proprietary fork and stop contributing towards the original open source one, possibly dumping prices and thereby starving the original project of code and donations.
I fully believe that Element want Matrix to be decentralised and diverse, but I don't think it's actually true.
Despite years of deployment, 90%[1] of the work is still done by paid Element employees rather than the community. Could you imagine a world where Microsoft make 90% of the effort to Linux and still tried to call it diverse?
Likewise, the vast majority (>80% anecdotally) of users on the main Matrix federated network live on a single instance centrally administered by matrix.org. Again, not a shining example of decentralisation at work.
My worry isn't about Matrix the protocol, though I think it leaves many aspects to be desired. My worry is that the fate of Matrix rests on Element Co, which seems to be a default-dead start up, repeatedly needs to seek funding, and nearly went bust in the past.
The lobsters comment is from me, a year ago, talking about the spec and implementation work published by the Matrix core team - i.e. the contents of https://github.com/matrix-org. Matrix started in 2014, and the core team formed Element in 2017 to fund its work, so it should hardly be surprising that much of that code comes from Element employees. Just as if Linus had chosen to fund himself to work on the linux kernel by creating a startup, the balance of code in the kernel would be different. Nowadays I'd guess it's more like 75% of the code at github.com/matrix-org which comes from Element employees contracted to work on Matrix by the Matrix.org Foundation.
However, across the wider ecosystem, Element's contributions are an increasingly small minority. There are completely new independent implementations out there like Conduit.rs (rust server) or the whole FluffyChat stack (cross-platform flutter clients) which have almost no contributions from Element and build on entirely different codebases to the reference implementations at https://github.com/matrix-org. So, where it counts, I'd guess that Element probably does <20% of the overall code in the Matrix ecosystem?
> Likewise, the vast majority (>80% anecdotally) of users on the main Matrix federated network live on a single instance centrally administered by matrix.org.
Looking at the phonehome stats, it's more like 30%.
> My worry is that the fate of Matrix rests on Element Co, which seems to be a default-dead start up
Nope, we didn't need to seek funding in this instance; we consciously chose to. We could have just continued profitably at a slower rate, but we wanted to go faster in order to compete with Discord & Teams etc.
> and nearly went bust in the past.
Nope, Element was formed after we lost funding for the original Matrix work... which is why we formed the company.
I downvoted you (I'm not an employee or affiliated with Matrix in any way except that I selfhost Synapse because it's cool) because you've veered off the good faith criticism path into paranoia and what looks like a personal vendetta, which I can't understand what for.
This is a tech chat product but the way you dig into it makes it sound like you have bones to pick with someone who came to your house and killed your cat.
Can I run my own identity server?
See also: What is an identity server?
Yes - the reference implementation is sydent and you can run your own ID server cluster that tracks 3rd party to Matrix ID mappings. This won't be very useful right now, though, and we don't recommend it.
If you want your server to participate in the global replicated Matrix ID service then please get in touch with us. Meanwhile, we are looking at ways of decentralising the 'official' Matrix identity service so that identity servers are 100% decentralised and can openly federate with each other. N.B. that you can use Matrix without ever using the identity service - it exists only to map 3rd party IDs (e.g. email addresses) to matrix IDs to aid user discovery.
As someone that really likes Matrix because of its decentralized nature, I'm not really seeing a problem here. TBH, I don't really care about mapping a foo@bar.com to @foo:bar.com. All of my matrix contacts I've just asked them what their username is, then started chatting with them.
I think those "phonehome stats" are exactly what most people are up in arms about. Particularly the exhaustive non-depersonalized nature of them. [0]
It appears that the data which is collected includes [1]:
Message senders
Message senders are never encrypted
Session/device IDs
Due to Matrix's design, encrypting this would break verification
Message timestamps
It's impossible to prevent timestamps from leaking, since the server can simply note when an event is received anyway
Room members (join/leave/invite events)
Join/leave/invite and other room events are never encrypted
Message edit events
While contents are not leaked, an attacker can know when messages are edited
Message reactions
Reactions are never encrypted
Read receipts
Read receipts are never encrypted
Nicknames
Nicknames are never encrypted
Profile pictures
Profile pictures are never encrypted
Put another way [2]:
The Matrix ID of users, usually including their username.
Email addresses, phone numbers of the user and their contacts.
Associations of Email, phone numbers with Matrix IDs.
Usage patterns of the user.
IP address of the user, which can give more or less precise geographical location information.
The user’s devices and system information.
The other servers that users talks to.
Room IDs, potentially identifying the Direct chat ones and the other user/server.
All the stuff you enumerate is metadata that your server stores in order to store your conversations. Until P2P Matrix lands, if you're worried about metadata, only talk to people on servers whose admins you trust.
Congrats on your round. Best wishes for turning that into a robust truly decentralized E2EE communications platform that the average person won't shy from. Btw, I hope SNEK sticks!
Thanks :) Also, another improvement to protect metadata that we're working on is https://github.com/matrix-org/matrix-doc/blob/rav/proposal/r... (and relatedly https://github.com/matrix-org/matrix-doc/blob/neilalexander/...). By giving each sender in a given room its own public key, you can de-correlate the identities between rooms by blowing away the mapping that links a matrix ID to an identity in a given room. (Of course, a malicious actor could deliberately monitor this and de-de-correlate - to which P2P is the longer term solution.)
Oh yes, great. I was wondering yesterday if you'd looked at an approach like this, but hadn't gotten to looking at docs/code. Thanks for the pointers! It's definitely a good start for obfuscation.
> Associations of Email, phone numbers with Matrix IDs.
Collected hashed at a identity server (you can choose) in case you decide that other people should be able to use the identity server to discover you via phone number
As a practical matter, I'm not concerned about this. The French government pays for support on a large Matrix deployment, a couple German states and the Bundeswehr do as well.
Those kinds of anchor clients leave me sanguine about the prospects of Matrix and Element.
As for decentralization, what the ~80% do is totally irrelevant to the other 20% of us. My company finally got off Slack (where 100% of users are trapped in a ransomware monolith) and we couldn't be happier. I federate with a couple other servers and it all Just Works.
Matrix is federated, and the way federated decentralization tends to play out involves a few big 'continents' and a vast archipelago of small instances. If you want true decentralization you have to force it with a peer-to-peer architecture, like Urbit or Secure Scuttlebutt.
I run synapse on Gentoo and it uses next to no resources except disk. Load averages 0.03 for all, 366.6MB used, 97% idle. 14 days uptime.[0] This is like rpi model B compatible.
We only have 5 users, and we use coturn on the same machine, but three of those users are also linked to glitter and matrix.org channels/rooms. The ~/synapse directory weighs in at 5GB with 2GB of that being logs.
The setup took me a 'few hours' over two nights, but my work revolves around setting up services and software[0] - it may take someone else a couple of days to correctly set up and run it.
[0] uptime reflects the rolling nature of Gentoo, and I had a certificate update at the same time, reboots are inevitable. I start with Gentoo with any new online service, since I know the pain points and failure modes. This homeserver is run on a VM in a datacenter. I have no complaints about synapse so far.
> 2) The license for Element is Apache 2.0. A fine choice for any OSS project looking to maintain a healthy ecosystem of contributors for decades to come.
The problem with Apache 2.0 is that it's incompatible with GPLv2. That's the main problem with copyleft licenses, they are made as if they were the only FOSS licenses in the world and just introduce incompatibilites between different camps. Apache 2.0 vs GPLv2, GPL vs CDDL, GPLv2 vs GPLv3[1]. I prefer to go with permissive licenses and save myself the headache. Regarding Apache, a common solution is dual-licensing under Apache+MIT (e.g. the default for Rust projects created with Cargo), which takes care of this problem.
[1]: And "vN or later" is not a solution, since that's just a backdoor of a random org in US.
The problem isn't with copyleft licenses, only with GPL (in its various variations). You don't get license incompatibility problems with other copyleft licenses, eg MPL; you need GPL for that.
Don't forget the LGPL, which, in its attempt to allow proprietary software to use LGPLed code with conditions, makes it painful to use LGPLed code in free software licensed under anything other than the GPL.
See LGPL v2.1 section 7. It's annoying to comply with. Section 6 too. 7a was clearly designed for proprietary software. It would be a problem with the GPL too if section 3 wasn't there.
3) add support for multiple accounts and identities (too many requests to list on the issue tracker), since federation is great, but it's not always wanted.
Disclaimer: I managed to convince a group of technical users to switch over to matrix. We stay for the principle, but not really for the experience so far. FluffyChat is the best client we tried on mobile. On desktop, I'm glad weechat-matrix and gomuks exist, because all the other clients "reek" to us. And even if you like the modern chat UIs, they're really not bug-free either.
Overall many clients and some severs to choose from, but I did prefer irc just for the simple-no-BS-clients alone (the protocol has nothing to do with it).
If you prefer FluffyChat's UI over Element's then I'm guessing you are after a 1:1 or group style chat (i.e. chat bubbles), similar to say Signal or Facebook Messenger. Element isn't catering to this audience from what I can tell, it has a UI that is similar to Slack or Discord, which is suited for large group chats. Just because you aren't using Element in this way doesn't mean that it has the "worst UX" of any other client.
Your third point is a client side feature. If you meant that you want Element to have that feature, then yes I agree. But in saying that, it wouldn't surprise me that it's not high on the priority list when most clients (of any chat app) have this feature.
I totally get it, but I still disagree. Getting more users on the network should be a #1 priority. You don't want to keep another 10 chat programs, just because matrix is "not" a plain chat app. If the element foundation doesn't do this, who will?
As a tech user, I still don't find the element UI great. It's clunky, quite slow and generally not intuitive, and wastes a lot of screen real-estate.
I'm using slack and discord and I find both to be _significantly_ better for group work.
But actively trying matrix on mobile, I still found the simplified FluffyChat UI much more usable on mobile anyway.
Element is this sort of annoying middle ground which is not great for either.
The third point is also important, because matrix is one of the few systems where you can have a private network for your work. You know, just like slack (again, the "group" they're apparently targeting?). Great feature. But if you, like me, would like to use matrix for both work and other communications, you're stuck.
So in the end you run two clients. Element for work, fluffychat for everything else? And maybe shildychat for your other private group (I wish this was a joke).
Not to justify the missing feature in any way, but assuming you're on Android can't you modify the applicationId of the existing apk (there are tools on GitHub that will do this for you), resign the apk, and adb push it? Unlike desktop, mobile apps are so thoroughly sandboxed from one another that I don't think there's any way for that to cause problems. I guess updates might be cumbersome though.
You can. People have suggested the Element foundation to publish "red blue green yellow" versions of element with just a different app id for this.
I wouldn't be against it (the _clear_ distinction between accounts is important!), but element is already a memory hog. You really don't want multiple instances running.
This is why I've always been confused by HN's comparisons of Signal and Matrix. I see Signal as a replacement to texting/Messenger/WhatsApp (chats focused on one on one or small groups) but I see Matrix as a replacement to Slack/Discord (chats focused on organizations or large groups). I'm not sure why these aren't two different paradigms, but maybe someone sees something I don't. Telegram seems the most in between to me, though there are security reasons I see Signal/Matrix as being better.
For the average user the element UI is just confusing. This is the #1 complaint I got from all non-techies. They expect to just see a contact list, with each contact being a simple chat without the typing bar. Most of the other interactions are also too complex (like sending an image).
You'd think this is a small complaint, but I've listed this as first as it's the biggest barrier to conversion. Ask the _same_ user to try FluffyChat, and no objections will be raised besides the expected "why another chat app".
I'm not a fan of the Element UI myself, although I "get it" as it's targeting to something more group-oriented like slack. The problem is that Element is currently neither oriented to plain users, nor it's great to technical ones.
If everything else had to stay the same, they should optimize for plain users on mobile and offer a better, more advanced desktop client instead.
I guess it depends on what Element is trying to replace.
If it's whatsapp etc then yeah, I agree, it is not going to work. But if it's Teams or Slack or something, then I don't see much difference.
I don't think it is meant to be a whatsapp replacement, I think it is a generic chat tool that lets me integrate all my services in one place - kinda like Pidgen.
As you say, maybe this cash injection cam let them get a mobile client that can work as a whatsapp replacement (as I guess that is what most people are moving from)
What important features? FluffyChat had cross-signing for more than a year now. A lot of other features are unlikely to be added, since FluffyChat aims to be easy to use. FluffChat even supports E2EE fallback keys!
I do agree it is quite ok, it has all the basic features, but it feels "slow" and "beta" at some points.
In addition to some decryption issues that made some of my friends hate Element (they could view messages on one device but not another one, and there was no clear action to fix this), one of the issues I think could be easily worked on is the settings: the current layout is way too complicated, too much scrolling, too many options, it doesn't feel clear at all. Also the stickers are really crappy: they are not useful for any serious chat (ie. work), and not useful for any fun chat (ie. friends).
There aren't that many showstopper issues in the UX (except for wrangling bridges, but that's not really an Element thing, it's more of a Matrix thing).
But everything is just a bit off. The text is a bit too spaced out for IRC users, the icons a bit too small for people coming from Slack and Discord. Colors are seemingly chosen at random by the coder and don't jive well together. The "These people have read the backlog this far" notification is just plain useless. It is death by a thousand cuts really. The small things stack up and make me not like using Element for Matrix.
I do love Matrix, the underlying technology, in theory.
IMO they just need to bite the bullet and make a truly user friendly mobile UI to replace Telegram, WhatsApp, FB Messenger etc. And a proper client for the major operating systems that's not too different from Discord and Slack.
Using it everyday too at $work, also used Slack and Gitter (and FreeNode/IRC FWIW). Quite happy with the current Element UI. They have slowly added features and fixed issues. I tried a beta some time ago with... topics? Rooms grouped in some sort of topic I think. It was really buggy, but I forgot about that I haven't seen it yet. So I assume they are doing some A/B testing, trying things slowly and seeing what works.
I want to like Element but I find strange UX issues or minor bugs every time I use it. It feels extremely beta from a polish perspective. I'm hopeful they can iterate and deliver something on par with the quality of mainstream chat apps they just need to decide that UX and look-and-feel is as important as delivering something conceptually novel from an engineering perspective.
Above all else, it's because core functionality is frequently broken and issues like this[1] languish for months and years without updates. When things don't work, it's rarely transparent to users whether this is due to a bug on Element's end (or on the server side), user error or misconfiguration, or operator misconfiguration.
Further, there's virtually zero documentation for end users. There are no in-app explainers as to what E2EE is or why anyone should care, leaving the onus on operators to document and explain these things to non-technical users.
For me the channel/room list is too messy with different parts which have their own scrolling zones. And each entry takes too much space leading to having to scroll all the time.
On Quassel I can have 30 channels open without having to scroll. On element only 10 or so. That's way too few considering the number of bridges available.
They have a high density xchat mode but it only affects the chat view, not the room list
Personally I’m always confused about the accounts I which one I’m currently using (they have the same names). Also I can never understand when I verified someone.
I had never heard of FluffyChat and so visited its site. Appears to be a very attractive landing page. However, UX of the site leaves a lot to be desired.
Their FAQ link in menu bar just links to their GitLab issues page, and AFAICTA nowhere on their site does it actually explain what FluffyChat is or which what network it operates, etc. (clearly from context I infer it is Matrix)
I'm not trying to talk down your personal experience or have any skin in the game, but...
We also have a group of technical users on Matrix, where we were formerly on IRC. Nobody complains about Element and most prefer it over the native clients they tried (but it doesn't rule out the possibility that everyone hates all native clients here).
This is also just anecdata with a sample size of "handful of users", but from the other side.
I personally would love to have a native Windows and Linux client I really like (preferably the same), but so far I've had no luck. The Android version of Element is perfect for my usage pattern though.
I never think a concrete issue will affect me. But over the last weeks I've been affected exactly by 2). Today I finally figured out that it had to do with the sender having turned on the setting "Never send encrypted messages to unverified sessions from this session". It's terribly implemented, because it gives the sender no feedback that they break any unverified receivers, and the unverified receivers only see an obscure error message. For more details, see my issue report: https://github.com/vector-im/element-web/issues/18255
Also +1 on Element's terrible UI and UX. It was designed by programmers instead of UI designers, and you can feel that. I always find it weird when people talk about Element being a good client. It's literally the best of the worst. From the thousands of open issues (5000+ Web, 1000+ iOS and Android each!) you can clearly see they have an organization problem. Even most volunteer open source projects are more organized. I hope at least 30 million will be enough for them to hire some talented people and build a better management.
I have the feeling most of them are hackers. Hacking and experimenting with new things like Matrix P2P is great, but it's not enough to have consistent output. You need to manage an organization, and I have the feeling they aren't capable of doing that. On that note, I'm surprised they managed (pun!) to get 30 million of investment.
> From the thousands of open issues (5000+ Web, 1000+ iOS and Android each!) you can clearly see they have an organization problem.
As I said before down thread (https://news.ycombinator.com/item?id=27974054), there’s nothing bad about thousands of issues, quite the reverse in fact. Many are feature requests that may or may not be implemented.
A large number of open issues means the project is growing and many people are have ideas for new ways it can improve.
Furthermore, those thousands of open issues hint to me that a lot of people are actively contributing, and that the dev team takes responsibility for legitimate problems.
Compare this to other projects with the illusion of quality because most bugs haven't been reported, or because their developers routinely dismiss and close reports of bugs that they don't feel like fixing, just to keep their bug tracker looking clean.
Indeed, the contents of the Matrix/Element/Synapse issue trackers played a significant part in convincing me that the developers are making good decisions, and that investing my time and contacts in this network would also be a good decision. That was over a year ago, and I do not regret it. The project still looks very much on track to me.
So much entitled whining in this discussion. With friends like open source users, who needs enemies?
> Element is probably one of the worst matrix clients in terms of UX.
If you ask nicely, I'm sure they will give you back all the money that you paid for it.
But your point 2 is spot-on:
> 2) fix decryption issues
Part of the problem is that Matrix nukes your crypto keys every time you log out. This traces back to Element's heritage as a primarily web-based app, where there isn't really a great local, durable place to store your secrets. Not having local on-device storage is painful when the protocol encrypts messages to individual devices rather than to users.
The fix is to set up encrypted key backup, aka secure server-side storage. Then all your keys from all your "devices" (including real devices and web sessions) get safely stored in encrypted form on the server, where you can always find them. You have to use a second passphrase to generate the new key-encryption key, so it's a little annoying. But the fix is pretty magical. Suddenly everything just works!
I was trying to figure out why this comment rubs me the wrong way so much. I think it's how quickly it leaps to hostility and calling the user entitled, only because they shared their honest feedback. You say users aren't entitled to anything, which I guess is true, but what does that say about the value that this project purports to provide?
I guess what I'm trying to say is I read this comment and my thought wasn't, "Oh, I guess those problems are handled", it was, "Oh, this projects advocates have a lot of contempt for their users."
The GP comment was well beyond honest feedback. Honest feedback is like "I find such-and-such piece of the UI ugly", or "All of my friends get confused by the way it does XYZ".
What I object to is the way our community viciously tears each other down. "This open source product is the worst thing ever! Kill it!" This crap is not productive. It's harmful.
We're up against companies who want to monopolize markets, lock us in to proprietary platforms, and own our data forever. And then when somebody finally comes along and tries to do the right thing, we attack them for not being perfect. F that noise. So, yes, I have contempt for this attitude.
(And no, I have no affiliation with the company being discussed in this article.)
Perhaps it is harsh, but element is being founded to improve the client, and I find several other open source clients to behave better than the official one.
I call this honest criticism. My hope is to push matrix as an open protocol, to push matrix as a slack replacement and I genuinely wish the greatest success to the element foundation.
I currently cannot say "element is awesome". Matrix as a protocol and ecosystem is awesome, but the client... I can't say that.
It's not about being perfect, it's about having a solid UX such that we can start recommending it to our friends and family to help wean them off the major platforms without a lot of headaches and frustrations, which will push them even further towards proprietary ecosystems.
There is a lot more than 4 clients out there. For example I develop Nheko, which supports E2EE (including cross-signing) as well as 1:1 calls (those only on X11 though, because time and none seems to be interested in adding call support on other platforms). Then there are UX improvement forks like SchildiChat, clients for other platforms like SailifshOS, etc. Oh, and I almost forgot about Mirage.
Given how frequently Matrix comes up in the Signal federation/alternative clients discussion, it's interesting to note that neither one of those supports the E2E encryption in the Matrix protocol.
I haven't tried it in a while but last time I tried about a year ago, the messaging was very slow - both to be sent as well as receive.
Has this changed recently? I would like to give it another shot as I want to support the tech. Can someone with use experience please comment with their experience on the speed?
About a year ago was in many places just after the start of the pandemic, which brought a large influx of users to the default public server. It got overloaded, and slowed down. I experienced it, too.
They have made several rounds of significant scaling improvements since then. It's almost never slow for me any more. (And even if it was, I could always just choose a server other than matrix.org, or run my own.)
That was probably a problem with their main matrix.org homeserver, more than with the protocol or your particular client app. It was very slow for a while, until they worked out some scaling issues to handle the load.
I’m on matrix.org pretty much every day now, and it’s a lot better than it was. And when I use my own server to talk with other local users, I never have any latency issues.
Fluffychat is mentioned a lot here as a good UI/UX alternative to Element. Just wanted to bring up another that I'm working on called Syphon. It's not at the stage where it can compete with Fluffychat in terms of spec parity or maturity, but I think it's worth discussing as an effort.
Like I said, it's still very much in Alpha and needs quite a bit of work, but the UX flows and design have been well received by others. Though there is an opinionated default UX and design paradigm, there is a focus is to make everything customizable and the theming options are growing over every release.
The goal is to eventually find a sweet spot between Discord and Signal and bridge the gap to Matrix between those communities.
I have a demanding day job and other obligations that keep me busy, but I spend nearly all my free time and every vacation in the last year working on this project. We're constantly looking for other contributors and there's several other ways to help including donations. Feel free to join the official room for updates to track progress and please feel free to reach out with feedback!
Additionally, I just merged Multi-account support this week and it will be in the next release. Not sure of any other Matrix client that has this feature, so there's some unique features that we're focusing on to set it apart.
> Additionally, I just merged Multi-account support this week and it will be in the next release. Not sure of any other Matrix client that has this feature
Mirage has this but it's the only one i know of. it also didnt seem to work with cross device signing last i tried it.
Very glad there's other clients supporting this. Thanks for the heads up!
I was under the impression some of the desktop clients had it in the form of swapping CLI flags on start, but it seems to support switching under the settings menu in the latest release. Much like email, many people will have more than one user they'd like to swap between so very glad to see other clients adding this feature with user friendly UX.
Yea, element has support for multiple profiles but you have to run multiple clients to use multiple accounts. It;s a bit like firefox profiles and it works but I don't really count it as multiple account support.
nice, i tried quaternion a long time ago so i wasn't aware it had it now. i haven't tried neochat before even though i use kde. i'll give it a shot and see how well it works
I have a pretty firm belief that matrix will form a core background of the next era and am building a software solution for project and life management that’s completely decentralized on top of it.
There’s a magic here in the interoperability and fact that so much hard work has been done to make it ready. The ability for this and IPFS to work together is pretty remarkable in the scope of what can be created.
Oh, but Matrix is much more than an instant messenger. It's a replicated database with ACLs.
It could theoretically fail in the IM space and still succeed in the data sharing space. For instance, you could build an Activitypub-like ecosystem on top of it.
> ...Matrix is much more than an instant messenger. It's a replicated database with ACLs...
THIS is one of the main reasons that I'm such a fan of the matrix protocol. Yes, the chat use case is by far - for now - the most popular direction...but i can envision many other use cases (not just, say, for IoT devices)!
It’s not clear to me what extent IPFS is already in use in matrix applications. If I want to use web torrents or beaker/hyperdrive instead that should be possible, no? What assumptions does the matrix protocol make about attachments / media uploads?
Haven’t tried developing for matrix yet but I’m intrigued by its inertia right now.
It looks like some of the Matrix devs were thinking about using IPFS for the Matrix "media" repository. It's basically an object store where the Matrix server keeps images and videos and files.
Coincidentally, that spec change proposal looks to have been posted exactly one year ago today. Doesn't look like there's anything concrete yet, but still there's obvious opportunities for combining a content-addressable object store API with a distributed content-addressable file system back end.
Matrix was designed to be extensible and with extreme ability to customize and interact with outside tools. A solid interface on top of Matrix could allow for everything from messaging to transactions to project management - and even massive timeline interfaces. Matrix is an interface for federation at scale - for any type of communication.
I imagine that these eventually become an “OS” that ties and links together peoples interactions through time. And the federation allows people to share timelines / information in a way that allows for new forms of collaboration- ones where it’s less focused on owner - employee relations and more P2P. Email me if you’re interested. I need some final designs made and am looking for developer partners - I have business cases and clients set up.
Matrix isn't P2P. You didn't even provide an email. No one is going to reach out unless you can create something to document at a high level what you think is so special about your ideas.
First, just because they are working on something doesn't make it something. That is like saying... hey I'm working on adding encryption. It isn't there yet, but I can still claim my app is encrypted.
Also, P2P overlays already exist in multiple forms.. Yggdrasil, Nebula, Tor, etc. Yet another example of them trying to re-invent the wheel when it isn't even necessary. Tox already does this.
1) Kill the electron crap. Just look how awesome, fast, funcional, beautiful and feature-rich telegram is
2) Kill synapse. Is close to impossible to run a home server with all that python shit going on. Dendrite is the way I guess, but it is super resource-consuming to have a small home server (and slow)
3) Make it accessible and interesting for the casual john doe: FluffyChat is one possible route
Why is Synapse “impossible to run”? I agree it’s not the most performance but for a small home server it’s quite fast to set up. Dendrite is definitely going to be faster but it also has a lot more complexity (multiple databases, Kafka etc). Synapse is quite simple to understand and reason about.
Running a communication server at home is inherently a bad idea. I have done so for a some years and switched to a Hetzner VM just with this service some time ago and it feels much better.
One of the problems with a server at home is connectivity, because every second your service is not reachable, you are not serving your users well. In general, I would say that I have a very stable connection, but once a year or so I have to disconnect the internet connection for some reason and it doesn't feel right to steal your friends and family the possibility to exchange messages. Furthermore, I had some trouble with the dynamic DNS from time to time, which always caused the communication service to fail.
In addition, my backup strategy wasn't very sophisticated and at some point I had to search 200GB of data (broken filesystem) in order to restore the contact roster of all people on the server (the last backup was a few weeks old)...
So if you really want to, do it, but if you ask me, my clear advice is to run communication services at some professional hosting partner.
If running an Ansible playbook [1] is "close to impossible" for you, then there are a few different companies who will host a server for you. Including the guys mentioned in the main article here.
Sure, Synapse's performance isn't great, but still. Last summer I was able to run Synapse on a 1 vCPU, 1 GB RAM droplet from Digital Ocean. I had 100 copies of a bot running, each with their own room, constantly sending messages and replies to each other. With all 100 going at once, it was super slow. But with fewer bots, or with a lower chance of replying to a message, it worked pretty well. Not bad for like $10 / month.
Also, if you want light and fast, check out Conduit, the homeserver written in Rust: https://conduit.rs/
Re #2, it's a Debian package now which makes it super easy to get running on Debian systems (and probably Ubuntu). I suspect there are also docker images which can also make it very easy to get it up and running without dealing with python deps (I feel you as a non-python-dev, it's really hard to get python apps to run).
2) Synapse works fine for me with 300MB memory to it and 400MB to the db, which can all be run (along with several other lighter applications) on the lowest tier Linode.
> Synapse is a reference "homeserver" implementation of Matrix from the core development team at matrix.org, written in Python/Twisted. It is intended to showcase the concept of Matrix and let folks see the spec in the context of a codebase and let you run your own homeserver and generally help bootstrap the ecosystem.
Is a reference "homeserver" implementation supposed to go into production on a large scale?
That would be the sensible business decisions. Feed new horses, don't feed old horses. But they are hackers and have no idea of management.
I'm really curious, if they manage to burn through 30 million and still keeping Element being crappy. At least thanks to Matrix being an open protocol anyone can develop a better alternative.
I'm yet to find a TUI client for matrix. I've checked those weechat plugins but the python one needs libolm3 dependency which is a hassle to install on my system and the Rust one is not ready.
Element webapp is clunky and slow. Element desktop is an Electron resource-hog. There is a Go client (gomuks) which was very buggy. I've also tried a QT client which was alright but not on-par with the official Electron webapp in terms of features.
And buggy. Element/Matrix is the worst chat app I have to use on a semi-regular basis.
I have to click away three modal popups during every single login, and it doesn't remember logins so I have to login every time I visit the page. It also asks me to verify my login/device on every login because it doesn't remember. This happens on two devices, with two different browsers.
Is that on a self hosted, or on app.element.io?
I have a self hosted, and I just opened it and it logged me straight in - I can't remember the last time I logged in as I use the desktop client.
I just tried app.element.io and it asks if I want to "store data in persistent storage" - maybe you clicked no a while back, and it is still blocked?
Hmm, interesting, those don't really sound to me like the cause. Is there anything in the site settings or anything, maybe it's disallowed from local storage?
For what little it's worth, I haven't run into the need to login on every visit on either FF or Chrome. Which is just to confirm that it's not supposed to work that way.
I'm not doing anything. Same thing happens on Firefox on one PC, and chrome on another. But only for Element, all other web pages have no issue with persistent logins.
Unfortunately, I don't, yet. Still waiting on a decent TUI. I had my hopes up for weechat-matrix-rs[1] but it hasn't seen a commit in two months so I guess it's dead. And so I remain on IRC.
On linux fluffy chat uses a lot more CPU than Element. That's not a compliment for Element, but rather a depiction of the poor state of Flutter apps.
I tried pretty much all third party Matrix apps, if you want cross device signing, there's only Element, an element fork and some of these half working flutter clients.
It's not great. The initial developer for the weechat client did a great job, but the move to rust has pretty much stalled from what I can tell.
mtxclient mostly implements the API calls and some crypto primitives. A lot of stuff still lives in Nheko, because we couldn't figure out how to fit it neatly into mtxclient (like the storage layer, device verification flows, etc). But apart from that, probably. It is pure C++, so you don't even need to use Qt to create a client with it. (In general it may be better to contribute to an existing client though. There are a lot and they could use some help to become more polished.)
I've been reading the Nheko updates in This Week in Matrix with enthusiasm. How are E2EE and cross-signing coming along? Once those parts are fully implemented, stable, and trustworthy, it will look pretty attractive as a replacement for Element desktop.
They are implemented, but I would say there are still bugs in it and it isn't yet 100% trustworthy. Moving E2EE out of beta is one of the goals for the next release though. There are still some minor kinks, but I have been using Nheko as my primary client for E2EE chats for 2 years now. I wouldn't trust it if you know someone is actively trying to get at your data, but for normal day to day chats the current master branch should be good enough.
Things that are currently still missing:
- online key backup: The asymmetric version allows server operators to insert keys and the symmetric one isn't yet supported by any client. I don't use key backup on my account, since I have enough devices that I don't need it and it makes bugs in E2EE harder to find.
- cross-signing bootstrap: You need Element to enable cross-signing on your account once atm.
- A toggle to only send keys to verified devices in a room and warnings if unverified devices are in a room: currently working on this
- Fixing one stupid edge case, where we create new identity keys by mistake, if Nheko fails to open the database and this breaks E2EE for that login. Hard to hit by accident, but it happens quite a lot if you change database code and mess something up. :D
I think apart from that we are in somewhat good shape. I still have a few small things on my to do list and we obviously need to go through the code a few more times to look for mistakes and test it a lot more, but for 0.9.0 that should be doable. After 0.9.0 we'll probably look into fallback keys as well as dehydrated devices.
Good: FluffyChat's CPU usage has been reduced so it no longer burns CPU (nor makes Xorg burn CPU) when idle, only when typing or moving your mouse (with call stacks deep in Flutter event handling).
Bad: It's written in Flutter, and the keyboard/mouse handling still has flaws.
Ugly: The FluffyChat Matrix library used by FluffyChat (https://pub.dev/packages/matrix) requires contributors to sign a CLA where you sign away copyrights/trademarks, and perhaps even become obligated to assist the Famedly company in IP lawsuits.
It absolutely does not work well. It only just barely works if all you need is chatting in public rooms that you joined from another client (e.g. Element). Everything else (joining rooms, sending private messages to people you don't have a 1:1 room with, viewing images sent to encrypted rooms, …) is painful or impossible.
And then there's the "little" issue of it not being able to coexist with wee-slack. That's a bug Python 3.9, not in weechat-matrix, but still.
I mean, I still use it because all I really need is chatting in already joined public rooms and for that it's better than that Element/Electron crap, because it's still a weechat after all, but it absolutely is not ready for any kind of serious usage. It's just a quick hack that sort of maybe works, sometimes.
I personally don't use a virtualenv for weechat-matrix; seems like a bit of a hassle.
Either way, `virtualenv` is a drop-in replacement for `python -m venv` (or rather it was the other way around - virtualenv came first, but virtualenv still exists for different tradeoffs).
It needs quite a few dependencies in its `requirements.txt`. Did you install them globally?
If I use `-m venv`, it doesn't produce the `activate_this.py` file that this plugin needs.
You could use matterbridge[1] to connect & bridge the various new networks including matrix back to a client of your choice - in my case the same znc+irssi I've been using for a long time[2]
In this case for example Matrix has been choosen as the Protocol to be used to connect all manner of Healthcareproviders, Healthinsurances and State Entitys in the Health sector in the future.
This is a highly fractured environment where there is alot of distrust and animosity between all the parties.
I see this e.g. as an incredible chance to provide matrix related services even for small companies in germany.
It’s really cool to see how people can foresee how to monetize these kind of startups whereas myself as a developer have been struggling to think the potential in the business side.
Try not to think about hospitals, but more about all the individual doctors offices that also need to be connect to this environment and don't have to to go through a EU wide bidding process.
E.g. there are more than thousand software solutions that are registered with the health insurance companies to manage patient data and billing processes.
In addition, Matrix has been chosen for quite a few large deployments by governments, so there presumably are large-ish support contracts associated with those.
If that's enough to justify a 30 Million round is another question.
> there are no plans to use cryptocurrency incentives in Matrix or Element any time soon
Note the wording here... "any time soon" is quite different from "no plans, period".
Matrix is a protocol. There's a lot of tooling and applications to be made around said protocol, plenty of which could be sold on on a license basis, support for enterprises etc.
Matrix has a fantastic B2B potential. It's just early.
It should be mentioned that it also allows for distributed authentication providers (home servers). A very important feature and big tech strategy is not hiding this. But you can keep Google, Apple, Microsoft and similar completely out of the loop.
The name of the protocol is very badly chosen though.
Do you know if they have a mechanism for hosted servers with your own domain name yet? This feels like a big thing missing for wider enthusiast adoption.
To be honest, I am no expert on Matrix, but I thought you can just host your own server on your own domain. That was the base assumption for my comment and I hope that is correct. They have a server reference component (synapse) that you could host anywhere I think.
Element's primary paid service is Element Matrix Services [1] which is exactly for that. They run a Matrix server for you, optionally on a domain that you provide.
The proposal that you linked is all about portable identities, tied to public keys. Is that really necessary for Element to host a server on a user's domain?
I would have thought it would work just like outsourcing your web server or your email service. You generate a DNS name and point it at their IP address. Then they get a certificate and start serving traffic for your domain. Easy peasy.
Exactly. The Matrix ecosystem is already used by governments in European countries and healthcare providers as well so that justifies the valuation of this fundraising round.
The enterprise potential for the Matrix ecosystem which includes Element is almost like what GitLab has done but for Git services and much more.
> The majority of the core team is now employed by Element, an independent company set up to hire the team and support Matrix's development. Other contributors are funded by their own employers or donate their own time to the project.
At least they are not fully reliant on donations and they have a solid way of making money.
Matrix / Element also run a private chat service for the French government to get their employees off Slack and WhatsApp for sensitive comms. I bet that has paid a decent support contract.
They won't. Matrix is a meta data sponge hence it is heavily sponsored by the intelligence community. Truly descentralized and peer-to-peer solutions like Jami won't recieve such funding.
Matrix's architecture today means that the servers can see who their users are talking to, and when - but not what (assuming it's end-to-end encrypted). Just like a PGP mail service like Protonmail. Because Matrix stores conversation history on the server (unlike Signal) so you can get at it when from multiple logins, you end up with that metadata stored on the server.
We're fixing this by working on P2P Matrix (as per the blog post - it's one of the main initiatives that the funding is going towards). https://matrix.org/blog/2020/06/02/introducing-p-2-p-matrix explains how P2P addresses the metadata problem.
The whole "heavily sponsored by the intelligence community" thing is a conspiracy theory. It's true that Matrix is popular with government and national security folks and Element gets money from them... but it's because they want the E2EE and data sovereignty for themselves, rather than because they are trying to torment their citizens(!!)
I work at Element. At first blush, https://serpentsec.1337.cx/matrix seems like a fair writeup of Matrix protocol metadata, with examples, by a third party.
My main problem is that many new features seem to leak more and more data. Encryption support is always "will be added later". For example if you want to send a sticker or any inline image you need to upload it to the server in plaintext. Topics and profiles are unencrypted even in "encrypted rooms". Matrix is a pain-text protocol with a couple of encrypted extensions on top. Even worse is that most clients will happily let you use these leaky features in encrypted rooms with no warnings.
I love Matrix, it is actually my primary chat network. But the way these features are getting added makes me really disappointed. You don't make a secure protocol by stuffing as many features as you can then adding encryption later. You build a secure protocol by making sure that every feature added is secure from the start, otherwise it is rejected or needs to explicitly justify why it can't or shouldn't be made secure.
It is interesting that the funding from them happened very early on, at the same time as the design of the protocol itself.
Now it is too late to rethink the design to be less of a honeypot. So the only solution is P2P matrix. But even P2P matrix will need some way to back up the metadata so it’s saved between sessions. So again the honeypot seems unavoidable.
The author admits to using Matrix personally and concedes that it’s better than basically everything but XMPP. It seems his progress was from Matrix to XMPP after personal experience.
The tone of the part about connections to Israeli intelligence doesn’t read as “anti-Semitic” to me, as it’s pointed at motivations of the government spy apparatus and doesn’t make generalizations about Israeli or Jewish people. Though the tongue-in-cheek sarcasm is hard to untangle.
The overall tone is sadly that of someone who has spent too much time making internet memes, but I believe the author is a trained linguist with a sardonic sense of humor.
We're hoping to get it good enough so that it literally is the first choice for new users - and it's only if they consciously want to pin their data (and metadata) to a server that they'd do so.
Who wouldn’t want their data pinned? That is the expected behavior of a chat app today. So to provide a “first choice” experience, they will need to do so. So, how does P2P solve the metadata sponge problem?
'Pinning your data on a server' basically means having a backup so that if you lose your phone or other logged in clients, you can still get at your account. Lots of people are happy to run without a cloud backup of their data - and in fact many orgs mandate that you don't back up data from your clients onto a server somewhere, given it makes it easier to steal.
The addition of threads and custom emoji, along with getting spaces out of beta, might finally mean the migration of my friends from Slack and Discord.
I have mixed feelings about threads. In Slack, it is not obvious whether one should continue discussion in a thread or a new post since the former would hurt the visibility of chat.
Spaces are a way to group channels together according to a topic : they are similar to Discord servers and groups of channels. You can add sub-spaces to further divide your channels, which is better than Discord's flat hierarchy.
So it's just grouping? Couldn't it be done merely in UI?
Also how to divide each chatroom according to a topic e.g. #general, #dev, #off-topic (like #namespaces in discord)
It's more than just grouping. Spaces are rooms under the hood, just like rooms in which you usually chat in Matrix.
What makes spaces what they are is the ability to specify some rooms as belonging to a space, in the sense of a collection. Since spaces are just rooms, this includes other spaces as well (which are then called subspaces). This allows building a tree which can be used for e.g. representing a company hierarchy. A single room can also be a part of more than one space.
Spaces also have the concept of members. Soon support will land for the ability to restrict room joining to the members of the space a room belongs to. This will make it possible to use this as an on-boarding tool. For instance when an employee joins a company, they'd get invited to a company space, allowing them to see all rooms therein and join the ones they need.
There's also a distinction between public and private spaces. Private spaces can be used purely as a tool for personal categorization. This still needs to be supported server-side so that you can have the same view on all your clients.
I'm not familiar enough with Teamspeak to comment, but there's nothing inherently Electron-specific about this. Other clients need to grow support for Spaces, of course.
Well, in teamspeak the basic unit of organisation is a channel, and channels can have subchannels. every channel can be give individual rights which it inherits to its children. basically, exactly what they seem to have introduced with spaces. as someone who still uses teamspeak i found the "we don't have a hierarchy and every channel next to the others" quite odd. good to hear that the rest of the market is now copying this feature though, it's really useful. maybe at some point they'll get temporary channels too.
It's way more than just grouping. It's like directories in a filesystem: you can share them; they have access control; they let you curate your rooms into hierarchies either for your own edification or for the benefit of the wider network. Think of it more like carving Matrix into a set of USENET-style namespaces - or having a global hierarchical filesystem for realtime data.
Matrix people like to claim that it is a protocol, because it is 'governed by the foundation'. Make no mistake, it is not. It is a product.
True foundation directs the development of a standard, and considers the interests of all parties. But in this case, there is just one party that means anything - the company that creates the actual product - and it is obvious that the foundation is powerless to resist any of its initiatives. Which makes the Matrix foundation just a facade, to better appeal to some people.
Matrix is a protocol because... it's a protocol. The spec is at https://matrix.org/docs/spec. There are loads of completely independent implementations of it, both clientside and serverside. Additionally, the spec is governed by the non-profit Matrix.org Foundation (https://matrix.org/foundation).
It's true that we (the team who created Matrix) also created Element as a for-profit startup to fund the core team to work fulltime on Matrix - and as anyone who works at Element will tell you, the reason the company exists is to grow Matrix and make it successful. In an ideal world Matrix ends up being a huge industry in its own right, effectively replacing the PSTN & email industries, and Element ends up with some small (10%?) marketshare alongside loads of other Matrix vendors out there doing their thing.
Just as XMPP wouldn't have happened if Jabber Inc hadn't bootstrapped the ecosystem back in the day; Element has a similar (but hopefully more successful) mission with Matrix. Or, perhaps similar to how Netscape helped bootstrap the open Web.
> Element ends up with some small (10%?) marketshare alongside loads of other Matrix vendors out there doing their thing.
What is a good reason for Element to relegate itself to only 10% of its own market and allow other vendors to pick up the remaining 90%? Can you name a product or service which Element is unable or unwilling to provide that competing investment could make returns on? If you can, why not pivot into that yourself? Can you assure parties investing in Matrix that Element is a trustworthy and synergistic counter-party?
> What is a good reason for Element to relegate itself to only 10% of its own market and allow other vendors to pick up the remaining 90%?
In a healthy ecosystem, the primary implementations do not represent most of the clients and servers.
HTTP for example is healthy because there are many http servers, many http clients, they're all pretty compatible and replaceable, and none of them represent the primary implementation with its own off spec quirks that others need to take into account.
The obvious answer is that it would be jack-of-all-trading, and others would focus on one area, do it better, perceived to be better, or just differently.
> effectively replacing the PSTN & email industries
I could see a path to Matrix replacing email (and it's the only one of the current candidates I would be happy with doing that), but how could it end up replacing the telephone network? Does it have voice capability?
Did you measure the latency? Latency should be below 100ms to have a pleasant conversation. Talking over a dedicated low-latency app like Jamulus is much nicer than the enormous latency in video calls.
I have not measured the latency but if both participants are on wifi there is usually no perceptible latency with my participants. (US -> UK calling daily)
If either of us is on mobile, sometimes latency can creep in, but this also happened on whatsapp too. That's the nature of mobile IMO.
what are you talking about? Are you confusing Parity with Protocol Labs? They are completely unrelated companies (other than both beginning with the letter P :/)
On 'loads of completely independent implementations': how can those independent developers stop Element from pushing some hypothetical changes to the protocol you would want to introduce against their wishes?
They'd object, either while the MSC was being drafted, or during the FCP (Final Call for Proposal) period. If the Spec Core Team voted to merge something which the community didn't believe was aligned with Matrix, then they'd appeal to the board of the Foundation (i.e. the Guardians), who are legally obligated to ensure that the only things which get merged into the spec are aligned with the stated mission and values of the project (as per the Mission and Values sections of https://matrix.org/foundation). If the Guardians fail to adhere this, they would complain to the UK non-profit regulator, and the foundation would get fined/dissolved. The recourse of the guardians would be to either get the Spec Core Team to change their mind or to replace the Spec Core Team to get back in line with the mission. The process for doing this is laid out in the Articles of Association of the foundation: https://matrix.org/media/2019-06-10%20-%20Matrix.org%20Found...
No, those are not the safeguarding positions; the Spec Core Team are the folks who approve PRs to the spec. Originally they were 50/50 element and non-element, although it's drifted thanks to members of the team choosing to work at Element so they can work on Matrix fulltime.
The safeguarding positions are the directors of the Foundation (aka Guardians), which is very deliberately majority non-element (3:2).
Why not spend your time improving XMPP rather than complaining about Matrix?
I'm criticizing matrix because it is a product of NIH syndrome [1] that should not have existed in the first place.
If you wanted an open federated protocol, you could have spent your time adding to an existing federated network. Everything you do with matrix is easily possible with XMPP. Instead, you want a protocol fully controlled by you. I oppose this goal and spread of such products.
XMPP failed for normal users. When I switched to matrix years ago it was because the XMPP ecosystem was totally inconsistent. The best client was on android but no desktop clients integrated properly with it (send files, encryption, roaming) especially across multi OSs. I moved to matrix in the early days and all those problems went way.
What you see as NIH I see as building something from the ground up that works better than what was currently available.
No. Matrix could just build Xmpp clients for all platforms consistently, and it would work out much better than building their own atrocious server. It is a very typical NIH-approach.
Also, what you call a totally inconsistent ecosystem is what real ecosystem looks like. Matrix looks better in this regard precisely because it is not a protocol. It didn't yet deserve to have such problems.
I also don't think it'll ever be able to successfully transition to a real ecosystem because Arathorn here always brushes off concerns about governance of the protocol, which shows that he doesn't have the mature understanding of the nature of the problem.
Unless something has recently changed, XMPP also failed on the server side for normal users:
- Finding a practical provider is nearly impossible, because all of the major ones closed their public XMPP service years ago, and most people don't know what qualities to look for in a small provider, let alone understand why those qualities matter.
- Even if they get help from a friend and manage to find a reliable server that supports the magic combination of XEPs that are needed to make things work, chances are that server is no longer accepting new users.
- Even if they manage to get an account on a featureful[1], trustworthy, stable, free[2] server, many don't last more than a few years, so there is a high chance that the user's new online identity will evaporate before long.
[1](Required features include end-to-end encrypted group chats with offline delivery, among other things.)
[2](Yes, free. That is critically important for mass adoption today.)
I'm not a normal user, in the sense that I have far more technical knowledge than most people who use messaging services. I actively used XMPP for at least a decade; probably closer to two. I tried last year to piece together an XMPP-based solution that my friends and family could use, but even I was unable to solve all the problems I found in a way that would work for normal users.
And then there's the client side, which is also problematic, as soupbowl said.
This has been the state of things for quite a few years. The only people I still see pushing for XMPP are people who have major blind spots. Some of them have experience only with small groups, and have not considered how a whole world of people conversing presents different challenges. Others (usually tech folks) have had a good XMPP provider and comfortable client software for so long that they have forgotten how much knowledge it takes to get set up in the first place. A few are people who run small for-profit XMPP services or develop XMPP software, aka conflicts of interest.
Dear Jabber, I'm sorry. I liked you. I had high hopes for you. I might even still consider you for niche purposes. But as a general purpose messaging network for regular people, you have failed. It would take a lot of effort and resources to make you viable, and I don't see any sign of that coming. The closest you came was when Google and Facebook embraced you, but those days are long gone.
Meanwhile, Matrix is succeeding. The rough spots are being fixed. The bloated clients are getting competition. The missing features are appearing. Even as a work in progress, it is already usable for some of us, and it's consistently moving in the right direction. Importantly, I can tell a regular person where to get it and (often with no help) they can be chatting with me in a few minutes.
It's permissively licensed FOSS. If the primary maintainers go against the community and can't be reasoned with it will be forked. If a fork doesn't end up having enough momentum to maintain it then perhaps the original wasn't actually doing such a bad job after all.
Not really. You are ignoring the network effect. The vast majority of the matrix network, including the by far the largest node, is using the software developed by Element. If they change something, any competing spec will lose access to federation, and, subsequently, users.
Every single time matrix comes up, people make this argument like it's some sort of massive illumination. Guess what? Every protocol started with a single major stakeholder. The internet was the military, HTTP/2 was google, and JS was netscape.
The foundation is not a facade. It has a rather clear governance system, and while it is predominantly populated by Element employees, that's mostly because most people passionate about matrix end up working there. When the fondation was set up, it actually had a 50/50 split between community members and elements employees in the core team, but the community members ended up joining element.
What makes matrix a protocol is that absolutely anyone can implement it, and anyone can get involved in the process to improve the spec.
> Every single time matrix comes up, people make this argument
it's often the same group of people too... Andrew_nenakhov "forgot" to mention it but he develops a XMPP client and likes to pop up in the comments ofpost on Matrix to complain
edit: I'm not really taking a side on either XMPP or Matrix, I wish for both to succeed but I'm currently disappointed by both. I'm just getting a bit tired of XMPP fanboys spewing FUD every time Matrix is mentioned
Mainly messages getting delayed or undelivered (often on the IRC bridge), everything getting randomly very slow, encryption randomly breaking... sadly what I consider the usual for Matrix.
I recently had a particularly vexing issue in a small encrypted room of 3 people, new messages were shown as undecrytable and then only readable a few hours later, we never figured out why.
I re test it every few months/years because I hear it's getting better, the server is properly configured now, encryption system was remade, there is a new client, etc...
Losing my whole chat history each time made the endeavor even more frustrating. I know not everyone keep logs but I can search my Mails and Irc logs from 20 years ago and I find it really useful.
Sorry for the rant but since you asked. Like I said I fully support your work on Matrix, I just find it so ... frustrating and it make me sad because I really like the idea.
I hear you. Personally I'm hesitant to recommend anything in the Matrix ecosystem in large part because there are mutually verified users on my server who haven't been able to talk to each other in like 10 months, and the issue thread has been stagnant for about that long. Frankly it's fine that there are bugs and it's even fine that there are bugs impacting core functionality for such an ambitious project, but it's frustrating that this ecosystem falls down so hard when it comes to providing an accessible experience for non-technical users (i.e. when things don't work, it's extremely ungraceful and unclear what exactly is happening or why).
Thanks for spelling it out. You really shouldn't ever lose your chat history, but it sounds like something is going horribly wrong on your encryption.
As part of the funding we're setting up a dedicated crypto team (at last) to focus on nothing but the remaining encryption problems. It's super embarassing that these failure modes can still exist today though - sorry :(
Same complaint here, I really like the project, hosted a server for a while, but ultimately the problems of verified users in channels were too much of a hassle.
To be fair, other E2E chat solutions have similar problems, like Signal. It feels more to me like we did not properly crack this problem yet.
I have yet to try it again but definitely want to.
What I do has little do to with Matrix masquerading as an open internet protocol while being fully owned by one commercial corporation. It is roughly the same to XMPP as AMP are to HTTP. That is the only reason I oppose it.
If it wasn't, I would not rule out developing a Matrix client (though doubtful, I don't really like the protocol and implementation)
This is where I’m getting suspicious. 30M isn’t a trivial amount of money…
@Andrew_nenakhov’s comment is on point. Normal initiatives of this kind are organized differently. This doesn’t look good regarding the future stability of the initiative.
---
On top of that @sprash has mentioned some valid concerns about Matrix being a potential metadata sponge (below in the comments).
Let me add some food for thought for you. Maybe you’re going to get suspicious too.
a) On the Matrix website, the one with the news about getting the 30M, we’re being given only two kind of information: who’s behind the leading round regarding the investments made, and what features are going to be developed due to that donation. Now, we know nothing about who’s actually giving the money, because both Protocol Labs and Metaplanet serve as proxies here. On top of that pointing the reader to the new features part seems to me like a: „forget about the money part, take a look on what we’re going to do with that, take a look on all those shiny things!!!”.
b) Both Protocol Labs and Metaplanet are kind of famous companies (proxies). The second one invested in the Boring Company for instance. It just looks so good. It’s like a miracle. Matrix is getting attention it deserves… But why on earth that happened? (take a look on (c)).
c) Protocol Labs has strange ties to World Economic Forum [1][2]. They are interested in Protocol’s work in the internet space in general. I don’t like that at all. I fundamentally don’t trust WEF and I consider whatever they „touch” cancer.
---
I’m on the market for something that’s going to help me and my friends replace Signal. Matrix looks very promising, but after a careful consideration it also looks like it really might be a metadata sponge. Yeah, it’s all rumors, and establishing real information about the parties involved and their motivations isn’t possible. But a suspicion is enough. It looks almost too good...
Metaplanet is the investment fund for Jaan Tallinn, one of the four founding engineers of Skype. He is definitely a very positive sign for this investment in my eyes. Having worked with him a long time ago and followed his doings and presentations [1] it gives me much hope for Matrix, especially as I run my own homeserver and really like the vision.
Element being made by the same people who made matrix, how much difference is there?
Is it not possible to see the source code? Is it not possible to partake in the development process in the same way most other open source projects work? Is it hard to connect to the network?
I see it more as a net positive given what is known.
But everything is based on a hunch with a negative worldview as a lens to view the information with, that just how it feels when giving out these speculations. Politely understand, I'm not saying you are wrong, but I am saying it is wrong to assume malintent due to lack of information.
And given their goal of being a general underlying protocol, to be used in different specific professional industries, it would be very damaging to close down feedback or the protocol in general, from outside influence. A hospital might need a specialized client to handle the needs of the profession, while a ministry might have a third, one does not fit all.
But I see the skepticism, because if the protocol can be used by one party, which ends up hosting most of the servers, to gather metadata, then having widespread use would allow insight into a rather large dataset of people and countries. But the onsite premise of this software, is the whole reason that etc. the French government started to back the protocol and mistrust for foreign communication services.
If you have secrets, why would you not just host this yourself? And there's the big difference between google and matrix, you can control all your data yourself, if you want. Totally block outside communication, setup private tunneling, separate a virtual network etc. I don't think twitter/whatsapp/whatever allows you to host their server infrastructure and block off access :-)
Please don't break the site guidelines like this. The rules are clear:
"Please don't post insinuations about astroturfing, shilling, brigading, foreign agents and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email hn@ycombinator.com and we'll look at the data."
This is for the extremely good reason that most (I do not say all, but certainly the overwhelming majority) of such perceptions prove to be imaginary when we investigate the actual data. We're still always willing to investigate when people ask—but you need to follow the protocol and not post garden-variety insinuations about it to the threads.
I think people complaining about echo chambers get downvoted for being annoying and without substance, which unfortunately validates their victim complex.
The root comment of this thread isn't "oppressed" - at least he put effort into the post, and others in their rebuttal.
I welcome these alternative suspicions and will be taking them with a grain of salt. We'll see what the Matrix ecosystem will do with the money. Until then, we can only sit back and wait.
> Anytime any legitimate criticisms get brought up they are quickly downvoted.. here on HN they get flagged so you can't even see them.
First time?
I have the suspicion that someone on HN setup a downvote bot on me so that for any comment I post, it is immediately downvoted even when I follow the 'HN guidelines' and submit tons of evidence to backup my claims.
This innocent comment will probably prove both of us right on our suspicions. Ultimately I want to be proven wrong here, but we'll see.
You might like XMPP then - IETF Internet standard, always had decentralization and e2e encryption. I still don't understand why so much energy was invested in building a seperate ecosystem. Matrix claims to be fundamentally different, but all their major selling points (dencentralization, e2ee, open protocol) were already there. And since the Matrix encryption protocol is incompatible with all the other ones there's currently no way to securely communicate with someone outside their network.
- encryption wasn't really there (and still is experimental)
- decentralization does not exist to the degree that Matrix provides it
And Matrix is fundamentally different. It works somewhat similar to git compared to XMPP being more like IRC, which results in a completely different form of decentralization.
E2EE is different as well - even if both are based on the Signal Protocol: Matrix encrypts for groups of people instead of single devices
I doubt Matrix would be where it is if they tried to bend XMPP
Maybe it failed in the consumer app space because it couldn’t keep up with user experience expectations. But if that is the metric, then Matrix already failed too, right?
One new server + consumer app combo could revive XMPP for consumers quite easily.
Obviously this is true of any encrypted chat system. Anyone could be recording your encrypted network traffic as we speak, your conversations will be busted wide open! It's nothing to do with Matrix.
If you're talking about the fact that Matrix stores your encrypted conversation history by default on the server: a) you can set history retention per room, b) if we saw a vulnerability in the encryption we could always go and re-encrypt the history (although it's a bit of a lost cause by that point :)
> On the other hand, if encrypted data is shared publicly on DHT, a replicated database, a blockchain or similar, in year 2050 your nephews will see grandpa's entire message history.
No, Matrix isn’t a public database or a blockchain. The conversations only are only replicated between the servers whose users participate in that given conversation.
You might as well be panicking about PGP archives getting compromised, or backups of devices with Signal history on them, etc.
> You might as well be panicking about PGP archives getting compromised
I don't have a strong opinion on that, but this doesn't sound like an unreasonable thing to worry about. Maybe 20 years ago it seemed like some sci-fi stuff and nobody really thought about it. But then, let's be honest, nobody really thought about e2e encryption back then either. Now this stuff may be not truly an impending disaster yet, but, actually, not so far from it either. Not a big "no-no" yet, but definitely something to be thinking about. And, honestly, I do actually feel uneasy about trusting any secrets with 50+ years expiration date to some integer factorization crypto. Maybe there won't be any practical possibilities to break that in the next 50 years, maybe there will, who knows: but it simply isn't so outrageous of an idea anymore to bet against it. And that's kind of the purpose of cryptography: exaggerating even slightly outrageous possibilities.
Weird objection. I don't think this is solvable even in theory.
I mean we have to encrypt with what we have, right? They could use lattices or something (my impression is this would be, er, hard on the battery, but that's a vague impression), but those could be cracked as well. They could be cracked first!
Let's just say it's a risk I'm willing to take, given that the alternatives appear to be either my messages being public right now, or communicating by snail mail and carrier pigeon.
If I encrypt a TCP connection with AES (e.g. SSL) between my home and your home very few attackers have the ability and budget to capture that traffic, store it for decades and break AES with some quantum-or-whatever computers in year 2050. NSA and perhaps few others.
On the other hand, if encrypted data is shared publicly on DHT, a replicated database, a blockchain or similar, in year 2050 your nephews will see grandpa's entire message history.
That's a reasonable point I suppose, although a private Matrix server is just a fat peer from this perspective. Unless its database lasts 50 years, those messages are just as gone, and Matrix (I think?) uses TLS in addition to E2E.
Score a point for urbit I guess: any channel is limited to those peers participating in it, so Mallory would have to get her hands on one of the planets which received the messages. There is no central point of failure because there is no privileged server.
It relies on the idea of encryption being safe forever in the same way any other program does. If somehow the encryption used is broken you will have a lot more to worry about than your messages.
"Perfect Forward Secrecy", better termed "Forward Secrecy", allows old messages to remain secret even if the long-term secrets are leaked.
If current cryptographic primitives are fundamentally broken, all data can be decrypted if it is saved. This is why it is safest to destroy everything if you are worried about threats in the distant future.
Got it. So the concern is that there's no support for time-based deletion of messages? That is on their public roadmap, and I think it's reasonable to assume that'll be deployed before modern ECC is broken.
> time-based deletion of messages? That is on their public roadmap,
How can deletion of a sent message be enforced? I realize that some messaging services offer this feature, but aren't they all misleading at best? Even on a centralized service with a trustworthy admin, the recipient can always copy/paste or take a screen shot.
The main concern is that the encrypted data is stored on the server long-term. The longer it is on the server, the more likely it becomes that it is saved by an adversary.
If data is only stored for a minimal amount of time, we lower the risk of an adversary acquiring it
Perhaps because the vast majority of points in the article are obviously false or exaggerated out of context?
Needless to say Matrix servers and clients don't send any data (private or otherwise) by default to central servers. The only central services we have are the identity lookup service (i.e. map phone number & email to a matrix ID), which is strictly opt-in and various anonymous stats reporting (which is also strictly opt-in).
This doesn't seem to have any reasons to avoid matrix that I can see. The whole bridges section is strange since that's set up by each homeserver admin, and you can just.. not do that.
Matrix/Element is the most promising messaging platform from a privacy standpoint, but I wish that they didn't chose Electron for building the Linux client...
> However, there are no plans to use cryptocurrency incentives in Matrix or Element any time soon.
Good.
At least with this funding, I can clearly explicitly see they are NOT implementing a secret cryptocurrency coin to be listed on an exchange, but instead they are focused on improving the security and privacy features of Element and Matrix.
> instead they are focused on improving the security and privacy features
Hopefully they also improve the UX and new user onboarding experience in order to gain wider adoption. I really want to promote Matrix for communities where I am involved but it lacks the product-orientation of Discord and Slack.
They're making great progress! There's still more work to do, but I've been very impressed by the improvements made by the Element team over the past year, ranging from many small details to large usability features like the UI for spaces as an easier way to organize communities
I've just decided to give it a try and honestly, their apps are a travesty. Even Signal, with all the criticism it gets for its UX and lack of certain features feel more mature.
I've tried Element and FluffyChat on iOS. Element is very slow. They messed the sign-up screen somehow and iOS suggested a "strong password" but didn't remember it, or didn't assign the log in to it. I went to generate a new password and couldn't log in since it required me to confirm my session from other devices, then gave an error that I have none.
FluffyChat has a very unfriendly log in screen that gives zero explanation about Matrix or how you should type in your login with the server. Also, no validation (they could try to adjust your login with @ and : symbols automatically if they see something is wrong).
It's not like I want to dunk on their developers, but it's hard for me to see this protocol and its apps getting many consumer users when it's so unfriendly and alien to them.
Yes, some government European agencies and old-fashioned corporations who want an on-premises chat app would use it, but I don't care much about them.
Just looking at their GitHub, they have an ridiculous amount of 7000+ open issues (5k on Web, 1k on each Android and iOS). Assuming they'd use a generous 1/4th of the money to fix outstanding bugs, assuming no duplicate bugs, and assuming a 100$/hour salary for the developers, they can spent on average about 10 hours to solve each bug (30000000$/4/7000/100$).
Many issues are pie in the sky enhancement / feature requests that may or may not be implemented some day. There is no intention to drive the number of open issues to 0 just for the sake of it.
As long as Element and Matrix continues to grow, I expect the number of open issues will grow indefinitely, and that is a sign of success.
The biggest thing i'd like to have would be bots in fully encrypted chats and the android client to not break the encryption between clients all the time.
Everyone who thinks that because Matrix is Apache v2 license, it will remain permissive open source is ignoring the reality of an active project. If Matrix changes license tomorrow, the old code will still be Apache v2. But are you going to fork the project to keep it Apache v2?
For some data point, look at recent relicense of MinIO, Grafana, Loki, Vector.dev etc.
Top comment right now points out that Matrix doesn't require copyright assignment, which means they have to get permission from every contributor or rewrite the code in order to relicense.
They don't. They can fork the "apache v2" version and start adding non apache v2 code given they are the primary contributor. If they own the trademark, they can call the new forked version "matrix".
What non having copy right assignment means is that they can't change the license of existing stuff. But they can change the license of future stuff using existing apache v2 licensed code which is permitted.
I want to love Matrix, but it still hasn't got a real native macOS client (not qt, not electron, native one made with Cocoa). It's really a shame. Though I do see its potential as a protocol, and the nice part is that it's federated.
My mistake then, sorry. Nearly every other client on that page that I've tried has gotten better over the past year, so I was hoping Seaglass had moved forwards as well.
I think Libera is (and only intends to be) restricted to catering to the pre-existing Freenode community; their sights are not particularly set on expanding/competing with newer platforms any more than the Freenode community's were. They just cater to people who like & want to stick to IRC, for whatever variety of reasons. I don't see any "growth" (nor "shrinkage") happening here beyond migration of users from Freenode.
Discord is not open-source, so I don't see how it's relevant; it's "communities" are primarily gamers & streamers. While there are some open-source communities based on Discord, the same goes for other closed-source platforms such as Slack & Telegram, and I'm sure the number of software development communities on Slack is (sadly) much larger than on Discord.
Of actual open-source options: Gitter, Discourse, Rocket, Mattermost, etc. - Matrix would seem to be competing relatively well.
The server is closed-source, which is all that matters for centralised platforms.
An open-source client would be relevant for something P2P like SSB/Manyverse*, but for all other tech the sourcecode of the server will be your primary concern.
* And even with something like Manyverse, the sourcecode of things commonly used as "de facto servers", like SSB "pubs", ends up still being extremely relevant in practice just because of the UX of using the platform.
Many people use Libera & Matrix interchangeably (although the bridge hasn't been perfect so far, but we're working on improving it). You can get to #foo on libera as #foo:libera.chat on Matrix and it should Just Work™.
Libera retained like 90% of the freenode channels, with maybe 5% jumping ship to other IRC networks, mostly OFTC, and 5% jumping ship to Matrix, Discord and Slack, from the posts about channels leaving freenode. Libera is also bridged to Matrix, so Matrix users can participate in Libera channels, so there's also a decent amount of people using Matrix as a glorified bouncer.
Very few new communities are setting up on IRC. My impression is that until the Freenode meltdown, Discord was most common, followed by Matrix, then Slack, but the freenode disaster seems to have benefited Matrix more than Discord or Slack.
That's if you look at official channels, if you look at user counts in unofficial community groups as well, Discord has to be way in the lead. The Python community discord has about as many online users as Libera in its entirety, for example.
Others have mentioned Discord and Slack being closed source, but I'm interested in Zulip as an alternative. I really like the "branch off a topic at any time" that leads to proper distinct threads of conversation that get much easier to follow. And the interface so far seems pretty polished and seamlessly responsive, with rich keyboard shortcut interface too (which I'm yet to learn tbh). I hope it too continues to grow as a good FOSS option.
Sure, but Discord is more closed than GitHub - at least with GitHub the core part - ie the git repos - can be fully used with the standard open-source git client. If github decides they want to fuck you over, you push your repo somewhere else and go on with your life (issues etc will need more work). If Discord decides to fuck you over, all your content and participants are gone.
I think IRC vs. Matrix does not exist.
There is a certain decision what is going to be the main communication source, but then you are going to bridge whatever you have on IRC to whatever you have on matrix.
I wonder. it were to be a non-compliant of Matrix Foundation guideline if the federate feature can be turned off at the server-side, just to contain the metadata leakage. Just askin’.
I hope fifty bucks out of this go toward Element on Android not slapping together separate paragraphs. And another hundred to display images that are larger than 5.5 mb.
No, the foundation has 5 directors. Two are the people who started the project in the first place (me & Amandine); Three are completely independent: one is a university professor, one is a decentralisation tech lawyer, one is CEO at Parity (and there is zero relationship of any kind between Parity and Element). The foundation is very deliberately structured so that the Element people are in minority control.
Upvoting before you get flagged... It appears Matrix is trying the Microsoft approach to marketing. Gaslight the public until you become too big to fail.
Element is strange, Ive tried to connect a buddy and he told me that he cannot read my msgs depsite I can read his ones. So, we decided to switch to xmpp and it works great for us.
1) Element or other matrix components do not require a copy right transfer. That means Element is hard to re-license under another license than its current one.
2) The license for Element is Apache 2.0. A fine choice for any OSS project looking to maintain a healthy ecosystem of contributors for decades to come.
3) The ecosystem has a diversity of stakeholders and contributors outside of Element the company maintaining various components, integrations, etc. It's an ecosystem that already serves many millions of users.
4) Not all the Matrix components are under the Element umbrella (see 3). Element is probably dominant in this community but it's based on merit rather than ownership. E.g. the Matrix foundation is mostly run by people outside of Element. Even the Element apps have contributions from outside Element the company (see 1).
5) Decentralization is at the core of the Element sales pitch. They are unlikely to want to walk back on that; or even be able to do that without damaging their credibility. For better or worse, that's what they are selling and stuck with. And they seem successful with it too. Hence the investment.