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

Command REGAIN/RECOVER #121

Open
ValwareIRC opened this issue Apr 11, 2024 · 2 comments
Open

Command REGAIN/RECOVER #121

ValwareIRC opened this issue Apr 11, 2024 · 2 comments

Comments

@ValwareIRC
Copy link

A mechanism to allow triggering a nick recovery of a ghosted user, also allowing before/during connection (after SASL).

The wording "ghost user" in the following context, for those to whom it's not clear, means a user who exists on IRC within the short time-frame whose connection has been interrupted/broken, but the upstream server doesn't know it's broken yet and is still waiting for a response, before eventually disconnecting it (usually with the message "Ping timeout").

That is to:

  1. End the session of a ghost user whose nick is specified by another user who is logged into the same account as the ghost user
  2. Assume the nick of the ghost user
  3. Optionally assume any other properties of that user such as inhabited channels or user-modes or metadata.

This is helpful for implementing some kind of rudimentary "session resume" like NickServ's RECOVER/REGAIN does, but since a lot (all?) clients automatically rejoin channels automatically upon reconnect, by implementing this pre-connect can turn this:

* Valware2 joined #chan
* Valware quit (Killed (NickServ (GHOST Command used by Valware2)))
* Valware2 is now known as Valware

Into this:

* Valware quit (Ghost)
* Valware joined #chan

Or even in some special cases...

Heh... I mean, would it even need to be shown at all if it were already the exact same?

@DarthGandalf
Copy link
Member

Does it also resend all the messages the old connection was supposed to be receiving of the last several minutes (needs clarification since when exactly)?

I mean, would it even need to be shown at all if it were already the exact same?

The quit/join tells other people that some messages could be lost due to ping. This information is now hidden, so messages will be silently lost.

@ValwareIRC
Copy link
Author

I thought about that but wasn't sure it was appropriate. I think it'd be possible to keep a track of everything that happened between the users last activity (pingpong or other?) and play it back if this scenario happened, but I'm not even sure how feasible a suggestion that is.

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

No branches or pull requests

2 participants