FAQ

Why, oh why?

First, from the point of view of users, remote Jabber transports have shortcomings:

• they’re single points of failure
• they cover a limited number of foreign protocols
• they’re sometimes buggy, memory-hungry, and lagging in development

The latter two could be fixed, the first one is intrinsic in the design. libpurple doesn’t share them.

Second, from the point of view of a developer who wants to implement an IM client, there are two options: either go with XMPP and enjoy its power but lament the lack of users, or use a multi-protocol library and settle for a lowest-common-denominator approach. Hopefully, with purplebridge or a similar solution, the developer will be able to concentrate 100% on XMPP while still reaching users on other networks.

But isn’t Jabber philosophy that of “move complexity to the server”?

purplebridge is a server. It runs locally, but as anyone who’s launched netstat -tunl at least once knows, client/server is about architecture, not geography.

If you still chose to interpret the above as “complexity should be moved away from the user’s machine”, feel free to prove it correct with a working implementation… I’ll surely be among the first to thank you. :-)