bug#48598: Strange ERC/ZNC Bug/Problem

[J.P.]

acdw <acdw@acdw.net> writes:

> I'm just going to recount what I experienced using ERC to the best of
> my remembrance; I haven't used it in about a week or so (see the last
> commit of my config using ERC at [1]), having switched to Circe.

Thanks a bunch for this, and apologies for the disappointing experience.
Since you're already an apostate, I'll spare you the annoying followup
questions as well as the customary plea to try out my changes (not that
your initial description wasn't plenty thorough enough).

> - After setting up ZNC on znc.tilde.team, ERC would connect to
>   channels on the wrong server, e.g. I had #politics@tilde.team setup,
>   it would connect to #politics@libera.chat (which doesn't exist, and
>   would redirect to ##politics).

This one is in fact what this entire bug (#48598) is about. On the
surface (at least in your case), the initial blame falls on the autojoin
module, whose flaws any simple half measure might paper over well
enough. But the "confusion" revealed by those flaws runs deeper and
speaks to foundational problems that (IMO) need addressing if ERC is to
remain relevant much longer.

>   This is with the new ERC on Emacs 28, that when connecting to
>   different servers directly, would /not/ be confused (i.e., two
>   buffers were created: “#emacs/tilde.chat”, “#emacs/libera.chat”).

Unfortunately, distinct connections like this aren't immune either. For
example, relinking previously used target buffers can still fail when
endpoints share the same host but different ports.

What's happening in both cases is that ERC makes presumptions about
session semantics based on dialed connection details instead of waiting
for authoritative info to arrive to better inform those decisions. And
for other, truly ambiguous situations, ERC (unlike most clients) doesn't
allow users to declare their intentions upfront but rather insists that
it knows best. Which leads to problems like yours. In ERC's mind, you're
connecting twice to server-network-thingy znc.tilde.team instead of to
networks Libera.Chat and tilde.chat [1].

>   To be honest, I'd never used ZNC before either, so it's possible I
>   set /that/ up wrong…

ZNC is off the hook here. The problem lies squarely with ERC.

> - Re-connection issues: I'm on a laptop so the connection drops in and
>   out. That's not the problem, but ERC was not so smart with
>   reconnecting. I'd run /reconnect in a server buffer, or try to map
>   the command over servers, and it'd reconnect but my nick would be
>   acdw` or similar. I don't think this is ERC's issue /per se/, but
>   Circe, e.g., handles it better, afaik.

For this one, I'd have to see some protocol logs before offering
anything of value because a number of factors influence the fate of
reconnection attempts. But just to speculate...

I'm assuming we're talking sans bouncer here (?) because your nick and
authentication status would've remained steady otherwise. I'm also
nixing anything involving client certs [2], based on the config you've
shared. So, ignoring the unlikely possibility you were using auth-source
to supply creds via a repurposed server password [3], I'm going to
assume you were doing the dreaded NickServ dance [4].

But without logs, I can only naively attribute this to some combination
of ERC's rather byzantine reconnect logic [5] and a vague heuristics
failure on the part of the services module in trying to reclaim your
nick. (The smart money's on my being wrong, of course.)

> That's really all I remember, I hope this is helpful. ERC is, on the
> whole, pretty good, and I might switch back later!

Well, if you ever do manage to cast off the spell of that other client
and transmutate back into a disgruntled primate, please take this bug's
proposed changes for a spin [6]. But even if that never happens, the
info you've provided here is very much appreciated. Thanks again.


Notes
~~~~~

[1] If you'll allow me to punctuate that by interjecting with a plug
    here for anyone similarly affected: my current patches for this bug
    take an aggressive but targeted (meaning still broadly conservative)
    approach toward tackling this kind of confusion:

    https://jpneverwas.gitlab.io/erc-tools/48598/patches.tar.gz

[2] I mention this because there's an outstanding bug in this area:

    https://lists.gnu.org/archive/html/emacs-erc/2021-05/msg00002.html

    Gone in [1], FWIW (though likely replaced by dozens more!).

[3] In case you're not familiar, this "PASS user:pwd" convention is a
    poor man's SASL-like legacy feature/hack supported by some public
    networks. An associated netrc entry might look something like:

    machine foo.chat login acdw password acdw:mypass

    This matters if I'm wrong (and you *were* attempting to use it)
    because it should always succeed on servers that allow it. And it
    should do so without any limbo period during which you're not fully
    authenticated (its reason for existing, AFAICT).

[4] "Dreaded" in the sense that it's vital to a session's health but
    relies on servers acting predictably in areas not governed by any
    standard.

    For example, `erc-nickserv-identify-on-nick-change' can optionally
    attempt to identify you to nick services after receiving a NICK
    message confirming the successful granting of your nickname, which
    is often the polar opposite of what you want, depending on how your
    network is configured. But this isn't currently adjustable per
    network; like so many thing ERC, it's all or nothing across the
    board.

    Similarly, `erc-nickserv-identify-autodetect' runs on NOTICE, but
    some IRCds send 433 ERR_NICKNAMEINUSE errors straight away before
    even letting you engage nick services. This at least obviates the
    need to scrape NOTICEs, but it demands a level of flexibility that
    erc-services.el just isn't equipped to offer. Accommodating this
    would at the very least involve tweaking how `erc-nickserv-identify'
    treats `erc-nickserv-alist-use-nick-p', perhaps by caching the most
    recently denied nick for use in the next IDENTIFY message.

    Luckily, this is a corner-ish case, and most public networks just
    speculatively grant whatever nick you've asked for unless it's
    already been taken by another connection, in which case you're met
    with that familiar uniquifying backtick (courtesy of the default
    433/437 handling). Anyhow, with the world moving on to SASL, the
    role of the services module will only continue to diminish. And
    that's a good thing, IMO.

[5] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50007

[6] Also available to try in package form (just disregard anything
    involving IRCv3):

    https://gitlab.com/jpneverwas/erc-v3/-/wikis/home.org