# Request for Feedback: Solid Migrator spec and vocab

**URL:** <https://forum.solidproject.org/t/request-for-feedback-solid-migrator-spec-and-vocab/4852>\
**Category:** Solid Specification\
**Created:** [November 10, 2021, 3:00pm UTC](https://forum.solidproject.org/t/request-for-feedback-solid-migrator-spec-and-vocab/4852 "2021-11-10T15:00:49Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![Potherca](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/potherca/32/1761_2.png) [@Potherca](https://forum.solidproject.org/u/Potherca)\
**Post date:** [November 10, 2021, 3:00pm UTC](https://forum.solidproject.org/t/request-for-feedback-solid-migrator-spec-and-vocab/4852/1 "2021-11-10T15:00:49Z")

</div>

After my initial post in [https://gitter.im/solid/specification?at=61840fb23f09d8573653d408](https://gitter.im/solid/specification?at=61840fb23f09d8573653d408), I though it might be a good idea to request feedback from a broader audience, hence my post here.

We ([PDS Interop effort](https://pdsinterop.org/)) are currently developing an RFC/specification that attempts to mitigate linkrot and make moving/migrating between solid pods easier. We’ve documented our problem definition and proposed solutions at [github.com/pdsinterop/solid-migrator.](https://github.com/pdsinterop/solid-migrator)

In a nutshell it is an extension on the existing content-representation metadata, as described in the in the [metadata part of the content-representation Solid spec](https://github.com/solid/solid-spec/blob/master/content-representation.md#metadata).

We’d really like feedback on our ideas thus far, specifically our [**specification**](https://github.com/pdsinterop/solid-migrator/blob/main/specification-changes.md) and [related **ontology**](https://github.com/pdsinterop/solid-link-metadata).

To make things as easy as possible, feedback can be provided by commenting here, in the Gitter channel, in the GitHub repo, or by mailing [ben@muze.nl](mailto:ben@muze.nl).

## Thanks

Much thanks to @AJamesPhillips for already provided feedback, and @csarven for the excellent [Linked Research on the Decentralised Web](https://csarven.ca/linked-research-decentralised-web)

## Links

> **[GitHub - pdsinterop/solid-migrator: Solid application and specification to forward...](https://github.com/pdsinterop/solid-migrator/)**
>
> Solid application and specification to forward and/or move solid data

> **[GitHub - pdsinterop/solid-link-metadata: Adds link forwarding and archive/cache information...](https://github.com/pdsinterop/solid-link-metadata)**
>
> Adds link forwarding and archive/cache information to a URL

---

<div class="post-metadata">

**Author:** ![timbl](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/timbl/32/24_2.png) [@timbl](https://forum.solidproject.org/u/timbl)\
**Post date:** [November 11, 2021, 7:09pm UTC](https://forum.solidproject.org/t/request-for-feedback-solid-migrator-spec-and-vocab/4852/2 "2021-11-11T19:09:31Z")

</div>

A few high level comments.

- The spec seems to be about setting servers up to be able to redirect specific individual resources, rather than whole pods or large subtrees of pods. I would expect “migration” to be more about the latter. Or I may have misunderstood
- Is we do migrate large chunks of stuff, then we may want to not only but also copy so bother places ill be maintained synced versions for security.
- This connects to ideas of “soft links” in a pod, which could be client-side only: something where the solidos and file browsers understand “Here imagine a virtual copy of that” a bit like a file mount.

---

<div class="post-metadata">

**Author:** ![Potherca](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/potherca/32/1761_2.png) [@Potherca](https://forum.solidproject.org/u/Potherca)\
**Post date:** [November 25, 2021, 1:51pm UTC](https://forum.solidproject.org/t/request-for-feedback-solid-migrator-spec-and-vocab/4852/3 "2021-11-25T13:51:18Z")

</div>

Thank you for the feedback! To address your points:

- 

> The spec seems to be about setting servers up to be able to redirect specific individual resources, rather than whole pods or large subtrees of pods.

Well, the specs is aimed at both! The idea is to enable redirection on separate levels, both low- and high-level:

  - Within a Resource (for specific entries)
  - Within a Container (for specific resources)
  - For an entire Container

This last use-case is what lead to something we’ve dubbed [a meta pod](https://github.com/pdsinterop/solid-migrator/blob/HEAD/Solutions/3-meta-pod.md), which would only contain a single `.redirect` file in the root. Such a pod would respond to all requests (except for the `.redirect` itself), by sending a redirect response to another Pod. This is also the original “migration” scenario we envisioned (inspired by [https://solid.community/](https://solid.community/) going down).

- 

> If we do migrate large chunks of stuff, then we may want to also copy so both places will be maintained synced versions

As redirects may be temporary, not permanent, it is not _required_ to delete the original file. Adding a meta entry at the source is sufficient. This is included in our original idea, although I think it would be good to add this as a _separate_ use-case to emphasise the difference with other use-cases more clearly. I’ve opened [an issue at our repo for this](https://github.com/pdsinterop/solid-link-metadata/issues/2) so we don’t forget. Very good point, thanks!

- 

> This connects to ideas of “soft links” in a pod, which could be client-side only: something where the SolidOS and file browsers understand “Here imagine a virtual copy of that” a bit like a file mount.

That’s a topic we’ve been discussing as well. Applications will definitely have to have an understanding of “Do not use this resource, use that one in its place”.

We’ve been trying to create the spec (and vocab) with this in mind, so applications can support different use-cases (across different specs) using the same mechanism without needing to create separate implementations to support each one.

* * *

I hope this gives some more detailed insight into what we’re trying to achive. If you have any further questions or comment, please let me know.

Anyway, great feedback thus far, thanks again!

---

<div class="post-metadata">

**Author:** ![Stanley963](https://avatars.discourse-cdn.com/v4/letter/s/bc8723/32.png) [@Stanley963](https://forum.solidproject.org/u/Stanley963)\
**Post date:** [December 13, 2021, 11:19am UTC](https://forum.solidproject.org/t/request-for-feedback-solid-migrator-spec-and-vocab/4852/4 "2021-12-13T11:19:14Z")

</div>

Thanks for sharing this info this is useful keep it up[.](https://www.skylightpaycard.biz/)

---

<div class="post-metadata">

**Author:** ![sjoerdvangroning](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/sjoerdvangroning/32/3031_2.png) [@sjoerdvangroning](https://forum.solidproject.org/u/sjoerdvangroning)\
**Post date:** [December 16, 2021, 10:00am UTC](https://forum.solidproject.org/t/request-for-feedback-solid-migrator-spec-and-vocab/4852/5 "2021-12-16T10:00:51Z")

</div>

> [@Potherca](#):
>
> - 
> 
> > The spec seems to be about setting servers up to be able to redirect specific individual resources, rather than whole pods or large subtrees of pods.  
> > Well, the specs is aimed at both! The idea is to enable redirection on separate levels, both low- and high-level:
> 
> - Within a Resource (for specific entries)
> - Within a Container (for specific resources)
> - For an entire Container

Would it also make scaling out certain content easier? For performance or capacity reasons?  
Maybe write a book and publish chapters in different locations? Cooperation of different editors?

---

<div class="post-metadata">

**Author:** ![Cristopher](https://avatars.discourse-cdn.com/v4/letter/c/977dab/32.png) [@Cristopher](https://forum.solidproject.org/u/Cristopher)\
**Post date:** [January 12, 2022, 9:50am UTC](https://forum.solidproject.org/t/request-for-feedback-solid-migrator-spec-and-vocab/4852/6 "2022-01-12T09:50:38Z")

</div>

Thanks for the info but i am still having issue to applying it can you suggest whare i am doing wrong[.](https://www.myccpay.bid/)

---

<div class="post-metadata">

**Author:** ![linonetwo](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/linonetwo/32/4039_2.png) [@linonetwo](https://forum.solidproject.org/u/linonetwo)\
**Post date:** [September 20, 2023, 9:07am UTC](https://forum.solidproject.org/t/request-for-feedback-solid-migrator-spec-and-vocab/4852/7 "2023-09-20T09:07:00Z")

</div>

@Potherca Is it possible to just download everything to browser local memory, and re-upload them to another pod to do the migration?

---

<div class="post-metadata">

**Author:** ![sjoerdvangroning](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/sjoerdvangroning/32/3031_2.png) [@sjoerdvangroning](https://forum.solidproject.org/u/sjoerdvangroning)\
**Post date:** [September 20, 2023, 1:07pm UTC](https://forum.solidproject.org/t/request-for-feedback-solid-migrator-spec-and-vocab/4852/8 "2023-09-20T13:07:27Z")

</div>

@auke Can you give some additional information about the state of the POD migrator?

---

<div class="post-metadata">

**Author:** ![Potherca](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/potherca/32/1761_2.png) [@Potherca](https://forum.solidproject.org/u/Potherca)\
**Post date:** [September 20, 2023, 7:49pm UTC](https://forum.solidproject.org/t/request-for-feedback-solid-migrator-spec-and-vocab/4852/9 "2023-09-20T19:49:06Z")

</div>

The [Solid Migrator App](https://pdsinterop.org/solid-migrator-app/www/) does just that.  
It copies files directly from one pod to another, via the browser, without using any kind of storage. It all happens in memory.

At the code level, it has a `fetch()` which does a read from one pod, followed by a `then()` which does a write to another pod.
