Giters

maxpowa / Inumuta

maxpowa's fork of Sopel containing some tweaks that don't fit in mainline Sopel.

Home Page:http://irc.everythingisawesome.us/Inumuta

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

CTCP-S Support

SoniEx2 opened this issue · comments

commented

https://gist.github.com/SoniEx2/6509bf2ca6a65a69a383

The FORWARD CTCP is very useful for bridge bots.

commented

Where is CTCP-S in the official IRC spec, I see nothing in rfc2812. There's something similar called Intents in IRCv3.3, which Inumuta/sopel both already support.

commented

Well there isn't ANY ctcp in rfc2812 either...

The issue is here that it's not implemented in clients, so it's kinda pointless to implement.

commented

Well yeah, that's true. Either way, any gap this would fill appears to be filled by IRCv3.3's intents. If clients don't support intents, they get downgraded to CTCP as in the IRCv3.3 spec.

commented

IRCv3.3 replacing CTCP is complete BS. Nothing can replace CTCP due to the client-client nature of CTCP. All IRCv3.3 does is add client-server "CTCP".

IRCv3 metadata doesn't replace CTCP because with CTCP:

  • Clients can choose what to reply with based on various factors such as: hostname, IP address, username, nickname, account name, RNG, timer, etc. Or a combination of them.
  • Clients can also send multiple replies to the same request.

And you can't do those with IRCv3 metadata.

Intents don't work either because:

  • Intents apply to the whole message.
  • Intents aren't a method to convey metadata but rather to convey messages.

Message tags don't work either because:

  • The server needs to explicitly support them, thus, they can't possibly replace CTCPs.
  • The client also needs to explicitly request them, and is not allowed to send them without knowing how to handle them.

We can all agree that it's possible to replace CTCP with a server-aided solution, but IRCv3 is not the way to do it, as it doesn't support distinctive features of CTCP.

commented

Inumuta requests tag and intent support by default, and any modern IRC server should support both already. CTCP is bad enough of a system as it is, I don't want to implement something that complicates it more.

To your point about the inability to make multiple replies to the same request, thats pretty easy with tags. @vendor.tag/reply-to=what,ever,you,want

Clients have to implement something either way. I can tell you that it's going to be IRCv3, especially with the contributors involved. Everyone in the modern IRC community is pushing to remove CTCP all together, it's a shitty solution.