User Onboarding, Incubation & Recovery For the Steem Eco-System: A Draft Software Specification.

This is a first draft of a specification of requirements for most of the onboarding processes that are intended to be made by (or in association with) @steempassport (additional options exist but are not all listed here).

The aim of this document is to describe, at a high level, the needs that must be met by systems that implement technical solutions for onboarding new users to the Steem eco-system. Once this is agreed upon by vested interests, more detailed design documents can be produced if needed.

Feedback is welcome!

steem passport post header

Document Covers:

Direct Sales of New Accounts
Creation of Accounts via Resource Credits
Account Incubation
Recovery Management For New Accounts
Delegation Management for New Accounts

1. Overview

1.1 Document Purpose

On-boarding of users to Steem includes several options and pathways – all of which must be supported with appropriate software solutions. The aim of this document is to outline the software required to meet all of these needs, to identify which needs are already being met by existing software and to also specify and design any new software that needs to be created.

1.2 Overview of On-boarding Pathways

Several main options have been identified that are available to facilitate new accounts for Steem users. Steem Passport aims to provide solutions for onboarding users that make use of the best options from this list and to package the options in an efficient and generic way so that dApp operators can interface with the system (or possibly self host their own instance) so as to reliably on-board potentially large numbers of new users.

Purchase new account directly from the blockchain: Pay for a new account by providing an amount of Steem (or equivalent) at the value of the current ‘account creation fee’.
Claim account through use of resource credits: Accounts are created for ‘free’ if creator has the required Steem Power.
Incubation of accounts: New users are given access to a temporary account and are allowed to use that to generate payouts from posts in order to earn the Steem needed to pay for their own full account.
Additional options: Further novel options exist which are beyond the scope of this document at the present time.

1.3 Additional Functionality

Additional requirements exist that are either necessary or useful when creating new accounts:

Account recovery (Mandatory)– In the event that users lose their login details, an account recovery process exists that they can use with the account’s ‘trustee’ to recover their original login. This must be handled by anyone issuing paid accounts and ideally for all accounts.
Delegation of Steem Power to new accounts (Optional). When accounts are created, they now have zero Steem Power, which means that they are effectively useless as actions on the blockchain require resource credits that are tied to the amount of Steem Power being held. Delegation of funds to new accounts is one way to get around this. Monitoring of exploitation and abuse of any free accounts is needed when delegations are made – in order to ensure Steem Power is not wasted.

2. Functional Requirements

Functional requirements define what the system should do.

2.1 Onboarding - Paid Accounts

Accounts can be created in exchange for direct payment.

To facilitate this a system must:

Allow the selection of a username.
Check the availability of a username.
Store a price for the creation of the account.
Accept payment for the account.
Connect to the Steem blockchain to create and pay for the account.
Create passwords for the account.
Log the creation of the account and it’s private owner password in a database to allow for account recovery in future.
Create accounts on the Steem blockchain.
Provide the user with the login details once an account has been created.
Provide user with feedback as to the status of the process via on screen prompts and email notifications.

2.2 Onboarding - Claiming Accounts Via Resource Credits

Accounts can be created in exchange for resource credits issued to Steem Power holders who have sufficient resource credits to do so.

To facilitate this, a system must:

Allow the selection of a username.
Check the availability of a username.
Facilitate the claiming of accounts via resource credits.
Connect to the Steem blockchain to create the account.
Create passwords for the account.
Log the creation of the account and it’s private owner password in a database to allow for account recovery in future.
Create accounts on the Steem blockchain.
Provide the user with the login details once an account has been created.
Provide user with feedback as to the status of the process via on screen prompts and email notifications.

2.3 Onboarding - Incubation of Accounts

Users may opt to create accounts without making any direct payment themselves. Instead, they can access live Steem accounts and use them to make live posts, but they do not receive full control of the account. This first account is a temporary incubation account which the dApp operator retains control of. Once the user has earned enough rewards to pay for a full account to be created on their behalf, they can then ‘upgrade’ to a new, full account.

To facilitate this, a system must:

Manage access to a number of Steem accounts to be used as ‘temporary’ user accounts.
Provide a means for users to manage basic account profile details without having full account control privileges on the blockchain level. Users can set a temporary username, image and other details via the system operator’s own web interface. The user cannot make these changes directly to the Steem blockchain while using a temporary incubation account.
Be able to create new temporary accounts as needed – either by resource credits or direct payment.
Allow new users to receive posting rights to a temporary account.
Allow dApp operator to delegate Steem Power to temporary accounts to allow them to interact with the blockchain.
Monitor rewards for temporary accounts and trigger an account upgrade process when rewards are high enough.
Migrate a user’s own posts from the temporary accounts to their new account – if desired by the user.
Allow the user to select a username when they upgrade their account.
Check the availability of a username.
Store a price for the creation of the account and the threshold value for rewards payments at which accounts can be upgraded.
Connect to the Steem blockchain to create and pay for the upgraded / new account using rewards from the incubation account’s own wallet.
Create passwords for the upgraded / new account.
Log the creation of the account and it’s private owner password in a database to allow for account recovery in future.
Create accounts on the Steem blockchain.
Provide the user with the login details once an account has been created.
Provide user with feedback as to the status of the process via on screen prompts and email notifications.
Output a list of the users currently going through incubation via an- API.
Monitor inactive incubation accounts to free them up for other users after a set time period of inactivity has been reached.
Reset incubation accounts, ready for a new user to take them over.
System operator can elect to require incubating users to receive payouts that cover Steem Power in addition to the cost of the account creation fee, if they prefer.
System operator can elect to take a percentage of the rewards from incubating account’s payouts as a beneficiary.

2.4 Account Recovery

In the event that security for a user’s account is compromised, the trustee (account creating entity) must take steps to initiate a recovery procedure on behalf of the user.

To facilitate this, a system must:

Allow users to notify the trustee that a recovery process is needed.
Allow a user to pass an old private owner key to the trustee.
Allow the user to provide evidence of their identity, to tie them to their account (in the form of images, text, ID numbers etc.). This could be done by a simple Email or by form on a website that accepts file attachments.
Create a new owner keypair for the account.
Allow system admins to review the recovery process, ID and Key in order to authorise or reject the data.
Connect to the Steem blockchain to trigger the account recovery process.
Inform the user of the success or failure of the reset procedure.
Update the system’s record of the password recovery for future reference.

2.5 Delegation to new accounts

New accounts are unable to transact effectively on the Steem blockchain without having a certain amount of Steem Power in their wallet. Therefore, some dApp operators may wish to delegate Steem Power to new users for a certain time period. The delegation process is relatively simple, however, to prevent abuse and exploitation of the delegation (which itself has a financial value), steps need to be taken to monitor accounts and remove delegations when necessary.

To facilitate this, a system must:

Allow dApp operator to elect to delegate to new accounts.
Allow dApp operator to choose an amount of Steem Power to delegate to new users.
Inform the dApp operator of how many accounts can be delegated to, using the current system settings.
Check that sufficient Steem Power is available in the dApp operator’s account to make a delegation.
Connect to the Steem Blockchain to delegate to the new account.
Allow users to report abuse of accounts created by the system and for dApp operators to view and manage the reports of abuse.
Allow the manual removal of a delegation by the dApp operator in response to community reports of abuse by any specific account.
Automatically monitor activity of new accounts in order to highlight potentially abusive accounts. Since voting behaviour is the primary metric for detecting abuse, rules must be allowed to be created to determine what constitutes abusive voting behaviour.
Automatically remove the delegation once a user earns an equivalent amount of Steem Power from their own posts.
(Optionally) Automatically remove delegations after a set time period.
Notify the dApp operator of automatically detected abusive accounts.
Allow the dApp operator some means of preventing further accounts being created by abusive users – such as highlighting email addresses and IP addresses that repeatedly create abusive accounts. Blacklisting repeat offenders needs to be a simple operation for the admin to complete. IP address blacklisting should last for a specific time period (configurable by the dApp operator) in order to minimise wrongly blocking new users in the event that IP addresses are dynamic or shared by many people.