So, what's happening is that it accepts our credentials, but immediately sends us a <message/> from 'chat.facebook.com' explaining the situation, and then disconnects us. However, the message never makes it to the UI, for two reasons:

• The message sender's JID is just a domain, not node@domain. Gabble currently
ignores messages from such JIDs. This is buggy; however, the flipside of
allowing IMing such JIDs is that if the user types 'foo.bar' rather than
'foo.bar@gmail.com', Gabble would happily try to communicate with the domain
foo.bar rather than raising an error as it currently does.

• Even if Gabble did expose the message, since the connection is immediately
terminated the channel would die before it has a chance to make it to the UI.

We should fix both of these issues. The former is just a Gabble issue; the
later needs work in the spec. and MC...

Spec meeting notes:

First problem: Gabble doesn't think chat.facebook.com is a valid handle.

• Should Gabble let you request a handle for JIDs with no node part? If
  so, then if you mistakenly try to contact 'will.thompson' rather than
  'will.thompson@collabora.co.uk', the failure will occur much later
  than it currently does (since at the moment Gabble won't give you a
  handle, or a channel, for the former).
• Idle is a bit more tolerant of contact IDs it receives from the
  network than those it receives over D-Bus, because bip uses a nickname
  that's illegal per the IRC RFC. This would be an acceptable stop-gap
  solution in Gabble, too.

Second problem: what do we do about channels appearing as the connection
closes?

• this could be a property of the disconnecting state in hypothetical
  Telepathy 1.0?
• add a flag for "i'm well behaved, i'll close up my own channels"
  · problem: then you have to ack all the messages before you can
    reconnect
  · here's a bad idea: uniquify channel paths across connections, make
    channel outlive connection. rejected: you need the connection to
    look up aliases and do other useful things with a channel.
  · here's another bad idea: re-use connections, rather than having them
    die when they become Disconnected.
• we punted on this for now.

The recent discussion about Captcha channels led me to wonder... maybe we could introduce a new channel type for server messages/notifications. That is, messages like these messages from the Facebook server, from IRC servers, and so on, which should be displayed to the user but to which the user has no way (or limited ways) to respond. (Sending normal text messages to servers on XMPP makes sense in some pretty restricted cases, though...)

If we were to introduce a new channel type, then having the connection stay open until they're closed would not break backwards compat.: either you have a handler — in which case it can ack messages/close the channel/etc. — or you don't — in which case the channel will be Close()d by MC in a huff.

We could hack the Facebook case by having Gabble save the message chat.facebook.com sends us (either by hard-coding that JID in Gabble, or by looking at the domain part of our JID). Then if the very next thing that happens is we get disconnected, we could put the message into ConnectionError, along with a d-bus error code which means “the server sent us a message and then booted us off”.

This obviously doesn't solve the general case of the user missing messages that arrive just as they're disconnecting (a distressing case, to be sure) but would make for a nicer experience in the Facebook case.

Empathy user hitting this bug (with logs): https://bugzilla.gnome.org/show_bug.cgi?id=686403

Afaik, facebook no longer supports XMPP, so I'm closing this report. The underlying issues may still appear with another service, but let's deal with that when it actually happens.