Signal the end of away status to the client after disconnecting #950

New Issue

2026-10-05T04:55:08+02:00

adam commented

2026-10-05 04:55:08 +02:00

Connect to a server
Mark yourself as away
Disconnect
(You are still away according to your client)
Reconnect
(Once again, you are still away according to your client, but not to the server)

Maybe there's a way to tell the client to cancel the away status without messing anything up?

1. Connect to a server 2. Mark yourself as away 3. Disconnect (You are still away according to your client) 4. Reconnect (Once again, you are still away according to your client, but not to the server) Maybe there's a way to tell the client to cancel the away status without messing anything up?

adam commented

2026-10-05 04:55:09 +02:00

That depends on your client. Does it let server know that it's away when connecting?

Also, any modules like simple_away used?

That depends on your client. Does it let server know that it's away when connecting? Also, any modules like simple_away used?

adam commented

2026-10-05 04:55:09 +02:00

That depends on your client. Does it let server know that it's away when connecting?

When I said connect/disconnect, I meant znc connecting and disconnecting from the server. The client has no idea of what's going on.

Also, any modules like simple_away used?

No.

>That depends on your client. Does it let server know that it's away when connecting? When I said connect/disconnect, I meant znc connecting and disconnecting from the server. The client has no idea of what's going on. >Also, any modules like simple_away used? No.

adam commented

2026-10-05 04:55:10 +02:00

I see. Probably it should send the away status to server instead upon connect.

I see. Probably it should send the away status to server instead upon connect.

adam commented

2026-10-05 04:55:11 +02:00

That seems like an even better solution.

That seems like an even better solution.

adam commented

2026-10-05 04:55:11 +02:00

I think this is a bit of a larger problem than just away, there's various states that a client may have which are not reset upon disconnect, or new connection. We can perhaps think about this a bit more holistically.

Joined channels, and subsequently the NAMES list (which might indicate to clients nicks that are online), and modes of those channels
Prior ISUPPORT state
AWAY state
MONITOR state (possibly connected to ISUPPORT, however reconnecting to server could leave client thinking it is monitoring something it is not anymore) - ties into #1725
User's hostmask (unsure, clients might update from other numerics).

User mode seems to be one of the things which is updated upon disconnect along with capabilities (providing cap-notify was used). Some clients might already have logic to reset some of these states in 001 welcome numeric such as resetting isupport/away state.

I think this is a bit of a larger problem than just away, there's various states that a client may have which are not reset upon disconnect, or new connection. We can perhaps think about this a bit more holistically. - Joined channels, and subsequently the NAMES list (which might indicate to clients nicks that are online), and modes of those channels - Prior ISUPPORT state - AWAY state - MONITOR state (possibly connected to ISUPPORT, however reconnecting to server could leave client thinking it is monitoring something it is not anymore) - ties into #1725 - User's hostmask (unsure, clients might update from other numerics). User mode seems to be one of the things which is updated upon disconnect along with capabilities (providing cap-notify was used). Some clients might already have logic to reset some of these states in 001 welcome numeric such as resetting isupport/away state.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#950