Flowdalic

As of now I recommend everybody to use Prosody stable as XMPP server running on Debian stable. Enable the Prosody modules that provide the XEPs mentioned in Daniel's blog post and/or in XEP-0375: XMPP Compliance Suites 2016[1]. You can either run it at home, which means you have the full stack incl. hardware under your control, or rent a cheap vServer for this, which eventually makes the initial setup easier, as you don't have to deal with dynamic IP addresses. Maintaining a Prosody stable installation on Debian stable means usually nero zero effort. Make sure to have the "security" apt sources and eventually Debian's unattended-upgrade[2] enabled. That's it.

1: https://xmpp.org/extensions/xep-0375.html 2: https://wiki.debian.org/UnattendedUpgrades

Your claim that XMPP is a bandwidth-hungry, but in my experience, if XMPP based systems drain battery and consume a lot of bandwidth, then it's because of a poor implementation and design decisions, and not because of the protocol.

Right, shouldn't have thrown them all together. Corrected the comment.

OTR [1], Axolotl [2] and OMEMO [3] all provide Perfect Forward Secrecy, which in turn means that you can't (or should not be able to) read your archived messages. And with OTR can't send messages to offline contacts. OpenPGP does not provide this property, which allows you to read your encrypted messages in the archive as long as you have access to your OpenPGP secret key and it allows you to send messages to offline contacts.

1: https://otr.cypherpunks.ca/ 2: https://github.com/WhisperSystems/Signal-Android/wiki/Protoc... 3: http://conversations.im/omemo/

Addendum: As Zash pointed out[1], this is documented behavior for offline messages, i.e. messages send while the user was offline. Those are only send if the user announced availability via a presence or if XEP-13: Flexible Offline Message Retrieval is used. This is to prevent storms of offline messages when the client (re-)connects.

But it's certainly not true that you "won't receive any message despite ... successful connection".

1: https://news.ycombinator.com/item?id=10043962

I don't think that aspect is intentionally ignored, it's just that most FOSS projects are seriously understaffed, and the UX/UI part is not a high priority item compared to getting it to work.

Course, you shouldn't poll and if those mechanisms aren't coordinated, then you you will suffer. But that's why Android provides the AlarmManager API and I would expect other mobile platforms to provide something similar.

I use my mobile XMPP connections without a TCP keepalive but send a server ping if there has been stanzas received in the last 30 minutes and get a useful and reliable XMPP connection without a noticeable impact on battery. If you use Android's AlarmManager to trigger the check, then Android will even take care of scheduling the "alarm" with other alarms for efficiency.

> Multiply that by the number of connections your application will have and by the number of background application you run on your phone, and the radio will never truly sleep or enter the "low" mode.

Why would X x Y idle connections (X: TCP connections per app, Y: applictions) prevent your radio from sleeping?

> I don't know how accurate Android's power estimates are, but I consistently have people telling me that they are switching back to proprietary messengers because every XMPP client they've tried drained their battery. Whatever causes it, there's a real problem here.

You have to differentiate between the specification and the implemetation. Nothing in the XMPP specification prevents you from implementing a battery friendly XMPP client. But some implementations suck/have room for improvement.

tl;dr It's being worked on (or already solved), but I'm sure the XMPP community welcomes additional contributors.

1-3. Could be solved with upcoming versions of XEP-313 MAM.

4. e2e There is currently a XSF GSOC project running, bringing axolotl to Conversations (and eventually describing the protocol as an XEP).

5. There are a few standards on how to perform encrypted file transfers, but implementations are lacking. You are invited to code one.

6. XEP-357: https://xmpp.org/extensions/xep-0357.html

Idle TCP connections do not consume any battery.

And on a data connectivity change, e.g. GSM <-> WiFi switch, there is a good chance that a dozen other components start trying to re-establish their connections, which means the radio is awake anyway (for, usually, at most a few seconds).

> For example, every client that successfully connected to an XMPP server must first send a "<presence>" message. Otherwise, it won't receive any messages despite their successful connection.

That statement is wrong. Sending an initial presence merely indicates your availability to entities subscribed to your presence. Not sending the initial presence does not prevent you from receiving message stanzas.

> 1. XMPP is not battery-friendly on mobile devices (this primarily has/had to do with the absence of push notifications, it seems).

I do use XMPP in a mobile environment without any noticeable impact on battery runtime. It's not the protocol which drains your battery, but how one uses it: If there is frequent activity in terms of XMPP stanzas being exchanged between your device and the device's XMPP server, then the device will be unable to e.g. put the radio to sleep. Which, in turn, is of course causing battery drain.

The golden rules to prevent that:

1. Only send XMPP stanzas when necessary

2. Bundle and defer outgoing stanzas if possible

3. Tell your XMPP service when the device is inactive, so that the service is able to optimize the traffic (XEP-352: Client State Indiation [1])

4. Consider service-side stanza blocking (e.g. XEP-16: Privacy Lists) for stanzas of "unknown" origin to prevent malicious users from draining your battery.

1: https://xmpp.org/extensions/xep-0352.html

It appears the opposite is true. ffmpeg is more or less a one man show. See http://thread.gmane.org/gmane.linux.debian.alioth.multimedia... and https://lwn.net/Articles/650816/

"I think the statistics indicate that the situation is much worse than I expected. Please keep in mind that because of the daily merges, all commits that are made in Libav also appear in FFmpeg, but not the other way round. With a finger-in-the-wind estimate of subtracting the numbers in the Libav table from the FFmpeg table, the distance between Michael and the other FFmpeg developers because even more extreme."

> tarsnap had a signal handler that was reading from a constant array. So what, how could this matter? The standard says thou shalt not.

An references to the standard (I assume he is referring to POSIX) where this is disallowed?

You are absolutely right. I usually encourage people to get involved in improving the (XMPP) situation.

Just last week I submitted a XEP for unique stanza IDs to the XSF [1], which will most likely be the base for IDs in MAM and other protocols. I guess that's the light reading you want. :)

And yes, Carbons (XEP-280), in it's current state, also suck. I'm working on a replacement XEP called "Message Routing 2.0 " (MR2): http://geekplace.eu/xeps/xep-mr2/xep-mr2.html It's in an early draft state, but I think it addresses most, if not all, issues with carbons, improving the multi-device situation in XMPP somewhat (I don't care if it's MR2 or an improved version of carbons that makes the race).

> see how ridiculously difficult this makes the basic idea of "all clients should see the same picture" Being involved in XMPP a bit, I get quite a few requests on how to implement WhatsApp/Hangouts like groupchats. And while the basic idea is quite simple, implementing it is a non-trivial task. But it can certainly be done. But we need more motivated developers and specification designers to get it done. While the XMPP community is just great, the count of activley involved people is quite small.

1: http://mail.jabber.org/pipermail/standards/2015-June/029865....

"If the user grants a permission, the system gives the app all permissions that the app manifest lists for that functional area."

It's unclear from the site if "functional area" == "permission group". But it appears to be case, as it's just like the Play Store handles permissions. This would mean that Apps requesting the RECEIVE_SMS permission, while also be able to read existing SMS messages.

XEP-136 is a good example why it's a bad idea to squeeze everything into a single specification (or XEP in this case): The reason it was not implemented by most XMPP stacks was, because it's so much you have to implement. XEP-313 focuses on what is important to achieve WhatsApp like persistent chats in XMPP. Functionality which is lacking in XEP-313 can be specified later on in a different XEP. After all that's why it is called the "Extensible Message and Presence Protocol (XMPP)".

That is not my observation. It is also not clear what you mean with "get upgraded to Hangouts". I use Hangouts extensively, but I use also Gajim as client for my Google account and still I'm able to add XMPP contacts from non Google XMPP servers to my Google roster.

So I basically can confirm that Google did not turn off XMPP federation for their XMPP service. It appears that there is simply no UI to add users from federated servers over hangouts, but it works with standard XMPP clients. So you could say that "Google dropped support for XMPP in their UIs". But you can still use your Google account as plain XMPP service (which doesn't mean that I would encourage it or think that it's a good idea).

But I can't rule out that e.g. some servers can't federate with Google, for example because of policy restrictions.