Accounts as a target

[Herringway]

The ability to specify an account instead of a nickname would be convenient. For example, !bar would refer to anyone authenticated as bar - PRIVMSG !bar :Hello! would be delivered to everyone logged into the bar account.

This would be useful for things like opping a particular authenticated user or sending private messages that are guaranteed to be delivered only to someone logged into the right account.

A server could advertise support for this via an ISUPPORT token.

[Herringway]

It would also work really well with the MONITOR command.

[SadieCat]

How would a server handle a message sent to an account with multiple IRC users logged into it?

[Herringway]

I would expect the message to be delivered to each user.

[grawity]

In the earlier @deliver-to=foo PRIVMSG foobar and @deliver-to=foo PRIVMSG * ideas, the latter would multicast to all matching clients... In XMPP, if I remember correctly, a message send to foo@bar (without a /resource) is also multicast to all clients, only explicit foo@bar/myclient is unicast.

[slingamn]

I like this a lot. I love IRC exceedingly but the whole concept of a nickname feels legacy / deprecated to me; almost any time I work with nicknames, I'd rather be working with accounts instead.

My one reservation about this is that I'm also interested in a mechanism that would deliver a message to a specific nickname (understood in this context as a session identifier similar to a Jabber Resource), but only on the condition that it's actually logged into a specified account. This is the context in which I was imagining @deliver-to.

Both proposals could coexist, of course (they could even be part of the same cap?)

[grawity]

I imagine both would be part of the same spec; e.g. targets:

foo/!bar or !bar@foo or whatever: deliver to a specific nickname, but ensure that it's logged into that account (probably numeric 401 if it doesn't match)

*/!bar or !bar@* or !bar or whatever: deliver to all nicknames logged in to that account (numeric 401 if there aren't any)

Are there cases where an ircd might really not want to support multicasting the message to multiple connections? I don't imagine it would be any different from just messaging a #channel...

[SadieCat]

I would expect the message to be delivered to each user.

I feel like this would provide a really crappy experience for users as they would end up just receiving one side of a communication on one client (echo-message does not work for different clients and extending it to work based on accounts could potentially result in undesired effects such as leaking chat).

A better solution imo would be to have a numeric (or a FAIL message, we can bikeshed that later) which informs the user that there is multiple clients logged into that account and then list the accounts for the client to choose from. Something like this:

:irc.example.com 1234 <YourNick> <!MessageTarget> <client1>[ <clientN>]... :Ambiguous message target

[slingamn]

I'm not sure about this but I think how Jabber works is: first message gets multicast to all resources, then when a reply comes in, the client directs future messages to the resource that sent the reply. This solves the problem of the first user having to guess which resource / nick actually has a human present.

[Herringway]

I imagine both would be part of the same spec; e.g. targets:

foo/!bar or !bar@foo or whatever: deliver to a specific nickname, but ensure that it's logged into that account (probably numeric 401 if it doesn't match)

*/!bar or !bar@* or !bar or whatever: deliver to all nicknames logged in to that account (numeric 401 if there aren't any)

As a bonus, you could also enable channel whispers simply by replacing !bar with #chan with whatever scheme is chosen...

[DanielOaks]

While I'm not opposed to this, there's something to be said for being able to just change your nickname and avoid having to continue a discussion with someone. I feel like an explicit account target should come with some fairly explicit access-control-like stuff, maybe including provisions for only allowing messages from certain other accounts, only allowing clients logged into an account to use the account target (or programmatically enabling/disabling this restriction in a more standard way than just hoping you get the right MODE character), or maybe even going crazy and building it into something like a more general 'buddy list' or 'friends' functionality?

While keeping this specific feature simple is important, I really don't want to blindly open an avenue for people to much more easily spam other users, making it real difficult for the recipients to stop it in the process.

[jwheare]

Well there’s already widely implemented usermode +g and /accept but it’s worth thinking about other ways to completely block specific users on the server side without having to go full on private, and/or a way suppress +g notifications.

Clients have /ignore but not all of them can ignore by account name (plus they won’t always know the account name from a pm without account-tag)