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

[WIP] Channel renaming extension. #308

Open
wants to merge 1 commit into
base: master
from

Conversation

@SaberUK
Contributor

SaberUK commented Jun 3, 2017

@jwheare

👍 looks good. Maybe a non normative suggestion for servers to optionally apply temp forwarding from old chan to new chan to aid migration for users offline when the rename happened?

Is there a reference implementation for inspircd?

@SaberUK

This comment has been minimized.

Show comment
Hide comment
@SaberUK

SaberUK Jun 4, 2017

Contributor

Is there a reference implementation for inspircd?

There will be soon™. I just need to finish up a few things.

Contributor

SaberUK commented Jun 4, 2017

Is there a reference implementation for inspircd?

There will be soon™. I just need to finish up a few things.

@Zarthus

This comment has been minimized.

Show comment
Hide comment
@Zarthus

Zarthus Jun 4, 2017

I don't see anything wrong, but I feel like rename is kind of generic of a keyword and won't really scale if you ever expand this idea. Let's say in the future you want to tack on the ability to archive (read-only) channels or close them down entirely. To be consistent with this format you'd need to reserve ARCHIVE and CLOSE, and /close already is an alias in many IRC clients.

I would probably do something like CHGCHAN (consistent with CHGHOST) or CHANRENAME, and I agree it is bikeshedding to some degree, but it's something that should at least be mentioned if you want to expand this idea to the degree Slack already has.

Zarthus commented Jun 4, 2017

I don't see anything wrong, but I feel like rename is kind of generic of a keyword and won't really scale if you ever expand this idea. Let's say in the future you want to tack on the ability to archive (read-only) channels or close them down entirely. To be consistent with this format you'd need to reserve ARCHIVE and CLOSE, and /close already is an alias in many IRC clients.

I would probably do something like CHGCHAN (consistent with CHGHOST) or CHANRENAME, and I agree it is bikeshedding to some degree, but it's something that should at least be mentioned if you want to expand this idea to the degree Slack already has.

@Zarthus

This comment has been minimized.

Show comment
Hide comment
@Zarthus

Zarthus Jun 4, 2017

Would it be possible to rename a channel from #chan to !chan? On some IRCds this means the channel serves a different function and clients may not wish to adhere to channel redirection (let's say #chan is a normal channel and !chan is opless mode which does not support founders).

Awfully ircd specific, but perhaps worth mentioning in a security or nonnormative section.

Zarthus commented Jun 4, 2017

Would it be possible to rename a channel from #chan to !chan? On some IRCds this means the channel serves a different function and clients may not wish to adhere to channel redirection (let's say #chan is a normal channel and !chan is opless mode which does not support founders).

Awfully ircd specific, but perhaps worth mentioning in a security or nonnormative section.

@RyanSquared

This comment has been minimized.

Show comment
Hide comment
@RyanSquared

RyanSquared Jun 5, 2017

Would it be possible to rename a channel from #chan to !chan?

To quote @SaberUK from IRC:

2017-06-04 09:23:12 SaberUK Zarthus: i'm thinking it should be a SHOULD NOT for servers

RyanSquared commented Jun 5, 2017

Would it be possible to rename a channel from #chan to !chan?

To quote @SaberUK from IRC:

2017-06-04 09:23:12 SaberUK Zarthus: i'm thinking it should be a SHOULD NOT for servers

@DanielOaks

This comment has been minimized.

Show comment
Hide comment
@DanielOaks

DanielOaks Jun 5, 2017

Member

If a more specific error like ERR_CHANOPRIVSNEEDED can be sent in response to a rename request, what should servers do?

Should they send both ERR_CHANOPRIVSNEEDED followed by ERR_CANNOTRENAME, and similar for ERR_CHANNAMEINUSE. It seems appealing for clients/bots to be able to expect either a RENAME command or a ERR_CANNOTRENAME numeric in response, to know for sure whether it failed or succeeded.

Plays into the questions brought up in IRC around how to alert for errors with specific commands in general going forward. I'm just using the existing ERR_UNKNOWNERROR in my hacked-up impl, which includes the original sent command in it.

Member

DanielOaks commented Jun 5, 2017

If a more specific error like ERR_CHANOPRIVSNEEDED can be sent in response to a rename request, what should servers do?

Should they send both ERR_CHANOPRIVSNEEDED followed by ERR_CANNOTRENAME, and similar for ERR_CHANNAMEINUSE. It seems appealing for clients/bots to be able to expect either a RENAME command or a ERR_CANNOTRENAME numeric in response, to know for sure whether it failed or succeeded.

Plays into the questions brought up in IRC around how to alert for errors with specific commands in general going forward. I'm just using the existing ERR_UNKNOWNERROR in my hacked-up impl, which includes the original sent command in it.

@SaberUK

This comment has been minimized.

Show comment
Hide comment
@SaberUK

SaberUK Jun 6, 2017

Contributor

If a more specific error like ERR_CHANOPRIVSNEEDED can be sent in response to a rename request, what should servers do?

Yeah, thats what my implementation sends. I'll amend the spec in a bit.

Contributor

SaberUK commented Jun 6, 2017

If a more specific error like ERR_CHANOPRIVSNEEDED can be sent in response to a rename request, what should servers do?

Yeah, thats what my implementation sends. I'll amend the spec in a bit.

@SaberUK

This comment has been minimized.

Show comment
Hide comment
@SaberUK

SaberUK Jun 25, 2017

Contributor

I think that should be everything other than deciding what numerics are to be used.

Contributor

SaberUK commented Jun 25, 2017

I think that should be everything other than deciding what numerics are to be used.

@jwheare jwheare added this to the Roadmap milestone Aug 9, 2017

@jwheare jwheare added the protocol label Aug 9, 2017

Show outdated Hide outdated extensions/rename.md
Show outdated Hide outdated extensions/rename.md
@jwheare

Cool, I think anything in "considerations" sections that involves normative MUST, SHOULD or MAY directives would be better further up in an "Details" section, above examples.

I feel like considerations are usually for non-normative stuff, and implementation details, where I would use lowercase "might" instead of MAY.

Even the MAY stuff in here is probably normative rather than a consideration. E.g. specific error numerics reserved for moderation/permission stuff MUST be used but only if the server is actually performing the validation in question (it MAY choose not to).

Server implementations MUST implement a fallback method for legacy clients. This method SHOULD involve sending the legacy client a `PART` message for the old channel name, with the rename reason as the part message if given, followed by the usual messages that would be sent if the legacy client had joined the new channel normally (`JOIN`, `RPL_TOPIC`, `RPL_NAMREPLY`, etc) and finally a `MODE` message to restore any prefix modes that the legacy client has applied to it.
Server implementations SHOULD implement `JOIN` redirection from the old channel to the new channel for as long as is deemed necessary.

This comment has been minimized.

@jwheare

jwheare Jan 22, 2018

Member

JOIN redirection is probably a MAY, "as long as is deemed necessary" is a bit wooly for a SHOULD anyway.

@jwheare

jwheare Jan 22, 2018

Member

JOIN redirection is probably a MAY, "as long as is deemed necessary" is a bit wooly for a SHOULD anyway.

## Implementation Considerations
Server implementations MUST implement a fallback method for legacy clients. This method SHOULD involve sending the legacy client a `PART` message for the old channel name, with the rename reason as the part message if given, followed by the usual messages that would be sent if the legacy client had joined the new channel normally (`JOIN`, `RPL_TOPIC`, `RPL_NAMREPLY`, etc) and finally a `MODE` message to restore any prefix modes that the legacy client has applied to it.

This comment has been minimized.

@jwheare

jwheare Jan 22, 2018

Member

Any reason this fallback is a SHOULD and not a MUST? How else might a server implement it?

@jwheare

jwheare Jan 22, 2018

Member

Any reason this fallback is a SHOULD and not a MUST? How else might a server implement it?

Server implementations SHOULD implement `JOIN` redirection from the old channel to the new channel for as long as is deemed necessary.
Server implementations SHOULD implement a cooldown system to prevent abuse.

This comment has been minimized.

@jwheare

jwheare Jan 22, 2018

Member

Probably can be MAY as well.

@jwheare

jwheare Jan 22, 2018

Member

Probably can be MAY as well.

Server implementations that link across a network MUST take measures to prevent channel name collisions. An example of such a method would be to use channel identifiers similar to how user identifiers are used to prevent nickname collisions in server-to-server protocols.
Server implementations SHOULD limit the renaming of channels to privileged individuals in order to prevent abuse.

This comment has been minimized.

@jwheare

jwheare Jan 22, 2018

Member

Also MAY I'd say.

@jwheare

jwheare Jan 22, 2018

Member

Also MAY I'd say.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment