The Client To Client Protocol commonly used on IRC is documented at http://www.irchelp.org/irchelp/rfc/ctcpspec.html . The CTCP is specifically for in-band communication between clients (as opposed to in-band communication between users, through clients). That is, CTCP messages are sent through the server; they are not exchanged through direct connections between clients.

I believe your objections apply to a separate service on IRC known as Direct Client Connection, or DCC. DCC sessions are negotiated on IRC using CTCP messages, but are otherwise not related to CTCP. DCC's inclusion in the CTCP spec paper is simply to consolidate the IRC sub-protocols.

-- n - 04 Dec 2003

I do believe I was one of the people who lobbied against a CTCP implementation in lily. My only concern, which no one could reasonably address at the time, was security. The CTCP support in IRC is one of the reasons I heard from firewall administrators when they blocked out IRC connections. It also enables people to directly exchange executable content through lily, and the potential risks and abuses there are numberless.

That being said, I had similar sensations about emotes, but I implemented those anyhow because the users desired it more than I did rejected it. If there is sufficient desire for this feature, then I would say to go for it regardless of my aged concerns.

-- ChristianRatliff - 07 Aug 2003

Lets be clear - there are two protocols here:

1. The protocol that the client negotiates with the server to acknowledge that it knows about client-to-client stuff.
2. The format of the messages that the clients themselves use when talking to each other.

Mr Reed first presented the document Garance talks about. Which is not a bad document, but it only talks about how the client would negotiate with the server, and then generalizes about the clients talking. Thats fine, but it wasn't sufficient for another client author to write a client that could talk to naim.

Which is why Mr Reed created the document that I refer to.

-- ThePrisoner - 07 Aug 2003

-- GaranceDrosehn - 06 Aug 2003

I would also say that EncryptingLilyTraffic is not a good example of something that should be done as client-to-client protocol. Well, it is fine if clients want to support their own unique encryption methods, but we should also have some degree of encryption which is supported at the server level.

-- GaranceDrosehn - 06 Aug 2003

It isn't that many of us were against it - its that the request was for "support for Client-to-client" without any documentation what that protocol would then entail. We didn't want to put support in the server without documentation about how the clients would use it to talk to each other because we wanted client interoperability.

There is a protocol used by naim. n has now documented it.

-- ThePrisoner - 06 Aug 2003

-- RobKudla - 06 Aug 2003

I think one way to do this effectively is start to have key/value pairs on connections as well. For a given connection you advertise +ctcp-aware as part of your "#$# options" line, and that's indicating to the server that you can receive them on some port. Bonus points for being able to specify when the client sends the line what port you're listening on for ctcp events.

-- ChrisParker - 06 Aug 2003

For the moment, we seem to have settled upon an inelegant hack to determine whether a client "supports" the as-yet-undeveloped CTCP functionality: a discussion named -ctcpmagic, the members of which may safely be assumed to receive CTCP events without complaint. So far it's been destroyed for inactivity once and recreated as invulnerable, but to my knowledge none of us client developers has actually begun designing or implementing the actual protocol yet.

Desirable properties of a lily client to client protocol:

• Handshaking done in some relatively non-intrusive manner for when people are in the discussion unintentionally.
• Optional negotiated exchange of IP addresses for direct client to client connections, for file transfers, secure chat, multimedia messaging or whatever else you'd do with a direct connection.
• ...

-- RobKudla - 06 Aug 2003