Add resume extension

[DanielOaks]

Occasionally, clients disconnect from IRC. What happens these days is that the client connects with a different nick, joins all their old channels again, waits for the old connection to time out (or manually kills it using services), and then changes back to their original nickname.

This feature intends to vastly simplify this form of reconnection, and reduce the amount of nick-switching, JOIN and QUIT notices, and general disruption that other clients see when this happens.

Note that this is not related to detaching and re-attaching an active connection (such as if a client is forced to change servers), but only to streamline the reconnection process for unintended connection drops.

Rendered specification

[DanielOaks]

The idea around using CHGHOST rather than an explicit separate verb for noting resumed connections.

One of the main things to convey when a reconnection happens is that message history may have been lost, which is why we send an explicit QUIT+JOIN for clients that don't support this capability. If we used CHGHOST with a resume tag, clients with message tags and resume would receive the CHGHOST, clients with resume but no tags would have to receive the QUIT+JOIN so the user knows that the connection was explicitly disconnected and reconnected. As well, not requiring message tags means that this can be implemented on clients and servers that don't currently support them.

Using an explicit new message reduces the dependencies on other extensions, which in this case I think is a good thing.

[jwheare]

How might this interact with a METADATA spec or anything else like that? I would expect all the client set metadata to be restored when resuming.

Probably needs to be documented in either this spec or the revised metadata spec or both, but not urgent now as neither of them are mergeable yet.

[prawnsalad]

There's no mention of the length of time a server may allow a connection to be resumed. Is the intended use to be able to resume after 5mins of disconnection? 1 hour? Or x2 ping timeout length?

And I'm assuming that once the RESUME cap has been negotiated that's when the server will not simply quit the user after a ping timeout. Which leads me to think the cap should also advertise the length of time a connection can be resumed within?

[prawnsalad]

As mentioned on other specs, scoping any errors to the command will help tidy things up and remove the need for extra numerics. Eg. resume ERR_CANNOT_RESUME.

[DanielOaks]

Honestly I haven't given thought to the possibility of letting/having the server extend the ping timeout length when the cap's negotiated, or similar. I suppose servers could definitely do so if they want to, that'd be interesting. Maybe the cap's value could be a series of k/v's similar to sts' params.

Right now, it's intended to just allow reconnection up to the point where the server disconnects the client due to ping timeout, but allowing servers to make it more clear (and extend how long the client connection stays open if they've negotiated the right cap) definitely makes sense, thanks for the yell with that!

[prawnsalad]

So if I've understood this correctly, the only way to make use of this is to guess the servers ping timeout length, and ping the server from the client at an interval shorter than that to try catch it before the server does. This sounds messy and ripe for a connection race condition.

Having an increased timeout once the cap has been negotiated will make this more useful.

[slingamn]

It should be noted that the client MUST NOT perform SASL authentication if the draft/resume-0.5 capability exists and they wish to resume their session, as completing SASL auth will end connection registration and abort the resumption attempt.

Is this language still accurate? Successful SASL does not terminate registration on oragono, at least. It seems like the only things that can terminate registration are NICK, USER, CAP END, or RESUME itself.

[DanielOaks]

suggestion from e, WRONG_SERVER FAIL code, used when the token tries to be redeemed on a different server and cannot be

[DanielOaks]

another suggestion, explicitly tell clients how to act if they receive a WARN/FAIL code that they don't understand (if a new one is added in future how to act?)

[edk0]

another suggestion: amend

<reason> is used as an AWAY reason for the client until either the client resumes their session or the window of time for resumption closes - in which case it will be used as the displayed QUIT reason.

to

<reason> is used as an AWAY reason for the client until either the client resumes their session or the window of time for resumption closes - in which case it will be used as the displayed QUIT reason. Upon successful resumption, the server SHOULD restore the connection's AWAY status to its previous value.

[DanielOaks]

note to self: in the examples, could probably remove the source from most of the std-replies responses and possibly other things

[DanielOaks]

Idea mentioned in the channel: make the server remember caps between sessions that are resumed? can probably cut down a lot on traffic needed to resume, client and server both already know what they've negotiated anyways.

[dequis]

Idea mentioned in the channel: make the server remember caps between sessions that are resumed? can probably cut down a lot on traffic needed to resume, client and server both already know what they've negotiated anyways.

Following that line of thought: how about assuming that in servers for which we have a resume token, we can just assume the cap is supported, and send the command before the CAP LS response?

So this example from the current version:

C2 - C: CAP LS
C2 - C: NICK dan-backup-nick
C2 - C: USER d * 0 :An example user!
C2 - S: :irc.example.com CAP * LS :multi-prefix draft/resume-0.5 sasl
C2 - C: CAP REQ :multi-prefix draft/resume-0.5 sasl
C2 - S: :irc.example.com CAP dan-backup-nick ACK :multi-prefix draft/resume-0.5 sasl
C2 - S: :irc.example.com RESUME TOKEN JKbAypzFiovffzuD8VEfcs6bOLrXsSenxsyZNt8
C2 - C: RESUME A8KgnZPYDaRiGMzZWLu2frVvtN7lbCxO3hTwGLO 2017-04-13T15:12:51.620Z
C2 - S: :irc.example.com RESUME dan

Becomes

C2 - C: RESUME A8KgnZPYDaRiGMzZWLu2frVvtN7lbCxO3hTwGLO 2017-04-13T15:12:51.620Z
C2 - C: CAP LS
C2 - C: NICK dan-backup-nick
C2 - C: USER d * 0 :An example user!
C2 - S: :irc.example.com RESUME dan
C2 - S: :irc.example.com CAP * LS :multi-prefix draft/resume-0.5 sasl

If RESUME isn't supported anymore for some reason, it will get ignored silently, and that will be visible in the CAP LS response.

If it is supported, the first response from the server is the RESUME command, at which point the client can assume the old caps from that session are back

(optionally, the server could send a cap ack as if we just had requested it?)

If someone really wants to, they can send CAP LS first and then RESUME later somewhere around NICK/USER, but it seems more convenient to do it the other way around for the usual event-response flow.

Sending it in response to the activation of the cap (as the current version) is still a valid flow, just a higher latency one.

[DanielOaks]

That flow may make more sense, yeah

[slingamn]

A note: one of the motivations for this change is to speed up reconnections of mobile clients that detach and wait for push notifications, but I'm not sure how viable it is for that purpose in its current form, since we'd have to keep the session information around for much longer than current implementations do (210 seconds in Oragono). This also has implications for presence and communication of presence to other clients.

Transfer of ISUPPORT (avoidable), MOTD (avoidable), and NAMES (probably unavoidable) were also suggested as reasons for slow mobile performance. It would be useful to have more details on mobile handshake performance (how much of it is roundtrips from the chattiness of the current registration sequence, how much of it is bandwidth).

[edk0]

C2 - C: RESUME A8KgnZPYDaRiGMzZWLu2frVvtN7lbCxO3hTwGLO 2017-04-13T15:12:51.620Z
C2 - C: CAP LS
C2 - C: NICK dan-backup-nick
C2 - C: USER d * 0 :An example user!
C2 - S: :irc.example.com RESUME dan
C2 - S: :irc.example.com CAP * LS :multi-prefix draft/resume-0.5 sasl

Under the normal rules, C would then change nick to dan-backup-nick, which seems unideal.

[slingamn]

In a potential low-latency version of the resume handshake, the server could send:

1. RESUME SUCCESS
2. CAP LIST (to compensate for any missed cap-notify)
3. RESUME TOKEN (the new resume token)
4. JOIN lines for all channels

and omit:

1. All of the conventional registration burst, including ISUPPORT and the MOTD
2. NAMES output (the client can re-request on demand, e.g., when the user tabs over to the channel)

[slingamn]

Would it make sense to publish the session lifetime as a cap value?

[DanielOaks]

I can't decide whether I like resume or not. The spec is pretty long (about 10 printed pages on A4 paper), or at least feels long for something that aims to solve a really simple issue ("Hey it's annoying when your connection drops and you need to use /ns ghost").

My specs tend to end up very long and wordy and precise, and a feature like this does require some specificity. But I feel like the current spec, as written, isn't as client-friendly as it could be. Server devs have seeeemed to like it though? (we have an impl, solanum has a pr, insp's been interested in implementing it).

Honestly it might just be that the spec as written is laid out very 'academically', whereas it should probably start up the top with a very quick rundown of 'here are a few flows inc. C2S proto stuff' that hotlinks to the actual message/etc definitions down below. Aiming to make it easier-to-understand for client devs. With a change like that, the length may not even be so much of an issue for me.

---

Now, onto some stuff that's RESUME-adjacent.

I like BRB. It's nice, it's shiny, it's (fairly) short and fairly specifically defined. And I do get the use case when it comes to installing upgrades (client/bot installs upgrade, sends a BRB and RESUMEs when it spins back up), but it feels like there's two other use cases along similar sorts of lines that aren't addressed, so it sticks out:

• Server upgrades, network management and changes in general, servers needing to push clients actively to another server. Think RPL_BOUNCE but like, actually properly defined and all that junk. I think we have/had a spec for this floating about, and/or that maybe... plexus was looking into it? Maybe? My memory around that is hazy. This certainly wouldn't fit in this spec, but it's in the same areas that this spec touches, and a push-client-to-new-server spec/message/etc might use the resume feature.
• Mobile clients. In Ora we're experimenting with an abbreviated-handshake cap to speed up reattach for mobile clients. It doesn't really 'compete' or whatever with this spec, but 'fix mobile clients and irc' is a goal that's pretty often been pushed onto this spec and that people use to justify either liking (it solves this yay!) or not-liking (it doesn't solve this, boo!) this spec.

I don't mind BRB being a part of this spec very much (esp since it's like a paragraph of explanation if that), but it is an extra add-on to the original goal, so the goal stated in the spec should be updated to include a mention of it. I also want to make very clear that the above two use cases aren't things that this spec tries to touch in any way.

---

Another very specific point. This spec isn't 'first and foremost' designed to replay history. That's like an added bonus (since we're already sending a timestamp to notify other clients of how much history we lost, hell why can't the server just automagically replay that lost history to us). I think it's a bit too prominent in the spec and mentions of it should be dialled back, because this spec isn't for that. Or maybe the spec is for that and I need to accept it. Server implementors, thoughts?

---

Another point, implementors allowing RESUME across servers on a network. Obviously, this isn't always possible because S2S protocols haven't been designed with 'transferring active clients between servers' in mind, so implementing this takes some doing. I don't really think it's a knock against this spec but it is something that I've heard very consistently (why bother with this feature if it doesn't work across the network? it's useless then!). The current solanum pr only allows same-server resuming, the Insp plans last I heard were to allow it across the network, in Ora we only have one server so ¯\_(ツ)_/¯

I'm interested in whether client devs think 'reconnect to the same server to use resume' complicates their reconnection logic significantly, or if there are other issues that make them not want to reconnect to the same server again as a rule (e.g. working around server issues, just not wanting to complicate their connection logic like that, etc). I've mentioned this and the general thoughts seem to be that it's either not enough of an issue for me to worry about or that it's a worthwhile complication. Further, would clients find a cap value like resume=across-network which indicates 'yes resume works across the network' actually useful?

[slingamn]

I am opposed to ratification of draft/resume-0.5 in its current form; in fact, I think clients and servers should not implement it.

The current spec tries to do too much and provides too little benefit to users, in exchange for a considerable increase in implementation complexity. In particular, the core purpose of the spec (as identified in its introduction) is essentially just to streamline or automate NS GHOST, i.e., the reclamation of stuck nicknames on reconnection. In the drafting process, this has become entangled with two unrelated concerns, neither of which is well addressed by the current text:

1. Giving users continuity of presence across disruptions to their connections. (In its current form, the proposal is capable of covering only very brief disruptions; the exact time window allowed is not visible to clients.)
2. Optimizing the handshake, in particular by removing the need for SASL. (In its current form, the proposal is not intended to reduce the bandwidth or the number of roundtrips in the handshake.)

On the server side, the spec is so difficult to implement that there are only two candidate implementations. One is Oragono, which doesn't have to consider the multiple-server case. The other implementation disallows resuming on a different server than the one you started on, which (a) increases the complexity of client reconnect implementations (b) is not currently exposed to clients.

There are workarounds for some of these problems, e.g., we could include both the server's extended ping timeout and whether all-server resume is supported in the CAP value. But I think at this point it's better to go back to the drawing board. For example:

1. ergo.chat/abbreviated-handshake ergochat/ergo#1420 is a sketch of a proposal for a bandwidth-optimized handshake
2. If SASL performance (both the latency added by password checking, and the costs imposed on a centralized services node) is a concern, we could think about a proposal to issue "auth cookies" (most likely temporary passwords that could be submitted with SASL PLAIN, but which wouldn't have the same sensitivity and storage requirements as hashed user passwords)
3. If a server implementation is extending its S2S protocol to support transparently migrating a client between servers during RESUME (which, as I understand it, is a significant implementation barrier), it might be better to develop full "multiclient" capability instead (i.e., allowing multiple endpoint connections to the same nickname/presence).

[slingamn]

Summarizing some discussion from #ircv3: the spec, as written, does not make IRC viable on mobile platforms (which are increasingly hostile to background TCP connections). So it's applicable mainly to connection disruptions and software restarts on desktops and servers. Moreover, not all implementations may be able to maintain history across spontaneous disruptions (as opposed to BRB).

So, the baseline supported use case is software restarts of desktop and server software. At which point the question is: is the (considerable) engineering effort involved in implementing this specification justified?

[DanielOaks]

In the drafting process, this has become entangled with two unrelated concerns, neither of which is well addressed by the current text: - Optimizing the handshake, in particular by removing the need for SASL

No, that's not the reason why SASL's disallowed with resuming a connection. The reason for that is just that... if you sasl, the connection registration process finishes, so you can't do it and also do something that hijacks the connection resumption process like resume. I'd be interested in client developer opinions on this, and how the spec handles this aspect.

On the server side, the spec is so difficult to implement that there are only two candidate implementations.

This is a v3 draft, you really can't use 'number of implementations' as an indicator of spec worth/complexity. I mean, this is more implementations than most of our junk gets before it gets pushed to the site in draft form.

But I think at this point it's better to go back to the drawing board. For example: [...]

1. I think these caps could be requested together.
2. SASL performance isn't a concern, the reason you can't do SASL and also resume is purely because of restrictions around the connection flow. And if I've screwed something up there, I'd be happy to resolve it.
3. Eh, maybe? It feels like it's much more difficult to dig into something like multiclient than it is to change active users between servers. Particularly since multiclient stuff relies on services authentication, and those other servers don't integrate as closely with their services packages as we do with ours in Ora.

the spec, as written, does not make IRC viable on mobile platforms

Um. Yeah. The part of my comment which says "'fix mobile clients and irc' is a goal that's pretty often been pushed onto this spec and that people use to justify either liking (it solves this yay!) or not-liking (it doesn't solve this, boo!) this spec. [...] I also want to make very clear that the above two use cases aren't things that this spec tries to touch in any way." indicates this.

So it's applicable mainly to connection disruptions and software restarts on desktops and servers.

Yes. This is the point. I don't see why it couldn't be useful to mobile clients in the same way, just that they'd probably also request whatever protocol-optimization cap we end up making for mobile clients.

Moreover, not all implementations may be able to maintain history across spontaneous disruptions (as opposed to BRB).

Yes. This is the point. I don't expect implementations to suddenly start storing history when they haven't before -- that bit's purely opportunistic if it's available, and if it's not then cool other clients will know that the reconnecting client missed messages at least.

[DanielOaks]

If someone is really bent on the 'this doesn't solve mobile, so it's not worth it' then what does a replacement for this spec which focuses on mobile look like? Does it aim at the same thing that this specification aims at, or is it pretty orthogonal to this?

The two alternate things which I've heard which would be mobile alternatives to this spec/functionality are:

• Something that speeds up connecting generally, see also abbreviated-handshake. While this does better help things like mobile devices connecting, I don't really see it as 'competing' with this spec. I could see a device requesting both and the two inter-operating just fine.
• Something that builds a full persistent presence into the server/bouncer/etc side. While, yeah, a persistent presence and that kind of integration helps mobile clients very much (that's why so many mobile clients run through bouncers with history-grabbing, etc), I don't think big, large, traditional IRC servers are going to transition to that any time soon. For servers with persistent presence, this specification doesn't make sense. In a typical client<->bouncer<->ircd setup, I'd imagine the 'persistent presence' stuff to be built and work between client<->bouncer, and for this spec to work on bouncer<->ircd, generally.

[slingamn]

Something that builds a full persistent presence into the server/bouncer/etc side.

That's my position: doing this is necessary to support mobile, and having it would make RESUME redundant. Optimizing the handshake is just the icing on the cake.

In a typical client<->bouncer<->ircd setup, I'd imagine the 'persistent presence' stuff to be built and work between client<->bouncer, and for this spec to work on bouncer<->ircd, generally.

I think we're on the same page here about use cases here. I just don't see bouncer<->ircd as something that's critical to streamline or optimize, particularly given the other limitations on functionality we're accepting.

No, that's not the reason why SASL's disallowed with resuming a connection. The reason for that is just that... if you sasl, the connection registration process finishes, so you can't do it and also do something that hijacks the connection resumption process like resume.

As discussed, I believe this to be inaccurate.

[DanielOaks]

As mentioned in the meeting, unless there's some more concrete client interest in this feature then I'm leaning very much towards killing it. As-is it probably isn't useful enough to justify the complexity.

If we do want to do something similar down the line as part of a client-redirection feature (e.g. a way for servers to push clients to new servers) then this'd probably be useful reference for that though, given it is fairly complete. edit: ignore me lol I totally forgot that #330 was already submitted.

[jwheare]

To clarify, I closed this in response to what looked like lack of interest from the proposers of the spec, and what appeared to be confused/conflicting ideas around what the spec is actually for. Apologies if that was hasty, I can reopen this if that's not the case.

From my own perspective as a client developer, I'm seeing resume as a solution to "faster and less noisy reconnect after brief/sudden loss of connectivity" or "brb for a software update restart". From that point of view, it seems like a cool concept, but not worth the length/complexity of this spec to achieve. And it's sounding like it will be hard to ratify as a result.

[DanielOaks]

I probably would've closed it in a few days anyway.

With regards to 'lack of client interest', for me that's mostly just me informally mentioning it around a few client devs and them largely seeming meh or unenthused. Very unofficial, but yeah it affects my want to continue working on the spec.

If clients like the idea/spec in its current form, awesome. If they like the idea but are unenthused about the spec as it stands, cool I could work with that. If they aren't really into the idea at all, then eh.

Generally it's felt like server devs are pretty into this while client devs aren't. I think the spec right now is way too long for client devs to be interested in implementing it, and it's also not really written in a way that helps people understand how to implement it (this is my spec/tech writing nerd coming out but it's written in a very 'clinical' way that server devs may appreciate but I can't see clients liking at all). I could probably spend time working on this and trying to make it shorter/simpler, and improve the structure of the spec, and make sure there's much less confusion about what exactly this feature aims to solve. But fact is that right now I'm not enthusiastic enough to put the time into doing that.

[kylef]

Generally it's felt like server devs are pretty into this while client devs aren't. I think the spec right now is way too long for client devs to be interested in implementing it

Would server dev's be interested in migrate more? I see both resume and migrate as trying to do something very similar (allowing the other party to reconnect), just one is orchestrated from the server, and the other from the client.

As a client author, I'd happily implement migrate as I can see this as a gap from being able to keep networks up to date and secure from a maintenance point of view.

For resume, it doesn't solve any of my problems as it is today, but that's not to say it doesn't solve problems for all clients. Perhaps it could be useful for bouncers and similar which may want to perform any patching at a scale without disrupting their customers.

[ailin-nemui]

as a client dev I like this extension idea

[sadiepowell]

Would server dev's be interested in migrate more?

As a server developer no. It has an entirely dififerent use case and honestly it seems like it's trying to solve a problem that doesn't really exist (at least not for us).

[kylef]

@SadieCat Orchestrating security patching/keep software up to date without disconnecting and disrupting ongoing conversations for connected clients is the use-case I imagine the most for migrate. I don't see this as an great user experiance at the moment.

[sadiepowell]

We've solved this problem by pushing TLS out to a separate process (in our case HAProxy) and transferring fds/data to the new process.

[kylef]

@SadieCat That doesn't count for all cases of security patching, the kernel/os, updating TLS libraries for active connections etc.

[ValwareIRC]

👀