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.
This is a tech chat product but the way you dig into it makes it sound like you have bones to pick with someone who came to your house and killed your cat.
Can I run my own identity server?
See also: What is an identity server?
Yes - the reference implementation is sydent and you can run your own ID server cluster that tracks 3rd party to Matrix ID mappings. This won't be very useful right now, though, and we don't recommend it.
If you want your server to participate in the global replicated Matrix ID service then please get in touch with us. Meanwhile, we are looking at ways of decentralising the 'official' Matrix identity service so that identity servers are 100% decentralised and can openly federate with each other. N.B. that you can use Matrix without ever using the identity service - it exists only to map 3rd party IDs (e.g. email addresses) to matrix IDs to aid user discovery.
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
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...>
All the stuff you enumerate is metadata that your server stores in order to store your conversations. Until P2P Matrix lands, if you're worried about metadata, only talk to people on servers whose admins you trust.
Congrats on your round. Best wishes for turning that into a robust truly decentralized E2EE communications platform that the average person won't shy from. Btw, I hope SNEK sticks!
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
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.
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.
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