[Standards-JIG] Re: Converting a chat session into a conference

Ian Paterson ian.paterson at clientside.co.uk
Fri Jul 30 20:55:21 UTC 2004

Peter SA wrote:
> Why does the user need to be involved? Can't the necessary protocols be
> hidden by a smart client, so that the user only has to push the "convert
> chat to conference" button or whatever?

Yes, that is the purpose of this proposal.

> How about <continue xmlns='http://jabber.org/protocol/chat2conf'/> or
> whatever? Do we need to modify MUC for this functionality? Though I
> suppose that doing this in MUC is not that evil.

Yes, IMHO this really needs to be in JEP-0045. <continue/> will only be used
in conjunction with <invite/>. It's a simple change, and it really doesn't
belong anywhere else.

> Perhaps the invite needs to be from user at host/resource
> (what happens if I have chats going with multiple resources)?

Yes. Good point.

> Also as mentioned later in the thread, it might be nice to send the
> prior (2-person) history to the third person. How to do so, and how much
> history to send, may be problematic. Would it be better to "publish" the
> history to the room rather than sending it directly from the initiator
> to the invitee?

Yes, it is definitely better to publish the history to the room. Then it
will be available to everyone who joins the room in the future (even if they
weren't invited). Legacy clients will also be able to access the history.

> I'll add these issues to my JEP-0045 review list...

Thank you Peter.

Joe wrote:
> I'm not quite sure how the room is going to generate
> room nicks from the JIDs, if the person you are talking
> with hasn't joined the room yet, but I'm sure the room
> could just guess the user portion of the JID.

Yes. There will be two JIDs in the history, but only one nick will be known
(the room owner's). Since most clients will automate the 'continue' process,
I am assuming both client and server would 'guess' the same nick -
especially if we propose the method in JEP-0045 (i.e. username - or
username2 if both users have the same username).

If the invited user were to enter with a different nick, there would be no
negative consequences (it would appear to clients receiving the history that
they had simply changed their nick).

> If you're going to use x:data, use x:data:...
> You could also add timestamps in as another value.

I would have liked to include both of these, but like I said, in this
exceptional case the protocol should be as compact as possible to avoid
triggering karma. In our example, the x:data items require 100% more bytes.
(Items without a 'from' attribute could also be assumed to come from the

Another strategy might be for room owners to send each chat history message
separately to the room server (interspersing delays if necessary). What do
you think about this example - where 'crone1 at shakespeare.lit' is the owner?

<message from='darkcave at macbeth.shakespeare.lit/crone1'
    to='darkcave at macbeth.shakespeare.lit'
  <body>Thrice the brinded cat hath mew'd.</body>
  <history from='hecate at shakespeare.lit/desktop'

<message from='darkcave at macbeth.shakespeare.lit/crone1'
    to='darkcave at macbeth.shakespeare.lit'
  <body>Thrice and once the hedge-pig whined.</body>
  <history from='crone1 at shakespeare.lit/pda'

Should the 'from' attribute of the <message/> elements be the owner's Full
JID or Room JID (as above)?

Finally, IMHO the room somehow needs to distinguish messages in the chat
history from normal groupchat history messages. After all, the MUC server
cannot be sure that the messages were ever exchanged between the room owner
and the other user! This could be achieved with a new <context/> element for
owner-supplied history messages. For example:

<message from='darkcave at macbeth.shakespeare.lit/hecate'
    to='hag66 at shakespeare.lit/laptop'
  <body>Thrice the brinded cat hath mew'd.</body>
  <x xmlns='jabber:x:delay'
     from='hecate at shakespeare.lit/desktop'
  <context from='crone1 at shakespeare.lit/pda'/>

More information about the Standards mailing list