How to use Jabber™ with PSYC

Three ways in

First of all we must distinguish the three access ports for Jabber™. Although the protocol should permit it, the Jabber™ architecture cannot handle clients and servers on the same access port. That's why psyced requires to listen on 5222 for client access and 5269 for interserver traffic (what a port number ;)). Additionally 5223 is allocated for TLS/SSL clients, but STARTTLS support is available on port 5222 aswell.

Can I install psyced together with Jabber™?

The dialback and addressing schemes of XMPP (the proposed standard protocol of Jabber™) do not permit to provide the service on other ports without using SRV-DNS records. So you first have to get familiar with SRV. Other than that it should work.

How do I address Jabber™ entities from PSYC?

There is no standard URL syntax for Jabber™, however there is a proposed URL syntax for XMPP. We implemented that. You can address those by prepending "xmpp:" as in "xmpp:alice.cooper@jabber.com". Unfortunately even in that proposal there is no way to distinguish a person from a room or a service, so you will have to figure that out for yourself. There is no way to enter a jabber groupchat from PSYC anyway, we'll explain why that is not possible later.

How do I address PSYC entities from the Jabber™ network?

Again since there is no way to distinguish people from rooms and services we had to make them up. First we did it the typical Jabber™ way which is to allocate a "conference.domain" hostname for chat groups, but we soon realized that this inhibits any ad hoc usage of the protocol even further as every conference server needs to be defined in the DNS domain before being even able to play around with it. We figured out a way to do it which is neither encouraged nor discouraged by the specifications:

We defined that rooms are always prefixed with the '*' character. Since jabber users love to make their groupchats look like IRC anyway, we thought the IRC channel character would be a most popular choice.

Pragmatically speaking, if you want to address a person from Jabber™, use <user>@<host> from the PSYC network uniform. Subobjects are not adressable. Places have the address #<place>@<host>. So if you want to meet us in our developer room, #psyc@ve.symlynX.com is what you need to tell your Jabber™ client. Any other objects and services are currently not addressable from Jabber™.

Using Jabber™ groupchat from PSYC

This only works if you are using a Jabber client to access PSYC, because psyced will then transparently forward your messages into the XMPP network, allowing for MUC usage and File Transfer. As a general approach this is not possible however for a series of technical reasons. One of them being the inability to distinguish room addresses from user addresses, followed up by the inability to distinguish room presence from user presence. The whitespace in nicknames, the fact that people in Jabber™ rooms have no identity - essentially the groupchat creates all nicknames and messages and even forces private messages to travel through the room. The room could fake any message and any identity, and it could mass invite all users without being recognizable as a spammer by the protocol. Also it sends a copy of each message to each recipient and cannot handle any form of routing. PSYC works very differently from that, since PSYC was originally planned as both a conferencing and messaging technology, it doesn't solve one or the other problem half-heartedly. So it just doesn't make any sense to support groupchat as provided by Jabber's conference servers. But you can use PSYC's conferencing abilities from Jabber™ instead:

Using PSYC for Jabber™ groupchat

It is certainly a good idea to host your Jabber™ groupchat rooms on a PSYC server rather than on a Jabber™ conference server. PSYC will provide for better security, scalability through proper multicasting, fully programmable conference control and the stable implementation of the IRC access protocol will make it useful to more people than just Jabber™ users.

I should however care to add, that the Jabber™ MUC protocol is a hack on top of one to one messaging. This implies that people in a MUC cannot be shown by their real address, as this would trigger spoofing protection. They are shown pseudo-anonymously as a nickname of the room. Consequently you cannot immediately exchanges messages with them directly. Instead you are given the "/msg" command which sends your private message to the room as only the room can resolve the recipient's nickname and forward the message to the final destination.

We have chosen not to support this practice, as it breaches your privacy. A person may decide to run a MUC server and invite all his friends in, and while they may keep some conversation secret behind his back, like the gift they are planning to buy for his birthday, he could modify his server to show him all "/msg" conversation not intended for him. When using PSYC from Jabber™ you are encouraged to always use direct messaging to the person and not send your private conversation through the room server, to avoid any potential abuse.

Another feature we are not planning to support is having multiple people chat with nicknames that differ only in upper/lower case. While it is consistent to treat resource parts of an URL (or, if you like XMPP IRIs) case-sensitive, this case is generating to much confusion. Or would you like follow a discussion between foo@bar/AbC and foo@bar/ABC?

Using psyced with Jabber™ clients

Yes, you can register and log into a psyced using its Jabber™ server emulation. This is still a bit experimental, but it brings some advantages.

One is, you have the complete PSYC command set available if you prefix PSYC commands with a '+' or whatever character you have defined as a command character, although you need to use a trick to transmit commands to your PSYC identity. When the manual speaks of commands like /sub you will have to enter a room and send the commands to the room, at least apparently (with a '+' instead of the regular '/'). This is again a trick to circumvent Jabber's inability to provide real ad-hoc commands. Jabber™ does provide a JEP for so-called ad-hoc commands, but what is ad-hoc about having to send a list of all possible commands in advance, and without possibility to add any arguments?

Two is, we managed to not confront you with a special new syntax to address people on the two chat network systems. All you do is insert the typical Jabber notation of user@host into your client, and the server will be smart enough to figure out if the person is still on Jabber or already on PSYC.

About the Jabber™ implementation in psyced

Most issues were able to be solved by the psyced backend, as they had already been dealt with for PSYC. Here and there some adaptions were necessary, but the greatest extra work was to parse a syntax which is overly complex for the tasks at hand, XML. In fact Jabber™ uses a particularely verbose form of XML with namespaces, although namespaces weren't really intended to be used in streams. So Jabber™ tweaks the XML syntax occasionally. Some things are still not well defined, for instance XML allows for a message that looks like this:

<body>XML has tags that look like &lt;this></body>

This is supposed to be displayed as "XML has tags that look like <this>". You would assume that ">" needs to be written as "&gt;", but it doesn't. The XMPP is unclear on whether such a message is permissible or not, but one thing is certain - implementing an XML parser which handles such syntax correctly is a lot less than fun.

The other major extra work was supporting the funky dialback principle in jabber. Dialback may look like a security strategy at first, but is really just a trick to circumvent a shortcoming of the Jabber™ server architecture. Jabber™ servers cannot handle incoming and outgoing data on the same TCP connection, so they need two connections for every interserver link. In fact since Jabber has no scheme for recognizing virtual hosts residing on the same server, they tend to open extra connections for every hosted domain on that server. In contrast, PSYC first does non-blocking resolution of the hostname, then figures out which existing link to use. Admittedly, that's a bit harder to implement.

Considering that these shortcomings had to be dealt with, the psyced emulation of a Jabber™ server was successfully accomplished in less than 2000 lines of code, dialback and XML support included.