4 ms·

I really don't like the forced end to end encryption of chats. I do not care that much about the security of my chats to justify the complications of end to end

I really don't like the forced end to end encryption of chats. I do not care that much about the security of my chats to justify the complications of end to end encryption -- verifying devices, constant "reset" prompts that I don't even know what they do, but they seem like they are very destructive. I trust my homeserver, since I host it myself. I do not need end to end encryption. I understand this is an issue of the client, not the protocol. But there aren't many clients. Prebuilt element for android from fDroid will connect to matrix.org, vector.im and other network hosts and I don't want that at all, although this tracking can't easily be disabled. It feels very centralised. I run my own homeserver and want to chat with my friend that runs his own server. It is unacceptable to me that clients connect to anything other than those two homeservers (apart from CRL and OCSP, which should also be disabled by default, as I consider those protocols great spyware). Not to mention the fact that homeserver software itself is known to make connections to the servers of the developers by default, without ever talking to someone on matrix.org. This is also unacceptable. My homeserver should only connect to other homeservers. 3PID is a failed attempt, as it centralises identities and works by utilising a single point that gathers a lot of personat information at one place. I don't want it. XMPP does not have those issues. Set up prosody and use dino or Conversations and they won't make any connections to non-essential servers. Furthermore, the end to end encryption is way easier to use in XMPP (OMEMO), and it's easy to turn it off if you don't need it.

lxgr 3y ago
It sounds like you’re happy with XMPP – are you missing anything from Matrix in terms of functionality? If not, why not just stick with XMPP?
- jesprenj 3y ago
  I think matrix has group voice calls. But maybe I'm wrong and they're just using Jitsi. I like that Matrix puts an emphasis on message history, but on XMPP that seems like an afterthought. For example on XMPP multi user chats, messages history retention relies on the server that hosts the chatroom and this is sometimes very limited, sometimes even disabled. And if that's the case, you only get messages when you have a _client_ online, as your server won't store messages when you don't have a client connected. Or something like that. And AFAIK, multiple clients with a MUC room opened will appear as multiple users sometimes. I'm not sure how it all works really, so take my words with a grain of salt. XMPP seems more like a pubsub system for system messages, like MQTT (:
dijit 3y ago
tbh the best thing about Matrix is that you have a hope in hell of actually federating it. XMPP had that promise but due the XEP situation it quickly became difficult to actually federate as most XEPs are optional or not supported on your federation partners. Everything you said is true; if you can tolerate centralisation then just stick to XMPP, it's pretty good.
- upofadown 3y ago
  What XEP interoperability issues prevent federation?
  - dijit 3y ago
    There are more than 370 XEPs. Here's the first one I found that causes server<->server incompatibility: https://xmpp.org/extensions/attic/xep-0369-0.7.1.html https://xmpp.org/extensions/attic/xep-0369-0.7.1.html What was always missing was a golden set of standards. Maybe XMPP "2" is XMPP and a set of XEPs and so on. Otherwise all you have is a bunch of half-working XMPP implementations. Very famous ones of course include voice/video. The UX on that is atrocious.
    - wiktor-k 3y ago
      > Here's the first one I found that causes server<->server incompatibility: https://xmpp.org/extensions/attic/xe https://xmpp.org/extensions/attic/xe What kind of incompatibilities does it cause? It's an unfinished spec for group chats, which, to my knowledge is barely implemented anywhere. Just for the record I'm using both XMPP and Matrix daily and both have issues :/
- zaik 3y ago
  > difficult to actually federate as most XEPs are optional or not supported on your federation partners This is false.
  - dijit 3y ago
    Voice/Video is an optional XEP and if it's not supported what happens to the client exactly? "this is false" is a terribly glib statement with literally no backing and can only be said if a person has either zero knowledge of what they're talking about or they've tied themselves to a single implementation of XMPP everywhere, which is essentially standardising a bunch of XEPs.

lxgr 3y ago

It sounds like you’re happy with XMPP – are you missing anything from Matrix in terms of functionality? If not, why not just stick with XMPP?

jesprenj 3y ago
I think matrix has group voice calls. But maybe I'm wrong and they're just using Jitsi. I like that Matrix puts an emphasis on message history, but on XMPP that seems like an afterthought. For example on XMPP multi user chats, messages history retention relies on the server that hosts the chatroom and this is sometimes very limited, sometimes even disabled. And if that's the case, you only get messages when you have a _client_ online, as your server won't store messages when you don't have a client connected. Or something like that. And AFAIK, multiple clients with a MUC room opened will appear as multiple users sometimes. I'm not sure how it all works really, so take my words with a grain of salt. XMPP seems more like a pubsub system for system messages, like MQTT (:

dijit 3y ago

tbh the best thing about Matrix is that you have a hope in hell of actually federating it. XMPP had that promise but due the XEP situation it quickly became difficult to actually federate as most XEPs are optional or not supported on your federation partners. Everything you said is true; if you can tolerate centralisation then just stick to XMPP, it's pretty good.

upofadown 3y ago
What XEP interoperability issues prevent federation?
- dijit 3y ago
  There are more than 370 XEPs. Here's the first one I found that causes server<->server incompatibility: https://xmpp.org/extensions/attic/xep-0369-0.7.1.html https://xmpp.org/extensions/attic/xep-0369-0.7.1.html What was always missing was a golden set of standards. Maybe XMPP "2" is XMPP and a set of XEPs and so on. Otherwise all you have is a bunch of half-working XMPP implementations. Very famous ones of course include voice/video. The UX on that is atrocious.
  - wiktor-k 3y ago
    > Here's the first one I found that causes server<->server incompatibility: https://xmpp.org/extensions/attic/xe https://xmpp.org/extensions/attic/xe What kind of incompatibilities does it cause? It's an unfinished spec for group chats, which, to my knowledge is barely implemented anywhere. Just for the record I'm using both XMPP and Matrix daily and both have issues :/
zaik 3y ago
> difficult to actually federate as most XEPs are optional or not supported on your federation partners This is false.
- dijit 3y ago
  Voice/Video is an optional XEP and if it's not supported what happens to the client exactly? "this is false" is a terribly glib statement with literally no backing and can only be said if a person has either zero knowledge of what they're talking about or they've tied themselves to a single implementation of XMPP everywhere, which is essentially standardising a bunch of XEPs.