ircv3-ideas
ircv3-ideas copied to clipboard
ircv3
Channel detaching
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.
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
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).
Well, that sounds like something I'd use. Looking forward to seeing more on this.