-
Notifications
You must be signed in to change notification settings - Fork 80
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 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?
There will be soon™. I just need to finish up a few things. |
I don't see anything wrong, but I feel like I would probably do something like |
Would it be possible to rename a channel from Awfully ircd specific, but perhaps worth mentioning in a security or nonnormative section. |
To quote @SaberUK from IRC:
|
If a more specific error like Should they send both 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 |
extensions/rename.md
Outdated
Server implementations MUST implement a fallback method for legacy clients. | ||
This method SHOULD involve sending a fake `PART` message for the old channel | ||
name and a `JOIN` message for the new channel name as well as a `MODE` message | ||
to restore any prefix modes that the legacy client has applied to it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like this should be specified in greater detail as a normative thing. Should the PART
message be the reason specified by the sending user, and include the name of the user who sent the rename request? It seems like they should also send the NAMES
message and TOPIC
ones if they normally send those, or it could even say something like 'just send everything as though it were a regular channel join' perhaps?
Specifying this in more detail might help reduce any possible confusion around here, and make sure servers stay consistent with how they implement it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As with the MODE
for sending prefix modes, what about modes that exist otherwise, such as prefix ones such as +b
and +f
(ban and forward) and all other possible channel modes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd probably just send everything you'd normally send on a client joining the channel. Name lists, channel modes and all. If you'd normally send it, cool. If not, I'd leave it out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, the standard channel join burst is definitely required here, NAMES, TOPIC, etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed, will push shortly.
Yeah, thats what my implementation sends. I'll amend the spec in a bit. |
I think that should be everything other than deciding what numerics are to be used. |
extensions/rename.md
Outdated
## 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should the PART reason should contain the RENAME reason?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, i'll add that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shouldn't it also contain the new channel name?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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).
Implemented in BitBot: bitbot-irc/bitbot@6d742f6a |
Implemented (minimally) in Moon Moon: wiseguiz/Moon-Moon@504e354 |
This is implemented in Oragono (has been since 0.8.1 - 2017-06), but there's been a faaair few spec updates since then, will update to match the latest state of the PR. |
Implemented in IRCCloud too. Spec still needs some adjustment, my prior review requesting changes still stands fwict. |
|
||
## Implementation Considerations | ||
|
||
Server implementations MUST implement a fallback method for legacy clients. This method MUST 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Prompted by ergochat/ergo#300 (comment)
MODE isn't needed here. Prefix modes come from NAMES, and the channel mode is not normally included in a join burst, clients will request it on join.
(Edit to add a one-click suggestion)
Server implementations MUST implement a fallback method for legacy clients. This method MUST 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 MUST implement a fallback method for legacy clients. This method MUST 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). |
As mentioned on IRC, it's probably a good idea to explicitly mention the possibility of a I feel like the requirement to provide a |
I think this would break clients that don't care about casing (such as my bot), whereas the PART/JOIN solution would most likely work on all clients. |
Such software is already broken as there is no guarantee the server will not change the case of a channel name (e.g. InspIRCd has a changecap module in extras). |
@SadieCat let me know if you want me to take this over to tidy it up? Not sure if it already allows edits from maintainers. |
It says "from unknown repository" so I think you gotta close this PR and open a new one with a new source repo. |
Replaced with #420 (blaze it) |
See <https://github.com/ircv3/ircv3-specifications/pull/420/files#diff-70e90beef48dc9cf5d784d1e179ea822R42> Moreover, make it so that clients that haven't negotiated `draft/rename` don't receive JOIN and PART messages. Rationale: <ircv3/ircv3-specifications#308 (comment)>
Rendered view here.