Channel detaching

[spb]

Something similar in principle to what bouncers like ZNC provide, but standardised enough to integrate into the client protocol.

The idea would be to specify the protocol messages/mechanism for detaching and reattaching, while leaving implementations free to make policy decisions on things like whether to support automatic re-attaching, notification of mentions in detached channels, and whether or how to make detached history available in channels that aren't otherwise publishing it.

[ValwareIRC]

Please could you elaborate with examples on how clients could take advantage of this? I read this a couple of times but didn't understand clearly

[emersion]

The bare minimum would one command to detach a channel. It would do the same as /quote detach #chan on ZNC (https://wiki.znc.in/Detaching) or /part detach on soju.

Once a channel is detached, the user is still a member of the channel, but the channel is no longer displayed in the channel list and the server no longer sends channel messages to the client. In other words, from the point of view of the server the user is still joined to the channel, but from the client point of view the user is not joined (the server hides the channel away from the client). When the client attempts to JOIN that channel again, it's re-attached (reverts to the normal behavior).

This is handy when a user is idling in many channels but isn't actively participating in discussions there. There are many possible use-cases, some with very low-volume channels (configured to auto-reattach when any message is sent), some with high-volume channels (configure to sent a NOTICE or auto-reattach on highlight).

An extension to detach from a channel could also feature a way to list all currently detached channels. If we have a proper extension to detach from a channel, servers wouldn't necessarily need to fake a PART for detached channels (ie, could be a channel mode or metadata).

[ValwareIRC]

Well, that sounds like something I'd use. Looking forward to seeing more on this.

[funderscore1]

I feel like this should probably be handled client-side instead of server-side.

[emersion]

If this is handled client-side, then it's not synced across all clients, and clients unnecessarily wake up (consumes power on mobile devices).

[NetworkJack2]

You can implement this entirely client-side without need to client-server protocol...

[nektro]

there are many parts in emersion's description that are not implementable client-only

[GoodClover]

How does this differ from a client & server implementing chat history?
Auto-reattach on highlight and similar can be implemented with the server joining the client to the channel normally.