Recommend that server names contain a dot

[emersion]

No description provided.

[progval]

I don't think a particular numeric is the right place to document something as central as this.

What about a new section early in the document, to define identifiers? You could merge in this paragraph from https://modern.ircdocs.horse/#client-to-server-protocol-structure :

Names of IRC entities (clients, servers, channels) are casemapped. This prevents, for example, someone having the nickname 'Dan' and someone else having the nickname 'dan', confusing other users. Servers MUST advertise the casemapping they use in the RPL_ISUPPORT numeric that’s sent when connection registration has completed.

And also reference it from https://modern.ircdocs.horse/#source

[emersion]

It doesn't seem like there's consensus, @jwheare said on IRC they're not a fan of this.

[tommyrot]

Can't think of any public network that doesn't use a dot in their servername. It is helpful for software to distinguish server from user and likely expected in certain cases. The thing is, the servername is a variable in a config file of the server software for end users to control. Unless there's a comment in that config to explain the usage of a dot, they won't be aware of it (end users don't read ircdocs).

That said, i'm not opposed to this PR.

[progval]

When configured with a server name without a dot:

• Insp ignores it, and generates one (gethostname() and appends .local)
• Unreal exits with illegal me::name, must be fully qualified hostname
• Ergo exits with Server name must match the format of a hostname
• Charybdis and Solanum exit with error: "/tmp/tmpewy0npx9/server.conf", line 3: Ignoring serverinfo::name -- must contain '.' + error: no server name specified in serverinfo block.
• Hybrid crashes
• ngircd exits with No (valid) server name configured in "/tmp/tmposyync0k/server.conf" (section 'Global': 'Name')!

and I couldn't test irc2, ircu2, and bahamut for unrelated reasons; but they are each deployed on a single network these days, so it doesn't really matter.

According to ircstats, this covers at least 75% of all servers, which seems good enough for me.

[jwheare]

I’m not opposed to recommending servers do this, especially given current IRCd behaviour. But I don’t think it fully solves the issue of disambiguating servers from nicknames because of instances in the wild that I’ve seen servers allow dots in nicks (even if that’s invalid).

I don’t think presence of a dot is a safe or robust heuristic to always rely on and the way it’s stated here encourages people that it is.

[progval]

ugh, I didn't think of that.

Do these servers with dotted nicks always send a full NUH?

[jwheare]

They should do, but might not always, e.g. if znc is sitting in front of them.

I think regardless of where and how this occurs in practice, we shouldn't be encouraging clients to rely on this. I'd prefer encouraging an approach that doesn't label the source one way or the other. You can determine how you treat the source at the point of use. e.g. for commands like JOIN, NICK etc, it's always going to be a nick so you can always treat it as such.

[emersion]

There are edge cases where this approach doesn't work too well, e.g. PRIVMSG/NOTICE. These can come from a server or a user, and there's no good way to make the difference.

[jwheare]

Can you describe a situation where that matters much though? If, for instance, you have a client that does things like exposing certain actions on clicking a nickname when displayed alongside their message, like PMing/whoising them or whatever, then you can do one or either of:

1. check that the source is a member of the channel at the time of receipt (if it's a channel message)
2. only expose those actions if you have a full nuh

This might result in not offering those actions for a non-nuh nick in a private message, but given this an edge case that's probably acceptable. It's not like users won't be able to perform those actions in other ways (slash commands etc)

[emersion]

Here's an example:

1. A bouncer is set up to connect to Libera Chat.
2. Upon connecting, the bouncer receives Libera Chat's "looking for ident" NOTICEs from e.g. strontium.libera.chat. It stores the NOTICE in its chathistory database.
3. A client connects to the bouncer, queries CHATHISTORY TARGETS, receives information that there are new messages sent by strontium.libera.chat. It queries the new messages.
4. The client receives the NOTICEs, and has no idea that they come from a server. It may open a new tab for this "conversation", may send a WHO command to fetch user details (realname, away status, account, etc). Note, the WHO command returns the list of all visible users on the server, which isn't ideal.

only expose those actions if you have a full nuh

Not really an option, the full NUH is optional for user messages, and some servers can omit it, especially when sending chathistory.

It's not like users won't be able to perform those actions in other ways (slash commands etc)

My mobile client doesn't have slash-commands, and I don't want to force users to know about slash-commands to be able to use IRC.

[jwheare]

I'm just going to leave it at my earlier comment "I’m not opposed to recommending servers do this". This PR is fine.

[emersion]

What about a new section early in the document, to define identifiers?

Hm, I'm not sure. There are already sections named "channel", "server" and "client". The one about channels describes the allowed characters. The one about clients says: "See the protocol grammar rules for what may and may not be used in a nickname" (but the document never actually defines the nickname in the grammar, see #157). So maybe it would make sense to describe the server/client name rules inside these existing sections?

[emersion]

Moved to the "server" section, let me know what you think.

[emersion]

Gentle ping, what do you think of this version @progval?