inputmice

FWIW this is completely reasonable. Push in XMPP works the same way. They way FCM (Google) and APNS (Apple) work is that only the app vendor with proper credentials can trigger push notification for an app. Therefor it has to be proxied through the app developers server anyway. And of course it cleanly separates the MDA from the various, proprietary push solutions.

But it has. It is enabled by default

The battery consumption of Conversations with or without FCM is about the same. (Battery consumption in both cases depends on a lot of factors like frequency of messages, quality of network or even how often your operating system kills Conversations due to a lack of memory. But eliminating all those factors battery consumption is in the same ballpark. The only difference from an end user perspective is that Conversations doesn’t have to ask for a Doze exemption if you use a server that has the push extension.

And here is the response to that https://gultsch.de/objection.html

There is dino: https://github.com/dino/dino

It's still very early in the development but it looks pretty good.

Xabber never fixed that even though their development branch has at least some activity? That's good prioritizing…

Co-author of the OMEMO standard and lead developer of Conversations here. To answer your question one after the other.

> What do we think about this protocol?

It's the first encryption protocol that allowed me to actually use it on a daily basis. I regularly use my desktop client and my mobile client in parallel and switch between them constantly. OMEMO allows me to do that.

> Is it a good idea?

Yes. Compared to OTR the entire stack (that includes the XMPP layer) is properly standardized. This also kinda answers your questions regarding the OTR implementations. OTR had the problem that it couldn't do multiple devices and the behavior regarding multiple devices and when to start and end sessions wasn't defined at all. All OMEMO developers are also in regular contact to coordinate behavior between the apps.

> Why are there three encryption choices I would really like to get rid of OTR (and we will eventually) but we currently still need it for backwards compatibility with older clients (primarily Pidgin) PGP servers a bit of a different use case. It doesn't provide forward secrecy and authentication but it turn allows for a server-side re-retrievable archive. If you get a new client it can automatically retrieve old messages. (In OMEMO the receiving must exist at the time of writing. It doesn't have to be online but it has to exist and announced the device specific key material)

In reality the choice isn't too much of a problem. You select it once per contact and that's it. It's not like you are getting new contacts every day.

> How is the server support.

The server requirements for OMEMO aren't too bad. However it is recommended that you do pick a modern XMPP server for other reasons (battery-friendliness, reliability). Have a look at this comparison list to see if your server supports all modern extensions: https://gultsch.de/compliance_ranked.html

> How is the support of group chat

Support for group chat exists and works fine once it is setup. However it has some limitations that make setup harder. Everyone has to be in everyone elses contact list. And the group needs to be setup with special parameters. (Conversations automatically sets it up this way, but you couldn't for example create the group with Pidgin and then expect OMEMO to work.) The readme on the Conversations github page explains this in a little more detail: https://github.com/siacs/Conversations/blob/master/README.md...

here is roughly the same information in an essay by the same author: https://gultsch.de/xmpp_2016.html if you don't have the time to watch a 45 minute video.

and the relevant discussion on HN: https://news.ycombinator.com/item?id=11837466

have a look at https://account.conversations.im I'm - the author of the essay and developer of Conversations - are running this server with one of the ejabberd developers. That server is really up-to-date and has everything you need to run Conversations. (every XEP mentioned in my essay)

If you want alternatives there is jabber.at, which has also proven to be very well maintained in the past.

And there is jabber.de (but they don't have MAM (yet))

It's impossible to get reliably statistics in a federated system. (Which of course is the entire point.) but looking at the little data I have from people sending me bug reports over XMPP at seems that a lot of Conversations users are running their own servers. The problem is not that the extensions are not implemented (Both prosody and ejabberd in fact support all the extensions Conversations does.) but that a lot of public servers out there are second class services for their operators and are not properly maintained. In that case you can either contact them and ask them to upgrade or ask yourself if you want to have an XMPP account on a provider who doesn't maintain their servers.

> There's a reason that everyone using Conversations essentially has to use a server that is maintained by the developers.

That is completely untrue. First of all there are public servers that have exactly the same feature set like jabber.at second of all we are running ejabberd on conversations.im. ejabberd is open source can be run by anyone. You just have to do it. Granted the list of public servers with a full feature set is not as long as we'd like. But the best way of changing this is to run one yourself.

Push messages on GCM are going through immediately. The push server is not queuing up messages to send them all at once. I admit that could be helpful but Google is not doing this either.

The alarm manager - where apps can schedule to be run at some point in the future - is in fact grouping those events together. But that happens entirely independent of GCM. The Alarm Manager is part of Android where as the push service is a proprietary Google service.

I'm just wondering what makes someone look at an XMPP client like Conversations and say: "This is fundamental flawed let's completely reinvent the wheel. There is no way we can ever get a good UX out of this" Matrix might not be a bad protocol for Instant Messaging. But neither is XMPP. And XMPP already has an established infrastructure of public servers and a fairly large user base which will take Matrix at least 5-10 years to build up (That's were the 5-10 years were coming from).

I'm not bad mouthing anything. It's just that Matrix doesn't solve any problems XMPP hasn't already solved or could have solved with an extension. Matrix is basically a pointer to a stream of messages. You could have easily made this into a XEP. In fact there have been ideas in the XMPP community called MAM subscriptions that are basically the same thing. Even if that extension would have been a radical change in C2S communication as long as S2S stays the same you could have built your protocol on an existing infrastructure.

I mean I rather have people use matrix than a closed system like WhatsApp or Signal. But I honestly don't see the point for developing a new protocol other than JSON over HTTP fits better into the zeitgeist and NIH syndrome.

This is a confinement of OTR. OTR was never made for modern day instant messaging. Use OMEMO or send unencrypted messages and you won't have this problem.

Before you dismiss XMPP and seek for alternatives that need at least another 5-10 years to be actually usable (looking at you [matrix]) you might want to take a look at how far XMPP has come in the last 2-3 years. The Android client Conversations (https://Conversations.im) is a prime example on what can be achieved with XMPP today. In band images, emojis, End-to-end encryption, group chats…