commit e740d952add17488e3eef8fc19316d444a67a08d Author: Hubert Hirtz <firstname.lastname@example.org> Date: Thu Aug 20 10:00:58 2020 +0200 Reject downstream NICK with illegal characters This should avoid confusion when mixing up nickname and user name. Also it avoid breaking downstreams (since '@' and '!' are used for host masks).
It works on my machine™:
21:54 DEBUG OUT -- NICK taiite/sr DEBUG IN -- :email@example.com NICK taiite -- taiitest→taiite
Though I'm not sure if it should change the connection NICK in multi-upstream mode. Sending back a ":nick NICK nick" would be more intuitive.
FTR, here is why those characters are considered illegal in soju:
:break message framing,
!break message prefixes,
?are used for masks (e.g.
WHO emer*). I believe clients can cope with such characters but they could be confusing for the user,
/is used as the network separator in soju.
/can be considered legal. soju and IRC clients are expected to work with the NICK containing such character. However, I put it in the list because some users were swapping the username (first parameter of USER) and the nickname (parameter of NICK) when connecting to soju. They expected such registration:
NICK hhirtz/chat.freenode.net USER taiite 0 * :Real name
to enable the single-upstream mode with
chat.freenode.net. The result, however, is that soju enables the multi-upstream mode and uses
hhirtz/chat.freenode.netas the connection nickname.
The result, however, is that soju enables the multi-upstream mode
Incorrect. soju supports specifying the network name in the nickname for clients that don't allow configuring the nickname and username separately.
It turns out you're right, correction:
- soju will only parse the network name from the username
- However, soju will disregard the nickname used while registering the connection, and reset it
Another argument against making
/legal: conflicts between the connection nickname and other users' nicknames.
If a users define a network named
fnand connects to soju with multi-upstream mode, you don't want to allow the connection nickname to end with
/fn. For example:
PASS pass NICK ddevault/fn USER sojuuser 0 * : soju user JOIN #sr.ht/fn ???
RPL_NAMREPLYwill have two
If you want soju to allow
/, then it'll need to check that what's later isn't a network name.
you don't want to allow the connection nickname to end with /fn
This is addressed by:
soju will disregard the nickname used while registering the connection, and reset it