Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

draft/persistence #503

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

draft/persistence #503

wants to merge 4 commits into from

Conversation

slingamn
Copy link
Contributor

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
Copy link
Contributor Author

slingamn commented Sep 2, 2022

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
Copy link
Contributor Author

slingamn commented Sep 2, 2022

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).

extensions/persistence.md Outdated Show resolved Hide resolved
extensions/persistence.md Outdated Show resolved Hide resolved
extensions/persistence.md Outdated Show resolved Hide resolved
@emersion
Copy link
Contributor

-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
Copy link

spb commented Oct 27, 2023

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
Copy link
Contributor Author

@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
Copy link

spb commented Oct 27, 2023

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
Copy link
Contributor Author

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants