ircv3-specifications icon indicating copy to clipboard operation
ircv3-specifications copied to clipboard

new irc server protocol "multi-nick" capability

Open highflyer77 opened this issue 9 years ago • 6 comments


title: "irc server protocol "multi-nick" capability" layout: spec work-in-progress: true copyrights:

name: "highflyer77"
email: "[email protected]"
year: 2016

Introduction

Allows users to use multible nicks on single server login instance.

Motivation

Many times a user would like to be able to specify a different nickname depending on the channel that they are currently using.
Some would call this activity role-playing, and is a very common thing to do using irc. Freenode and others allow you to have multiple nicks and group them together under one account.
The reasons they allow you to do this are the same. So instead of changing nicks and changing it for all currently joined channels, this would allow you to join a channel using a specific registered nick, and resuming to be another nick in the other channels.
One of the side benefits this could provide is less frequent nickchange notices being shown to the other users.

Architecture

This was discussed on #ircv3 several days ago and it seemed there could be different ways of implimenting it, one of them was using: intents, tags, etc.

Client Commands

/join #channel -nick foo2

Server Commands

JOIN <#channel> [-nick nick]

Channel Modes

This specification defines no channel modes.

User Modes

This specification defines no user modes.

Examples

see commands above.

Security Considerations

There are no security considerations that implementations should note when implementing this specification.

Alternatives

There are none that exist.

Errata

  • This is using the new proposed template for new feature requests, please let me know if I should remove the irrelevant parts, or if I should make any adjustments to the other parts.

highflyer77 avatar Feb 19 '16 01:02 highflyer77

Here is a security consideration for you: When I'm doing /msg nick hi, how can I know that the right person receives it, and not someone else with the same nick?

DarthGandalf avatar Feb 19 '16 07:02 DarthGandalf

I'm not so sure that adding a fifth name field is a good idea.

P.S. that specification template is intended for use as a file in a pull request not for being pasted into issues.

SadieCat avatar Feb 19 '16 07:02 SadieCat

Simply based on how complex this makes the protocol, and the sort of information tracking and hacks that servers and clients would need to do based on it, I think this proposal is a very bad idea and would bring up lots of security issues.

However, if this behaviour is desired (I know it is for RP), I think the 'name' intent that was recently discussed in the channel would be a much better way to go about it. Along with removing those security questions since the same nick is being sent over the wire, that also allows people to change their desired name for each message with less hassle, which is better for RP purposes.

I'd vote to close this and focus on that intents stuff instead.

DanielOaks avatar Feb 19 '16 08:02 DanielOaks

I'm not sure if intents are right here, but either way, +1 for having this as a per-message tag instead of low-level hackery.

grawity avatar Feb 19 '16 09:02 grawity

This can be achieved with 3.3 client-only tags now. Intents are dead as of #270

FWIW twitch uses a display-name tag for this, sent with every message. https://github.com/justintv/Twitch-API/blob/master/IRC.md#privmsg

jwheare avatar Sep 05 '16 07:09 jwheare

I'd like to add, a number of IRCds already support this functionality (through bundled or community modules) with the roleplay commands roughly described here (I've still got a number of things to update and fix with that spec, but the basic commands and how they work applies). Either that or client-only tags would work best for this.

DanielOaks avatar Nov 07 '16 02:11 DanielOaks