atheme-services account degradation

gistfile1.md

Account Degradation

1. Current System

---

1. Account reaches an age (e.g. 30d)

2. Services considers the account expired

3. Services removes this account. This frees all nicknames associated with the account for re-registration and removes this account, including all metadata, group and channel access from the database.

4. There is no D. That's all that happens.

5. Account Degradation System (Proposed by @alyx)

---

1. Account reaches an age.
2. Services considers the nicknames associated with the account to be expired.
3. Services frees the associated nicknames for re-registration.
4. The account name is set to the accounts unique id, which is defined internally by Atheme on account registry.
5. The "account" is a permanent entity, and nicknames are the perishable product.

Discussion Questions

1. Would the degraded system continue to support functioning as a full account?
2. How would the degraded user regain his account? (Problem: People don't write down their UID.)
3. How would the degraded account be displayed to users and services operators?

Currently Proposed Answers

1. Discussion needed.
2. The original idea was to send the user an email. However it would not be ideal for users to receive emails they haven't requested. Perhaps we could have a per-user option for them to enable email alerts for their account?
3. Post-degradation, there would be two views for the different user classes.

Users would see:

Information on AAAAAABD5 (account AAAAAABD5):
Original Account Name  : Alyx
Last addr              : alyx@198.52.gwx.tr
Last seen              : Oct 15 01:44:23 2013 (32 weeks, 1 day, 09:35:21 ago)
*** End of Info ***

and operators would see the following:

Information on AAAAAABD5 (account AAAAAABD5):
Registered             : Oct 15 01:44:23 2013 (32 weeks, 1 day, 09:35:21 ago)
Entity ID              : AAAAAABD5
Expired Account Name   : Alyx
Last addr              : alyx@198.52.gwx.tr
Real addr              : alyx@198.52.ip.addr
Last seen              : Oct 15 01:44:23 2013 (32 weeks, 1 day, 09:35:21 ago)
Expired Nicknames      : Alyx, NotAlyx
Channels               : 2 founder, 2 other (See below note)
Groups                 : !atheme-developers (See below note)
*** End of Info ***

4. Note: This could be changed to "Expired Channels" or just removed, depending on the discussion of [question one][q1].

It would be neat if you could identify with the entity ID regardless of any nicknames associated with the account. It would also be neat if you could have an account with no account name or nicknames attached to it in the first place. Then, you wouldn't have to do something special to "reactivate it" after the nicknames expire. It would never "deactivate" or become dormant. It would simply be an account with no nicknames, one to which you can add some nicknames later if you so please.

Also, accounts should eventually expire at a much-longer (configurable) date than the nicknames, such as many years into the future. IRC is eternal and should account for the possibility that enormous networks will still exist a thousand years from now with millions of dead people's accounts still in the database.

The only issue I can see with entity ID identifications is telling the difference between nick AAAAAABD5 and account AAAAAABD5. Maybe just prefix the UID with a number of symbol so you can tell the difference?

Hm, didn't notice that it starts with a letter. I think it would be simpler to try looking up the ID first and fallback to the nickname because it's rather unlikely that such a nickname would exist. It would make sense also to prohibit registration of ID-like nicknames...

On this issue:

[23:05:05]  <mitch>  how would it appear in the flags list? just the ID? how would the current +f-ers know who they belong(ed) to?
[23:05:19]  <Attila>     yeah thatd be annoying to manage

Here's a whole different idea:

1. The account nickname expires.
2. The new account name becomes an altered version of the former account name with an (incrementing) number prefixing it, rendering it an invalid nickname.
3. The user can later identify with the new altered account name and register a new nickname.

The prefixing number ensures that any new accounts with the same nickname will not be confused with the former account. For example, in a channel flag list with entires for the old account, it might say "1Nick" – the user who used to be "Nick" but whose nickname expired. I think this is better than showing emails or account IDs in flags lists.

This might be ridiculous. I don't know.

"Rather unlikely"

It'll happen by people just wanting to toll

"Prohibit registration of ID-like nicknames"

Assuming IDs are all 9 characters long and go from A-Z0-9, that's going to forbid all 9-character long nicknames from being registered.

I currently see as the best solution:

1. Tom registers an account. He is informed that if he is inactive for too long, he will receive an email. He will also have the option to disable this feature at the time of registration with some SET command if he doesn't want to be bothered.

/msg NickServ SET EXPMAIL OFF

1. Tom leaves for a long time while he is raising his new son. The former "account expiration" process would have begun, but instead the "account name expiration" process begins.
2. Tom's account name becomes EntityID-Tom. Entity IDs will have to be invalid nicknames, which we mostly all agreed should be prefixed with a symbol or number. The purpose of this temporary ID is to ensure that it will not occupy a valid nickname from the pool of available ones, while it will maintain the recognizability of who the account belongs to in flags and other lists throughout services.
3. Tom receives an email that his account name has expired. It will explain to him that his new account name is EntityID-Tom and how to log in to his account in the future.
4. Tom returns after his relationship didn't work out and he lost custody of his son. He uses LOGIN and GROUP OR the new RECLAIM command which does both operations at once. He will login with either the temporary account ID, which behaves like any other account ID, or with the entity ID alone – a new functionality that will always work under any situation. This command might have an optional parameter for which nickname to use as the new account name, defaulting to the current nickname just as GROUP would.

/msg NickServ RECLAIM <temporary account name OR entity ID> <password> [<new account name>]
/msg NickServ RECLAIM 1AAAAAAAA-Tom rlys3cure
/msg NickServ RECLAIM 1AAAAAAAA-Tom rlys3cure Thomas

For clarity

• The account nickname cannot expire until the account would have expired in the previous system. This is a simpler solution than for it to expire completely independently of the account because if that were the case, there would have to be some way to determine which other nicks (if others are grouped) would inherit the account name title.
• MOST IMPORTANTLY: Accounts do not go dormant or into a deactivated state. There should be no special treatment for accounts whose account names have expired. They're just normal accounts that happen to have account names that are not valid nicknames.

Other considerations

• I think it would be really neat if the functions that look up accounts by nickname or account name could also look them up by entity ID. Rather than specific commands searching for accounts both ways, it would be great if services could find accounts by either method all throughout. I assume this would be easier anyway.
• Attila brings up the possibility that existing code may always expect the account name to be a valid nick while the user is logged in. Perhaps the identify command should refuse identification to an account whose name is not a valid nickname, instead forcing the use of the RECLAIM command. However, alyx argues that this should not be an issue since the accounts aren't associated with nicknames at all in a UserServ-style system anyway.

I think it would be really neat if the functions that look up accounts by nickname or account name could also look them up by entity ID

Already exists, ?entityid syntax. Some places opt out of it though (e.g. NickServ IDENTIFY). Discussed on IRC.