[pmlnr]

> Matrix tries to do a lot more than XMPP

It's not that simple. Many doesn't know about omemo, jingle, etc, when it comes to xmpp. Or xmpp bridges like biboumi.

Matrix is is doing the same thing, but on differrent - and way more complicated - infrastructure ideas.

Prosody is definitely much simpler to configure, even with multiple domains, especially when per domain specific setting are needed.

[phicoh]

The problem with omemo, jingle, etc. is that you have makes sure that the XMPP components you use support them. It would be fine if all popular implementations support those features, but that's not the case.

So you can't just say, let's use XMPP. You have to be very specific and make sure people use the right versions.

You can say that Prosody is easy. I don't find the following list easy: https://prosody.im/doc/modules

And you probably need 'Component "conference.example.org" "muc"' for any kind of 'room' support.

The the next question, does prosody have the equivent of federated rooms in matrix. Here is a list of XMPP extensions in the documentation: https://www.prosody.im/doc/xeplist

I guess the answer is, there are no federated rooms in prosody.

Another question is whether it is possible to send someone an XMPP message when that person is offline. I have no idea how to search for that.

[jgtrosh]

It seems that some people that host XMPP servers should select a set of required extensions with specific versions and give the whole thing a name and version and use that in lieu of “XMPP”. Likewise, clients would need to provide and claim compatibility with the extended XMPP. Has this not been done before?

[Boulth]

No federated rooms. Offline messages are supported.

I guess newer Prosody supports this and much more out of the box but the generic configuration instructions I used are here: https://serverfault.com/questions/835635/what-prosody-module...

> The problem with omemo, jingle, etc. is that you have makes sure that the XMPP components you use support them. It would be fine if all popular implementations support those features, but that's not the case.

Isn't this also the case with Matrix that no implementations except the official ones support E2E encryption?

[Arathorn]

> Isn't this also the case with Matrix that no implementations except the official ones support E2E encryption?

This isn't true. There are independent working E2E implementations in weechat-matrix and pantalaimon (python-nio), nheko (mtxclient), and even a read-only one in purple-matrix. Meanwhile lots of independent apps build on the official SDKs (e.g. Seaglass on macOS, bots like Matrix-Recorder, the various Riot forks, etc)

[Boulth]

Glad to hear the update, thanks!

[phicoh]

Just curious, which XEP is offline messages?

In Matrix, clients are supposed to implement the full Client-Server API. If a client leaves out e2e then it cannot claim to implement the matrix protocol.

Given that 1.0 of the full matrix protocol was published only a few days ago, it makes sense that anything other than the official implementations are behind. E2e in the official implementation is not that old either.

Even the official implementations need some work to be useful. For example, cross device signing is not there yet.

[Boulth]

> Just curious, which XEP is offline messages?

Simple retaining messages until the client is online was supported since ages, I don't think there is XEP for that but I could be wrong. More elaborate scheme with persistence, multidevice access, paging etc is here: https://xmpp.org/extensions/xep-0313.html

> In Matrix, clients are supposed to implement the full Client-Server API. If a client leaves out e2e then it cannot claim to implement the matrix protocol.

Yes, XMPP has XEP suites that serve the same purpose: https://xmpp.org/extensions/xep-0387.html

[monort]

Just a note - without XEP-0198 you will be losing offline messages if your connection is unreliable. I think most desktop jabber clients still do not support it.

[derin]

> Isn't this also the case with Matrix that no implementations except the official ones support E2E encryption?

A general purpose project to provide all clients with E2E encryption is being developed (and is usable right now): https://github.com/matrix-org/pantalaimon

Right now it runs as a daemon on a user's local machine.

[dngray]

> So you can't just say, let's use XMPP. You have to be very specific and make sure people use the right versions.

I too ran an XMPP server for years, used plaintext and OTR, it was nice.

This was in the days before everyone had tablets, phones and laptops. I used ChatSecure (formerly Gibberbot) on my phone and Pidgin on my PC.

OMEMO wasn't invented then and nobody else had the double ratchet so I had to just deal with the fact there wasn't multi device support and E2E.

Google and Facebook both offered XMPP bridges too. Google and Facebook have discontinued such services. Voice/Video never worked with them and file transfer with Pidgin never worked with Google Talk.

Now in today's world, how am I seriously going to convince my friends to use XMPP when they will say, can we use camera/video, oh do we have group E2E too?

Am I seriously going to say "lets use this XMPP client for chatting in text because it supports OMEMO, and lets use this other client because now we want to have a video call?".. What am I going to do when they're on Android?. Conversations.im is nice, but there's no voice/video with that.

The problem simply is there's no reference client that does everything. Many of the clients are ancient fugly GTK clients, and if they do Jingle it's only on Linux (Pidgin, Gajim, Telepathy based etc)

* https://en.wikipedia.org/wiki/Jingle_(protocol)

* https://omemo.top/

* https://en.wikipedia.org/wiki/Comparison_of_instant_messagin...

If we all use different clients for different things how am I supposed to say "Mom you click here to do that".

Then you do have some promising clients like Coy.im that look nice. And they've said NOPE NO OMEMO HERE. https://github.com/coyim/coyim/issues/233#issuecomment-21200...

Oh you can have video here, but no OMEMO https://github.com/jitsi/jitsi/issues/199#issuecomment-17017...

[masterfooo]

That is exactly why I had to dump my Ejabberd server after years of self hosting. The XMPP client app habitat is in disarray.

If Conversations offered voice/video, that would have been a different story.

[pmlnr]

You are not wrong at all.

That said, self hosting matrix seems to be similarly hard to execute at this point in time - simply too many opaque and moving components on the server side.

The riot client is also incredibly slow for my taste.

[masterfooo]

Installing Synapse is very easy actually with Pip, however as this OP showed that using your own identity server is also necessity. FOr that you want https://github.com/kamax-matrix/mxisd

[pmlnr]

But this is what I've been pointing at; to self host XMPP with multiple domains and per domain settings, I need prosody, nothing else. Not identity server, no video servers, etc. This is the based of my problems.

[Arathorn]

on what platform is riot slow? if android, give riotx a try - it’s roughly 6x faster.

in terms of too many opaque moving components serverside; the baseline is just a homeserver. pip install matrix-synapse and off you go. configure your client not to use an identity or integration server if you are worried about them.