[patch] irssi and core IRC quirks

Find attached a patch making connections of irssi and coreIRC to pounce 
succeed, when CAP negotiation is enabled.

In CoreIRCs case, a simple blank line needs to be handled. In Irssi's 
case, they intentionally send a bogus "JOIN :" - This is in irssi's 
irc-servers.c:

     if (!conn->no_cap) {
         signal_emit("server waiting cap ls", 2, server, CAP_LS_VERSION);
         irc_send_cmd_now(server, "CAP LS " CAP_LS_VERSION);
         /* to detect non-CAP servers, send this bogus join */
         /* the : will make INSPIRCD respond with 451 instead of 461, too */
         irc_send_cmd_now(server, "JOIN :");
     }
  

Both, irssi's and CoreIRCs' behaviour make pounce hang up without the 
patch.


The patch is more of a suggestion than intended to be applied literally, 
this is what was needed to get both clients connected, successfully, but 
it doesn't really follow the naming style, etc.. Also, I'm not sure who 
exactly the culprit is, pounce or those clients. I reviewed a bit the 
IRCv3 docs and:

- the v3 standard isn't exactly clear what is allowed during CAP
   negotiation, however, implicitly it refers to messages being sent that
   are required for registration, between CAP LS and CAP END:

   "Upon connecting to the server, the client attempts to start the
   capability negotiation process, as well as sending the standard
   NICK/USER commands (to complete registration if the server doesn’t
   support capability negotiation). [...] Following [CAP LS], the client
   MUST send the standard NICK and USER IRC commands."


- with CAP stuff going on, the registration is complete after CAP END:

   "the server MUST not complete registration until the client sends a
   CAP END command"


- JOIN requires a fully connected client, so I personally deduce that
   this is not allowed where irssi puts it, but it can be argued
   otherwise, e.g. the fact that 451 exists might suggest that this is
   allowed:

   "[451 is] Returned when a client command cannot be parsed as they are
   not yet registered."


- v3 further says: "Until registration is complete, only a limited
   subset of commands SHOULD be accepted by the server. This is because
   it makes sense to require a registered (fully connected) client
   connection before allowing commands such as JOIN, PRIVMSG and others."


So, it's all basically a big SHOULD. Pounce decides to not accept it and 
hangs up.

Still, not sure what's best to do here, but wanted to add the above for 
completeness.

Hope my input and hack-patch helps in terms of simple feedback, maybe 
you have other reports about incompatibilities, as well, and maybe this 
helps some other reader of this mailing list..

Cheers

• patch-pounce-ignore-client-CAP-spec-violations

> On Feb 7, 2023, at 03:42, Tassilo Philipp <tphilipp@potion-studios.com> wrote:
> 
> Find attached a patch making connections of irssi and coreIRC to pounce succeed, when CAP negotiation is enabled.
> 
> In CoreIRCs case, a simple blank line needs to be handled.

the existing code intended to allow this but was incorrect. it's
fixed by
<https://git.causal.agency/pounce/commit/?id=625de6979e28269bf27b9d35f4e2bb030ad2920a>.

> In Irssi's case, they intentionally send a bogus "JOIN :" - This is in irssi's irc-servers.c:
> 
>    if (!conn->no_cap) {
>        signal_emit("server waiting cap ls", 2, server, CAP_LS_VERSION);
>        irc_send_cmd_now(server, "CAP LS " CAP_LS_VERSION);
>        /* to detect non-CAP servers, send this bogus join */
>        /* the : will make INSPIRCD respond with 451 instead of 461, too */
>        irc_send_cmd_now(server, "JOIN :");
>    }

this is incredible. I had someone else report this problem but I
assumed their irssi must have been misconfigured because it made
no damn sense. fixed in
<https://git.causal.agency/pounce/commit/?id=2abf0df3017195842c12197de3ea092febf2e60c>.

thanks for the report!

Man, very nice, that was quick! Thanks!

>> In Irssi's case, they intentionally send a bogus "JOIN :" - This is in irssi's irc-servers.c:
>>
>>    if (!conn->no_cap) {
>>  ......
>>    }
>
> this is incredible. I had someone else report this problem but I 
> assumed their irssi must have been misconfigured because it made
> no damn sense.

Believe me, I went through all my scripts first, then disabled them one 
by one, to get to the conclusion that it must come within irssi. A 
simple

$  strings `which irssi`

then showed "JOIN :" and then I started digging into the code. Quite a 
surprise. But well documented at least. :)


> thanks for the report!

And thanks for implementing it your way, much better!