Malformed command when '.' in source field

[rockorager]

Issue

If a server sends a command like:

:foo.bar JOIN #baz

Halloy will log an error:

11:18:58.464:ERROR -- [apollo] Malformed command: JOIN("#baz", None)

If the '.' is removed from the nick, the command succeeds, ie

:foobar JOIN #baz

Will succeed

I assume this is not a bug in the message parsing of the source param...server names often have a '.' in them, so possibly it's higher up the stack in nick resolution or something? I've only just started poking around the codebase.

[rockorager]

I did a bit more digging. The issue is that halloy parses source and expects a User or a Server. the source foo.bar fails at parsing as a User, so is parsed as a Server.

The User parsing allows a '.' but only if there is also a username + host portion. For example, this test passes:

            (
                ":foo.bar!foo@localhost JOIN #bar\r\n",
                Message {
                    tags: vec![],
                    source: Some(Source::User(User {
                        nickname: "foo.bar".into(),
                        username: Some("foo".into()),
                        hostname: Some("localhost".into()),
                    })),
                    command: Command::JOIN("#bar".to_string(), None),
                },
            ),

And likewise, when I modify my server to send a username and host when there is a '.' in the there is no more error in the log. However, halloy still doesn't allow the client to join the channel[0]. There are comments in the code about a workaround for matrix bridges which have both : and . in the nick portion - if I add a : to the nick, the JOINed channel appears in the message list

I don't know where in the codebase to go next to find out why that channel isn't showing up, but I'm guessing there is some "split on : logic? Would it be possible to modify that logic such that if there is a '.' but no ':', the entire thing is taken to be the nick?

[0]: By allow, I mean show the channel in the channel list. Everything according to server logs and client logs show that the JOIN was successful, it's just the channel doesn't appear in the sidebar.

[andymandias]

From what I'm familiar with (e.g. IRCdocs) the prefix of a JOIN command should be a username, in which a dot character is forbidden. Those expectations are probably the proximate cause of why things are weird, as you've discovered. (This is not to say Halloy can't change to be more accommodating in this regard, just trying to provide context.)

I haven't worked through the implications of your suggested workaround yet, but a suggestion re: your channel issue: the JOIN messages received are compared to what Halloy thinks your nickname is in order to distinguish between JOIN messages for other clients and JOIN messages for itself (see the match for Command::JOIN inside handle in data/src/client.rs).

[rockorager]

the prefix of a JOIN command should be a username, in which a dot character is forbidden.

Yes, I was heavily relying on the SHOULD in SHOULD NOT use .. I am reconsidering the usage of a dot in a nick for my use case :/

[rockorager]

To add to that, I've generally considered the interpretation of source to be context dependent on the actual command. IE, JOIN is always a username, PRIVMSG is always a username, 001 is always a server, etc. I haven't come across one which is ambiguous for the interpretation of the source of the command.

[andymandias]

Apologies, I think I may have been unclear previously: I did not intend the references above to be a statement of "this is wrong/unworkable (so we won't support it)". I was trying to explain the viewpoint I think that parsing code is coming from, in the hopes that it would be helpful to your efforts. (In particular, that we'll need to make sure those same assumptions are not relied upon elsewhere.)

Even if IRCdocs did state that a nickname a MUST NOT use ., which as you correctly point out it does not, that would not preclude it being allowed in Halloy. If users need it, then it should be accommodated regardless (barring some unforeseen implementation difficulty).

Is there a public instance of your server that can be used for testing?

[rockorager]

Thanks for the clarification! I sent you details on IRC for logging into an instance for testing.