One of the big points emphasized with solid PODs is if you don’t like one provider of PODs, you can always switch to another. It made sense at first, but as I thought about it more, how would one transfer their URL? If they went from this.provider to that.provider, all friends, likes, tags, etc would be pointing to this.provider, not to that.provider. Would this.provider set up a permanent link to that.provider? Or on transfer, should this.provider notify all PODs pointing to this.provider say to change it to that.provider? Another possible solution (though I don’t like it) would be to set up a temporary link from this.provider to that.provider, and on each request would tell that there is a new provider.
1 Like
Good question. We are setting up something for Solid (and Holo) called MyPod.ID. Basically a free, completely private/secure registration process, that allows people to register and manage their pods, IDs and URLs in one master place. Any changes to the server, or adding new avatars / projects, update MyPod.ID, and it updates the links. Sort of like a distributed DNS system. Many details and parameters to address but something like this will be the solution.
very rough site up now, https://mypod.id
Can you explain how this is decentralised? I don’t have time to dig in, but I haven’t been able to figure out how to decentralise this - other than people owning their own domains. Thanks.
This may be totally off-topic in the sense that it may be completely different to what you are looking for. If so, just delete this.
Is it not possible for this to work in the same way that online research currently works?
When research is published on the web it is given a DOI number (a unique and persistent Digital Object Identifier) similar to an ISBN number for a paper based publication.
However much it may later move location on the web, it can always be found by DOI number alone.
For example, the following url relates to 2005 research on intestinal microbes, the page has changed several times since first publication, but when it was first published it was given the DOI of 10.1016/j.cub.2005.03.032
The URL (containing the DOI number) still finds it: https://doi.org/10.1016/j.cub.2005.03.032
I don’t know how it works exactly, but the whole process is managed by a not-for-profit membership organisation The International DOI Foundation.
2 Likes
Interesting… I like that idea! So, applying that idea to PODs, you would get a URL that points to your POD. If you ever wanted to transfer to a new provider, all you have to do is update your URL and copy over your data.
Yes. Not sure how they work it behind the scenes, but the DOI Foundation would know.
From a user perspective, when I publish research to a peer reviewed science magazine, the magazine usually automatically allocates a DOI number.
If I download research papers so they can be viewed on the ResearchGate website, I get asked if I want to allocate a DOI number, and if I click on ‘Yes’, then it gets published on the ResearchGate website, but the same page can also be found using a DOI website address.
I think @Sea 's approach is good, it may become a thing like the Web Archive
.
Normally you can setup redirect in your old pod, so visitors and crawlers get redirected to your new POD.
But if old POD provider is down, visitors can then search the old link in MyPod.ID , and found the new location.
1 Like
Very similar to a DOI number, which will be useful when more and more sites and domains become distributed.
On a simpler level - think of the present Solid subdomains… in a master login, the subdomain could always remain the same, for “life”. e.g. sea.alternative-solid.site - but the A Record of, for instance, sea.alternative-solid.site could be pointed at the current hosting pod. A simple Solid DNS app could manage that.
Phase II we are looking at a Holo dAPP, and noting that it is not limited to Solid, but to similar and future platforms as well.
As for domains, they are part of the centralized world. Before I ran a domain company, I lost one of my most popular and successful domains because of lack of renewal notices from the reseller. It’s since been resold by others time and time again. Or the Registrar can change the rules, up the pricing (Uniregistry, .movie, etc), claim a violation of TOS, and take our domains away… so we cannot be dependent on domains at all. I’m working on a white paper for the disruptive future of domains and all signs are pointed to distributed networks of domains and fragments of distributed content to create pages. This acts like a Web Archive as well - helping to preserve old websites “forever”.
I was recently reading through the AT protocol, and one thing that I love about it is that all of the documents are cryptographically signed in a merkle tree to verify both document contents as well as ordering. I don’t think I merkle tree would be viable with SOLID since not all documents are visible to all actors, but would there be some way to “verify” a transferred pod? Or perhaps something like a zero knowledge password proof? It would be amazing to guarantee a transferred pod is who they say they are.