bug#48598: 28.0.50; buffer-naming collisions involving bouncers in ERC

["J.P." <jp@neverwas.me>]

Thanks for taking the time to respond with thoughtful remarks.

Olivier Certner <ocert.dev@free.fr> writes:

> This approach seems to have drawbacks, at least in principle. For
> example, I don't think it allows to connect and join different
> channels with different nicknames at once. Surely, this is not the
> most straightforward scenario, but maybe some people would be
> interested in doing that. I would be interested, for example.

Yes, I think it would be nice to either support multiple connections per
network from the get go or leave the door open by providing a flexible
means of determining connection identity. My current approach is rather
inflexible, but I believe the underlying foundation (rooted in the test
suite) robust enough to withstand a quick pivot in most any direction.

> Of course, if the principle above is rooted into ERC, many changes are
> going to be needed in practice to allow multiple "sessions", so it
> doesn't matter much if the proposal below is at odds with that (it
> won't worsen the situation compared to now). Multiple sessions can be
> dealt with independently at some later point.

What I was trying (perhaps failing) to communicate initially was that
the principle above is only ingrained in the library in the sense that

  connection = (maybe sometimes dialed server:port
                or
                maybe sometimes announced.domain.name
                or
                maybe sometimes NeTwOrK)

whereas I was trying to force a shift to make it solely connection =
network (as massaged by user/library presets).

> 1. Separate the network (or the session), seen as the user's target,
> from the means to connect (directly or through a bouncer, or whatever
> else). This way, there is no confusion between the transport part
> (just a mean) and the session (which is what matters to the user in
> terms of context, i.e., which network I'm in (and channels) and under
> which identity).

This is an important distinction, and it's not unique to IRC in the
least, as I'm sure you know. Divorcing the means of connection from a
connection's identity (or "session" [1]) was among the (perhaps under-)
stated goals. If that wasn't made clear enough, it should've been.

> With this, there will be no problem in the scenario where one connects
> to a bouncer to do maintenance tasks while there is already a
> connection to it to access some other network. There will be two
> sessions: One for the maintenance task, designating the bouncer, and
> one for the other network, each having its own connection and separate
> buffers.

Yes, this is already how I have things currently working. But this all
depends on what we ultimately settle on as determining the start of a
session. Because of what I view as incomplete guidance on this matter
from on high (IETF, docs, etc.), I'm resigned to just following the lead
of the dedicated IRC clients.

BTW, often when I say "bouncer," I actually mean *any* proxy. But in an
effort to keep the bug focused and concrete, I've chosen to stick to
scenarios involving bouncers. But in many contexts, you could easily
swap out "bouncer" for, say, "web proxy" [2].

Also, by abstracting away transport from protocol, as you say, we could
easily, for example, provide "virtual servers" that do within Emacs what
would normally require a proxy. One use case might be something that
provides the chathistory interface [3] and fetches cached logs when a
real server is offline or lacking support. Another example might be a
fake server (like the one I've introduced in these patches) that's
intended solely for testing. Possibilities abound.

> I think that having a single connection to the bouncer in this
> particular case is a refinement that could be implemented later (or
> not), unless of course it is absolutely impossible to have more than
> one at a time (is it the case with usual bouncers?).

If you're talking about multiplexing generally, this requires filtering
and routing in keeping with a chosen proxy protocol (again, doable with
pluggable core components).

> 2. Also, buffers should not be associated on the fly to networks,
> depending on what the network says. They should be associated to
> sessions, as a priori targets specified by the user, with unambiguous
> (i.e., different buffers for channels with same name in different
> sessions) and unchanging names (may be internal "names" of any form
> instead of the buffer name, if one wants short buffer names in common
> situations). This way there is no "dangling" buffer, and it is always
> very clear which buffer belongs to which session, enabling smarter
> management in case a session is disconnected and then reconnected, or
> log storing.

I agree in principle, but in practice, this can only be introduced
optionally without causing overly disruptive churn.

It's easy to forget that this is legacy software, and tradition here
plays an outsize role. And for better or worse, ERC's passive detection
and automatic assigning of connection identities, however quaint, falls
right in line with the DWIM philosophy common throughout Emacs. I
suspect folks feel a certain attachment to this experience that
shouldn't be overlooked. Not saying I wouldn't welcome some other
reality in which this weren't the case.

Almost every popular client out there works the way you say: a priori
designation describes logical destination. AFAIK, this is the only
widely adopted method. Basically, a user declares some unique identifier
up front when dialing the connection (or via configuration). This then
becomes the ID associated with that connection over its lifetime.

So I believe we need to do both for now, both declared *and* discovered.
We can perhaps promote the former as being superior and regard "on the
fly" associations as fully but grudgingly supported. And interpreting
the network's word as gospel for that purpose *should* be adopted in
full instead of only sparingly, which is in large part the source of the
current problems. But again, discovered truth should also be considered
subordinate to whatever a human operator dictates. (IMO.)

If we are to allow multiple connections to networks, as you're
requesting, then adopting discovered network names as session
identifiers won't be enough. For this use case, we may simply end up
requiring declared identifiers. Alternatively, adding nicks as a second
identifying component for this purpose could effectively preclude
intra-network collisions [4], though it may not be worth the added
complexity. That said, it would make it easier to transition to full
"account" awareness [5] once we go v3, at which point many of these
problems may just vanish.

As far as "dangling" buffers are concerned, I'm going to interpret that
as the limbo period between when a connection is dialed and when its
session association has been cemented. Know that this "only" affects
server buffers, which isn't great, but at least that means it won't
happen mid session. But in cases where associations cannot be determined
(such as with the maintenance scenario), a user *must* supply an
identity for the association to survive reconnection. This may be as
simple as passing an extra keyword arg, something like :name, to the
`erc' and `erc-tls' entry point functions.

> I don't know precisely which changes 1 and 2 require given the current
> code, but I intend to dig that at some point. Unfortunately, I don't
> think I'll be able to before weeks, probably even months. At least, I
> hope we can agree (or if not, discuss) on these target points.

I'd like to keep moving aggressively on this. Hopefully you can continue
to participate in design discussions, which should leave little room for
big surprises later on.


Notes
~~~~~

[1] The term "session" is a bit ambiguous but may be the most fitting
    for what we want to describe. For now, let's assume one connection
    per account per service (here, an IRC network). Multiple connections
    for the same account/service pair are not worth speculating over or
    supporting at present, IMO. So for our purposes, a session means an
    authenticated, healthy connection to a network, for as long as both
    properties endure.

[2] These are indeed a thing. They allow a normal client to talk to
    servers when denied access to non-HTTP ports.

    https://github.com/kiwiirc/webircgateway

[3] https://ircv3.net/specs/extensions/chathistory

[4] While I'd love to use ident and maybe hostname, those aren't
    considered reliable as unique account/session identifiers. Also, I
    say "account" with reservation here because there's really no such
    thing yet. See also 5.

[5] https://ircv3.net/specs/extensions/account-notify

    https://raw.githubusercontent.com/quakenet/snircd/master/doc/readme.who