-
Notifications
You must be signed in to change notification settings - Fork 3
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
Channel detaching #122
Comments
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 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. |
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.
The text was updated successfully, but these errors were encountered: