4 ms·

> 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

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

dingnuts 1y ago
at least when I help someone set up XMPP it doesn't have a single blessed client that tries to convince them to create an account on matrix.org
tguvot 1y ago
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.
- Arathorn 1y ago
  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.
  - tguvot 1y ago
    isn't matrix is direct continuation of amdocs uc with same team, your including ?
    - Arathorn 1y ago
      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.
      - tguvot 1y ago
        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.
        Arathorn 1y ago
        > matrix was initiated by/inside amdocs. 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-matrix/ 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 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
morshu9001 1y ago
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
- mixcocam 1y ago
  take a look at the way https://delta.chat https://delta.chat solved for that very modern/looking/feeling - just email.
tcfhgj 1y ago
> 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?
- SJC_Hacker 1y ago
  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
  - mixcocam 1y ago
    Check out delta.chat thy have solved super simple p2p messages https://delta.chat/en/2024-11-20-webxdc-realtime https://delta.chat/en/2024-11-20-webxdc-realtime
  - tcfhgj 1y ago
    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...
pkulak 1y ago
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.
- SJC_Hacker 1y ago
  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.
  - pkulak 1y ago
    Also very difficult because: - 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.

dingnuts 1y ago

at least when I help someone set up XMPP it doesn't have a single blessed client that tries to convince them to create an account on matrix.org

tguvot 1y ago

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.

Arathorn 1y ago
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.
- tguvot 1y ago
  isn't matrix is direct continuation of amdocs uc with same team, your including ?
  - Arathorn 1y ago
    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.
    - tguvot 1y ago
      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.
      - Arathorn 1y ago
        > matrix was initiated by/inside amdocs. 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-matrix/ 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 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

morshu9001 1y ago

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

mixcocam 1y ago
take a look at the way https://delta.chat https://delta.chat solved for that very modern/looking/feeling - just email.

tcfhgj 1y ago

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

SJC_Hacker 1y ago
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
- mixcocam 1y ago
  Check out delta.chat thy have solved super simple p2p messages https://delta.chat/en/2024-11-20-webxdc-realtime https://delta.chat/en/2024-11-20-webxdc-realtime
- tcfhgj 1y ago
  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...

pkulak 1y ago

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.

SJC_Hacker 1y ago
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.
- pkulak 1y ago
  Also very difficult because: - 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.