API to download/export account data

[dmitrizagidulin]

Create an API to enable users to download or export their account data. Useful when moving to/from a different server.

Open questions:

• Is this just to export the WebID profile, or all of the data on a storage provider? (profile, preferences, all the workspaces)?

To do:

• get consensus on the account export API
• determine the format of the exported data (see Portability of user data #72)
• document the API on solid-spec
• implement on gold - see API for downloading/exporting account data linkeddata/gold#27
• implement on ldnode - create issue
• add an 'Export Account' link to the profile-editor app

[csarven]

I strongly suggest that everything in their storage should be exportable. Exportable b/c if the server application wants to offer a UI in which the user can select what they want to export, they can. So, not necessarily everything.

Related: I would also suggest that this feature is brought to the user's attention when they start the process to delete their account. Emphasize on the point that "once you delete your account, you will lose this and this and this.. and will never get it back. We don't have archives..."

[dmitrizagidulin]

Agreed. (And, good point on emphasizing the point when deleting account. I'll add a note to the delete acct issue)

[melvincarvalho]

I just want to note that while moving data on the web is possible it is always hard and often painful. That is something that wont change, and we cant solve.

The reason being that the web has inbound links that are not under your control. By moving something you affect not only yourself, but the inbound links. It's a bit like moving house. We can try and ease the pain as much as possible but not eliminate it. As a consequence, URIs build up a reputation over time.

Personal data, with relative URIs, and no external inbound links, however, could be moved with relative ease.

Just my 2 cents. Others may completely disagree.

seeAlso
http://www.w3.org/TR/cooluris/

[dmitrizagidulin]

@melvincarvalho - completely agreed, then when actually moving an account, that should be implemented explicitly, so that the previous provider can set up actual well-behaved HTTP 301 redirects.

The exporting data functionality is orthogonal to that, however - we definitely need that capability regardless.

[ghost]

i'vr consideed a redirect policy / recommendation, perhaps incorporating
use of webdht...

in effect:

if user has specified subdomain

ie:

61413837492.optus.net.au

then they should be about to 'churn' their account to:
0413837492.telstra.net.au or 0413837493.webizen.xyz or whatever...

perhaps an update patch could run too.

yet therein: the means in which to 'authorise' the migration and update is
important.

if the data cannot be made portable and user centric, then its difficult to
understand how the systrm ends-up being user centric rather than service
centric.

imho.

On Mon, 11 Jan 2016 8:08 AM Melvin Carvalho notifications@github.com
wrote:

I just want to note that while moving data on the web is possible it is
always hard and often painful. That is something that wont change,
and we cant solve.

The reason being that the web has inbound links that are not under your
control. By moving something you affect not only yourself, but the inbound
links. It's a bit like moving house. We can try and ease the pain as much
as possible but not eliminate it. As a consequence, URIs build up a
reputation over time.

Personal data, with relative URIs, and no external inbound links, however,
could be moved with relative ease.

Just my 2 cents. Others may completely disagree.

seeAlso
http://www.w3.org/TR/cooluris/

—
Reply to this email directly or view it on GitHub
#68 (comment).

[csarven]

Healthy (eco)systems include deletions or obsolescence (or death) by design [citation needed]. Setting up and maintaining redirects is costly, and it is at best a nice to have from the server that one departs.

[ghost]

redirect policy via subdomain shouldnt be too taxing.

example problems best to avoid are that similar to the functionality
provided by facebook should a user seek to stop using their platform: can't
take your friends with you.

or if a service provider changes their terms: data must be both portable
and capable of being backed up by the user.

problem is about trapping a user by way of url/uri.

usercentric would allow user to control the data accessibility including
deletion and portability, imho.

On Mon, 11 Jan 2016 7:40 PM Sarven Capadisli notifications@github.com
wrote:

Healthy (eco)systems include deletions or obsolescence (or death) by
design [citation needed]. Setting up and maintaining redirects is costly,
and it is at best a nice to have from the server that one departs.

—
Reply to this email directly or view it on GitHub
#68 (comment).

[ghost]

this might be helpful [1]

[1]
https://www.w3.org/Payments/IG/wiki/ProposalsQ42015/VerifiableClaimsTaskForce
On Mon, 11 Jan 2016 7:40 PM Sarven Capadisli notifications@github.com
wrote:

Healthy (eco)systems include deletions or obsolescence (or death) by
design [citation needed]. Setting up and maintaining redirects is costly,
and it is at best a nice to have from the server that one departs.

—
Reply to this email directly or view it on GitHub
#68 (comment).

[dmitrizagidulin]

(Moving this discussion to issues https://github.com/solid/solid/issues/13 and https://github.com/solid/solid/issues/12 as a result of the solid project workflow discussion. Closing.