Have you looked at the protocol? Have you built things in both? I have, and I think the Matrix protocol is pretty good. The goals are different. It's not a send once and forget kind of thing, like XMPP, Signal and email. It's about keeping your chats synced on your server, and with any other server you happen to be federating with. It's Discord or Slack, except federated. That's not easy, and it's not simple, but it has huge advantages too.
And huge disadvantages. I don't understand why everything has to be centralized/ routed through an intermediary. Well I do understand it, modern big corps wants to be that intermediary for various reasons, but thats a business reason not a technical one.
hence, matrix by definition was born due to business reasons and not technical.
In other words, this wasn't really a "hey we need to sell messaging apps to telcos" play - it was a long-term R&D experiment, more like Bell Labs funding UNIX.
I was sufficiently "high up" in organization to hear this pitch. For record I said that they (telecoms) won't buy it and I didn't like project technically
Later when Amdocs saw that it's a no go they span you outside and later cut the funding.
it was initiated very much by me & the UC team while inside Amdocs.
> it (given that it was amdocs) was meant to be sold to telecoms to compete with OTT offerings
in the 5-10 year horizon, yes. And indeed eventually (as Element) we have ended up with a bunch of telco customers. However, this was not the immediate goal at the time - it's not like Matrix was created to improve EBIT for Amdocs UC; it was a long-term R&D play.
> Later when Amdocs saw that it's a no go they span you outside and later cut the funding.
It was the opposite. Amdocs saw that Matrix had legs - e.g. Ericsson started selling Matrix-based solutions (stuff like https://matrix.org/blog/2016/11/23/when-ericsson-discovered-...) - but also saw that it didn't fit inside Amdocs. The whole idea of Matrix is to be an open standard for everyone, just like XMPP or SIP or HTTP. For it to succeed, it obviously couldn't live inside Amdocs.
So, they agreed to both cut funding and span us out; we then raised funding independently and set up The Matrix.org Foundation as non-profit to look after Matrix for everyone, and separately set up Element as for-profit to fund our work on Matrix. It's not exactly been a smooth journey (see https://youtu.be/lkCKhP1jxdk?t=363 for my FOSDEM talk trying to explain the route so far), but I can confidently say that Matrix was not borne out of trying to scratch an immediate business itch for Amdocs, but instead a longer-term experiment in building something better for everyone (including Amdocs).
But what do I know :D
in other words by amdocs.
ericsson starting to sell matrix based solution while amdocs not selling any (or none of traditional amdocs clients like AT&T, Comcast, T-Mobile, etc expressing interest in buying one), it's the definition of "no go" and "no fit" for amdocs. At this timeframe, amdocs could sink tens of millions of dollars into open source project if they thought that they will get some money back. ONAP will be prime example of this.
internal presentation in amdocs that were circulated on VP+ level most definitely talked about scratching immediate business itch for Amdocs. It was talking about how telecoms are upset that OTT messaging killing SMS and profits and that matrix is attempt to give to telecoms something to compete with it. I said that idea that telecoms can get this market back is bananas, but management had shiny new toy to play with and they were excited about it. Hence they allowed it to run till the moment that they saw that no profit can be done there.
Disclaimer: I have a lot of XMPP experience but have never used Matrix
centralized? no
If you sign up for messaging on let's say Signal, do you really want your client to talk to Facebook, Google and dozens of other services?
And do you want the users of your chat service depend on "random" other services ? Not being able to access chats, media, because an outage or even shutdown of a random service over which you don't have control?
If you allow for forwarding in between, there are p2p messengers. Messages are stored - if at all - using store & forward techniques. They can use the internet, but also bluetooth and other communication technology to transmit messages. The most popular ones would be Briar and Jami. Matrix P2P exists at an experimental stage as well (moving servers onto devices).
The problem with them you give up convenient things, even though there are often are workarounds. For instance, plain p2p you cannot communicate with offline devices, but store and forward techniques exist, either storing messages on random people or dedicated store and forward servers.
Battery drain, lack of reliability. It's just extremely simple, quick and reliable to send messages to a defined server and receive Push Notifications via push service.
Want a reliable storage of your messages (encrypted) such that you can always access them when you wish? well...
That is how "the internet" has worked forever.
People have been running servers on their own home machines, for a long time. If you really want you can setup a webserver/sshd/etc. on your own machine and access it from the outside if you don't care about DNS and static IP. Will also probably need to port forward at the router, though.
Its less common nowadays due to the cloud, and security issues, etc. sure. And I'm not sure to what extent its possible over mobile.
But for two people who are on PCs/Macs, it should definitely be possible. And it would be much lower latency because you don't have to bounce it off another server.
Wouldn't work well for more than a few people, but not every conversation has group sizes that large.
- direct connections are really hard (Tailscale built a whole company on solving this one problem)
- even Tailscale can't establish direct connections without a coordination server
- even if you can reliably, and always, establish direct connections, it doesn't matter if someone is offline
- push notifications don't work without a server, on Android or iOS, so even if you're online, you're out of luck (won't ever get a new message because there's no push notification to tell the client to connect, and you can't just leave a TCP connection open forever on a mobile phone)
My take is that it's fine to have a server in the middle with E2EE. That's the whole point of E2EE.