Request for Feedback: Solid Migrator spec and vocab

After my initial post in solid/specification - Gitter, I though it might be a good idea to request feedback from a broader audience, hence my post here.

We (PDS Interop effort) 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.

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.

We’d really like feedback on our ideas thus far, specifically our specification and related ontology.

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.

Thanks

Much thanks to @AJamesPhillips for already provided feedback, and @csarven for the excellent Linked Research on the Decentralised Web

Links

5 Likes

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.

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, 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/ 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 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!