From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "J.P." Newsgroups: gmane.emacs.bugs Subject: bug#48598: 28.0.50; buffer-naming collisions involving bouncers in ERC Date: Thu, 10 Jun 2021 07:36:48 -0700 Message-ID: <87pmwtyef3.fsf__20694.4750085071$1623335900$gmane$org@neverwas.me> References: <875yzakzvi.fsf@neverwas.me> <2355590.Kj97tzTlbN@ravel> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29804"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 48598@debbugs.gnu.org, emacs-erc@gnu.org To: Olivier Certner Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jun 10 16:38:12 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lrLox-0007aG-Ou for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 10 Jun 2021 16:38:11 +0200 Original-Received: from localhost ([::1]:43616 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lrLow-0003OK-QY for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 10 Jun 2021 10:38:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34486) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lrLoo-0003Lg-VT for bug-gnu-emacs@gnu.org; Thu, 10 Jun 2021 10:38:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54209) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lrLoo-0004II-OB for bug-gnu-emacs@gnu.org; Thu, 10 Jun 2021 10:38:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lrLoo-0000JH-Hu for bug-gnu-emacs@gnu.org; Thu, 10 Jun 2021 10:38:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "J.P." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Jun 2021 14:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48598 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 48598-submit@debbugs.gnu.org id=B48598.16233358241115 (code B ref 48598); Thu, 10 Jun 2021 14:38:02 +0000 Original-Received: (at 48598) by debbugs.gnu.org; 10 Jun 2021 14:37:04 +0000 Original-Received: from localhost ([127.0.0.1]:37522 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lrLnr-0000Hv-Di for submit@debbugs.gnu.org; Thu, 10 Jun 2021 10:37:03 -0400 Original-Received: from mail-110-mta15.mxroute.com ([136.175.110.15]:42327) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lrLnp-0000HO-Hs for 48598@debbugs.gnu.org; Thu, 10 Jun 2021 10:37:02 -0400 Original-Received: from filter004.mxroute.com ([149.28.56.236] filter004.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-110-mta15.mxroute.com (ZoneMTA) with ESMTPSA id 179f65aba88000a2c9.001 for <48598@debbugs.gnu.org> (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Thu, 10 Jun 2021 14:36:51 +0000 X-Zone-Loop: 208abf6f884c7845b5a659c46b6cfc177885d829cb19 X-Originating-IP: [149.28.56.236] In-Reply-To: <2355590.Kj97tzTlbN@ravel> (Olivier Certner's message of "Wed, 09 Jun 2021 16:36:19 +0200") X-AuthUser: masked@neverwas.me X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:208323 Archived-At: Thanks for taking the time to respond with thoughtful remarks. Olivier Certner 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