Controlled accounts

[erkinalp]

Is your feature request related to a problem? Please describe. Companies, schools and parents would like ability to white- and black- list certain users to certain guilds, channels and user groups. Bridge bots could also make use of this feature.

Describe the solution you'd like

• Group whitelist/blacklist create (list of guilds and DM targets)
• Group whitelist/blacklist fetch
• Group whitelist/blacklist delete
• Discriminator range reserve
• Discriminator range unreserve
• Create controlled account (#408)
• Delete controlled account (#351)
• Fetch all accounts controlled by self
• Apply group white/blacklist to controlled user
• Action in behalf of controlled user

Detailed description of the endpoints

Create controlled account: This endpoint shall create a controlled user account. Parameters:

• username: Name of the controlled account
• tag: Discriminator of the controlled account
• scope: Array of group white/blacklists to apply (if both white- and blacklists are present, then blacklist is subtracted from the whitelist)
• controller: The user who controls the account (implicit in writes, returned in reads of the controlled user)
• rights: Initial rights of the user Returns: If unauthorised to create a controlled user or apply one or more of the control flags, return 403 Forbidden. On success, return 200 OK.

Delete controlled account: This endpoint shall remove a controlled user account.

Parameters: same as /users/@me/delete, but controlled accounts cannot initiate account delete on their own. Returns: If unauthorised to delete the user or apply one or more of the control flags, return 403 Forbidden. On attempt to delete a non-existent user in a discriminator range controlled by said user, return 400 Bad Request. On success, return 200 OK.

Group white- and blacklist objects: Parameters:

• whitelist: if true, a whitelist, else, a blacklist
• guilds: list of guilds
• users: list of DM targets
• roles: list of roles If unauthorised to create a controlled user or apply one or more of the control flags, return 403 Forbidden. On success, return 200 OK.

Group whitelist/blacklist create:

• users: Array of user IDs to be affected initially
• scope Group whitelist/blacklist object

If unauthorised to create a controlled user or apply one or more of the control flags, return 403 Forbidden. On success, return 200 OK.

Discriminator range reserve: Reserve certain discriminators for a certain account controller. An account controller can only reserve discriminators for itself, not for other controllers. Parameters:

• include: a pair of discriminators, which denote an inclusive range
• exclude: array of pairs of discriminators, which denote ranges to be excluded from above

If unauthorised to create a controlled user or apply one or more of the control flags, return 403 Forbidden. On success, return 200 OK.

Discriminator range fetch: Returns the reservation by reservation ID. Discriminator range reservations shall be returnable by any user.

If unauthorised to create the reservation or attempts to re-reserve an already reserved range, return 403 Forbidden. On success, return 200 OK.

Discriminator range delete: Deletes the reservation by reservation ID. Only the user that created the reservation can delete it.

If unauthorised to unreserve the range, return 403 Forbidden. On attempt to delete a non-existent reservation, return 400 Bad Request. On success, return 200 OK.

Apply group white/blacklist to controlled user: Applies group scope limits to a given user. Parameters:

• user: User ID to apply the group white/blacklist.
• scope Array of IDs of group white/blacklist to be applied. A user can have as many scopes applied as wanted.

Sub-tasks

• [ ] Account controller configuration
• [ ] Create/delete controlled account
• [ ] Controlled account configuration
• [ ] Act on behalf of a controlled account
• [ ] Controlled account limits&exemptions

[SamuelScheit]

I think this is especially useful for schools and organizations/companies who want to provide an easy way to signup their employees/pupils/members. I think can_edit_self should be controlled in a more general way, that instance owners can create certain types of users (flags/badges) that have instance-wide permissions. Also I'm not sure if the accounts should be bound to a certain controller it rather should be the instance admin. I think many ideas could be adapted in a more general way. (e.g. an admin should be able to block/delete any account)

[SamuelScheit]

Action in behalf of controlled user

What kind of actions?

[erkinalp]

Also I'm not sure if the accounts should be bound to a certain controller it rather should be the instance admin.

In the model I had in mind, server administrator would approve the account controller privileges, and controllers would administer those accounts.

What kind of actions?

Any, but can be scoped further by permission bits. This will be handy in implementing puppeting bridges.

an admin should be able to block/delete any account

Account controllers are something separate from server administrators, and will not have direct database access.

[DiegoMagdaleno]

Users should be able to claim this account, so the way we could do this is by linking the IDs of the Discord account with the Fosscord account. Then when the user wants to "migrate" fosscord, we could give two options to verify it is indeed him:

1. Use OAUTH, once that's done the account is now activated, along with all the messages, roles, and servers that meta account might be on.
2. Use a Keybase like verification method, where we provide a key that the user most input somewhere, if the keys the match, the user can then claim the account