3. synchronising messages between devices (what this solves)
More background: XMPP is designed around keeping a connection open to the client and pushing through updates and new messages. These assumptions worked well in a desktop environment on a solid TCP connection. But for power, intermittent network, and mobile OS design reason, holding open a socket isn't ideal.
Push notification work because the OS provider (Apple, Google, Mozilla etc.) keep one socket open and then push through important notifications. This keeps the phone's radio from powering up for silly things like "contact came online/went offline" type messages.
A push notification might be "xyz posted ... ". Your phone needs to now come online and synchronise messages that might have been posted on your tablet or desktop client. Hence XEP-0280. It helps resync messages from other clients.
The XSF is also writing up a push notification XEP that makes it easy for mobile apps to use XMPP as a signalling channel and throw out push notification where necessary.
Thanks for the hard work on this. It's a problem I find particularly bad in my day to day use of chat on various clients across a phone, tablet and laptop.
this XEP is supported by the most popular XMPP servers (prosody, ejabberd) but it is still quite difficult to get a good XMPP client on all platforms that can support this.
this is especially important for mobile clients on iOS or Android or web clients. I don't see another way to have OSS multi-client chats with XMPP similar to hangouts/Facebook/WhatsApp.
Using this and XEP-0313 allows for syncing conversations to all clients, whether they were online or offline. I helped implement an XMPP chat feature on a large web application last year and I think that implementing these two XEPs are critical to fixing the things users complain about most: Receiving a message in one browser window, opening a new tab or window and not being able to see those old messages, just new ones.
Not well. OTR doesn't integrate with XMPP in any way, so adding carbons is just going to feed undecryptable garbage to your other clients. Solving that is pretty much the same problem as mpOTR aims to solve. There's also a new proposed end-to-end encryption spec for XMPP being developed: http://tools.ietf.org/html/draft-miller-xmpp-e2e
One of the nice things about the "do not change the title"-policy is that submitters do not need to be concerned with spelling. Unfortunately, pg can not save you from yourself if you do choose to violate the policy and change the title.
Though as described here: http://op-co.de/blog/posts/mobile_xmpp_in_2014/#index2h2 -- Message Carbons don't help if your phone is out of coverage for a few minutes, as your desktop client will get the carbons, but when you come back online, you'll be oblivious to any messages sent during that time.
Be aware that push is very early. But there are two working implementations already - oTalk and Buddycloud (https://github.com/buddycloud/buddycloud-pusher). What's interesting is that we both came up with very similar solutions. So specing something official and then adapting our code to match the spec should be trivial (in the grand scheme of things).
18 comments
[ 3.1 ms ] story [ 53.0 ms ] threadThe XSF (XMPP Standards Foundation) are working hard to make XMPP more mobile friendly. (disclaimer: I'm an XMPP board member).
There are three problems to solve:
1. knowing when to retrieve messages (push notifications)
2. retrieving messages (message archive management)
3. synchronising messages between devices (what this solves)
More background: XMPP is designed around keeping a connection open to the client and pushing through updates and new messages. These assumptions worked well in a desktop environment on a solid TCP connection. But for power, intermittent network, and mobile OS design reason, holding open a socket isn't ideal.
Push notification work because the OS provider (Apple, Google, Mozilla etc.) keep one socket open and then push through important notifications. This keeps the phone's radio from powering up for silly things like "contact came online/went offline" type messages.
A push notification might be "xyz posted ... ". Your phone needs to now come online and synchronise messages that might have been posted on your tablet or desktop client. Hence XEP-0280. It helps resync messages from other clients.
The XSF is also writing up a push notification XEP that makes it easy for mobile apps to use XMPP as a signalling channel and throw out push notification where necessary.
this is especially important for mobile clients on iOS or Android or web clients. I don't see another way to have OSS multi-client chats with XMPP similar to hangouts/Facebook/WhatsApp.
I guess the alternative would be PGP, which has disadvantages, but no sessions.
I can't see how OTR would work when one client is offline since they need to both be online to do the key exchange dance. Happy to be corrected.
http://xmpp.org/extensions/xep-0280.html#disabling