draft/persistence

[slingamn]

This is a draft of an extension for automating certain interactions around persistent connections (i.e. connections where the user remains present on the server even after the connection is lost, as with a typical bouncer or Ergo's "always-on" functionality). The core goals as per the introduction:

• Servers can communicate to clients whether their connection is "persistent" in the above sense, so clients can adjust their behavior accordingly
• Clients can request that the server make their connection persistent or non-persistent, and the server can grant or deny the request

[slingamn]

A question that has come up a few times about this specification: why isn't it simply a CAP?

CAPs have always been per-connection (and this distinction is especially important in the bouncer context). For example, ZNC separately tracks client-to-ZNC CAPs and ZNC-to-server CAPs. It is not the expectation that requesting a client-to-ZNC CAP will directly affect the persistent connection (the ZNC-to-server connection).

Since this affects the "global" or "persistent" presence state, it's more like a NickServ command than a CAP.

[slingamn]

Another objection that's come up: this specification is more general than required by any implementation other than Ergo.

This is true, but IMO the spec doesn't place an excessive burden on less general implementations:

1. Clients that don't want to introduce a user-controllable toggle can treat this the same way they would treat an informational CAP. The only difference is, an informational CAP would be seen during connection registration, but this comes as part of the registration burst (but since it's before RPL_ENDOFMOTD/ERR_NOMOTD, it will be seen alongside other successful registration numerics like RPL_ISUPPORT, so there's still time to make decisions based on the result).
2. Servers that don't support toggling (because the user is always persistent) just have to store the value of the user's requested setting (it should be simple to store this alongside other persistent user state).

[emersion]

-1 from me. I think the cap is good, but I don't see the need for a standard command to get/set persistence setting.

[spb]

Another objection that's come up: this specification is more general than required by any implementation other than Ergo.

My problem is that it's not general enough - it assumes that there can be at most one persistent session per account. I'd rather see a newly-connecting client able to authenticate, request a list of available sessions, and choose which one to attach to.

[slingamn]

@spb I had this conversation with Jess a while back; I think this specification can actually be decoupled from that assumption. See proposed change here: slingamn@16e6cbc

[spb]

That change does go some way towards it, but then you have the problem that a client needs to implement this spec and also whatever other spec defines the session selection mechanism. Combining them would make the ecosystem as a whole simpler.

[slingamn]

From discussion in #ircv3, I'm open to an extension of this spec that would:

1. Mandate SASL as a prerequisite for reattaching to a session (allowing a bearer token mechanism to cover hypothetical cases where there is no conventional account system)
2. After this prerequisite is met, allow optionally enumerating the sessions and choosing one. It will still be possible for the client to proceed to CAP END without choosing a session, in which case they will get the "default" behavior (e.g. for a conventional bouncer or Ergo, they will attach to the unique session associated with the account)