CTCP-S Support

[SoniEx2]

https://github.com/SoniEx2/CTCP-S

[TheLQ]

Hmm, so is FORWARD like "tagging" ctcp requests? What's the use case for this? Why is it called FORWARD?

How is this better than the IRCv3 message intents ( http://ircv3.net/specs/core/message-intents-3.3.html ) or message tags outside of being client only?

How is this better than sending a regular message just with the users name in it, even in your example in kvirc/KVIrc#1628 ? The bot could just strip out the users name

BATCH looks interesting since it standardizes what "finished" is when sending multiple lines.

I'm open to including features, but does any other client support or plan to support this? Have you talked with the IRCv3 group?

Also this:

PRIVMSG User :\001ACTION joins\001Hello!

I don't think is a valid CTCP request. I'm not aware of any client that send requests like this nor does it make sense visually as the whole line usually gets italicized or marked up, not just part of the line. PircBotX won't parse this as an ACTION since it doesn't begin and end with \001

[SoniEx2]

maxpowa/Inumuta#10 (comment)

Also that technically is a valid CTCP request, based on the CTCP "standard" (more like documentation). It's just that most clients implement a crippled version of CTCP. A conformant implementation might translate it to a single line <Other> *joins* Hello! or 2 lines (in an implementation-defined order) * Other joins and <Other> Hello! (the former (inlining) is recommended, as it preserves the original structure of the message).

The main use-case for FORWARD is bridge bots (namely sending CTCP queries over bridge bots). Also STOP SAYING IRCv3 SHOULD REPLACE CTCP. We should coexist. We have different goals. IRCv3 is client<->server, CTCP is client<->client. Maybe use that little IRCv3 thing called metadata as a method to sync supported CTCPs.

And yes. I have a few projects in the making that need this in order to work nicely.

[TheLQ]

Well first shouting at me isn't going to get this implemented any faster. Client-to-client is a legitimately useful feature, I was just wondering if you were adding extra value I wasn't seeing. I'm also open to (and have) implementing things outside of the IRCv3 spec

Being spec compliant is nice in theory, but in reality each IRCd and client implements things slightly differently, which means IRC libraries and standards have to be de facto standard compliant. Your probably right spec-wise, but if it breaks popular clients its wrong.

Anyway lets take your minecraft bot example, why can't your bot handle re-sending messages with commands like all other bots are usually written? Messages from minecraft to irc are sent publicly, the bot sees it, it sends <SomeDude> hi there to the IRC channel. SomeDude uses the equivalent of /me in minecraft, bot sends /me <SomeDude> hi there in the channel. PMs use something like a .sendMsg SomeDude says hi command. Sure if your trying to send CTCP it will actually say something like * MinecraftBot: SomeDude says hi but I don't think that's a big enough problem to warrant a new protocol.

What I'm trying to say is it sounds like your problems that your solving with FORWARD can be solved today with regular commands. If you want this to be implemented anywhere, you'll need to give a clear example chatlog that shows commands are impossible or too obtuse, then another chatlog that clearly shows FORWARD is so much simpler and easier to use that it deserves a protocol. Without an example, you're going to struggle to get it implemented anywhere

BATCH however does look useful, but your going to have to call it something else for google-ability since IRCv3 calls there's the same thing. Eg clientbatch, ctcpbatch, etc. Once you come up with a searchable name I'm open to adding it to PircBotX

[SoniEx2]

The CTCP you use is BATCH, but the full name is "CTCP-S BATCH", as with any other CTCP-S. ("batch" is a pretty generic term, you'd have to look for "IRCv3 BATCH" or "IRC BATCH" (because "IRC" is part of "IRCv3" and stuff) to find the IRCv3 spec for BATCH. "CTCP BATCH" should let you find CTCP-S BATCH.)

Also, how do you send an actual CTCP VERSION request (or any other CTCP query) across a bridge?

[TheLQ]

Also, how do you send an actual CTCP VERSION request (or any other CTCP query) across a bridge?

By writing a .sendctcp command, or interpret a message starting with \001 as a CTCP message. Eg

.sendctcp someUser VERSION`
.sendmsg someUser \001VERSION\001

Whatever response you get, you send back to the other side. There's only a few CTCP commands so its not difficult to do.

[SoniEx2]

And how do you send it FROM the bridge in a way the target can filter out? (e.g. tag it with a nickname - which you can't do without FORWARD or CTCP-S)