[jdev] GSoC - IRC-to-MUC bridge

Carlo v. Loesch CvL at mail.symlynX.com
Thu Mar 20 01:36:30 CDT 2008

LRN typeth:
| PSYC is out of scope of "IRC-to-MUC component" project. The idea behind 
| the project, as i understand it, is that xmpp protocol is superior to 
| IRC, and that it would be good to have a bridge back to IRC from xmpp 

Well, that is an incorrect statement. IRC is stupid at some things,
XMPP is stupid at some other things. When it comes to scalability
for large groupchats, IRC is clearly superior thanks to its simple
but effective multicast distribution tree. Having MUC gateways on
each IRC server makes an IRCnet a backbone for a distributed MUC.

I have seen IRC channels working fine with 3000 people in it (#wtc
on 2001-09-11 for example). I have seen 10000 people on a PSYC
multicast channel (Webchat event with German rock band "Die Ärzte").
I never saw a MUC anywhere close in size. The reason we publically
announced the MTV EMA chats accessible by MUC protocol was because
we already had the PSYC multicast backbone in place for distributed
MUC. So MUC is an access interface just like an HTTP or Flash webchat.

It is pointless wanting to declare any of XMPP, IRC or PSYC legacy
or superceded or something. As long as they do certain things better
than their counterparts, they will all stay. IRC and Jabber will even
stay, should they be technically superceded. Since these are all
open source technologies, there is totally no reason not to use all of
them and make them interoperate. psyced is good at building bridges
between them, as it understands the requirements of all sides fully.
psyced has ten years of experience in practice - rewriting this
knowledge into a new piece of code, all the tricky details of each
protocol and such, is a daring task to undertake.

| server (from MUC room exactly) for backward compatibility. And it is 
| proposed to do so by making a component for xmpp server. "Component" 
| means that this project is generally simpler/smaller than the whole 

Yes "component" means it cannot offer all the advantages of federation
to the IRC users. It is a more limited and one-way approach, but why
restrict yourself artificially? The project description is just a
suggestion what could be useful - it didn't take into account, that
something even more useful and powerful has already been implemented.


More information about the JDev mailing list