There's also some weird behavior with how E2EE works, which is causing me problems in group chats. Initially it worked, but now people are unable to read some messages with errors like "this message was not encrypted for this device"
FWIW, everything works great on Android with the Conversations app, and also I admit I haven't really RTFM'd too much so it may be my fault as a lazy admin.
Edit: this is with ejabberd btw
The intersection of developers who want to develop on and for a proprietary walled platform and also want to work on open source clients for open standard, descentralised protocol must be pretty small.
If anyone reading this thread has iOS dev skills and cares about improving open-source messaging on iOS, feel free to get in touch.
There’s an extra step that could have been skipped entirely there and we’d be better off.
client - server - server like?
Pidgin implemented support for various networks under an abstraction layer and had a unified UI for all of them.
XMPP implements this via gateways. I used to talk from XMPP with folks who used MSN or Yahoo on their end. We have gateways for Telegram, WhatsApp and Signal nowadays.
The Nokia N900 used the Telepathy framework to expose a local D-Bus messaging service which itself connected to various networks (SMS, MSN, XMPP, etc). The UI was a single unified one for all these networks.
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.
I get that not everyone would accept a web-app replacement, but it sure would be nice if iOS wasn't actively obstructing the possibility of some folks using a web-app messaging service.
Now if only it actually worked consistently and reliably.
I'm not being snarky, the app is flakey as hell. Reactions are nice and all but pointless if they don't have the send a message part down.
It does. I use a self hosted Matrix server for chat with friends (multiple servers federated, even!) and it is rock solid.
between that and the unwanted features (federation, spaces) that aren't useful in a texting context, no way to search message logs, and a server to maintain.
...
I went back to RCS
Search on mobile (in Element X) is on its way and is making good progress: https://youtu.be/Q6NSmptZIS4?t=1297 from a demo from a few days ago.
Finally, self-maintaining servers now exist (https://element.io/server-suite, complete with AGPL distro: https://element.io/server-suite/community)
(On the other hand, notification reliability on Android is still a known problem on Element X for some users that we're working on.)
And there's no way it's more secure anyway, cause your secret is just a 4-digit pin.