User:Senya/Account Backup And Restore

Work in progress:

This article is a work in progress, it may contain incomplete or inaccurate information. There may be additional information on the talk page.

Note:

This is a proposal, not an accepted specification.

Description

Proposal specification to deal with two problems:

• Dying pods (ie losing your account due to pod disappearing)
• Pod migration (ie not being able to move pods)

High level concept

• Users are backed up automatically to pods who opt-in to receive backup data
• The restore process migrates the user to the pod he/she is restoring on
• Backup data is encrypted to protect the private key contained
• Backup is automatic and after the user chooses a pass phrase, the user doesn't have to do anything else, except store a piece of information

User stories

User creation

• User arrives at user creation.
• User is asked to give a pass phrase for backups. User can opt-out, which ends this user story.
• Pass phrase is stored in user table in plain text (so it can be used to encrypt).
• Backup pod is chosen from available pods automatically and stored in user data. In the case of no available backup pods, exit here.
• User is sent an email containing information regarding: Where to restore in case of problems? What information to store (the pass phrase)
• Schedule initial sync immediately.

Manually choosing a backup pod

• User goes to settings.
• User chooses to a new backup pod from a list of available pods.
• User chooses a pass phrase.
• User is sent an email containing information regarding: Where to restore in case of problems? What information to store (the pass phrase)
• Schedule initial sync immediately.

User data restore

• User follows link to restore page on backup pod (for example /restore_backup)
• User gives email and pass phrase.
• User is sent an email which needs to be verified by opening the link.
• User is asked to provide a password and username for their account.
• A local account is created on the backup pod and linked to a possible profile.
• Backup pod sends out "I've moved" federation messages to all known pods, signed with the users private key.

Receiving a moved message - remote pod

• Pod verifies message against user public key (as normal)
• Pod fetches new profile as per moved message
• Pod replaces local profile with new information
• Pod makes sure all locally stored content to this person points to the changed profile (should only require change of profile data)

Receiving a moved message - old home pod

• Pod verifies message against user public key (as normal)
• Pod fetches new profile as per moved message
• Pod replaces local profile with new information
• Pod removes local user, making the user now a remote user
• Pod makes sure all locally stored content to this person points to the changed profile (should only require change of profile data)

Backup pod receiving a backup for the first time

• Send email to user that backups are being received and instructions on how to proceed if migration is wanted.

Becoming a backup pod

• Podmins enable "allow_backups_and_migration" in pod settings.
• NodeInfo gets a new metadata entry to indicate pod accepts backups.

Receiving backups

• Pod receives a backup message from another pod and stores it.
• If a previous backup for the user already exists, replace it.

Automatic sync

• Pods should send out backups of user data every X days to the backup pods.
• When a backup is sent out, the next one should be scheduled in sidetiq for the next time.

Sync to backup pod fails

• Increase failed count in user data.
• If failed count is over threshold (default 3), choose a new backup pod from available pods.
• User is sent an email containing information regarding: Where to restore in case of problems? What information to store (the pass phrase)
• Schedule initial sync immediately.

Pod reads NodeInfo from other pods

• Update information of pods wanting to receive backups
• If no backup pods previously existed, add backup pod to all existing users who didn't opt out, send them a notification and schedule initial sync (see User creation -story)

Pod schema changes

Backup data

Pods need a new model "backups" to contain backups from remote pods. This should be uniqued on email and any new backups should replace the current one.

• email
• content (encrypted)

Pods don't need to even know where the data is from - just email and the actual encrypted backup.

User data

Users need some extra flags:

• backup pod
• backup pod failed sync count
• pass phrase

Backup pod is the domain.tld where the backups are sent. If it changes, it should be updated.

Pod data

• backups allowed flag

Backup contents

• Profile
• Aspects
• Contacts
• Followed tags
• Public and private key