Stream management support

[a-iv]

http://xmpp.org/extensions/xep-0198.html

[Natanji]

This would be a very important feature for mobile use to prevent everyone seeing mobile users disconnect/reconnect all the time in quick succession...

[mhellwig]

is there any info whether this can/will be added and with what sort of timeframe?

mobile XMPP is almost unusable without this.

[JazJazgot]

This is really very important

[hillbicks]

Hi everyone,

I’d like to see this as well. Seeing that xabber is a client for android, therefore a primarily mobile client, this is a very important feature. I’m still trying to convince everyone and their mother to use xmpp as an alternative to facebook chats, google hangout and whatnot. But this is still difficult because every once in a while messages get lost when losing the connection. Yes, the little green check mark helps, but not everyone looks for that - constantly. I really think this should be a priority because it prevents people from taking xmpp seriously and using it on a daily basis.

Please don’t see this as a “I’m entitled to that feature, hurry up and programm”, I’m just trying to make the case for reliable message delivery. It would be really nice if you could share your thoughts on this feature. Are you considering it, is there an estimate for this feature, etc.

Thanks very much!

[gjedeer]

So this is why messages are lost sometimes. XEP-198 looks like a must-have on a mobile connection.

[inittab]

Hi, please, pretty please, implement this must-have feature on a mobile client. Otherwise messages get silently lost.
Thanks for you work!

[Nekmo]

Another one that loses messages because of this :(

[busybit]

When can we expect this "must-have extension" in Xabber?

Does someone know some other Android client with XEP-0198?

[casperklein]

Securechat, Yaxim and Conversation

[AndreasUfert]

Would like to see XEP-0198 support in Xabber, too. The need is well-founded described here: http://op-co.de/blog/posts/XEP-0198/

[devurandom]

Any news or progress in this matter?

[hillbicks]

Since the last update to the development edition of xabber is from september of last year, I'm pretty sure they abandoned this project and it doesn't seem that anyone is working on making xmpp a usable experience for mobile users. Sad state of affairs really.

[ghost]

Before August last year there had been a period of 6 months without any updates to the development version, so that's not a guarantee the project was abandoned.

[casperklein]

According to twitter, they are still working on xabber development: https://twitter.com/Xabber_XMPP/status/428140402529402880

[geramaya]

pardon, but i don't like twitter. i would like to use github for communication and watch the project :)
thx in advance

[hillbicks]

yaxim now supports xep-0198 and it seems to work just fine! Just switched the client. Version 0.87.

[DrAzraelTod]

+1

[schtobia]

+1, the single most important missing feature of xabber and the reason I'm with yaxim right now.

[Polve]

+1

[egon0]

+1

[Finkregh]

what @schtobia said.

:(

[kaimast]

Would be so nice to see this in Xabber. +1

[kiowas]

+1

[jplitza]

FTR, here is the feature request in Smack, the XMPP library Xabber uses. No activity there for over a year now either, but it contains links to the relevant pull requests in [gibberbot/ChatSecure](which uses Smack as well) and their build system for Smack, aSmack.

[DanScharon]

+1 a must-have, indeed

[gjedeer]

https://www.bountysource.com/issues/1025378-stream-management-support

[tejasinamdar]

We have developed the plugin to ensure that no messages are lost (in the context of Openfire). Using Openfire, in the presence of a weak network, messages/packets are lost. Hence, to ensure deliveries (at-least-once) and no message/packet losses we have developed the plugin. The plugin ensures 'Stanza Acknowledgements' (the ability to know if messages have been received by one's peers) with no losses (at-least-once deliveries).
See 'https://www.atklique.com/bridge/blog/?q=node/5'.

[SafwatHalaby]

@busybit
Conversations.

[sbrl]

This is getting really bad. Recently on the mobile network I've just 10% of messages sent / received have got through. I don't want to, but I might have to switch out from Xabber temporarily while this is implemented.

Also, I've noticed that @gjedeer has created a bounty for this issue, which currently stands at $45. Link here.

[schtobia]

I've thrown in an additional $15 bucks. This issue needs to be done.

[denschub]

Smack supports stream management since 4.1.0...

[Ape]

Why is this issue still open if #595 was merged?

[sbrl]

@Ape Good question. I'll have to try and see if I am dropping any messages now.

[SafwatHalaby]

Note that "Stream Management" alone does not guarantee messages are never dropped. In the case where a client disconnects and stays offline from a while, stream management will timeout. If a message was pending to be sent to said client and such a timeout occurs, then it is up to the server implementation to either notify the sender of an error, or store the message and treat it as a message sent to an offline contact.

The latter behavior is required for a true 100% guarantee of delivery. So pick the right server. Ejabberd optionally supports the latter option via the resend_on_timeout listening module setting.

[sbrl]

@LogicParrot My server should be configured to support both stream management and storing messages sent to offline contacts. I'll test it when I next get a chance.

[weiss]

You don't usually want the server to write such pending messages to offline storage unless you know the recipient wasn't online with a second device which already received those messages (by means of carbon copies, for example). ejabberd's resend_on_timeout option can be set to if_offline which does the right thing™ in most but not all cases. The details are explained in an FAQ entry.

The proper way to ensure reliable delivery (and at the same time, multi-device sync) is to use MAM.

[SafwatHalaby]

Can MAM act as a complete substitute for Carbon Copies and/or Stream Management?

[weiss]

No, you want to use carbon copies to synchronize online clients and MAM to let offline clients catch up. You also want to continue using stream management to figure out which outgoing messages must be resent after network outages, and for quick stream resumption.

[denschub]

@grigoryfedorov do you mind closing this feature request?

[ItchyBugReporter]

I say keep it open. It's definitely a must-have for mobile-only users.

[denschub]

This was implemented in #595 almost 8 months ago.

[ItchyBugReporter]

Ah, I didn't realize you've already submitted the code for it. Looks like it just needs to be merged in :-)

[denschub]

It, uh, was merged 8 months ago. That's the reason I insist on having this issue closed, because this is resovled. :)

[ItchyBugReporter]

If it's been merged, then github is lieing to me about the contents of the files you changed. Neither of the files referenced in your pull request have your changes in Redsolution's repository.

[denschub]

https://github.com/redsolution/xabber-android/blob/develop/xabber/src/main/java/com/xabber/android/data/connection/ConnectionThread.java#L95-L97

[sbrl]

Just a note: I still appear to be dropping messages in both directions when switching networks on my phone (e.g. 3G <-> WiFi or moving mobile network cells).

[ItchyBugReporter]

@denschub Ah, I was looking at the master branch, not the dev branch. Whoops.

@sbrl Since it's been merged into development, I'm guessing you'll need to use the development version of Xabber for the time being if you want to get stream management support.

[sbrl]

@ItchyBugReporter Right. It'll be in the next beta release then I assume?

[ItchyBugReporter]

I'm the wrong person to ask, I'm not a developer for Xabber, and other than this particular thread on the issue tracker I have no communication with the Xabber developers.

I do know that the version on FDroid (which uses the development branch) was built after the merge, so if you're using the FDroid version you probably already have it.

[denschub]

@grigoryfedorov please... close this issue. ;)

[sbrl]

Ping @a-iv

[andrewnenakhov]

Implemented in v2.0.

[gjedeer]

@andrewnenakhov it seems this is implemented but you did not claim the reward in bountysource, check it out if interested https://www.bountysource.com/issues/1025378-stream-management-support