▲ 57 points
back
18 comments
Background: XEPs are the protocol building blocks of XMPP.
The 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.
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.
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.
Ge0rg wrote that post shortly before the last XMPP summit. Then we put together the plans for push notifications (https://github.com/legastero/customxeps/blob/gh-pages/extens...) working in conjunction with Message archive management (http://xmpp.org/extensions/xep-0313.html) to catch up on messages that might have been missed (in your example: on your desktop client).
Cool, thanks for the link. I knew about MAM, but hadn't seen the push stuff.
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).
Does anyone know how this will work when combined with OTR?
I guess the alternative would be PGP, which has disadvantages, but no sessions.
OTR works great when both parties/clients are online.
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.
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
Doesn't this resolve the issue that you describe?
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.
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.
yaxim supports message carbons
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.
Can you tell me what was wrong with the old title ?
You spelled conversations incorrectly. I forget what word your computer autcorrected/substituted for it.
noooooooooooooooooice! something i've wanted for a long time, and it seems only iMessage has perfected.
TIL piping data together for big data purposes is called a protocol and not a dragnet.