Have a look at http://icecap.irssi2.org/ and you'll find a meta-IRC protocol as suggested by Timo Sirainen, author of Irssi, the popular unix IRC client. The Irssi2 protocol has been renamed into Icecap. Irssi2 is still intended as the frontend client for Icecap.

Contents 1 IRC+ vs Icecap (aka Irssi2) 2 http://icecap.irssi2.org/IcecapProtocol 3 http://irccrew.org/~cras/irssi2-intro.txt 3.1 Features in Irssi2 compared to PSYC 3.2 Future: Irssi2 interserver 4 Protocol Details 4.1 Syntax 4.2 Commands 4.3 Command replies 4.4 Events 4.5 Networks and presences 4.6 Channels 4.7 Groups 4.8 IRC events 4.9 File transfer 4.10 Requesting old events 4.11 Dialogs 5 Conclusion

1 IRC+ vs Icecap (aka Irssi2)

He once wrote up an abstract idea for a protocol years ago called IRC+, so we happily wrote back that his ideas where to a large extent already implemented in PSYC. Now his new Irssi2 protocol actually is not a follow-up to IRC+. By looking at the TODO we understand that Irssi2 is not planning to even become a decentralized chat technology beyond IRC anywhere in the near future (see "Irssi2 interserver" for the distant future plans however). It's merely a meta-chat-protocol, similar to Jabber without S2S (interserver communication, or call it federation) but with a seriously good IRC transport instead. So when it comes to massive ircing it is a doubtlessly better choice than using Jabber.

2 http://icecap.irssi2.org/IcecapProtocol

If you look at the message codes it soon becomes clear that the protocol is primarily focused on remote controlling what IRCers call a bouncer. A bouncer de luxe protocol in a way.

PSYC has gateways into IRC networks and elsewhere, too, but it is indeed currently not providing a ways to "log in" into each of those legacy chat systems. This might work for IRC networks (but aren't there plenty of "bouncer" applications which do this job quite well?) but when it comes to proprietary messaging networks the Jabber experience has shown that multiprotocol clients are the safer design choice. Not technologically but politically. If politics were on our side, our attempt to do gateways (http://psyc.pages.de/gatebot) instead of holding TCP links for every user as Jabber does, would have been the technologically cleanest approach. But we're not in a world where chat companies want to do their users any good.

3 http://irccrew.org/~cras/irssi2-intro.txt

Apparently Irssi2 has naturally evolved out of the irssi client by deciding that a client shouldn't have to do so many complex things as today's IRC clients have to, but rather focus on user interface issues. We totally agree on that, that's why psyced has all the core client functions built-in and lets you implement completely lightweight clients, or even just use a Telnet. So Timo has split irssi into a minimal client and a new server side. A logical step to take and good work as such. Some people on the http://2.irssi.org/moin.cgi/Comments page claim the split to be a non unixish step to take. That's conservative humbug. No-one is taking away the screen+ssh option for IRCing, but you are getting plenty of new options beyond that. By the way, you console friends would probably really like elridion's curses-based psycion client for PSYC.  ;) We love it. Some of us however stick to irssi with PSYC.

3.1 Features in Irssi2 compared to PSYC

• Irssi2 allows for several clients to connect, just like Jabber and PSYC too. PSYC allows clients to register _service's and thus fulfil a certain type of function.
• Highlighting and ignoring on the server side is unusual, but in fact PSYC provides that, too.
• Scripting! Irssi2 is the only other protocol that plans a server side scripting approach. You know in PSYC it is absolutely fundamental to even Create Places.
• Full text search indexes. We'd love to have that, too. Bring it in!
• Full support for round robin DNS addresses (try every IP). PSYC would only need this to access heavily loaded IRC networks, so it's a gateway thing. Better of course, if we can uplink into the IRCnet doing interserver.
• Provides centralized location for storing client configuration. This is called _request_store in PSYC.
• Character set conversions. Yep, /set charset.
• Server administrator can give users default configuration. Interesting thought!
• "placing a local server in front" of a remote one. This is subset of regular interserver communication which in PSYC (unlike IRC) is naturally transparent.
• "colored flag in statusbar" - PSYC has the remote echo feature to give a feeling for reliability of a communication link without having to swamp the user with detailed network status.
• Global Client Settings: PSYC has a concept of a current place and a current talk target. It is left to the client implementors to make use of it or to do it their own way. This is clearly a similar thing here.
• Irssi2 doesn't like XML and we share that feeling.

3.2 Future: Irssi2 interserver

"Irssi2 servers could start talking directly together, or to special channel servers which host only a couple of channels. After this, the need for IRC networks drops. Or rather there would be many small "networks" which host only a couple of channels."

This in fact is a rather bad idea, as the purpose of large IRC networks is not just to have a large choice of people to talk to (which indeed is conceptionally superceded) but to have a proper multicast routing infrastructure. By moving to Irssi2 and small IRC networks such multicasting gets lost, whereas PSYC even improves on IRC's multicasting abilities dramatically while at the same time making "large networks" in IRC-think unnecessary. So trying to replace IRC by Irssi2 without taking care of routing is an even worse idea than switching to Jabber.

Okay, you didn't say you were not going to take care of multicasting, but hey - then you are definitely re-inventing the PSYC wheel which took long enough to develop, so you don't want to go through that again. Believe me!

4 Protocol Details

What's different to PSYC:

4.1 Syntax

• Irssi2 escapes colons and newlines. PSYC only escapes newlines in variables. Message bodies need not to be escaped.

• This also applies for PSYC. We never cared to mention it, though. We'd like to cite this sentence for our own specs, is that okay? :) Here it is:

"The protocol by design is asynchronous. That means that a command may be sent to server and before it's finished server may have sent replies to previous commands or sent events unilaterally."

4.2 Commands

• Irssi2 uses a line-oriented parameter passing scheme like IRC, but like PSYC and XMPP this time the parameters are named. Good.

• Tagging: A very important thing from a client coder's perspective. We respect that, that's why PSYC echoes _tag_reply in any message that was triggered by a message containing a _tag. The difference is: it's optional, you can leave it out if your application absolutely doesn't need tags (and we have gotten along fine without tags for years). We also have packet ids and _reply, which additionally serve the purpose of tagging, but on a routing level.

4.3 Command replies

• Command reply glyphs: A new way to distinguish successful replies from errors, using '+' and '-'. The traditional way would have been to use numeric codes. Our approach is to use hierarchic method names starting in _error or _failure. See Method Naming for the whole big intellectual ballaballa how we got there. Interesting is this "more to come" glyph '>'. We might want to add something similar to this, once we meet a necessity for it. It's cool. How do we call this.. _interim? Or just _wait? _more?

4.4 Events

• Events are _notice's in PSYC.

4.5 Networks and presences

• PSYC uses uniforms (URLs) to address people on other chat systems or IRC networks. This seems like a more open-minded way to do this than to hardcode the IRC network concept into a new protocol. Especially since talking to legacy networks is one of the lesser important operations on PSYC.
• PSYC has a much more complex notion of presence and even knows how to multicast it.

4.6 Channels

Interesting concept to keep data structures for channels no matter if joined. PSYC has some similar concepts, like channels you never really leave, and we are indeed planning to generalize the sort of profiling information kept for people to all kinds of entities so you can alias place adresses and give it settings, no matter if you are currently using it. This shows us we are moving in a right direction, at least for a certain type of applications, even if those haven't been a major field for PSYC as yet.

4.7 Groups

PSYC lacks a grouping solution for entities, too. Right now we only have it for Jabber clients and will gain some experience and ideas before coming up with our own plan. It will most likely be in conjunction with PSYC channels which are a very different concept from IRC channels.

4.8 IRC events

We try to translate legacy protocol methods into appropriate PSYC methods. We can do this because of the flexible hierarchical PSYC method scheme, so we don't need to deliver "raw events" in most cases.

4.9 File transfer

Irssi2 suggests file transfer to go through the Irssi2 server, but this is a point where a client should take action directly. PSYC suggests to do peer-to-peer File Transfers unless inhibited by NAT etc, and it even relays IRCs DCC requests to the client so that it can handle those the traditional way. Obviously a PSYC server could implement the file transfer features of PSYC, too.

One thing that is noteworthy about the file transfer example is that it needs two lines (messages/packets) for sending the data. Effectively, those two can never occur in a self-contained way, so they should be one packet, which again is hindered by the protocol syntax. Problem here?

4.10 Requesting old events

• By looking at this elaborate syntax you could safely say that Irssi2's storage retrieval features are widely more elaborate than our current /log and /hist commands. We'll take inspiration!  :-)
• There is however architecturally a nice side about PSYC's approach. We can decide if we look up the message history on our own Identification home server (which is technologically similar to the Irssi2 server function) or on the remote entities' server (a remote place's history usually).

4.11 Dialogs

PSYC has the more generic family of _request methods, because not all questions need to be answered interactively. _requests are fundamentally asynchronous, so it doesn't matter if the answer to a question is found interactively or automatically. We also have a '?' query glyph on protocol level, but it hasn't proven to be necessary for any job, yet. The advantage in the Irssi2 approach however lies in its obviousness for the client coder how to implement it.

5 Conclusion

Icecap is no longer an attempt to do a new better IRC protocol. It is totally focused on client developer issues and unsuitable to create a decentralized chat system, or federated as some people say these days. So for us it is nice seeing where other people are heading and taking some inspiration back home for PSYC. fippo already suggested, it wouldn't be too hard to actually provide Icecap support in psyced, since the home server functions in PSYC are similar, even if less specific and occasionally rudimentary in comparison. Let's see if there is a real need for something like this.

For now what PSYC does is actually exactly the other way around: We use IRC not as an interserver protocol but as a client interface protocol so that clients can stick to the familiar IRC, but at the same time we enhance the backend behind the IRC server interface dramatically, so that the clients no longer have to be so complex to achieve operations beyond talking to a single server. I guess we took a server-oriented approach to these problems instead.

But this is all software design talk - still PSYC does not provide elaborate IRC network gatewaying and many of the extensions Icecap would like to see, so there would be work to do should we want PSYC also to be a "bouncer de luxe" application.  :-)