Data portability features

This covers some of the design for features that let users leave a site.

Configuration variables

Administrators can modify 4 configuration variables to control profile manipulation by the user. All are in the 'profile' section, and true by default.

backup 

whether users can backup their accounts in Activity Streams format.

restore 

whether users can restore their accounts from backup.

delete 

whether users can delete their own accounts.

move 

whether users can move to a different account or a different server.

Rights

There are 4 corresponding rights defined; by default users can exercise these rights if the corresponding configuration variables are set. More fine-grained rights-management can by done by hooking the UserRightsCheck event.

Actions

There are four new user interfaces for these features.

Backup

A link from the profile settings page goes to a form that explains how the backup works. If the user chooses to backup, an ActivityStreams representation of their account history (from UserActivityStream class) is sent to the browser.

Restore

A link from the profile settings page asks for a file upload. Data is then restored by an offline processor.

This code needs to be moved to a library from the scripts/restoreuser.php script and given a Web interface.

Delete

A link from the profile settings page goes to a form that explains how deleting your account really, really, truly deletes the account. It will link to the backup page and strongly encourage the user to backup their account.

It will include a text box and instructions to type "Yes" (or language equivalent) in the box. This should prevent (most) accidental deletions.

When posted to, it gives the user a DELETED role, and schedules the deletion with an offline queue. Finally, it logs out the current user, since they no longer have an account. It then shows a message indicating that the user is logged out.

Move

See http://lists.status.net/pipermail/statusnet-dev/2010-November/003734.html for origin

1. user1 at example.com decides to move her account to user2 at example.net .
2. She goes to http://example.com/ , goes to her account settings, says she wants to move her account, and gives her API credentials for example.net.
3. example.com pushes activities (notices, follows, faves), in chronological order, to example.net. (This would probably happen in a queue handler.)
4. example.com fixes up local subscriptions to user1 to follow user2 at example.net instead.
5. example.com changes the URL (but not the URI!) of user1's notices, so Web hits will now redirect to the page on example.net.
6. example.com disables user1 at example.com account; can't follow, be followed, post notices, do faves -- pretty much "silenced".
7. example.com sets up a feed mirror of user2 at example.net to user1 at example.com so remote subscribers to the old (.com) account will receive notices from the new account.