The Second Life Game has published its protocol...
https://wiki.secondlife.com/wiki/Protocol
Interesting to see that it comes to several similar solutions as PSYC. Yes it looks much more like PSYC than XMPP or IRC.
opensim also is interesting software, written in C# with a similar architecture to PSYC applications.
Interserver messaging problem
Apparently however, Second Life is having some issues implementing interdomain or inter-grid messaging, and thus looking at technologies to compensate. The wiki and developer lists host discussions on how to handle these things in conjunction with the Open Grid Protocol. Yesterday, Thraxis pointed out the existence of PSYC.
Many of the Use Cases are familiar: chatroom, messaging, gateways, spatial chat ... and what about encryption? The proposed solutions are also quite familiar:
According to Ambrosia SL has groups of up to 3000 members, predicted to grow. This pretty much rules out using XMPP for the task. As the Jabber and scalability documents explain, the XMPP protocol provides no multicast mechanism. It would thus send a copy of a message to each of 3000 people. That will not work. Since XMPP has a lot of other strengths, you may not want to give up just that early. Well, you can try to mount your own custom multicast solution on top of XMPP. There have been several suggestions on how to have a distribution overlay network on top of MUCs. You will have a lots of blues with that stuff, but you may get lucky. Once you have done that, you will still have a problem with the scalability of interserver presence in XMPP. The best solution to tackle that is to avoid interserver XMPP and simply run one huge central server. Not sure how good that works.
The other option is IRC. IRC can handle 3000 people in a channel easily. In fact it should be able to scale up to close to a million, these days. The downside is that broadcast overhead in IRC is huge, so running an IRC network of that size requires plenty of bandwidth. But at least it works. Another downside is the ancient protocol, not exactly friendly for the purpose of adding meta-data. And you will have to deal with the 512 byte limit per message etc. Also, you will need to run centralized bots and service packages (NickServ, ChanServ etc) for authentication and conference control. IRC does not provide presence, so you may want to implement your own in form of CTCP PRESENCE and presence channels or something like that. The old IRC way of doing this, polling for the existence of certain nicknames in the global database, isn't something you really want to do. Also it isn't nice to privacy. Services have been trying to fill these gaps, but they ruin the healthy multicast architecture when doing so: If one centralized service handles all presence notification, you're back at square one.
And then, Thraxis Epsilon mentions that stuff called PSYC, as it has some good points in comparison to the other two. Yes, it does multicast chatrooms, and it does so without IRC's broadcast overhead. It also does multicast presence, which presently is close to impossible to do with XMPP. The problem is, even though it has been around, it keeps changing frequently and isn't specified all that much. Also it talks about a lot of stuff which isn't always actually implemented. Still, the way psyced stands today, may already be a better choice for your needs. Interestingly, it comes from a similar background. Oh, and psyced supports legacy interfaces for IRC and XMPP users, so you're not losing out on anything.