IRCX / MSN Chat - Pre 2000 was more advanced than you might think...

[realJoshByrnes]

Let me flog a dead horse, and note some of the interesting things that MSN Chat had that I believe IRCv3 could benefit from (or could at least be a discussion point)...
Some of these may be implemented already, and I'm not aware of them. If this is the case, sorry. I'm not suggesting that these be implemented exactly as per IRCX/MSN, just that they are very useful and worth discussion.

MSN Chat was based upon the IRCX Draft. It's important to note that the IRCX Draft was not updated since June 1998, and MSN Chat kept pushing forward with updates in a proprietary manner. I think understanding how MSN Chat had pushed forward may help us see a way forward with IRCv3.

❌ACCESS command
IRCX (Section 5.1) supports adding ACCESS entries.
eg /access John ADD DENY *!*@* would disable anyone from contacting John
Additionally, it could be used to add access to channels in the form DENY, GRANT, VOICE, HOST, OWNER. ACCESS could bypass keys (for positive access)
Adding DENY access to a channel worked identically to CHMODE +b, with the exception that a reason could be added.

✅ AUTH command
The AUTH command is well defined in the IRCX draft, although it is not opinionated on which SASL authentication methods could be used. IRCv3 has implemented a suitable alternative.

✅AWAY command
The IRCv3.1 Away-Notif spec offers a somewhat suitable alternative to what MSN did.
Limitations: Away-Notify offers no way of being able to differentiate between if a user joined the channel and was already away, and if the user joins the channel, then uses the AWAY command. It also offers no notification when joining a channel of who is away, and the draft suggests using the /who command to get this information. I'm not sure why it wasn't suggested that the server automatically send a WHO reply on behalf of the client when joining a channel and had Away-Notify set active.
MSN used an extended JOIN / NAMES (see below, which was able to show this information, as well as others)

❌REDIRECT message
While it may seem limited, this is an amazing command for an IRC Admin. It's very useful for load balancing (and moving geographic users to their closest server). Additionally, it is very useful when a server is taken offline for maintenance.

❌ONJOIN (privmsg) / ONPART (notice) messages
When a user JOINS or PARTs a channel, they would receive a message from the channel if an onjoin/onpart message was set. This was set using the PROP command. Notably, messages could be split when set by escaping using \n.
ie. Channel operator setting ONJOIN message
PROP %#Channel ONJOIN :Welcome to our channel\nI hope you enjoy your stay
User receiving ONJOIN message
:%#Channel PRIVMSG %#Channel :Welcome to our channel
:%#Channel PRIVMSG %#Channel :I hope you enjoy your stay

❌Standard escaping
The IRCX draft notes a standard escaping sequence, although it should be noted that \0 was used to represent NUL in later revisions, so that the AUTH command could use all 256 bytes.

              \b            " " (blank)
              \c            ","
              \\            "\"
              \r            CR
              \n            LF
              \t            TAB

IRCv3 has worked around this with various methods, such as using base64 encoding (>25% extra data), as well as using other escaping methods such as the one defined in IRCv3 Message Tags. I believe it would be beneficial to create a standard escaping sequence that MUST be used where practical.
eg. Both message tags, as well as authentication could have used the same table above (including \0).

❌Extended channel keys
As well as a normal channel key, it was possible to specify an OWNERKEY or HOSTKEY, which would not only allow the user to join the channel, but to receive a specific mode (+o/+q) in this case. These were set using the IRCX PROP command. eg. PROP %#Test OWNERKEY :ThisIsThePassword. Setting a key to '' (null) would render it unusable.

❌Self reference
IRCX defines the dollar symbol ($) as a server prefix. ie $irc.example.com, but when it is used by itself rather than a prefix, it specifies the current client/server. This allows you to send commands without knowing your nickname.
eg. On connect, where a nickname is often forcibly changed by a server, you need to establish that nickname before you can set a MODE. By using $, it does not matter which nickname you use. MODE $ +i would allow you to set invisible mode on yourself.

❓Longer/Unicode nicknames and channel names
Although there was some suggestion in the IRCX draft, this was later changed to assume universal support by clients. As far as I'm aware, most/all clients will support this automatically, and did pre-year 2000.

❌Extended JOIN/NAMES reply
When sending a JOIN message, MSN Chat would specify the status of the user.
:Nick!User@Host JOIN H,U,RXB %#Test. The same prefix was also used on NAMES replies eg H,U,RXB,@Nickname, which interestingly, would be compatible with both IRCv3.1 Multi-Prefix and IRCv3.2 Userhost-In-Names
The format for H,U,RXB was as follows:

• Here | Gone (Away Status)
• User | Guide | Sysop | Admin (Guide/Sysop/Admin were all different levels of IRC operator)
• Male | Gender Neutral/Not Specified (P) | Female | No Profile (R)
• Has Picture (Y) | No Picture (X)
• Subscriber (B) | Non Subscriber (O)

The gender and picture fields would be set to a singular G if the user was a Guest

[DanielOaks]

Definitely, it's always worth looking at how others have extended things! We've tried to do this somewhat but especially because of the age some things don't translate as well, this writeup's a nice summary.

On the Access point in particular, there are some questions around whether we also incorporate accounts into any sorta system. I've been throwing ideas around for a 'buddy list' system, though that's also to help with nickname discovery when first joining a network and all.

On the Unicode nicks and channel names I've got ircv3/ircv3-specifications#272 underway. The main issue with just pushing forward with it without worrying about casemapping is that you can very easily get identifiers which look identical unless you're very careful. I'm keeping the work going on that PR but the main consensus on how we're gonna push forward is the display-name metadata key (some more info over here), which bypasses the protocol identifier (the nick / channel name itself) needing to be totally unique. Kinda like Discord users' display names vs their full tag.

The escaping point is an interesting one. There's a rough tracking ticket here but the idea (or at least mine) is to create a separate doc that identifies and lays out the methods, then we just reuse those always rather than creating new ones. We're always somewhat doing it in e.g. the WebIRC options parameter, but having it fully split-out would be useful. In terms of other general escape methods, I don't think it'd be worth creating any new ones (we've already got like 3, 4, 5? using less custom parsey encodey escapey stuff would definitely ease implementation), even if \0 can't be represented by some of the existing methods.

Redirection is definitely useful. ircv3/ircv3-specifications#330 is cool but hasn't seen too much activity for a while, and on a tangent we've got ircv3/ircv3-specifications#306 which solves a lot of the same things protocol-wise. Def need to look at migrate some more.

Thanks again for opening the issue! Hopefully that's a reeeasonable writeup of where v3 generally is on those at the moment, definitely interested in all of these :)

[edk0]

Implicit WHO on join would be a good way to kill clients who join a lot of big channels.

[kythyria]

Re the OnJoin/OnPart thing: the former is supported by some services packages, but not in a standard way. It's also tripped up by the peculiar behaviour of NOTICE messages: the rules for where they go are neither consistent between clients nor necessarily particularly obvious.

There might be cause to standardise a metadata key for channel greetings, or some other mechanism for setting them.

NOTICE is probably a lost cause by now, but there's some use for what I've seen called "whispers": A message which is routed to one specific user or even client, but which arrives at its destination in such a form as to remain associated with a particular channel or DM. Besides greetings, the most obvious application is bots for playing games with imperfect information (werewolf/mafia, poker, etc).

I might send

WHISPER ozjd #ircv3 :You are now a werewolf

and you might see

@whisper :Kythyria PRIVMSG #ircv3 :You are now a werewolf

[realJoshByrnes]

@DanielOaks I'd strongly encourage you to take a look at the OID feature in the draft. It was not used on MSN, but certainly has its benefits. There was a similar feature in ConferenceRoom's IRCd. Rather than a per connection OID, you could re-assign it on user login, and therefor the target would become available. Once logged in, MSN Chat would assign you a username/hostname such as ozjd!28F444FD9BCA2BAB@GateKeeperPassport (this was specific to GateKeeper authentication using a Microsoft Passport. Other authentications might specify their own addresses. It's important that a user (including an IRC Operator) MUST NOT be able to set their mask to that of an existing user.

As for the buddy list
Add someone to friend list: ACCESS $ ADD GRANT GoodUser!Username@Host
Add someone to block list: ACCESS $ ADD DENY BadUser!Username@Host
If you want anyone to be able to message you: ACCESS $ ADD GRANT *!*@*

@edk0 I do see your point, but according to the away-notify spec, you'd still to receive the same amount of traffic for it to be of any serious use. This is why I like the (MSN) way of pre-pending the NAMES reply.

@kythyria The idea behind the NOTICE command was simple... It was meant to be used by bots for replies to prevent a loop. Unfortunately, It didn't really work out that way, with the exception of the client CTCP / CTCPREPLY implementations, which usually isn't fully implemented in clients as per spec.

Also, the idea behind WHISPER (also introduced in IRCX I believe) was to be able to create context, and be able to limit controls.
Usually, it would look like this:
WHISPER ozjd #ircv3 :You are now a werewolf
and the recipient would receive:
:Kythria!user@host WHISPER #ircv3 :You are now a werewolf
A non-IRCX client would receive a standard PRIVMSG
:Kythria!user@host PRIVMSG :You are now a wereworlf

Adding context allows you to do a few things...

• Decide where the information should be displayed (as you mentioned)

• Clients such as mIRC already support the WHISPER message, and will display it in the channel, rather than in a Query window.

• Limit channel Whisper support

The channel mode 'w' will disable whispers between ordinary members of the channel (but not whispers from or to channel operators).

• Preventing spam
  All users are required to be in the same channel for the message to be received

Where a channel mode +w is supported, PRIVMSG/NOTICE should be modified to only allow messages if the users are on an a common channel where 'w' is not set, or a user is a Channel Operator.

[sadiepowell]

Is the self reference actually necessary? I can't speak for others but InspIRCd does not ever forcibly change the nicks of users during registration. In cases where someone takes their nick before they finish connecting we send ERR_NICKNAMEINUSE. Additionally, clients can retrieve their nick from the numeric messages they receive on connecting to the server.

[a-v-s]

The IRCX WHISPER command reminds me of the channel-context tag ( https://ircv3.net/specs/client-tags/channel-context )

The equivalent of receiving

:Kythria!user@host WHISPER #ircv3 :You are now a werewolf

would be

@+draft/channel-context=#ircv3 :Kythria!user@host PRIVMSG ozjd :You are now a werewolf

[NetworkJack2]

we really need to standardized /nickserv /chanserv /opserv /memoserv their subcommands and syntax as part of RFC. If its optional.

We need tighter integration between services and ircd.