Today, while reading logs on an unrelated bug, I noticed that Facebook pushes messages that the user sends via another client (such as the web interface) out to connected XMPP sessions. Here's an example. I sent a message—“please ignore this message”—to a contact (whose user ID I have redacted) using the web interface, while connected using Gabble. Gabble received this stanza: _end_element_ns: Received stanza * iq xmlns='jabber:client' from='chat.facebook.com' to='will.joseph.thompson@chat.facebook.com/b756e715_3fcfe842_4AE62CA0B8312' id='fbiq4AE6571A03651' type='set' * own-message xmlns='http://www.facebook.com/xmpp/messages' to='-<redacted>@chat.facebook.com' self='false' * body "please ignore this message" Observations: • the IQ comes from the server; • the recipient of the message is an attribute of the payload; • when I sent a message using Gabble, it was pushed straight back to Gabble in the same format, but with self='true'. We could potentially expose these in a number of ways: • As normal messages, annotated as 'scrollback'; • As delivery reports; • On a to-be-defined API for retrieving logs.
I have a WIP branch at http://cgit.collabora.com/git/user/wjt/telepathy-gabble-wjt.git/log/?h=facebook-own-message (in case anyone finds themselves filled with a burning desire to implement this).
It's finished! The delivery reports use Delivery_Status_Accepted: all we know is that the message reached the Facebook server. They don't have delivery-token because Facebook doesn't give us the id='' of the message we sent. Sigh. Whether the message was sent locally or via some other client is not exposed; should I invent a key for that, do people think? I think we can revisit that when some UI exposes this. The actual Facebook patch is quite small. The branch, on the other hand, is quite big. But it's mostly bits of cleanup plus a bit of refactoring of the delivery report code. So it shouldn't be too heavy to review. There's a slight quirk in this which I discovered while testing it: if I send Jonny a message using the email-style interface in the Facebook web interface, I (sometimes, but not always) get an own-message push, but the to='' attribute on own-message is wrong: it claims that I sent the IM to myself! So Gabble doesn't push it out as a delivery report, because I don't have an IM channel open to myself. (Gabble can't actually (easily) detect that this has happened: it thinks my JID is will.joseph.thompson@chat.facebook.com/..., but the to='' attribute on own-message is -36800444@chat.facebook.com.)
Only two comments for your most recent patch: Firefox is ruining my indentation pasting, but this block should be indented and have curly brackets: + if (!tp_strdiff (stream_server, "chat.facebook.com")) + wocky_porter_register_handler_from ( The Facebook own-message test seems to rely on Gabble acking the IQ *before* signalling MessageReceived? Is that right?
(In reply to comment #3) > Only two comments for your most recent patch: > > Firefox is ruining my indentation pasting, but this block should be indented > and have curly brackets: > > + if (!tp_strdiff (stream_server, "chat.facebook.com")) > + wocky_porter_register_handler_from ( Fair. If bug 39057 is fixed I can replace this with wocky_porter_register_handler_from_server() in any case I guess and remove the conditional. > The Facebook own-message test seems to rely on Gabble acking the IQ *before* > signalling MessageReceived? Is that right? No, the 'stream-' and 'dbus-' queues are independent these days.
(In reply to comment #4) > (In reply to comment #3) > > Only two comments for your most recent patch: > > > > Firefox is ruining my indentation pasting, but this block should be indented > > and have curly brackets: > > > > + if (!tp_strdiff (stream_server, "chat.facebook.com")) > > + wocky_porter_register_handler_from ( > > Fair. Fixed and merged to master.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.