Opened 10 years ago

Closed 8 years ago

Last modified 6 years ago

#3360 closed enhancement

Chat Room Support in Google Talk

Reported by: onlineapps Owned by: darkrain42
Milestone: Component: Google Talk
Version: 2.2.0 Keywords: chat
Cc: skliarie, musuruan, Merkaba, zorkerz

Description

Google Talk's flash app has support for chat rooms. But Pidgin doesn't. Why not reverse-engineer it?

Change History (33)

comment:1 Changed 10 years ago by lithium

Wouldn't this be just a matter of setting the right XMPP conversation server for the gtalk protocol?

comment:2 Changed 10 years ago by seanegan

Google Talk doesn't support proper capabilities detection, which is why it doesn't use normal group chat with Pidgin. I'll work on that.

comment:3 Changed 10 years ago by skliarieh

As a workaround, until we can utilize Google Talk chat servers, can we use an public chat servers? I would prefer to have pidgin-clients-only chat working, instead of no chat at all.

comment:4 Changed 10 years ago by rekkanoryo

Yes, you can use any public MUC server that's part of the federated network, such as conference.jabber.org or any of the others that are around.

comment:5 Changed 10 years ago by skliarieh

Can pidgin by default configure XMPP or GTalk account to use public chat servers? Until the problem with GTalk chat servers is resolved?

I can't tell my pidgin+XMPP friends to manually change configuration to be able to use chat option. But I can ask them to upgrade :-).

comment:6 Changed 10 years ago by rekkanoryo

There is no configuration option. You enter the server name when you join the conference or look at Tools->Room List.

comment:7 Changed 10 years ago by skliarieh

I just tried to join a chat (pidgin 2.0.1) and got nothing happend. Here is output of the corresponding action under "pidgin --debug" mode:

(05:22:03) jabber: Sending (ssl): <presence to='blah421522@…/skliarieh'><priority>1</priority><c xmlns='http://jabber.org/protocol/caps' node='http://pidgin.im/caps' ver='2.0.1'/><x xmlns='http://jabber.org/protocol/muc'/></presence> (05:23:12) jabber: Recv (ssl)(1):

comment:8 Changed 10 years ago by deryni

jabber.org seems to be having issues at the moment, try some other server (like conference.jabber.ru as) a test it should work.

comment:9 Changed 10 years ago by kentyman

I'm confused. When logged into Google Talk, how can I use Buddies>>Join a Chat to create a chat room that other Pidgin users can join? Or can you only join rooms that already exist?

comment:10 Changed 10 years ago by mork.the.delayer

It looks like the gmail version of google talk now supports group chat: http://googlesystem.blogspot.com/2007/11/new-version-of-gmail-adds-group-chat.html

Maybe this can be reverse-engineered in order to get chat rooms working in Pidgin?

comment:11 Changed 10 years ago by rekkanoryo

As has been said numerous times, Google Talk does NOT support proper multi-user conferences. The "chat" features are implemented only by their gadget and their gmail web interface; there is no support for it in any XMPP client.

comment:12 follow-up: Changed 10 years ago by blodulv

comment:13 in reply to: ↑ 12 Changed 9 years ago by shreevatsa

Summary of "more information" at the link in the previous post, and my own experiments:

  • The Google server ignores chat invites from non-contacts, and does not send chat invites to non-contacts. (This is probably the right behaviour.)
  • From a XMPP MUC (a room on conference.jabber.org, say), inviting a talkgadget user makes talkgadet automatically add that user to the room with the nick "username_gmail.com", and that user sees all names as "undefined", and one person joining the room is interpreted as several people named "undefined" joining the room, etc. If the room was created as allowing anyone to see bare jids, then talkgadget sees the jids and reports the username part of them. It is not possible to invite a gmail user.
  • If you try to invite someone to a "group chat" from talkgadget, it *refuses* to invite people with non-Google accounts, and to the Google accounts (irrespective of client they are using) it send an *IM* saying "$talkgadget_user has invited you to a group chat. Click here to join the conversation: http://talkgadget.google.com/talkgadget/joinpmuc?r=CjlZh...etc...&si=1

So Google's "group chat" _is_ probably some form of XMPP MUC, but it doesn't understand room names or nicks, uses only jids, doesn't invite non-Google accounts, sends invitations as IMs with links, and auto-accepts invitations.

comment:14 Changed 9 years ago by shreevatsa

The http://talkgadget.google.com/talkgadget/joinpmuc?r=CjlZh...etc...&si=1 links also seem to be some kind of persistent something.

Typing something random gives "'r' parameter is invalid Error 400", going to the link while logged in to the wrong account says "You are signed in as something.else@…, but this invitation is addressed to a different account. Please sign out and sign in with the account to which the invitation you received was addressed.", going to the link from the right account remembers who had sent that invitation (even after more than a month!), and the talkgadget also tries to connect to www.orkut.com for some evil reason. (And it also seems to actually join a group chat after that...)

comment:15 in reply to: ↑ description Changed 9 years ago by chipwizme

Replying to onlineapps:

Google Talk's flash app has support for chat rooms. But Pidgin doesn't. Why not reverse-engineer it?

This is how it works:

When someone invites you to a group chat, but you aren't using the google talk gadget, the server sends you the message:

<message to='christian@freedomofknowledge.org' type='chat' from='chipwizme@gmail.com/gmail.56E2E6BB'>
	<body>Christian Wisner-Carlson has invited you to a group chat.  Click here to join the conversation: http://hostedtalkgadget.google.com/a/freedomofknowledge.org/talkgadget/joinpmuc?r=ClJS5jqNzLxqtqs2d2ra2b_rsj3Lyyp1DH6q01TIXyRm4wbMPEcFYpp0-ZUrY4RtG-zbL-lo7P94IFQtVTHLnM_l4f2Ed10zSmKyiozyG-VEYrjdEgzuahbXUDIXxXseoa4YAQ&si=1</body>
	<google-mail-signature xmlns='google:metadata'>7281a0a37d732938</google-mail-signature>
	<x xmlns='google:nosave' value='disabled'/>
	<record xmlns='http://jabber.org/protocol/archive' otr='false'/>
</message>

if you click on the link (you have to have "remember me" enabled or it will prompt you to login) a page with a "launch group chat" button appears. examining the source reveals a line:

var room = "private-chat-ecad2d98-1347-43d9-8bdc-55b25a1b4814@groupchat.google.com";

to join the chat in pidgin, paste everything before the "@" in the "room" box and "groupchat.google.com" into the server box.

I propose a plugin to pidgin that intercepts the invite messages, uses wget or curl to login to google (see http://code.google.com/support/bin/answer.py?answer=78451&topic=12022#authenticating-clientlogin ) and fetches the page, then joins the chatroom enumerated in "var room". Unfortunately, I'm a crappy coder, and have no idea how to write such a plugin. If anyone would like to do this, please email me (christian@…) and i will give you all my pertinent research.

comment:16 Changed 9 years ago by onlineapps

Another option would be to add a Google Talk protocol. We already have one, but it changes into an XMPP one. If we kept them separate, we could add support for group chats.

comment:17 Changed 9 years ago by chipwizme

Well, yes, but it seems trivial (read: one hour) for a half-decent coder to make a plugin to do as i proposed. Full integration with pidgin would come later. Adding a google talk protocol would be pretty easy as well, i guess, because one would just need to sed the code to change the protocol name and make a few trivial changes. Also, the off the record feature could be easily implemented.

comment:18 Changed 8 years ago by QuLogic

  • Owner changed from seanegan to darkrain42

comment:19 Changed 8 years ago by darkrain42

  • Milestone set to Patches welcome

A completely separate "Google Talk" protocol is not necessary and is largely counterproductive, due to the massive overlap between XMPP and GTalk.

As chipwizme said, a plugin could be written to intercept the messages, and fetching the URL and popping up a "Join a chat" dialog are both doable events.

I'd even consider integrating a well-written patch (that keeps the google hackery separate from the actual XMPP MUC support) into the XMPP prpl, although that strongly depends on how the patch goes about determining that a message is actually an invitation to a GTalk chat. This could also work equally well as a completely separate plugin.

comment:20 Changed 8 years ago by darkrain42

  • Milestone Patches welcome deleted
  • Status changed from new to pending

I've just been informed by malu that this should be working properly and I was able to test it using the gmail web interface.

You still need to be invited by a gmail/google talk user, but could people test this, please?

comment:21 Changed 8 years ago by trac-robot

  • Status changed from pending to closed

This ticket was closed automatically by the system. It was previously set to a Pending status and hasn't been updated within 14 days.

comment:22 follow-up: Changed 8 years ago by kentyman

How can we test this?

comment:23 Changed 8 years ago by skliarie

I just tested the functionality in pidgin 1:2.5.5-1ubuntu8.4 (ubuntu jaunty) and it worked - I had successful conference between a pidgin and two GTalk (in GMail) users.

The pidgin's chat interface can benefit from some polishing though.

And what about pidgin to be able to create a chat room by itself and invite others? Please open the bug until invitations are implemented.

comment:24 in reply to: ↑ 22 Changed 8 years ago by darkrain42

Replying to kentyman:

How can we test this?

As skliarie correctly points out, the gmail user needs to be the one to initiate the conference.

If someone wants to file a ticket to allow Pidgin users to initiate the chat, that's fine, but it's not going to happen unless someone finds documentation on how a third-party client is supposed to do that; I can neither find any documentation on that nor how to start a chatroom on groupchat.google.com.

edit: fixed a typo on 'groupchat' --darkrain42

comment:26 Changed 8 years ago by eion@…

(In febb4e314c57a724a7f639f226ee40790dabc56c):
jabber: Add an "Initiate Chat" blist context menu option for GTalk accounts.

Patch from Eion Robb with minor cleanup. Closes #10413. Refs #3360.

comment:27 Changed 8 years ago by darkrain42

Ticket #10513 has been marked as a duplicate of this ticket.

comment:28 Changed 7 years ago by skliarie

Can pidgin do following on "Join chat" function (on GTalk/XMPP contacts): 1) automatically generate random room number for the "Room" field using private-chat-00000000-0000-0000-0000-000000000000 template 2) Use groupchat.google.com server for the "Server:" field.

This pretty cosmetic fix would enable many pidgin users to create GTalk group chats easily.

comment:29 Changed 7 years ago by deryni

As best I can see doing this would require preventing Google Talk accounts from joining normal (that is non-Google Talk) muc rooms/services. At best (assuming Google Talk were to respond to our disco request with their muc service) we could fill in the default server name and then ignore any room name the user put in but that is decidedly ugly from a user interaction perspective.

I'm open to other/better ideas but I can't see any good solutions at the moment.

comment:30 Changed 7 years ago by skliarie

The current situation is simply unacceptable. The delicate balance of freedom/easy-to-use is too over-bent already that it takes me and probably others great self-control not to jump ship to the very proprietary but oh-so-easy-to-use system that should not be mentioned here (May its name be blotted out).

I propose to add another field to the "Join chat" window: "Muc room system" that will have drop-down menu with several public muc-room services (With groupchat.google.com and "Manual" among them). Selection of pre-programmed muc-room service would automatically populate the necessary fields (optionally greying-out them).

Pidgin should remember the last-used muc-room service (or manually entered settings) and always use these when user enters the "Join chat" window.

comment:31 Changed 7 years ago by deryni

We are not going to start keeping lists of public muc rooms in pidgin, maintenance on such a list is going to be a nightmare. If a list were retrievable from somewhere online it would at least be possible to consider using that list (though I'm still not sure I like this idea).

Google Talk should be returning the service it provides in its disco response which would allow us to populate the server field correctly (a minor long-standing bug about switching fields notwithstanding) but it isn't doing so.

I believe there is a ticket asking that pidgin remember previously used settings, I'm neutral on that idea in general.

Last I knew the official Google Talk client didn't support group chats at all, only the gadget (and possibly the gmail interface did) and they supported this as a conversion from an existing conversation and/or from the buddy list. pidgin doesn't support conversion of a one-on-one conversation into a chat but does support the buddy list room creation method so I'm not really sure how pidgin is handling this all that much worse than the official clients do.

Again, assuming Google Talk starts correctly advertising their service name I could see adding an "Automatic room" option to the Join a Chat dialog which would do the Right Thing for any server we know supports that sort of feature.

comment:32 Changed 7 years ago by skliarie

I don't think it will be hard to maintain the list of "public muc rooms". They don't change often. Just put couple most reliable ones (with groupchat.google.com among them) and *many* users will be thankful for easy access to group chat.

If there be any problems with the list maintenance, you can always remove the functionality.

Let me to repeat myself - the current situation is unacceptable and you can not blame Google Talk for not providing proper "disco" response and do nothing.

BTW, the ticket remains closed, despite the fact that the chat rooms are unusable out of the box...

comment:33 Changed 7 years ago by deryni

The main couple certainly don't change all that often, but the smaller ones almost certainly do (and it is those smaller ones that people will clamor for and which will be a maintenance nightmare).

I think you exaggerate the amount of people this will matter for, largely because I think most people are likely to either use the muc service of their server (which should be reported via disco info results and therefore pre-populated in the dialog) or one of the "well known" servers (the same ones you would want us to have in the list).

It might make sense to support autocompletion of previously entered servers (and a patch for that is something I'd likely accept).

Removing things is approximately a million times harder than adding them (in terms of support costs and user reaction), so no we can't just remove the list if maintenance becomes a pain.

I will ask again, how exactly is the current situation unacceptable when the problem is that Google Talk does things differently and in ways that work poorly (especially since they could have chosen to advertise the muc service and simply remap requested room names to their scheme in normal join/create attempts) combined with the fact that (as far as I'm aware and you haven't disputed this yet) the official Google Talk clients present exactly the same interface we do for this feature (they also provide an interface in the conversation window which we don't, but that's not what you are asking for)? Could you explain?

This ticket is about support for Google Talk group chats, that support exists, thus the ticket was rightly closed. Discussions for further enhancement to the feature can happen here or in a new ticket but do not require this ticket to be re-opened until and unless it is clear there is actual need for work to be done (an enhancement ticket would stay open until and unless we decided it wasn't something we would accept).

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!