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 schedule backups of user data once a week to the backup pods. This probably should not be configurable to avoid easy abuse. Do this as a sidetiq job.
• When sidetiq job triggers, schedule a job backup sidekiq job for each individual user. Check when scheduling a job for a user that queue doesn't already have a job for this user (to avoid creating endless amounts of jobs is sidekiq processing has stopped for a long time).

Rationale: one sidetiq job as master to trigger lots of small regular sidekiq jobs. Doing all backups through one job would be too heavy on large pods. Scheduling all jobs individually in sidetiq would be error prone and bloat the sidetiq scheduling.

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).
• If a pod that was previously backup ready becomes not backup ready, choose a new backup pod to all existing users who have that pod currently, send them a notification and schedule initial sync (see User creation -story).

Maintenance of stale backup data

• Sidetiq job running every month to purge backup data that has not been updated in the last year.

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