unnecessary pain

No plan survives contact with the enemy. This was made abundantly clear when Qunu was released as alpha for the public to abuse. As with any alpha there were countless problems that I dealt with on a daily basis. Clients insisting that a jid must have a node, xdata limitations in iq:register, double subscriptions, broken muc support, etc…

For some of these problems I was able to hack up a work around, such as quser@qunu.com as a subscription proxy for quser.alpha.qunu.com. A few of them had no decent solution and I had to suggest other clients. The wiki page, http://qunu.com/wiki/index.php/Documentation, has a list of clients which have the bare minimum feature set.

The default gtalk client does not support muc or groupchat. Since a lot of people had a gmail account they naturally tried to use their gtalk clients. Making the brash assumption that gtalk behaved like every other xmpp server I directed them to the above list of working clients to try. After several confusing chats and some poking of my own I quickly discovered that gtalk is not xmpp.

That may sound rather harsh so let me qualify that. While google’s xmpp-like servers may follow the letter of the xmpp RFC‘s they most certainly do not follow the spirit. The reason I say this is that the gtalk servers will block any stanza which their default client will not understand regardless of which client you are actually using. This means that even if you wanted to get cool new features by using another jabber client, gtalk will block the stanzas before they get to your client. Not only do you have to get a different client, but you have to use a different server. *sigh*

The biggest issue, at least for qunu, is muc invites. GTalk silently drops them regardless of which client is on the other end. disco requests are reported assuming the default client. iq:version is always reported as not implemented, again ignoring the client.

Of course there is no bug/issue report system at google. Thus this blog post. Hopefully someone at gtalk will see this and file a bug. Of course, if you need further clarification, feel free test this yourself or ping me at zion@openaether.org

Comments (6)

  1. Anonymous wrote::

    > Of course there is no bug/issue report system at google.

    Try this:
    http://www.google.com/support/talk/bin/request.pycontact=1&ctx=contact-us

    > the gtalk servers will block any stanza which their default
    > client will not understand

    I don’t think this is true. I have been able to send custom stanzas through Google Talk servers.

    A more likely explanation of your problem is that the Google Talk server uses the roster as a whitelist. Unless the muc is on the user’s roster, the invitation from the muc will not get through.

    Wednesday, July 5, 2006 at 6:41 am #
  2. Anonymous wrote::

    oops, bad url. here it is again: http://www.google.com/support/talk/bin/request.py?contact=1&ctx=contact-us

    Wednesday, July 5, 2006 at 6:44 am #
  3. Joe LaPenna wrote::

    http://www.google.com/support/talk/bin/request.py?contact=1&ctx=contact-us Is Google’s Talk support page.

    http://groups.google.com/group/Google-Talk-Help-Discuss Is the google group to talk about this in.

    As best I remember gtalk didn’t always do this. Perhaps its something thats slipped by Google’s unittests.

    Wednesday, July 5, 2006 at 7:54 am #
  4. Chris DiBona wrote::

    Two things:

    Support Info

    Also, make sure the muc is in the users roster. If they are not a contact of the user, we make sure they don’t get bothered. We do not filter muc stanzas (from what I understand, I’m not on that particular team) Also, consider joining the gtalk mailing list (not as technical as I’d like, but it is a start).

    Wednesday, July 5, 2006 at 12:01 pm #
  5. Anonymous wrote::

    > Perhaps its something thats slipped by Google’s unittests.

    Blocking any stanza which their default client will not understand is not something that happens by accident. This is not something that slipped by a unittest.

    Thursday, July 6, 2006 at 10:19 am #
  6. Helmar wrote::

    Chris wrote: “If they are not a contact of the user, we make sure they don’t get bothered.”

    Shouldn’t that be left to the user to decide whether they want to be bothered or not? If you don’t have quser.alpha.qunu.com on your roster you won’t get bothered in the first place.

    Filtering stuff based on assumptions only works if the assumptions are correct. In this case they aren’t.

    Perhaps the XMPP system itself needs an overhaul. But that’s another subject altogether, and a sore one for anyone who’s ever used the Sonork IM and who feels thrown back into stone age when confronted with any of the current Jabber clients out there.

    Friday, July 7, 2006 at 4:22 am #