Greg Hudson’s MIT blog

XMPP: Chatroom aggregator idea

Posted in XMPP by ghudson on the June 20th, 2007

The problem: in the Zephyr culture, people join a lot of different chatrooms (or “triplets”), and the clients make this reasonable.  I’m in almost 300 at the moment.  In every other IM culture including XMPP, that’s highly unusual and the clients don’t support it reasonably.  You’d have to have 300 open windows or 300 tabs to be a member of all of those rooms, and keeping up with the incoming traffic would be impossible.

Until recently, my best idea for resolving this issue was to get the clients to change or to make Zephyr clients work for XMPP.  Changing existing clients is slow and failure-prone and it’s not clear how far it can go–the best I can think of is to make it possible to be in a zero-traffic chatroom without a visible tab, and have the tab pop up when traffic comes in (or if you ask the client to join the chatroom when you’re already in it, in case you want to proactively send a message there).  Better than what they do now, but still not great.

Making Zephyr clients work for XMPP is happening, but at best it’s a fractured solution–people using the more traditional GUI clients like Pidgin aren’t going to be able to join in the many-room culture even if people using barnowl can.

At Monday’s meeting, Matt suggested maybe the problem could be solved in the server, somehow.  This led me to think about a server-side chatroom aggregator.  To the client, it would look like a single chatroom, but it would maintain subscriptions to other chatrooms and would display messages from all of them.  It wouldn’t be as flexible as good client-side support for many low-traffic chats, but it would be accessible to any client.

Design questions I came up with yesterday and today (“MUC” means “Multi-User Chat” and is the technical term for a chatroom in XMPP):

  • To the real MUC, does the user appear to have joined from the user’s real JID ( or from the aggregator’s JID?  The former is more transparent, but probably requires the implementation to be an Openfire server plugin rather than a proper network component.  And it’s more hackish from a protocol perspective.
  • Can a single user have multiple aggregators (e.g. one to aggregate work chats and one to aggregate personal chats) or only one?
  • What do the JIDs of these aggregators look like?  Do different users’ aggregators have to have distinct JIDs?  Do different resources for the same user ( and share the same aggregators, or do they each have a separate namespace?
  • Do aggregators have persistent configuration data, such as a list of real MUCs to auto-join, or is it all soft state which disappears when no user clients are joined to the aggregator?
  • Can the aggregator be configured to remain subscribed to the real MUCs while the user is not joined to the aggregator?
  • When the aggregator joins a real MUC, it will receive recent history from that MUC.  Does that need to be handled in any special way, or should it simply be sent through to the user?
  • How does the aggregator convey room presence information to the user?  Does it try to aggregate the room list of all the rooms and present that in a unified room list, or does it convey an empty room list and make the room lists of the real MUCs available through query commands?
  • Will the aggregator have any kind of logging functionality which users could query through commands?
  • What is the display format of messages from the real MUCs?  Will it be configurable?  How pretty can it be made to look in existing XMPP clients?  Will real MUCs have associated nicknames to avoid having to present a long source identifier like with each message?
  • What is the input format of commands to add or remove real MUCs or send messages to real MUCs?

I can’t run off and implement such a thing because I’m busy with other stuff.  But I thought I would throw the idea and design questions out there while I had them in my head.

Leave a Reply

You must be logged in to post a comment.