Hacker News Reader

Comment by Flowdalic | Hacker News Reader

> 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.

View on HN

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

Indeed, my description was rough and from memories a few year ago. But I believe it still demonstrates the point I was trying to illustrate:

There is unneccessary complex behaviour in XMPP that you must write extra code in your client for. Otherwise it will work mostly, but not always and not reliably.

Pretty sure you want your XMPP client to announce that it is online, so you'd have to implement that anyways.

This is all well described in the RFCs and http://www.xmpp.org/extensions/xep-0160.html

IIRC, the ejabberd server will wait until you are "present". Only then it will send you all messages so far received for you.

That ejabberd does something doesn't mean it's the proper behaviour. Maybe it's a bug?

Really? The old Google Talk service used to do this, but I didn't think ejabberd did. There's a bunch of non-IM use-cases which need presence-less messaging.

Seems like Prosody has the same behavior. Ran into just this morning.

Reply on news.ycombinator.com