This document should probably merge into a generic document about PSYC services.

Transports are for those users that already own accounts on several centralistic messaging systems - they fire up a TCP connection for each user for each service, log you in and relay your messages to you. This is rather ugly, but for some strange reason currently politically viable.

True peerings against centralistic networks are only available for money, however there is also the gatebot approach to this, where the legacy system users see a generic robot user which however can gateway anybody in the PSYC/Jabber federation into those systems and back without forcing them to register a fake account. That approach is currently dysfunctional and disputed upon.

IRC and XMPP transports are a special case as they may prefer to be implemented in form of an interserver gateway or at least a gatebot. The transport option is usually the worst, from a technological standpoint. All three options for gatewaying are discussed in detail on the gateway page, not here.

Current problem with *.py transports

psyced sends presence from the UNI not the UNR (the jid with an appended resource name). This is legal, but unusual. pyICQ does not handle bare jids properly, so it currently doesn't work with psyced. To use transports again, we need to find other transport implementations, or fix the existing ones.

It worked before, because for a period of time the XMPP implementation in psyced used to generate resource names.

Using Jabber Transports from PSYC

You can register at any transport in Jabberland. The following description applies to psyced which provides such /disco and /registerservice commands.

Discovering a gateway and registering

First, make sure that the gateway is for the protocol you want:

myhost <> /disco xmpp:icq.example.org

In the reply, look for "gateway":

myhost <> xmpp:icq.example.org is a gateway/icq called ICQ Transport offering features jabber:iq:register, jabber:iq:gateway, ...

Now, query registration info:

myhost <> /registerservice xmpp:icq.example.org

myhost <> xmpp:icq.example.org provides the following registration instructions: 
Bitte geben Sie Ihre ICQ Nummer in das Benutzernamen-Feld und Ihr Passwort ein.

and now (you could have skipped the last step)

myhost <> /registerservice myusername mypassword

If everything went well, you will be told so and the transport will ask for your friendship. After you acknowledged this, you will get tons of friendship requests from your legacy IM system buddies. Friend them as well and then alias them.

Deleting your registration with the transport

It is sufficient to unfriend the transport. This will delete your account there.

Unfortunately, the transports won't clean up after themselves, so they leave you with many unreachable friends in your contact list.

Installing your own transports

We had installed ICQ, AIM and MSN transports in a way that they are accessible via localhost as xmpp:icq, xmpp:aim and xmpp:msn. This makes things a little less ugly. Also, xmpp:aim isn't really necessary as you can address all AIM users as icq:aimscreenname, no I mean xmpp:aimscreenname@icq.

TODO: The real scheme

It is intended to teach psyced to map any xmpp:user%host@msn.gateway.example.org into msn:user@host and equivalent for ICQ etc, so that the address almost has qualities of a UNI, using a real custom scheme per IM system.

Once that is available you can change to another transport anytime, but all your friendship data and aliases stay valid, as they are independent of how the gatewaying is actually implemented - by transports, peering or built-in. No more dreadful Jabber transport migration. Unfortunately this function isn't implemented yet. Why don't you start?

Vapor: Use PSYC with transports

The current solution requires you to befriend both the robot, than the people behind it. Then you have to acknowledge them all, and when you want to change the service robot you are left with a lot of trash in your contact list and have to restart from zero.

It may be a better idea to use PSYC with transports than XMPP.

• The registration procedure could pass a trust token to the service, so that it can insert your friends into your buddy list without disturbing you. Also it doesn't have to become a friend of yours itself.
• It could use proper transport-independent uniforms for your friends, so you don't end up having new friends just because you switch to a different transport service.
• Your presence information will only be delivered once to the transport service, no matter how many friends you have there.
• Should we have channels someday, you could have legacy people on a different level of presence transparency than your other friends.