rough account-id proposal

[jesopo]

drafted up a brief description of my proposal for exposing indefinitely unique and unchanging account IDs. too rough to be a pull request but hopefully enough to get conversation going.

https://gist.github.com/jesopo/f2e8af7f24a8aea9dde5f8c048bf11a5

[prawnsalad]

i suggest that this account ID is not ever changed unless the user directly and explicitly asks for it to be; at which point they should be heavily warned about the potential implications of doing so.

Having this even as a possibility goes against the whole point of having an ID otherwise you've just duplicated account with no other benefits. It would be best to keep this specifically static. People can create a new account if they need a completely new identity.

We've actually implemented something very similar for avatars on irc.com using a irc.com/avatar message tag in joins/account/privmsg but also notice, 900 (logged in) and each WHO/X user line. Adding a WHOX flag is nice but for consistency a message tag would be ideal too. These events with message tags have worked well for us so far.

Another thought that comes to mind is how are they intended to be used? Since they are exposed to the client are we to use a new type of extban to specify an account-id in things like bans/exemptions/invites/etc? Or would it be simpler to recommend that services takes an account name as they currently do and translates those to account-ids internally? Personally I think this would be easier as users would be telling each other their account names to use in various places, not look up their ID and then share that.

[edk0]

Having this even as a possibility goes against the whole point of having an ID otherwise you've just duplicated account with no other benefits. It would be best to keep this specifically static. People can create a new account if they need a completely new identity.

IRCv3 specifies protocol. This proposal operates within that remit and should continue to do so. Demanding that implementations and/or service providers allow or deny users the ability to change any particular property of their account is not a protocol concern.

[dgw]

@edk0 Defining which account properties are mutable is a protocol concern, as it informs which properties are suitable for use in different situations by clients (e.g. bots). If an account ID can be changed, to a bot trying to specifically identify someone (for preferences purposes or what-have-you) whose account name has changed, the ID is not reliable and no different than using the account name directly.

[prawnsalad]

@edk0 if some services package does not want any form of static user ID then they could just not enable account-id. We don't need to duplicate the account name for no reason. But what some services or bots do need is a way to differentiate users with certainty.

[DarthGandalf]

Let's separate 2 different concerns:

1. changing id of the same account
2. reusing id of old account for some other account if the old account stopped using that id for some reason (maybe account was dropped, or due to the id change)

[prawnsalad]

As mentioned on IRC, a middle ground that at least works for my use cases is that account IDs must never be reused. But changing an ID should mention to the user that connected services or functions of the IRCd may break.

[jesopo]

I've added two pieces to the gist:

• in rationale:

additionally, people abuse mechanics for account name changes to avoid extbans (e.g., +b $a:jess to ban the account name "jess".) we could leverage unchanging account IDs to enact bans on these kinds of problem users that would persist through account name changes by targetting account ID rather than account name.

• in technicals:

account IDs MUST NOT be reused. account IDs SHOULD NOT change.

[prawnsalad]

Any input on the other points mentioned, re. referencing these IDs?

[jesopo]

my concern is how we get the IRCd and services to work together to translate account names and IDs back-and-forth.

if we have e.g. an extban for "account ID" that we feed an account name to and leave it up to services to translate that actually in to the account ID (and thus continue to apply it even if account name is changed), that's asking a little too much of ircd<->services cooperation, i think. I'm no ircd or services expert tho.

unless services steps in the moment you set the extban and immediately translates it permanently in to an ID-based ban (think /mode +b $a:jess -> jess has set mode +b $a:123456) but that leaves us in a position where listing the current bans of a channel that has a lot of account ID bans will be highly confusing unless you can remember which nicknames map to which uuids or so

[edk0]

I'm wondering about inventing an extban with syntax like $A:sam/3666, where the part after the slash is the part that does the actual work, and the part before is a comment of sorts. As a helpful shortcut, you can set +I $A:sam and services will swing in and replace it with +I $A:sam/3666, and then as a further shortcut I'm less confident about, -I $A:sam will automatically become -I $A:sam/3666.

[ilbelkyr]

my concern is how we get the IRCd and services to work together to translate account names and IDs back-and-forth.

if we have e.g. an extban for "account ID" that we feed an account name to and leave it up to services to translate that actually in to the account ID (and thus continue to apply it even if account name is changed), that's asking a little too much of ircd<->services cooperation, i think. I'm no ircd or services expert tho.

speaking as atheme/seven person here, this would require a bit of server-to-server protocol work and quite possibly some adjustment to how bans are handled in general. I don't think that should be a blocking issue, though; personally I'd rather go through more effort to make things work than simplify the requirements just because it'd be easier for specific existing implementations.

(To be clear: In this case, a lot of the difficulty would be due to the separation between ircd and services. I don't think we should tailor specifications to this specific design at the expense of having a better, more useful specification. If the software design is making it hard to implement, perhaps it's an issue with the implementation, not with the protocol specification.)

unless services steps in the moment you set the extban and immediately translates it permanently in to an ID-based ban (think /mode +b $a:jess -> jess has set mode +b $a:123456) but that leaves us in a position where listing the current bans of a channel that has a lot of account ID bans will be highly confusing unless you can remember which nicknames map to which uuids or so

I'm wondering about the impact this would have on existing clients, considering they would see themselves setting a mode different from what they tried to set. (There's some precedent for this in servers translating e.g. +b foo@bar into +b *!foo@bar already, though.)

So far, I've considered account-id to be mostly about exposing an ID for clients to use to identify other users by account. While there are probably a number of decent ways to use them when interacting with the server (extbans being one of them), I'm thinking this might be better left for a separate spec, partly to get this one finished but also because just making account-id available to clients has reasonable use cases even without the server being able to use them for anything.

(Extbans specifically seem like an entire new can of worms, given the variety of ways different servers express them and the lack of standardization for them; it's something we'll probably want to address at some point, but personally I'd rather not wait for that to happen just to get account-id support out there.)

---

I was going to include some more thoughts about standardizing an interface for a lot of things currently exposed by services in a /msg FooServ arbitrary command goes here fashion, but those are probably better put in another issue (likely in the ideas repo). Perhaps a simple pair of commands to map between account names and account IDs would be simple and useful enough, though.

[jesopo]

so are we relatively content with the gist as it currently is?

[edk0]

yes

[slingamn]

Do we have any strategy for eliminating the duplication of the account and account-id tags? I don't have any fully formed ideas on this (or extremely strong feelings in general), but it would be nice in principle if clients could request some set of caps such that they would only receive account-id attached to typical messages.

In general, I think it might be useful to figure out everywhere that account names are used in specs right now (is it only account-tag and extended-join?), and then understand how account-id fits into that world.

I don't want to hold up the process on turning this into a PR, but I think these questions are going to come up eventually so we might as well start thinking about them now.

[slingamn]

Commenting on discussion that ensued from this in #ircv3: I don't want to hold this proposal up or bikeshed unnecessarily, but I think we're faced with an alarming proliferation of user identifiers, with overlapping meanings and purposes. We've got:

1. Nicknames
2. Account names
3. "Display names" under various proposals (metadata etc.)
4. The permanent account identifier

so ideally, this would be an opportunity to think carefully about what all of these identifiers mean an what their purpose is. edk0 suggested that the way to move forward is some kind of fusion between nicknames and account names (the two items on the list that are both human-readable and machine-readable). I'm not sure exactly which way to go, but I do have the sense that the current proposal renders account names somewhat redundant.

[SadieCat]

The latest Anope release sends account ids to the IRCd when using InspIRCd v3 and my implementation (here) is currently deployed on the InspIRCd testnet (testnet.inspircd.org).

[SadieCat]

@jesopo Are you interested in submitting a spec for this (or an amendment to account-tag)?

[ailin-nemui]

users could just register new accounts (with new account-ids)

realistically this proposal seems to be useful only for (1) users that want to change their account "name" without losing existing permissions (2) accounts getting dropped and re-registered

[SadieCat]

realistically this proposal seems to be useful only for (1) users that want to change their account "name" without losing existing permissions (2) accounts getting dropped and re-registered

I mean, yeah? That's what it's intended for. As-is you can't use accounts for authentication in bots without being at risk of someone registering the name of an expired account and gaining access.

[ailin-nemui]

the original draft had some vague promises of countering ban-evasion...
I think it would be enough to implement the following: servers where accounts can be re-used, may send an additional account-id which is unique to the creation of this account

[prdes]

What's the consensus on this currently? Asking so as to understand what to expect. Thanks.

[nektro]

love to see this!
nit: should become account-ids before merge

[SadieCat]

FWIW we've been shipping this in Anope and InspIRCd under a vendor prefix for quite a while now. It'd be good if it could be standardised.