Contents |
XMPP / Jabber
XMPP is a built-in client and interserver protocol of psyced. Also the MUC extension of Jabber is supported for all psyced places. You can enable or disable it at installation time.
If you are using a different PSYC software you may want to make use of psyced's relaying capability so you can still send messages into Jabberland. We do however currently not provide a syntax for relaying messages back from XMPP into PSYC, as that would require kludging with the Jabber JID format.
In combination with the following IRC gatewaying features you can build all sorts of Jabber/IRC gateways depending on your requirements.
IRC
How to gateway to existing IRC networks.
The IRC Gatebot
Solution number one is to have a PSYCgate bot connect the network. See http://www.psyc.eu/ircgate for documentation on that.
Installation
The place/irc.c file shows you how to set something up like that. It comes with the psyced distribution.
Embedded PSYC/Jabber Gateway In IRC Networks
Solution number two is to have psyced connect as an IRC server to the IRC network, and implement a generic gateway for uniforms. That means every IRC user can send a message to something like psyc://psyced.org/~lynX and it will be routed to the gateway. Also xmpp: uniforms are supported.
On the other side the users of the IRC network are given a federation address and thus appear like regular PSYC or Jabber users. Authentication is currently left to local ircnet policies, usually NickServ.
<coyo> this is interesting. we'd still need to code the various irc s2s dialects, since i want to run inspircd, whose spanning tree protocol hasnt been written yet.
Functionality available
- relaying from ircnet to remote psyc and xmpp entities works.
- relaying from remote entities into the ircnet works, too.
- rendering of error messages from PSYC and Jabber.
- message types known to work: PRIVMSG, NOTICE, CTCP, DCC¹.
- relaying between seperated ircnets through PSYC addressing.
- optional: allow communications for registered ircers only (look out for user mode +r)
- logging every ircnet user into psyced and providing a way to send commands to it so that she becomes in control of a full-fledged psyc/jabber identification - this automatically results in all typical features like presence and buddy list to become instantly available. funny, this even opens up usage of transports for every registered ircnet user.
- commands to your psyced identity are passed using /psyc or /QUOTE PSYC
¹) obviously file transfers and other DCC functions only work if your counterpart is also using an IRC client - it doesn't matter whether your counterpart is on a PSYC server or on a remote IRCnet also federated via psyced. you may however have to use the appropriate psyc: uniforms rather than xmpp. Also going through Bitlbee is not going to work, as it has no native support for PSYC.
Usage Instructions
First you probably have to register your IRCnet identity with NickServ, or the psyced gateway won't be talking to you. Then you can send messages from IRCnet using
- /msg <uniform> hello
with uniform being anything that starts with psyc: or xmpp:. The other side will see your nickname at the hostname of the psyced acting as gateway, so you will have a regular federation address.
To submit commands to your psyced identification issue
- /psyc <command>
or /quote psyc <command> if your client doesn't allow custom server commands.
The commands are the same as in every psyced documentation. As some commands are very powerful you can issue a lot of commands which are not useful at all and rather disturb service. Remember that you will have to issue a friend first before you can talk to any google user.
This is a list of commands that are useful in an ircnet context. Try them out or check out the psyced Manual for details.
- friend, unfriend, show, set filter strangers, ignore, trust
- shout (see Friendcast)
- examine, surf, expose, set stylefile, set photofile (see Social Network and Profile for more)
- subscribe, unsubscribe (see Newscasting)
- mood, availability: here, busy, away, vacation etc. (see Presence)
Some of the commands also work with local nicknames instead of uniforms, adding functions to IRC which would otherwise be implemented by Servs. Like friend is a server side buddy list implementation, no matter if the buddies are remote or within the IRCnet. Also the extended profiling features and integrated HTTP server of psyced provide for Social Network facilities for the IRCnet, just try surf <nickname>. Etc etc.
Shortcomings (solved and unsolved)
- SOLVED: google talk won't talk to us because we haven't made friendships first. you can now use the +friend command.
- SOLVED: some clients think they missed out on a nickchange when they see two people with the same user@host credentials (file under "obnoxiousnesses of IRC protocol and the hacks to handle them!")
- SOLVED: 2nd degree brasnet servers are replacing the uniform source of incoming messages with their own server name. it's a brasnet-specific problem (ptlink6 does it correctly) which can be circumvented by activating ADVERTISE_PSYCERS.
- SOLVED: in theory a command like +friend could use the message recipient as argument instead of requiring it extra, but that is a difficult thing to teach the psyced parsers. also i'd rather teach the ircd to forward unknown commands to psyced so that you can actually just type /friend <uniform>. a catch-all in ircd may be too invasive, although it would certainly be cooler. i decided to add /PSYC.
- SOLVED: psyced undefs a lot of commands which make no sense in the ircgate set-up.
... generally however IRC clients have been acting very tolerantly and cooperatively with the advent of uniforms instead of plain nicknames - this much we can tell since we have been providing an IRC server facility within psyced ever since 2001 or so, and have gained plenty of experience with it. only in one occasion we had to ask a developer to change a detail in a client's parsing (always parse for @ from behind ;)).
Deployment gotchas
- It is a good idea to teach NickServ & Co. to ignore uniforms, ircgate will however skip messages from them, should they arrive.
- OperServ or similar apps may be checking how many users are coming from a certain host. Since the gateway subscribes psyc/xmpp users with a fake hostname, this will quickly exceed usual limits - so upgrade/disable those limits if you have some. If you see messages coming from a certain server instead of coming from the appropriate uniform, OperServ may have killed the uniform in the meantime.
- The semantics of JOIN/PART differs in S2S as you are not supposed to echo this back to the caller, whereas in regular ircserver mode you would. Of course there are more cases like that, PART was just the first I encountered and had to fix (we are using mostly regular net/irc/user objects to model each ircnet user, providing for terrific power but also potential bugs).
In the making
- enable federation users to enter ircnet channels. since they are already in the ircnet database there's pretty much just glue missing here.
- the builtin irc server of psyced does not accept server connects yet so the link always has to be created from psyced to the ircnet
Discussion
- logging ircnet users into psyced: there are two options currently: either we expand the relay/user approach, and allow PSYC clients to log in in parallel, or -the el way- we reject the relay/user approach, let the ircgate implement virtual psyc clients for each ircnet user (use _link protocol, see identification), allow one² alternate type of login and maybe later allow for multiple full-fledged psyc clients. for now both solutions have the same result: since only the ircgate has the NickServ authority, we cannot easily auth any other incoming connections, anyway. the current solution is an improved relay-user approach: we use full fledged net/irc/user objects which would normally implement an ircd for a client, and inherit the huge amount of irc-specific intelligence in that code.
- gatewaying channels in whatever way can be done, but the question is: which is the best way? ideally keeping existing ircnet communities, yet making use of PSYCs conference control and multicast capabilities? this would challenge ChanServ, but having psyced handle channel authority³ would be a lot more powerful and, by the way, open up the ircnet for psyc multicasting and even MUC access.
²) out of a temporary software structural limitation, psyced cannot allow the same user to log in with several protocols at the same time. a plan how to address this exists, but it is on the long term TODO list. so far nobody has come up with an effectively relevant scenario, where this would prove useful anyway.
³) for completeness i must note that some ChanServ implementations may provide confctrl functions that noone on PSYC has needed yet, but it's not a serious problem to hack them in.
Installation
The place/ircgate.c file shows you how to set something up like that. It comes with the psyced distribution. Of course you need to apply some changes to the ircd software, so it can deal with uniforms transparently. Ask lynX for the newest patches, as this is just fresh in the making, and then adapt them for your flavor of ircd. Luckily the involved core functions of ircd haven't changed much in the past fifteen years, no matter how often the ircd derivates have changed their name, so the patches may work as is with many brands of ircd.
Deployments
- psyc://brasnet.org is the first IRC network to feature PSYC/XMPP peering for all its users. Just make sure you are registered with NickServ (hopefully you are fluent in portuguese ;)), then you can msg to any psyc or xmpp uniform and all the other things described in this document.
The IRC Transport
Solution number three is the transport style where a connection for each user and network is created, potentially entering the same channels multiply, receiving all the content redundantly, just to appear politically correct to the average IRC user while actually causing a higher strain on the IRC network than any of the solutions mentioned before.
Should you insist on implementing such an approach it would still be nice to have proper irc://server/ircchannel IRC URIs in use for routing within PSYC. See also transport and scheme on that. To achieve normal chatroom behaviour of an IRC channel it would have to emulate a context where you are the only physical member in terms of PSYC routing, yet you are given a _list_members_IRC containing all the IRC uniforms of the other people on the IRC network, so you can also send private messages to them.
Should however several users be talking to an external transport application and joining the same IRC channel, it would require quite an effort to sync the IRC channel's persistent data in order for both to use the same context and state. You MAY prefer to use a unique context name for each user (effectively killing multicast here, but since you are doing this, it is probably not your priority now). A simple plan for unique context names is to use the chosen IRC nickname of each user as a PSYC channel name (as in irc://server/ircchannel#ircnick which goes beyond the IRC URI specification and turns it into a uniform really). This even makes the strategy capable of upgrade, in case you do find out a way to synchronize the contexts and share a common state and do proper multicasting of IRC channels, later. In that case clients would still see the same traffic from the same context, merely in a different channel of it (Sorry for the confusing double meaning of the word channel here).
Centralistic
How to gateway to centralistic proprietary IM legacy systems.
http://www.psyc.eu/gatebot describes the robot gateway approach that we weren't successful in pursuing politically. So we gave in to the Jabber way to do it, using transports.
We even considered plugging in libpurple into psyclpc, but we aren't sure if libpurple would bring instability to a server application supposed to run non-stop for months. Maybe a libpurple-based gateway application could be developed to run alongside psyced, communicate via PSYC and recover gently when some change in some proprietary protocol once again produces protocol engine crashes in libpurple as it has happened in the past. Maybe that gateway could be just another psyced with less or no directly connected users, or it could be based on libpsyc.