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.
> 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.
There are technical advantages to a dumb client. The more you outfit an XMPP server with basic things modern users want like message history and push notifications, the more state and responsibility moves to the server.
Disclaimer: I have a lot of XMPP experience but have never used Matrix
> 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.
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?
My idea is basically person to person comms. Why can't they just send messages directly to each other? I guess mobile can't do this and relies on polling (i.e. you can't expose a service running on the phone for security reasons). And when the group gets large enough, beyond say 3-4, sending messages to each recipient gets unwieldly
Directly doesn't work over the internet, because the internet doesn't work like that. You'd be restricted to bluetooth, wifi direct or similar.
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...
> Directly doesn't work over the internet, because the internet doesn't work like that. You'd be restricted to bluetooth, wifi direct or similar.
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.
XMPP is a client/server model too, that needs to store messages for some configurable amount of time. What distinction are you trying to make here? There are very few peer-to-peer messengers.
Yeah peer-to-peer would be my idea. Send directly to each participants device, no third party involved, at least for the messaging part. So one less vector for attack. You'd probably want a central service for determining who's online.
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.
iirc, matrix started as attempt by Amdocs (in same org that I worked at) to give to telecoms their own messaging client that will be better than SMS in order to compete with OTT clients that they saw as "unfair" and "eating their revenue"
hence, matrix by definition was born due to business reasons and not technical.
you may be mixing up Amdocs UC (which i ran) which was explicitly OTT-messaging-for-telcos… with Matrix, which is what the UC team did next. The point of Matrix is/was to replace the PSTN with a decentralised alt on the internet - so everyone (including Amdocs) could then go build cool stuff on top.
nope, Matrix has zero code or philosophy in common with Amdocs UC (which was proprietary, centralised, unencrypted XMPP + SIP held together with HTTP). Instead, after we gave up on trying to persuade telcos to roll out OTT messaging apps built on the Amdocs UC stack, we started Matrix as an new project to instead try to disrupt the PSTN (decentralising & disrupting it much as cryptocurrencies try to disrupt legacy payments networks). The reason Amdocs funded us to do it was in case we were successful enough that Amdocs could then sell Matrix solutions alongside PSTN solutions in the long term future.
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.
ok. now i remember things better let me rephrase it. matrix was initiated by/inside amdocs. it (given that it was amdocs) was meant to be sold to telecoms to compete with OTT offerings (open source wording, etc - amdocs was adding it to everything back in this timeframe as it was trendy).
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).
>it was initiated very much by me & the UC team while inside Amdocs.
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.
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.