Skip to content

Mention that servers may use ERR_NOSUCHCHANNEL instead of ERR_CHANOPRIVSNEEDED to conceal +s channels #247

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.

Sign up for GitHub

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

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Mention that servers may use ERR_NOSUCHCHANNEL instead of ERR_CHANOPRIVSNEEDED to conceal +s channels #247

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
34c541e
Mention that servers may use ERR_NOSUCHCHANNEL instead of ERR_CHANOPR…
progval Feb 20, 2025
b44e8d2
Mention ERR_NOTONCHANNEL too, as many servers do that
progval Feb 21, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions _includes/modern-appendix.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -149,6 +149,9 @@ This channel mode controls whether the channel is 'secret', and does not have an

A channel that is set to secret will not show up in responses to the {% message LIST %} or {% message NAMES %} command unless the client sending the command is joined to the channel. Likewise, secret channels will not show up in the {% numeric RPL_WHOISCHANNELS %} numeric unless the user the numeric is being sent to is joined to that channel.

Additionally, servers may return {% numeric ERR_NOSUCHCHANNEL %} instead of {% numeric ERR_CHANOPRIVSNEEDED %} to channel commands ({% message MODE %}, {% message TOPIC %}, {% message PRIVMSG %}, {% message NOTICE %}) to a secret channel from a user not on that channel.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TAGMSG too --- any others?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

idk, TAGMSG isn't mentioned elsewhere in the spec, and it seems obvious that TAGMSG should behave like PRIVMSG and NOTICE

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds like we need a section covering TAGMSG :-)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it a goal to import all IRCv3 specs into modern? I see some are mentioned but it's a bit random.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having two copies of the same documentation will inevitably go out of sync. I suggest to stick with referencing the (coherent & unambiguous) docs already on the ircv3 site.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jwheare my intention has usually been to update the base doc (e.g. syntax, formats, etc) wherever needed to explain the basics, then link off to v3 for the full story. E.g. in the Capability Negotiation section Modern gives an overview, but then says to refer to the actual spec for details:
image
image

Copy link
Member

@DanielOaks DanielOaks Feb 21, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On which ones to mention, I've always thought about it like "optimistic real use", like whether Modern mentions something or not depends on whether it's used in the real world by software today, with a lean towards being optimistic about v3 stuff.

My thought was always while it'd be great to include docs on e.g. most of the unambiguous stuff from 'defs' that'd just be... so much work... so that's why I stuck to the core-feeling things for the base Modern doc.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For PRIVMSG/NOTICE i'd stick with the documented 401 NOSUCHNICK, which commonly has the text "No such nick/channel". Note that 401 is already listed as a response to these commands in both rfcs (and consequently modern-irc as well), whereas 403 is not.

Both TOPIC and MODE already list 403 NOSUCHCHANNEL as a response on modern-irc.

So except for the suggestion, i'm ok.

This allows servers to further conceal the channel's existence silently (as the only other way to reveal a channel is then to {% message JOIN %} it, which notifies channel members on success).

### Protected Topic Mode

This mode is standard, and the mode letter used for it is `"+t"`.
Expand Down