Pod Import

[Laurin-W]

Once, the pod export feature is complete (#136 #228) , we can start to create a utility to import that data.

The importer will have to modify the URI references of the old pod's rdf data.

To reduce link rot, we should consider creating a redirect service from the old pod provider to the new one.

The export-import process should be able to be done manually or triggered automatically together with an AP Move activity.

[srosset81]

@Laurin-W On the pad I had put this idea:

Import and export could be done by an external app, which receives full rights on the Pod.

You added:

Since ActivityPods include activitypub collections which are not interpretable by a standard spec-compliant solid / ldp client, the external app will have to query the pod using a user-facing SPARQL endpoint (which is at risk right now) or need to support recursing through AP collections as well. Export using the backend is therefore easier.
For clients, see also https://pdsinterop.org/solid-migrator/ and https://github.com/jeff-zucker/solid-file-client/

By external apps, I was not talking about a browser-based client, but about the backend part that apps in v2 will be able to deploy. We could, in theory, allow some apps to have full access to our Pod, including the SPARQL endpoint (without WAC permissions check), even if we don't use SPARQL elsewhere anymore.

The advantage I see is that we avoid putting too much code in the Pod provider. But there could be some problems nonetheless so this is something to think about thouroughly.