ircv3-specifications
ircv3-specifications copied to clipboard
ircv3
nick=accountname in PRIVMSG/NOTICE
This was discussed briefly last night or the night before. Basic idea is allowing users to send queries to nick=accountname instead of just nick, similar to the nick@server format that has been used before.
If =accountname doesn't match the services account of the nick the message is being sent to it should be rejected with an error.
The account-tag CAP is using (at the time of writing this) the !service account name for network-based services. If that is accepted then it should be used in this as well for conformity.
Since this doesn't require any additional client support a CAP to support it is unneeded. It should be denoted in the 005 numeric as ACCOUNTMSG for servers that support this.
Edit :: SECUREMSG was renamed to ACCOUNTMSG due to the CAP that was going to use that name being renamed to account-tag
SECUREMSG is misleading and I don't see why you'd do this. If you really need to ensure identity, why not just use MemoServ? Or, if you have to PM them directly, =accountname is more appropriate, considering people who are going to make use of this are most likely going to WHOIS first.
It was intended to work in the case of mid-conversation ping timeouts, obviously people usually /whois before messaging but they don't continually /whois during the conversation.
I agree SECUREMSG could be a better term, I'm open to suggestions for that.
I'd rather leave services accounts out of this and let the IRCd do it on a pure IRCd level which would work for both identified and unidentified users. It does not require major protocol changes, would be as simple as your solution but more general.
A problem with this is, how would you handle multiple users authenticated to the same accountname?
Well from the original idea, it'd be nick=accountname, so the message would only go to a specific nick regardless of other nicks being authenticated to the same account.
oh, that is kind of interesting. i might have to play with that in tethys soon.
Updated the initial post about using ACCOUNTMSG in the 005 numeric instead of SECUREMSG, since the current account-msg cap is being renamed to account-tag