Skip to content

Instantly share code, notes, and snippets.

@jesopo
Last active January 20, 2020 22:01
Show Gist options
  • Save jesopo/f2e8af7f24a8aea9dde5f8c048bf11a5 to your computer and use it in GitHub Desktop.
Save jesopo/f2e8af7f24a8aea9dde5f8c048bf11a5 to your computer and use it in GitHub Desktop.
draft/account-id IRCv3 proposal

account-id proposal

rationale

bots, like BitBot, track user accounts (through WHOX, extended-join, account-notify) to grant permissions to users without them having to register/identify directly with BitBot.

This works well most of the time but there's two problematic situations;

  1. a user changes the name of their account and loses their permissions
  2. a user changes the name of their account or drops their account, someone else comes along and registers the same nickname and is granted the permissions that user had

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.

solution

pretty simple; expose an indefinitely unique and unchanging (and opaque!) account ID.

technicals

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

i propose this account ID is exposed in at least 4 areas;

  1. a WHOX flag
  2. a message-tag on JOIN
  3. a message-tag on ACCOUNT (account-notify)
  4. a message-tag on PRIVMSG/NOTIFY/TAGMSG

and i also suggest it is exposed on as many messages, sourced from a user action, as possible; e.g. if a bot will only respond to INVITEs from users with a given permission.

examples

@account=jess;draft/account-id=123 :jess!u@h JOIN #channel
:jess!u@h JOIN #channel
@draft/account-id=123 :jess!u@h ACCOUNT jess
@account=jess;draft/account-id=123 :jess!u@h PRIVMSG #channel :hey everyone!

server/services considerations

as mentioned, this ID should be opaque. it is recommend that it is not just an incrementing integer because that exposes the order of registrations which may be unwanted.

anecdotally, services devs have told me it wouldn't be a big issue to introduce this ID.

privacy/trackability considerations

having a persistently trackable ID tied to your account means that changing your account name will not protect you from being tracked.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment