Element raises $30M to boost Matrix | Hacker News Reader

Element raises $30M to boost Matrix

matrix.org

809 pointsSami_Lehtinen339 comments

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)

What do you mean by "kept with the original license"?

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.

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 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.

Correct, also a feature, not a bug.

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.

They're welcome to try, of course.

Examples of permissively licensed code being used in proprietary systems abound.

Has anyone ever successfully copyleft-jacked such a project? I grant that it's possible but I'm not aware of it actually happening.

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.

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.

[1]: https://lobste.rs/s/emxymp/introducing_p2p_matrix#c_ilr501

Lots of confusion here.

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, if you read the Element blog post at https://element.io/blog/element-raises-30m-as-matrix-explode..., you'll see that Element is explicitly default-alive.

> repeatedly needs to seek funding

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 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.

[0] <https://www.hackea.org/notas/matrix.html>

[1] <https://serpentsec.1337.cx/matrix>

[2] <https://www.hackea.org/notas/matrix.html#facing-the-real-and...>

no, the "phonehome stats" i was referring to are the opt-in anonymous aggregated usage stats that synapse provides: https://github.com/matrix-org/synapse/blob/master/synapse/ap... etc.

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.

Thanks for the clarification.

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

What other projects would be an example of a fast growing open source project with lots of development and that are highly distributed?

You mean like wordpress.org ?

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.

Those have their place, but so does Matrix.

It's really time for dendrite to mature as synapse is pretty heavy. I think a lightweight home server will really help adoption.

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.

Does Apache 2.0 license protect from Embrace, Extend, Extinguish (Microsoft) or from Embrace, SaaS, Tax (AWS and the like) in any way?

No. Like BSD and MIT it cannot protect from prorietization, tivoization and SaaS. You need GPLv3 or AGPL for that.

Gplv3 doesn't protect against saas

That's why I wrote AGPL in the sentence.

Yes, but your sentence suggests either of those would be protective against all of the former.

It is a bit more nuanced than that:

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.

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.

So, that's a feature not a bug.

> 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.

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.

Can you elaborate? This does not make sense to me

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.

LGPL v3 didn't make things better.

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.

The MPL v2 license would be a better choice. It offers the same kind of terms and it explicitly compatible with the GPL licenses.

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.

This can lead to accidentally violations.

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.

> 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.

This is all working as intended.

I don't think you are correct here: https://www.gnu.org/licenses/gpl-faq.en.html#WhatDoesCompatM...

> 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.

---

Taking this to the MPL example: https://www.mozilla.org/en-US/MPL/2.0/

> 1.12. “Secondary License”

> 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.

First you wrote:

> There is no such thing as a GPL compatible license

...and later on:

> MPL 2.0 is compatible with GPL

If you want air quotes around compatible, I can add them. However the entire point remains.

It is GPL compatible because the GPL licenses can explicitly be added to it. Adding the license requires all of the restrictions that licence brings.

Is your entire point that GPL implements copyleft?

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.

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"

please, stop comenting about this topic.

you are wrong about basic gpl code linking concepts.

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.

The Element foundation should use some of that sweet money to:

1) buy FluffyChat and some serious UI designers, because Element is probably one of the worst matrix clients in terms of UX.

2) fix decryption issues that happen randomly even by just using Element on the matrix.org server: https://github.com/vector-im/element-android/issues/1721 as it's a real show-stopper once you hit it

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).

> because Element is probably one of the worst matrix clients in terms of UX

I'm genuinely curious why? I use it on desktop and mobile, and I haven't found it lacking in anything? I've heard this said before, but I don't get it

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 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).

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.

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)

My suggestion, again: buy FluffyChat. Add important missing features, such as cross-signing. Make it the default client.

You can keep element for advanced users.

I'd argue it's still not a great client for tech users either, but I see an evolution in that direction more likely than the opposite.

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 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.

[1] https://github.com/vector-im/element-ios/issues/3762

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.

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

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?

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.

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.)

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.

Matrix is a protocol. Element is a reference app built on top of that protocol, and Element looks like Slack/Discord.

Other apps built on Matrix do not look like Slack, e.g. Fluffychat, which looks very similar to Signal.

But don't you still have the same server paradigm on Fluffychat as you do with Slack/Discord? That's very much not like Signal/WhatsApp.

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.

Fractal and NeoChat are two more Matrix clients. Fractal builds on the matrix-rust-sdk crate.

https://invent.kde.org/network/neochat https://gitlab.gnome.org/GNOME/fractal

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.

It's funny, but I can not agree more.

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.

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)

It's just an alternative Matrix client built with Flutter. It works with any Matrix server.

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.

Agree wholeheartedly here.

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.

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.

https://syphon.org

https://github.com/syphon-org/syphon

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!

https://matrix.to/#/#syphon:matrix.org

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.

https://matrix.org/docs/projects/client/mirage

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.

Quaternion and Neochat have multi-account support as well.

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

It would be nice when you're advertising on your UX, to have a screenshot of your application on the website.

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.

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.

> Matrix isn't P2P

Incorrect.

https://github.com/matrix-org/pinecone

It's nowhere near mature/stable, but they are definitely working on it.

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.

This is a very bold claim. There are a lot of projects and protocols to do so.

Matrix was not designed with that goal in mind.

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.

Here's a sneak peek at some of our interfaces:

https://www.icloud.com/sharedalbum/#B165qXGF1GxreFs

The very same can be said of XMPP, ActivityPub and even XHTML. It's far from enough.

Even email can carry arbitrary payloads, federates natively and scales extremely well.

Sneak peek of the interface we're building on top of matrix - a timeline focused universal interface for projects

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.

https://github.com/matrix-org/matrix-doc/blob/travis/msc/ipf...

Magic will be gone when there is no mass adoption due to bad UX. And UX is not that good right now.

This. They really need to invest in a better UX above anything else right now, imo.

Really? I've been extremely happy with Element.

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)!

Nice! Now please:

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.

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.

> 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?

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/

[1] https://github.com/spantaleev/matrix-docker-ansible-deploy

Conduit's homepage says:

> Note: This project is work-in-progress. Do _not_ rely on it yet.

Last I checked it also didn't support federation.

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.

3) Yes

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).

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.

How do people connect to matrix?

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.

Fluffychat [1] is probably the best alternative client, written in Flutter. But it is also missing a lot of features and is not exactly polished.

[1] https://fluffychat.im/

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.

Nheko is not perfect and lacks polish in some places, but I like it a lot, and it supports cross-signing.

Appreciate the comment, last time I tried it all of this was missing. Seems like it's a fully fledged alternative now.

I'll try it out. Seems like they implemented most code in a mtxclient library, so it might be possible to reuse it for other clients.

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.

I can vouch for Nheko. It’s fast as well (native code with Qt?).

Yes, most of it is Qt quick, some parts are still Qt widgets AFAIK.

Subjectively speaking, it's one of the fastest and most fully-featured clients: it even supports desktop sharing with pipewire and gstreamer.

It's a lot easier to use once you get used to the Ctrl+K shortcut to select a room.

The Rust rewrite is stalled but not abandoned, there's just been a bit of a slump due to time constraints. Which features are you missing the most?

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.

Schildichat works between devices, I get notifications on both riot.im element and schildichat on Android, as well as on my desktop.

Maybe I am unclear of what cross device signing is

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.

Sounds like you log in from a web browser, but clear local storage (or cookies) at the end of your browsing session?

I log in rarely enough that this doesn't accommodate me: my most recent browser login must have been two years ago or so.

Any other website with login manages to remember my login. Not sure what causes it, but it's not fun.

What are the modals you have to dismiss? That doesn't sound familiar to me at all. Could have something to do with it?

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?

weechat-matrix works well; you should just install the libolm3 dependency.

I tried it before but the other problem is that the plugin seem to _only_ accept `virtualenv` method of python virtual env handling which I'm not familiar with. https://github.com/poljar/weechat-matrix#using-virtualenv

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.

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.

> How do people connect to matrix?

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.

[1] https://github.com/poljar/weechat-matrix-rs

The author appears to be working on the matrix-rust-sdk which is a dependency of that plugin pretty consistently for the last month: https://github.com/matrix-org/matrix-rust-sdk/commits/master

I'm using Fractal several months, working fine.

Fractal is nice and looks great on GNOME, but no e2ee and uses more CPU than Element.

> uses more CPU than Element

0.25% CPU right now, ~10 channels, some of them are 1k+ on Libera.

Hope e2ee arrives soon in Next branch.

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]

[1] https://github.com/42wim/matterbridge/

[2] https://xkcd.com/1782/

How will the investors get their money back on this investment?

Self-managed Slack / Teams alternative for enterprise users?

I'd rather see Zulip adopted.

That's fine, I'm just exploring monetization options, not making any claims of superiority.

Seeing the Rust-lang zulip has absolutely ruined slack for me.

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.

Right but maybe you don't want to host your own server, but do want your own domain. Like emails.

That's not possible yet, see

https://github.com/matrix-org/matrix-doc/blob/neilalexander/...

That's not possible yet, see this proposal

https://github.com/matrix-org/matrix-doc/blob/neilalexander/...

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.

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.

[1]: https://ems.element.io/

Yeah, they've had that for a long time. I ran my own server on my own domain name a couple years ago or so.

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.

That does not answer the question.

They receive shares of the company's stock, which is a security that can be exchanged for other forms of value, including money.

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.

Interesting take. Do you have any reference to back these allegations up? (Honestly interested)

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.

What's your take on this analysis? https://lukesmith.xyz/articles/matrix-vs-xmpp

It seems like the connection to Amdocs and their interest in collecting metadata for surveillance is a stain on the privacy-focused image.

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.

that analysis seems to be a hatchet job in favour of XMPP, complete with a deeply unpleasant undertone of antisemitism...

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.

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.

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(!!)

Congratulations on the raise and keep up the good work!

It's a simple fact: a distributed/p2p application that cannot be monetized does not generate revenue.

If you read the post, the very first work item they mention is

> finish building out P2P Matrix and get it live

ps: p2p is nice to have, but also comes with a lot of problems and and probably shouldn't be a first choice for many users.

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.

https://news.ycombinator.com/item?id=27906336

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.

Meh that is a pretty terrible place to try and make money. The only thing worse may be trying to sell to schools.

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.

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.

Element sells business plans. [1]

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".

[1] https://element.io/pricing

Slack's valuation in 2019 was over 20B. 30M ain't much.

Why do you think Element is trying to optimize for short term valuations?

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.

I really hope they'll use the money to fix the confusing account creation and maintenance because I cannot use Element anymore for some reason.

My main gripes are that you cannot reset a password by username, and you cannot add a phone number that belonged to a deactivated account.

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.

Is "spaces" similar to Discord channels? (#)

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 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.

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.

This reads like they reinvented teamspeak, but this time its electron

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.

Teamspeak 5 may be a Matrix client: https://news.ycombinator.com/item?id=25743874

Discord just got threads.

Are they as terrible as slack's implementation?

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.

> But in this case, there is just one party that means anything

not true, two more companies building on Matrix:

- https://www.beeper.com/

- https://famedly.com/

There were a lot of companies building on Twitter API back in 2010. Do you remember what happened to them?

How do you know this is a negative influence?

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.

For a product, it is a positive influence. For protocol - not so much.

Would you be happy if Google had the ability to unilaterally define web standards?

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 :-)

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.

In other words: you are wrong; it's not a facade.

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 :/)

Ah ok, my mistake, sorry.

> 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.

> 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%?

From a purely capitalist perspective, 10% of a $1TB industry is better than 100% of a $10B company.

A growing ecosystem where the largest participant is 10% of the userbase is one which is immune from antitrust concerns.

It's likely one that is responsive to user needs.

It's everything that capitalists say that they want: a healthy competitive marketplace.

Rocketchat also has the open spec.

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...

So, all the safeguarding positions are predominantly filled with Element employees (according to another commenter)? [1]

Consider me not impressed.

[1]: https://news.ycombinator.com/item?id=27970233

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.

And yes, I do spend all my time improving XMPP.

[1]: https://en.wikipedia.org/wiki/Not_invented_here

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.

This issue is hardly unique to Matrix.

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.

Spot on. When one organization controls servers, protocols and main implementation it creates lock-in just like closed source software.

Signal is a good example.

> 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?

Matrix does support voice chat. I use it every day (and it's been pretty good.)

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.

Yes. I haven't used it so I can't tell how complete it is. But it exists. https://matrix.org/blog/2018/02/05/3-d-video-calling-with-ma...

Yes there is VoIP capability. And video as well.

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

why disappointed on the Matrix side ooi?

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...

This is how I decided to go with XMPP instead.

Good luck. Make your own informed decisions.

---

[1] https://www.weforum.org/organizations/protocol-labs

[2] https://www.reddit.com/r/ipfs/comments/os8plh/the_world_econ...

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.

[0] https://www.theregister.com/2021/07/27/element_seriesb_thirt...

[1] https://www.youtube.com/results?search_query=jaan+tallinn

Nothing is going to change unless we break free of this shit VC funny money cycle.

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.

But XMPP failed (as a decentralized open protocol in the wider picture).

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.

So not keeping up to users expectations - no matter how much - makes a failure?

I think your argumentation is flawed. If your server+consumer app combo can do that, do that

I was giving the person above me the benefit of the doubt. I assume that was their argument, not mine. But i entertained the idea regardless.

It hasn't really been there:

- 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

Decentralization in XMPP exists to a much greater degree that in is in Matrix.

Practical decentralization, where you can talk to your friend that uses a different provider?

Not just using the same client for Facebook and your corporate chat instance?

Practical decentralisation, as in thousands of servers connected to each other in one federation, working for 20 years.

> Practical decentralization, where you can talk to your friend that uses a different provider?

Yes. You can find some lists of servers participating in the federation here: https://xmpp.org/getting-started/

It's just that XMPP providers are not required to participate in the federation. Sadly, large instances like WhatsApp choose not to.

> encryption wasn't really there (and still is experimental)

Clients could encrypt messages using OpenPGP and the more recent OMEMO seems pretty reliable to me (Conversations, Gajim).

Not only Matrix leaks metadata all over the place, but it relies on the idea of encryption being safe FOREVER.

In 30 or 40 years all your messages might be public.

They use perfect forward secrecy through OLM, no?

"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.

Or am I misunderstanding the concern?

You cannot delete encrypted data once it has been shared with the whole world.

messages don't get shared with the whole world, but only the users and the homeservers the users choose

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

> 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.

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.

> I don't think this is solvable even in theory.

It is very solvable in practice.

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.

On a practical level, that's a huge difference.

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.

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 :)

No, read the other answers.

> 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.

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.

Why would anybody use Matrix after reading https://www.hackea.org/notas/matrix.html ?

This article seems all about a particular implementation, not the protocol.

The only section that doesn't end with "we suspect foul play but did not investigate" is a citation of [1], so might as well read that instead.

[1]: https://github.com/libremonde-org/paper-research-privacy-mat...

That article makes it seem like private servers unconditionally sends metadata to official servers (is this really the case, seems odd?)

Other articles mentions sending metadata only to servers you have users from (which of course can be a problem, but at least is explainable).

"Why would anyone use X after reading a critic blog post about it?"

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.

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).

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...

Congratulations to them on the fundraising.

> 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.

Well done!

> 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.

> Hopefully they also improve the UX

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.

> they could try to adjust your login with @ and : symbols automatically if they see something is wrong

how specifically? especially the ":"

When it asked me to type the full log in with the server I made a guess and typed user@matrix.org.

I also think it didn't even accept user:matrix.org without the "@" in front.

Finally they have money to get rid of Electron.

LOL! I hope so.

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.

+1000000000.

Judging a project by its number of open issues is like judging a book by its number of pages.

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.

Isn't this already possible (if a given bot supports it)?

See t2bot.io which has some bots with encryption hosted: https://t2bot.io/docs/encrypted-integrations/

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.

I don't have a Mac, so I can't test it, but isn't Seaglass [0] a native Mac client?

[0] https://matrix.org/docs/projects/client/seaglass

Yes. Of course that was the first thing I installed. It's buggy and abandoned.

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.

How is Libera vs. Discord vs. Matrix playing out in the open source community?

but Discord is closed source...

And so is GitHub.

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 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.

> closed-source platforms such as Slack & Telegram

I'm pretty sure Telegram is open-source (at least the client)

https://github.com/telegramdesktop

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.

>Of actual open-source options: Gitter

Gitter was bought by Element, it's effectively a Matrix client now.

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™.

Discord is... for folks who have got lost.

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.

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.

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’.

Yes, private federation is supported.

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.

> adding Threading to Element (yes, it's finally happening!)

Arathorn: Please make it similar to how Zulip works, and not how Slack or Discord have implemented it.

I have a feeling they'll never do this with a foundation that truly values open source until they plan on announcing something else they can control.

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.

Indeed, my bad.

So... how is whoever invested in Element going to exit?

building matrix is really expensive i guess. i wish them luck, but so far i haven't been sold. probably wont be either.

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.

Reply on news.ycombinator.com