"move it at any time, without interruption of service"?

#1

This might be a stupid question, but I didn’t find anything on it yet, so here we go. On the Solid How it Works page, we find this statement:

Since you own your data, you’re free to move it at any time , without interruption of service.

That sounds great in theory, but normally, when I move data, all the links to it need to be changed, or I need to leave a forwarding address. I can imagine that the process of moving data triggers notifications to all the other pods that are known to link to my data - but what if there was some public data where I don’t know where all the links to it are? (ie: Links locked away in some emails)

The more I think about, the more complicated it gets in my mind, so some pointers to how this should work would be greatly appreciated. :slight_smile:

Questions for inrupt
#2

I think that with “move” they mean that you can move your data to a new server, just redirect your domain and everything just works as before.

#3

That would be doable, provided you have

  • an own domain
  • the data on a pod that is attached to that domain
  • and the means to backup and install the pod on a new machine

At the danger of sounding snarky - but that is then the same as if I host my own blog / Nextcloud instance. Not every enduser will want to do that. (heck, even I don’t want to do everything on my own these days anymore.)

So how would I do the move from the Pod I have at jollyorc.inrupt.net to some other service, say solid.community?

Will tying web IDs to hosters create lock-in?
#4

I can’t see how you can move without breaking stuff - especially not with linked data. Everything in linked data is based on referencing other linked data resources by their URL.

If I have my own blog and that blog references my own images with RDF statements like [<http://my-domain/my-blog/post-1>, has-image, <http://my-domain/images/img1.jpg>] and I then move to a different POD provider, then non of that statement would make sense as neither blog post 1 nor image 1 exists on those URLs anymore.

Moving from one POD to another needs some kind of fancy rewrite of all moved statements before it will work.

That seems like a big problem - unless others have already figured a nice solution?

#5

Which is fine, users will then pay a company to do that for them.

I guess we will have some import/export feature at some point.

Yes, indeed, but moving to a different POD does not necessarily mean that you need to change the URL. Ideally, you would keep the same URL. Millions of website move from one hosting service to the other every day, without breaking urls that have been in use for years. This is not different from PODs.

Best practices for ownership in social?
#6

again, I don’t want to be snarky, I just want to grok things:

  • "moving without breaking" means:
    ** download all data
    ** move/copy it to new pod instance, ensuring logical paths stay the same
    ** change DNS so incoming links keep working.
  • it does not mean:
    ** I have my data at jollyorc.inrupt.net, use it under that URL and somehow end up having it all at jollyorc.solid.community with all links again intact, using it under that new URL.
#7

Unless I don’t have my own hostname - for instance when I use a POD on Inrupt (https://elfisk.solid.community/) and later on want to move it to another provider (https://elfisk-2.evenbetter.com/).

With a “classic” database approach I could move my whole website and its database and then be up and running. But with linked data we mix hostname and database together, so my data is bound to a specific hostname … but that is just repeating what has been said already.

#8

So you mean here that you would need to rewrite the urls to reflect the new domain?

Well, in my opinion, you should always publish Linked Data under a domain that you control. You are responsible that it stays dereferencable, that people can work with it. However, I have to add: if your WebId allows to dynamically find all the rest of your data, then you “only” need to make sure that WebID url remains the same. And the moment you move, you make sure that the urls in the your profile are updated.

#9

So you mean here that you would need to rewrite the urls to reflect the new domain?

well, do I need to? That’s the heart of the question. I’m fine if the answer is yes, because then I know I understand what is meant with the statement of “you’re free to move [your data] at any time.”. But at the same time, I’ll also know that the “without interruption of service” is to be taken with a large grain of salt.

It is important to understand that only a comparatively small fraction of people actually bother with webhosting. There are vastly more blogs that have an address like thisismyblog.blogger.com or myotherthing.tumblr.com than there are people who bother getting a DNS entry pointing to their sites.

If you say “move anytime”, they expect something where they don’t have to go to their DNS settings, because they have never touched DNS settings before.

I completely understand that this community right here is not made up of that userbase. But we should keep them in mind.

But I think the last sentence of yours is the thing that is needed to understand things:

make sure that WebID url remains the same. And the moment you move, you make sure that the urls in the your profile are updated.

There are pods, the things that store your data, and there is the WebID, the thing that stores your identity. You can easily switch pods, because your WebID will then tell other entities where your data is now - but you cannot easily change the WebID, because that is the directory things look at.

Did I get that right?

#10

Correct - for “now and future” use. But it won’t help all those applications that has stored a reference to my earlier data location (not even my own application data which is most likely to hold absolute URL references internally).

“move it at any time, without interruption of service” is just a very bold statement about Solid - and to some point I would even call it misleading. A promise that can be difficult to fulfill.

#11

It depends on how you created your files, with relative paths or not, but in the latter case, yes you have to rewrite them.

Yeah true, things like this are important.

Yes indeed. That’s how I see it at least :wink:

#12

Wouldn’t it be possible to store your WebID as data in an ‘identity directory’ app, and supply that URL (http://directory.inrupt.net/my_key) for apps to initially look up your WebID, from which they obtain your pod URL to use as base URL for links? The WebID could then be relocated by updating any directory apps you have referenced. Apps could even be retrofitted to support this redirection by adding lookup support and dynamically updating their ‘old’ absolute URLs with the new data URL.

#13

I believe all of this is supposed to be taken care of with “303” links. All linked data is supposed to be able to be dereferenced. That was all taken care of more by the RDF standard than by Solid itself. Solid is just extending off of RDF.

#14

That would result in centralisation again.

#15

DNS is a kind of centralisation but it’s relatively cheap to own a domain and easy to migrate, so this is tolerable.

I like the 303 links. Perhaps the hosts can periodically run an app that updates the links and flag dead ones. It won’t be as easy as it sounds here probably.

#16

I think it’s can be done with some modification in the way we store the linked data

1./ If a blog refer to my photo instead of using the domain in the link, the pieces of data on their pod could refer to something like :
<https://[my public key]/photos/beach>
and we keep a key value database on the pod with key is the public key of the post owner and data is an json format of something like { “domain”: “mydomain.com”,“lastchange”:[a time stamp], “sig”:" a signature to the data" }

2./ when I want to change my pod, my new pod then broadcast a message to the network with my new domain/ip, a timestamp and a signed signature that prove the change come from me.

3./ when a pod’s is being requested by a client with a link that is broken, they will broadcast a message asking if there’s an update version of the host from the public key’s owner of the post. This of course needs to be done with a time to live for the message to prevent flooding the network with this kind of message

This approach require more work because it’s involve setting up a p2p network between the pods ,or maybe introduce more technical problem we need to solve . But with this approach I think we’ll get closer to a free and more decentralize Internet. People don’t even need a domain or even a static ip to host their blog . Of course it’s not recommended to host at home due to unstable internet connection and such.

If this idea is adopted by the dev team ,I would very much like to work with the team to make it through the code stage.

#17

There’s quite a couple of alternatives to DNS we can consider, DNS indeed being the one centralized piece of Web infrastructure.
An alternative way of thinking that @timbl has suggested in the past, is to basically have a local version of the hosts file which is synchronized with peers.

#18

Another relevant take on the same problem and reference to the SAFE network in this topic

#19

I’ve thought about this a bit longer, and came up with this interpretation, where everything actually works fine:

You choose your Solid pod for authentication & data storage. This pod very rarely changes, as it is ideally with a host that you control or that is under trusted control.

Any services and applications you use then make use of that data, and you can move your data between those services and applications anytime, because you do keep your pod.

@MitziLaszlo, would that be a correct interpretation?