Command to request a reconnect without showing other clients a QUIT

[jesopo]

This came out of a discussion about https://github.com/ircv3/ircv3-specifications/pull/306...

There should be a command to ask the server to allow the client to disconnect but hold the session open (e.g. don't send QUITs to other clients) to allow for a short period of time that the client can reconnect, have the state replayed (with a playback of missed data?) and carry on as it was. This would be very useful for e.g. restarting clients/bots for software upgrades without spamming other users with QUITs/JOINs.

I suggest the command used to request this be called BRB (Be Right Back)

[jesopo]

Considerations

• this will be heavily used for software upgrades, CAPs are likely to change
• this is very similar to RESUME, it should probably also use a token system and timestamping

[DanielOaks]

So on the resume spec, my original intention was to say "just leave the old connection open and then RESUME on the new connection before breaking the old one", as is mentioned a number of times for existing cases.

I could see a BRB command being useful as basically a client-initiated ping-timeout starter. So client sends the BRB, server kills the TCP connection but leaves the client online until their standard ping-timeout time happens (extended a bit, if the resume cap is negotiated, as per that spec), and the client can then resume on a new connection.

Right now when a RESUME happens, the CAPs aren't carried over anyways, as per this line in the spec: "Session information that MUST NOT be applied from the old client and replayed includes", so we're fine there.

We shouldn't create a whole new token/timestamping/etc process for this, just piggyback off the existing resume system to vastly simplify client implementations of this brb stuff.

[Herringway]

Without a maximum time, this feature could replicate the persistent presences that services like discord provide.

However, I imagine many networks would want the BRB to upgrade to a full QUIT after some time.

[jesopo]

huge :+1: for piggybacking off resume

[Herringway]

Perhaps a message could be provided with BRB and be treated as an AWAY message (or QUIT message if "upgraded"?)

[DanielOaks]

Feels like it might be useful to clarify what this is intended to do. Allow for IRC client software upgrades, allow for persistence across days and weeks, some other use cases? I'd prefer keeping it short to allow upgrades, and using other methods of persistence for the discord-like services, but whatever way we go we should clarify the intention for the feature in here. No harm in having a couple different specs/commands better tailored to their use cases.

As-is, servers could do BRB as just the ping-timeout length without any dramas. Adding the long-running persistence on top is a fairly significant change, even for e.g. Oragono which is really flexible. Presumably the long-running persistence comes with the implicit guarantee of holding loooots of message-history for any client using it?

Providing a message with it and all, yeah makes sense to do, use as AWAY message and then QUIT message if they fail to resume in time and the brb wasn't persistent.

[RyanSquared]

So should servers send a BRB token to the client, or should it piggyback off of the RESUME spec? it would probably help clients share code a lot more if, for example, this were an extension of the RESUME spec as a way to ping the server to restart the RESUME counter.

Additionally, if something like BRB :Restarting client for an update were to happen, we should keep in mind that servers should store the current AWAY message, so it's not lost during the transaction.

[jesopo]

Yes, we're saying BRB should rely on the resume token mechanism to be able to resume a BRB-ed session

[jesopo]

Should a BRB command from a client be met with a confirmation from the server that is instantly followed by the server terminating the TCP connection? Seems important that we get a confirmation that the BRB was the reason the server disconnected us instead.

[jesopo]

https://github.com/ircv3/ircv3-specifications/pull/363