The PSYC protocol can serve as an interserver replacement plug-in for XMPP, since XMPP has some serious scalability issues concerning S2S, especially in its implementation of presence (see Jabber for details).

Fixing the cumbersome JID concept

First of all, server implementations who wish to support both PSYC and XMPP interserver protocols need to provide a way for user@host addressing as is presented by current XMPP client protocol to be applied to either PSYC or XMPP routing back-end. This is achieved with the protocol switch extension. Both protocols provide ways to show when other protocols are available. DNS may provide hints, to not even try using the wrong one. See also "JIDs are no URLs" in Jabber. This allows for servers to choose the more efficient PSYC, wherever available. psyced implements this.

Supporting all the nice XEPs

psyced tries to convert as many XMPP formats into native PSYC methods as possible, but it should at any time stay transparent not to lose information. Currently we are losing formatting on messages, and probably a few more things. For all the things it doesn't know anything about, like the many XEPs that extended XMPP, psyced delivers unmodified XML stanzas in its packet body. In the long term, using Jabber over PSYC shouldn't feel too different from using it over XMPP-S2S. It's just more reliable and efficient.

As a result PSYC and XMPP clients would be able to communicate just as they already do, yet each breed would have its own set of extension features, like PSYC clients having native binary file transfers whereas Jabber clients are good at whiteboarding, playing chess and telephony, to name some random strengths.

Multihoming

I like the plan of allowing users to use their favorite CNAME for their server in the host part, someday. That means: Users owning a DNS domain don't have to run their own server, they can map it onto a public server willing to host them.

PSYC's use of hostnames in certificate when using TLS however currently limits the amount of hostnames to a certain non-dynamic amount. Only unencrypted use of PSYC could support the dynamic CNAME plan (still somebody has to code it first).

XMPP is even more limited on this issue, since SASL external only allows for a single hostname and the old piggybacking strategy used with unencrypted dialback is horrible to write and debug.

PSYC will continue to provide several hostnames over a single TCP or TLS circuit, while XMPP is slowly heading towards having separate connections for each hostname.

Migrating uniforms

What happens when you start receiving presence from psyc://host/~user instead of xmpp:user@host?

Since Jabber clients only see user@host, there exists no problem on the client side. Surely some technical issues need to be addressed in psyced internally as soon as any xmpp:user@host is considered equivalent to any psyc://host/~user uniform. I am positive this can be solved. Native XMPP servers have it even easier, they just keep on identifying people as user@host.

<fippo> these upgrade problems are mainly concerning xmpp: entries in alias and ppl. Maybe this can even be solved by manipulating those data structures using perl during an offline period.

Managing the Jabber resource

We have to solve that issue anyhow. The way XMPP tries to route messages to a particular client, but at the same time not heading straight for the client's actual location, has created a lot of headaches to the Jabber folks themselves.

While PSYC allows for UNLs to be the real IP address and reception ports of the clients, for XMPP we simply keep on using the person's UNI plus resource appended. We just do it depending on the choice of S2S at hand, and we also choose depending on the user access protocol at hand. After all it is useless to feed Jabber clients with real PSYC UNLs currently. This might obviously change one day.

Maybe it even makes sense to conceptually integrate the "UNR" as an inbetween thing between the UNI and the UNL. In the case of PSYC it would provide a way to address a client "explicitely" yet indirectly, without exposing its IP address (which is desireable only with friends and jobs like file transfer).

Currently PSYC does this through the identification, always letting it decide where to route things to. This seems to actually be a better design choice and we might even want to disable resource routing in Jabber over PSYC.