Re: [Standards] Using XMPP In A Mobile Environment
On 18 Feb 2015 09:14, "Sergey Dobrov" wrote: > I've looked through the XEP and it seems to be quite wise to me still. > Thanks, but I think it could benefit from discussion about use of CSI, etc. > So, generally, I'd leave XEP-0286 as is because it only has > recommendations (which don't even say how server can know if the client > is mobile or not?) inside and they seem to be still actual. But if we > negotiate anything new, I'll try to prepare update to the XEP also. I think there's probably a bunch of stuff we can usefully discuss there; most of this thread, for example. Mostly I think it's several years behind the state of the art. Even if you don't feel it's worth adding anything new, then I think it'd be worth tidying it up and moving it to Active. Dave.
Re: [Standards] Using XMPP In A Mobile Environment
On 18.02.2015 10:14, Sergey Dobrov wrote: > The problem is that I've not written anything for mobile too and don't > know the details, but this article seems to be pretty good for me: > http://developer.android.com/training/efficient-downloads/efficient-network-access.html > > And also it seems to me that it's actually possible to know when the > network is going to high power state so we can transmit data as > efficient as we could sharing connection with other apps when possible: > http://developer.android.com/reference/android/net/ConnectivityManager.html Ahh, thanks for pointing this out. Once again the Android documentation is not very clear, but it looks like ConnectivityManager.isDefaultNetworkActive() could be used to query the GSM radio state. > But it could be cool if anyone could confirm that I understood this > correctly :) I'll dig into the Android source once I find the time. Not sure when this will be, but it's a top priority item on my TODO list. What I did in the last few days is adding *experimental* support for client-side "bundle and defer| in Smack and made MAXS's "Transport XMPP" use of those nice Android API 21 features together with the new Smack API. - Florian signature.asc Description: OpenPGP digital signature
Re: [Standards] Using XMPP In A Mobile Environment
Hi Dave, I've looked through the XEP and it seems to be quite wise to me still. The problem is that I've not written anything for mobile too and don't know the details, but this article seems to be pretty good for me: http://developer.android.com/training/efficient-downloads/efficient-network-access.html And also it seems to me that it's actually possible to know when the network is going to high power state so we can transmit data as efficient as we could sharing connection with other apps when possible: http://developer.android.com/reference/android/net/ConnectivityManager.html But it could be cool if anyone could confirm that I understood this correctly :) I also have no any idea about iOS but I suspect that the capabilities should be very similar? So, generally, I'd leave XEP-0286 as is because it only has recommendations (which don't even say how server can know if the client is mobile or not?) inside and they seem to be still actual. But if we negotiate anything new, I'll try to prepare update to the XEP also. Thanks. On 02/13/2015 06:03 PM, Dave Cridland wrote: > I don't have anything useful to add here, really, but please can you > guys capture your knowledge into XEP-0286? It's clearly behind the > times, as it's 5 years old, but if we could capture some more modern > thinking it might become useful again. > > Thanks, > > Dave. -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] Using XMPP In A Mobile Environment
On Fr, 2015-02-13 at 15:51 -0500, Brian Cully wrote: > > On 13-Feb-2015, at 13:50, Ivan Vučica wrote: > > So the clients with the most enjoyable experience typically open a > > connection from the developer's servers, and deliver notifications over > > APNS. Should that continue to be true? > > Speaking personally, absolutely not. I can’t use current iOS XMPP > clients because I’m worried about the data security of this model, and at a > previous job we specifically told people not to for the same reason. There > are clients that do not connect to a developer’s server, but none that I’ve > found except one (Bria w/ the XMPP IAP) will maintain a connection for more > than a few minutes with the app in the background. > > I believe you can use the VoIP class of background applications, as > you’ve mentioned, to do this, but as yet I’ve not seen this become popular. > > Another option which has occurred to me is using BOSH to handle this > scenario; you can wake up the app w/i the BOSH timeout window without having > it killed by the OS (assuming your window is larger than a few seconds). I’ve > not really investigated this as I don’t think it’s an optimal solution in any > way, merely something that might work if nothing else does. > > -bjc > The xep draft of Lance Stout [1] will not require users to connect to third party servers. It enables the client's home server to send push messages to the proprietary push server, e.g. APNS (same problem exists on Ubuntu Touch [2]). The client can configure the server to not include message contents and sender jids. So it can be used only as a wake-up mechanism. I am currently implementing the draft as an ejabberd module [3]. It's not ready to be played with yet but I will come back and tell you when it is. The idea of deferring stanzas is very relevant to the draft (currently push messages will be crafted when stream management stores a message for later delivery or the user's mobile client is offline). I think sending wakeup-messges via proprietary services in combination with csi / a new filterig mechanism will make good user experience possible on iOS / Ubuntu Touch. [1] https://github.com/legastero/customxeps/blob/gh-pages/extensions/push.md [2] https://docs.google.com/a/canonical.com/document/d/1ij8RtPsR_eYMW3mys8Gu1Y2CVFZpjXdMpdIjIGZ1SCA/edit?pli=1#heading=h.28drra4u9knx [3] https://github.com/royneary/ejabberd/blob/master/src/mod_push.erl
Re: [Standards] Using XMPP In A Mobile Environment
> On 13-Feb-2015, at 13:50, Ivan Vučica wrote: > So the clients with the most enjoyable experience typically open a connection > from the developer's servers, and deliver notifications over APNS. Should > that continue to be true? Speaking personally, absolutely not. I can’t use current iOS XMPP clients because I’m worried about the data security of this model, and at a previous job we specifically told people not to for the same reason. There are clients that do not connect to a developer’s server, but none that I’ve found except one (Bria w/ the XMPP IAP) will maintain a connection for more than a few minutes with the app in the background. I believe you can use the VoIP class of background applications, as you’ve mentioned, to do this, but as yet I’ve not seen this become popular. Another option which has occurred to me is using BOSH to handle this scenario; you can wake up the app w/i the BOSH timeout window without having it killed by the OS (assuming your window is larger than a few seconds). I’ve not really investigated this as I don’t think it’s an optimal solution in any way, merely something that might work if nothing else does. -bjc
Re: [Standards] Using XMPP In A Mobile Environment
On Fri, Feb 13, 2015 at 3:33 PM, Florian Schmaus wrote: > I'm not an iOS export, but I think I've heard that TCP connection are > terminated anyway after something like 60 seconds (of inactivity?). > While I have not tested this, I would highly doubt this is the case for the 'VOIP' class of background applications, as this is exactly the use case. > Anyway I would right now, not take iOS into consideration, because, as > far as I know, you would need to use APNS anyway for XMPP push > notifications. > I don't expect this statement to be correct either. You can trigger a local notification from the background, which, as long as the app is running, is functionally equivalent to a push notification. https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Introduction.html https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIApplication_Class/index.html#//apple_ref/occ/instm/UIApplication/presentLocalNotificationNow : Strictly speaking, your statement is currently true, precisely because clients get killed by the OS. So indeed you need to use APNS for XMPP. But this is due to not satisfying possibly overly conservative requirements imposed by the OS. So the clients with the most enjoyable experience typically open a connection from the developer's servers, and deliver notifications over APNS. Should that continue to be true? Right now, I'm trying to build a minimal set of required functionality. > And this does include to bundle and defer stanzas that are by some > mechanisms determined on the users server. But not the general deferring > of all incoming stanzas Don't misunderstand me, I'm highly appreciative of any efforts. I just feel that iOS's very conservative backgrounding requirements could be satisfied by (optionally) making the deferring more strict and conservative. And I suspect other platforms might be happier as well. My understanding of the difference is: - you propose deferring /some/ stanzas (good by itself) - I'd see use in, aside from deferring some stanzas, /all/ stanzas (even the most urgent ones) should be coalesceable, to be delivered at most every [client-determined value] seconds. If we're discussing improving on ways to reduce or delay s2c traffic in a mobile environment, we should seriously consider the needs of one of the two largest mobile platforms. :-)
Re: [Standards] Using XMPP In A Mobile Environment
On 13.02.2015 12:35, Sergey Dobrov wrote: > On 02/11/2015 12:12 AM, Florian Schmaus wrote: >> On 10.02.2015 09:11, Sergey Dobrov wrote: >>> On 02/10/2015 01:57 AM, Florian Schmaus wrote: >> I'm not sure about that, Even if you defer all messages for only 30 >> seconds, realtime (chat) communication would become a pain. And there is >> also little gain in that. I guess that only if your defer interval is >> something > 15 minutes you will see a measurable positive effect on the >> battery consumption. > I'm not sure here. This page > http://chimera.labs.oreilly.com/books/123000545/ch07.html#_initiating_a_request > says that it can take few dozen seconds for the radio to go to dormant > state to conserve radio and each next wake up of it can consume up to > 100ms and corresponding battery consumption. Ahh that's an interesting reference you have here. I'm still unsure if deferring all stanzas is something one should do. At least not as part of the XEP I've in mind. So the basic idea is clear, but I'm undecided how to specify such an mechanism. For example: - Should the stanzas which are bundled and deferred be matched by - Privacy Lists - SIFT. But SIFT has no way to filter on roster status (e.g. "If sender is not subscribed to my presence, defer and bundle the stanza he wants to send to me" :-( ) - Delay Time? I'm thinking about recommending 15-30 minutes, while warning that it should be not less then 15 minutes (a typical SMTP greylisting timeout). >>> But it can be less than 15 minutes if device wakes up earlier, right? >> >> Well we could say that if the client becomes active (by means of CSI), >> all bundled and deferred stanzas are flushed (just like the presences >> are). I would maybe mention this optimization in the spec but make it >> optional, while noting that bundling and deferring should still happen >> if the client is in active (CSI) state, because otherwise you circumvent >> the protection. > I don't see why the circumvention happens here? Inactive state does not > mean you don't want anything to be received but rather means that it > would be better to not receive because I don't wait for the data. But if > smth urgent happens, we can deliver it all because it actually doesn't > affect battery consumption again and from the other hand it keeps the > xml stream sorted by time. I meant to say, that deferring should still happen when the CSI state is active. There is just *one* flush of the bundled and deferred stanzas when the client enters the CSI active state (if any). If you don't continue to bundle and defer stanzas when the CSI state is active, you circumvent the protection it provides. - Florian signature.asc Description: OpenPGP digital signature
Re: [Standards] Using XMPP In A Mobile Environment
On 13.02.2015 16:14, Ivan Vučica wrote: > Let's not forget that iOS gets into a violent mood in case your > background app wakes up more frequently than 15 times in 300 seconds. > Message in the log is, quite literally, "exceeded 15 wakes in 300 sec". > > This matters only if the app is in background (including if the phone is > off). And there will probably be little or no consequences if the > delivery of second message in a row is delayed by 20-30 sec, or until > the user unlocks the screen and the client 'permits' the delivery, right? I'm not an iOS export, but I think I've heard that TCP connection are terminated anyway after something like 60 seconds (of inactivity?). Anyway I would right now, not take iOS into consideration, because, as far as I know, you would need to use APNS anyway for XMPP push notifications. Right now, I'm trying to build a minimal set of required functionality. And this does include to bundle and defer stanzas that are by some mechanisms determined on the users server. But not the general deferring of all incoming stanzas or the modification of incoming stanzas in any way. - Florian signature.asc Description: OpenPGP digital signature
Re: [Standards] Using XMPP In A Mobile Environment
On Tue, Feb 10, 2015 at 6:12 PM, Florian Schmaus wrote: > >> Let's start by classifying inbound stanzas into three types. There are > >> stanza that… > >> 1. require immediate delivery > > Even those stanzas can be slightly deferred and be bundled, I believe. > > Just the interval will be much thicker, and still it can reduce number > > of necessary wakes up. > > I'm not sure about that, Even if you defer all messages for only 30 > seconds, realtime (chat) communication would become a pain. And there is > also little gain in that. I guess that only if your defer interval is > something > 15 minutes you will see a measurable positive effect on the > battery consumption. > Let's not forget that iOS gets into a violent mood in case your background app wakes up more frequently than 15 times in 300 seconds. Message in the log is, quite literally, "exceeded 15 wakes in 300 sec". This matters only if the app is in background (including if the phone is off). And there will probably be little or no consequences if the delivery of second message in a row is delayed by 20-30 sec, or until the user unlocks the screen and the client 'permits' the delivery, right?
Re: [Standards] Using XMPP In A Mobile Environment
I don't have anything useful to add here, really, but please can you guys capture your knowledge into XEP-0286? It's clearly behind the times, as it's 5 years old, but if we could capture some more modern thinking it might become useful again. Thanks, Dave.
Re: [Standards] Using XMPP In A Mobile Environment
On 02/11/2015 12:12 AM, Florian Schmaus wrote: > Hi Sergey, thanks for you reply. :) Hey Florian, thanks you are interested in this question. > > On 10.02.2015 09:11, Sergey Dobrov wrote: >> On 02/10/2015 01:57 AM, Florian Schmaus wrote: >>> But IMHO there is one piece missing. If we assume that the outbound >>> traffic of a mobile device is not causing any unwanted battery drain, >>> that is because if the device sends something it usually has a pretty >>> good reason to do so, it becomes obvious that we need to focus on >>> inbound traffic. >> I'd say it another way: we can move the responsibility to client as it >> tightly depends on client's UI and approaches so they need to decide, >> this will be a way of competing among clients :) > > Yep, but not all XMPP clients have an UI. It basically comes down to > "The XMPP client is responsible to avoid sending data where possible, > and if it does send data it should send as less data as possible, e.g. > by omitting the 'from' stanza attribute". > >>> Let's start by classifying inbound stanzas into three types. There are >>> stanza that… >>> 1. require immediate delivery >> Even those stanzas can be slightly deferred and be bundled, I believe. >> Just the interval will be much thicker, and still it can reduce number >> of necessary wakes up. > > I'm not sure about that, Even if you defer all messages for only 30 > seconds, realtime (chat) communication would become a pain. And there is > also little gain in that. I guess that only if your defer interval is > something > 15 minutes you will see a measurable positive effect on the > battery consumption. I'm not sure here. This page http://chimera.labs.oreilly.com/books/123000545/ch07.html#_initiating_a_request says that it can take few dozen seconds for the radio to go to dormant state to conserve radio and each next wake up of it can consume up to 100ms and corresponding battery consumption. I have no idea if there's an API on mobile device that can say if the radio is in active state or not but I guess it could be a good optimisation to flush our buffer when someone else woke up the radio. >From the other hand, if stanza requires immediate delivery, it's unlikely we can defer it even for a minute, so it's probably useless anyway. But from now it's a good question on how to classify the stanzas. For example, chatstates can be slightly deferred in an expectation that someone else will wake up the radio, right? I also think, that even 5 minutes interval (for incoming stanzas from client side) can be a good deal still. Also, when the client sees that radio has been woken up, it can send a request to server to flush the buffers quickly without any hurt to battery (but this can require additional CSI state). I have more ideas but need to do some investigation of what APIs modern mobile platforms provide to track those states. (for example, there is a persistent low-bandwidth outgoing channel on HSDPA networks which can be used to deliver small payloads regardless of the current radio states which could have interesting applications in our case) So, I think that the best performance can be achieved when we have long intervals (15 minutes looks good) and when we ask server to flush the queue each time our radio wakes up. > >>> 2. can be delayed >>> 3. should not be delivered at all >>> >>> The appealing simplicity of CSI is that it categorizes presences >>> stanzas as type 2., and simply delays them until the client reports >>> that it is active. >> I think that we also should remove presences from sending queue when new >> presence from the same full JID has came, as old ones are not needed >> anymore anyway. > > IIRC that is what most CSI implementations already do. wonderful. > >>> I pointed out a possible attack scenario at my lightning talk [1], >>> where a malicious entity drains the victims battery by repeatedly >>> sending XMPP stanzas to the victims mobile. The stanzas originating by >>> the malicious entity obviously are of type 3. >> I think that this is a completely different problems actually because >> this can happen also with subscribed contacts, so it's unnecessary to >> focus on this problem in as part of CSI. Instead, some new security >> protocols should be invented including spam protection. (They are too >> complicated to discuss them here, I think?) > > Please note that I'm not describing an extension of CSI. Bundling and > Deferring is a concept unrelated to CSI, their only relation is that > both come in handy in a mobile environment and that they are useless in > an environment where traffic volume and battery consumption doesn't count. > > Also this is not meant as SPAM protection measure. That's not the scope > of the bundle and defer mechanism. > >>> A possible countermeasure would be using Privacy Lists (XEP-16) to >>> block all incoming stanzas from entities not in the user's >>> roster. When I told Chris Deering about that, his response was that >>> this would y
Re: [Standards] Using XMPP In A Mobile Environment
Hi Sergey, thanks for you reply. :) On 10.02.2015 09:11, Sergey Dobrov wrote: > On 02/10/2015 01:57 AM, Florian Schmaus wrote: >> But IMHO there is one piece missing. If we assume that the outbound >> traffic of a mobile device is not causing any unwanted battery drain, >> that is because if the device sends something it usually has a pretty >> good reason to do so, it becomes obvious that we need to focus on >> inbound traffic. > I'd say it another way: we can move the responsibility to client as it > tightly depends on client's UI and approaches so they need to decide, > this will be a way of competing among clients :) Yep, but not all XMPP clients have an UI. It basically comes down to "The XMPP client is responsible to avoid sending data where possible, and if it does send data it should send as less data as possible, e.g. by omitting the 'from' stanza attribute". >> Let's start by classifying inbound stanzas into three types. There are >> stanza that… >> 1. require immediate delivery > Even those stanzas can be slightly deferred and be bundled, I believe. > Just the interval will be much thicker, and still it can reduce number > of necessary wakes up. I'm not sure about that, Even if you defer all messages for only 30 seconds, realtime (chat) communication would become a pain. And there is also little gain in that. I guess that only if your defer interval is something > 15 minutes you will see a measurable positive effect on the battery consumption. >> 2. can be delayed >> 3. should not be delivered at all >> >> The appealing simplicity of CSI is that it categorizes presences >> stanzas as type 2., and simply delays them until the client reports >> that it is active. > I think that we also should remove presences from sending queue when new > presence from the same full JID has came, as old ones are not needed > anymore anyway. IIRC that is what most CSI implementations already do. >> I pointed out a possible attack scenario at my lightning talk [1], >> where a malicious entity drains the victims battery by repeatedly >> sending XMPP stanzas to the victims mobile. The stanzas originating by >> the malicious entity obviously are of type 3. > I think that this is a completely different problems actually because > this can happen also with subscribed contacts, so it's unnecessary to > focus on this problem in as part of CSI. Instead, some new security > protocols should be invented including spam protection. (They are too > complicated to discuss them here, I think?) Please note that I'm not describing an extension of CSI. Bundling and Deferring is a concept unrelated to CSI, their only relation is that both come in handy in a mobile environment and that they are useless in an environment where traffic volume and battery consumption doesn't count. Also this is not meant as SPAM protection measure. That's not the scope of the bundle and defer mechanism. >> A possible countermeasure would be using Privacy Lists (XEP-16) to >> block all incoming stanzas from entities not in the user's >> roster. When I told Chris Deering about that, his response was that >> this would yield a bad UX. And he is of course right. There is no way to >> reliable know if a stanza is of type 3. But do we really need that? > Probably, those security protocols should be extensions to Privacy Lists... Yeah, but I guess exploring how this could be used together with SIFT too. If it only had a roster/subscription state based filtering mechanism. >> The missing piece I was talking about at the beginning, is a mechanism >> to *bundle and defer* stanzas (usually messages): Particular stanzas are >> bundled and their delivery to the (mobile) user is deferred, so that the >> stanzas are send in bulk, giving the mobile device the possibility to >> enter sleep mode while the stanzas are deferred. This could (typically) >> apply to stanzas send from entities which don't have a subscription to >> the users presence. > ALSO, if client supports such a feature, we could actually hide the > message content (if it exceeds certain size) and offer to fetch it with > MAM later if needed. (just as PubSub does when content delivery in > events is switched off in node configuration). Not sure about the hiding of message content if the message already was deferred. It seems to add just extra complexity without no big advantage. >> So the basic idea is clear, but I'm undecided how to specify such an >> mechanism. For example: >> - Should the stanzas which are bundled and deferred be matched by >> - Privacy Lists >> - SIFT. But SIFT has no way to filter on roster status (e.g. "If sender is >> not subscribed to my presence, defer and bundle the stanza he >> wants to send to me" :-( ) >> - Delay Time? I'm thinking about recommending 15-30 minutes, while >> warning that it should be not less then 15 minutes (a typical SMTP >> greylisting timeout). > But it can be less than 15 minutes if device wakes up earlier, right? Well we coul
Re: [Standards] Using XMPP In A Mobile Environment
Hi Florian and folks, On 02/10/2015 01:57 AM, Florian Schmaus wrote: > XEP-352: Client State Indication (CSI) is a big step towards reducing > XMPP battery usage which is crucial in a mobile environment. > > But IMHO there is one piece missing. If we assume that the outbound > traffic of a mobile device is not causing any unwanted battery drain, > that is because if the device sends something it usually has a pretty > good reason to do so, it becomes obvious that we need to focus on > inbound traffic. I'd say it another way: we can move the responsibility to client as it tightly depends on client's UI and approaches so they need to decide, this will be a way of competing among clients :) > > Let's start by classifying inbound stanzas into three types. There are > stanza that… > 1. require immediate delivery Even those stanzas can be slightly deferred and be bundled, I believe. Just the interval will be much thicker, and still it can reduce number of necessary wakes up. > 2. can be delayed > 3. should not be delivered at all > > The appealing simplicity of CSI is that it categorizes presences > stanzas as type 2., and simply delays them until the client reports > that it is active. I think that we also should remove presences from sending queue when new presence from the same full JID has came, as old ones are not needed anymore anyway. > > I pointed out a possible attack scenario at my lightning talk [1], > where a malicious entity drains the victims battery by repeatedly > sending XMPP stanzas to the victims mobile. The stanzas originating by > the malicious entity obviously are of type 3. I think that this is a completely different problems actually because this can happen also with subscribed contacts, so it's unnecessary to focus on this problem in as part of CSI. Instead, some new security protocols should be invented including spam protection. (They are too complicated to discuss them here, I think?) > > A possible countermeasure would be using Privacy Lists (XEP-16) to > block all incoming stanzas from entities not in the user's > roster. When I told Chris Deering about that, his response was that > this would yield a bad UX. And he is of course right. There is no way to > reliable know if a stanza is of type 3. But do we really need that? Probably, those security protocols should be extensions to Privacy Lists... > > The missing piece I was talking about at the beginning, is a mechanism > to *bundle and defer* stanzas (usually messages): Particular stanzas are > bundled and their delivery to the (mobile) user is deferred, so that the > stanzas are send in bulk, giving the mobile device the possibility to > enter sleep mode while the stanzas are deferred. This could (typically) > apply to stanzas send from entities which don't have a subscription to > the users presence. ALSO, if client supports such a feature, we could actually hide the message content (if it exceeds certain size) and offer to fetch it with MAM later if needed. (just as PubSub does when content delivery in events is switched off in node configuration). > > So the basic idea is clear, but I'm undecided how to specify such an > mechanism. For example: > - Should the stanzas which are bundled and deferred be matched by > - Privacy Lists > - SIFT. But SIFT has no way to filter on roster status (e.g. "If sender is > not subscribed to my presence, defer and bundle the stanza he > wants to send to me" :-( ) > - Delay Time? I'm thinking about recommending 15-30 minutes, while > warning that it should be not less then 15 minutes (a typical SMTP > greylisting timeout). But it can be less than 15 minutes if device wakes up earlier, right? > - Should the server send a "your message has been queued for later > delivery" message back to the sender? Yes, I believe it is must have. Just like the notifying that the message has been stored in the offline storage. > > I'd love to hear some feedback, and if someone is willing to > collaborate working on a specification it would be welcomed too. Not sure that I really can be helpful here but I'd love to discuss and give feedbacks on the things I'm smart enough to comment on :) > > - Florian > -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
[Standards] Using XMPP In A Mobile Environment
XEP-352: Client State Indication (CSI) is a big step towards reducing XMPP battery usage which is crucial in a mobile environment. But IMHO there is one piece missing. If we assume that the outbound traffic of a mobile device is not causing any unwanted battery drain, that is because if the device sends something it usually has a pretty good reason to do so, it becomes obvious that we need to focus on inbound traffic. Let's start by classifying inbound stanzas into three types. There are stanza that… 1. require immediate delivery 2. can be delayed 3. should not be delivered at all The appealing simplicity of CSI is that it categorizes presences stanzas as type 2., and simply delays them until the client reports that it is active. I pointed out a possible attack scenario at my lightning talk [1], where a malicious entity drains the victims battery by repeatedly sending XMPP stanzas to the victims mobile. The stanzas originating by the malicious entity obviously are of type 3. A possible countermeasure would be using Privacy Lists (XEP-16) to block all incoming stanzas from entities not in the user's roster. When I told Chris Deering about that, his response was that this would yield a bad UX. And he is of course right. There is no way to reliable know if a stanza is of type 3. But do we really need that? The missing piece I was talking about at the beginning, is a mechanism to *bundle and defer* stanzas (usually messages): Particular stanzas are bundled and their delivery to the (mobile) user is deferred, so that the stanzas are send in bulk, giving the mobile device the possibility to enter sleep mode while the stanzas are deferred. This could (typically) apply to stanzas send from entities which don't have a subscription to the users presence. So the basic idea is clear, but I'm undecided how to specify such an mechanism. For example: - Should the stanzas which are bundled and deferred be matched by - Privacy Lists - SIFT. But SIFT has no way to filter on roster status (e.g. "If sender is not subscribed to my presence, defer and bundle the stanza he wants to send to me" :-( ) - Delay Time? I'm thinking about recommending 15-30 minutes, while warning that it should be not less then 15 minutes (a typical SMTP greylisting timeout). - Should the server send a "your message has been queued for later delivery" message back to the sender? I'd love to hear some feedback, and if someone is willing to collaborate working on a specification it would be welcomed too. - Florian signature.asc Description: OpenPGP digital signature
