-
Notifications
You must be signed in to change notification settings - Fork 36
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
Distinguishing servernames from bare nicknames in source prefixes #227
Comments
There is no reliable way to know. The convention is to use names with a dot for server names, and names without dots for nicknames. But it's just a convention. |
I've considered adding a vendor tag for differentiating messages from servers but without universal support it doesn't really make sense. |
I believe it would still help if there is a cap guaranteeing that all server messages will carry the tag. Clients could disable their heuristic in that case. |
The wording in this repo regarding nick and servernames is weak unfortunately. In reality servernames must contain a dot and nicknames must not contain a dot. See also related discussion in #148 As for your second point: some commands allow a user to request information from a different server on the network as one is connected to, thus the reply will indeed be of that other server. |
If a client receives a message whose source does not contain either
!
or@
, are there any rules that could be included in this spec for determining whether the source is a servername versus just a "bare" nickname?I assume that servernames are supposed to be internet hosts (i.e., a domain name or IP address), but, as far as I'm aware, there's no rule against a nickname also being a valid host (though https://modern.ircdocs.horse/#clients states that nicknames "SHOULD NOT contain any dot character").
At first, I thought that servername prefixes are supposed to always equal the name of the server that the client is connected to, and that they remain the same throughout a connection, but this would make servername prefixes pretty much superfluous, and the statement that "The source indicates the true origin of a message" somewhat suggests that a source could be the name of another server in the network.
The text was updated successfully, but these errors were encountered: