Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CNAME to w3id.org possible? #2515

Open
alanruttenberg opened this issue Feb 4, 2022 · 3 comments
Open

CNAME to w3id.org possible? #2515

alanruttenberg opened this issue Feb 4, 2022 · 3 comments

Comments

@alanruttenberg
Copy link

A protection against single point of failure, however unlikely for this resource but nonetheless, is to own a domain name which points to w3id.org. PURLs for a project could then use a custom domain name if they wanted to protect against this potential failure point.

Is it reasonable to do this for w3id.org?

@davidlehn
Copy link
Collaborator

I'm not clear what the ask is here and how it would help.

My guess is:

  • do something like github and add a CNAME file in .../example/CNAME, that says it's example.org
  • example.org domain owner points their servers at a magic w3id.org server
  • requests to https://example.org/foobar/baz would go to https://w3id.org
  • those requests remaped to https://w3id.org/example/foobar/baz
  • then those requests finally redirected as configured now to... https://{elsewhere}/woof/meow/baz.ext

That seems to be getting a bit complex for this service. One of the main reasons this service exists is to avoid that initial domain in the first place! The idea was that semantic web resource naming was using domains or resource paths that change due to expired domains, changed ownership, maintainers that are gone, etc etc. So this service tries to provide URLs that could be stable for decades if needed by just updating redirect rules. But if you put a custom domain in front of that, you are back to the same problem that people might use that domain and then it expires and invalidates anything that was dereferencing those URLs.

I doubt this feature will happen anytime soon since the operational issues seem non-trivial. Would need background tasks to map added/changed/removed CNAMEs over to some load balanced front end that sets up letsencrypt certs and keeps them updated. And then internally maps domains to paths. That's a bit much for what would probably end up being a task for me. :-)

@alanruttenberg
Copy link
Author

For the OBO PURLS, we initially bought the domain obolibrary.org and came to an agreement with purl.org that we could aim purl.obolibrary.org at purl.org, with all our PURLs having the prefix /obo/. This turned out to be a fortuitous choice when PURL service was interrupted.

As it turns out, OBO now runs our own PURL service.

Now I am working with another organization that is considering using PURLs and I would like to do the same, if they decide to go ahead. The situation would be easier than you outline. The domain record for our domain would have a CNAME with w3id.org. We would use a PURL of the form https://example.org//foobar/baz, to https://w3id.org//foobar/baz, so no URL rewriting necessary. If the PURL service is the only domain hosted at w3id.org, then there is no need for further setup. Otherwise, the web server needs a VHOST entry to recognize our domain. The only ongoing cost is our domain registration.

I very well understand the intent of w3id and I hope it is indeed up and running in decades. But purl.org was also supposed to last forever. I don't recall exactly, but IIRC when purl.org came back up a year late at archive.org, the redirects database was not complete and the server had different redirect capabilities so we would have had to be reconfigured. In any case, when it went down it was undetermined if it would ever come back and we didn't want to wait and see. Having our own domain saved the day. I hope you can understand the desire to hedge our bets.

@davidlehn
Copy link
Collaborator

Yeah, I understand hedging bets on such things. How I see this ecosystem is that the service maintainers want to keep things simple and easy to maintain. Redirect authors want to depend on servers staying up and have fallbacks (and have it all be free of course). Redirect users want URLs to stay valid forever. It may be a pick two situation here.

I can see a couple issues with the mapping you propose. In many semantic web use cases I think users want to pick a URL for a resource and stick with it forever. Apps get static string comparisons and such that make URLs hard to change. w3id was kind of made for that purpose. The URL redirects can change behind the scenes as needed. If someone uses their own domain, then there is the same issue as before that the project might fade or domain change hands and all the old URLs could become invalid. w3id could fail too of course, but maybe the bet is that enough people are using it that someone will step up to keep it going if needed.

Another issue is the https cert issue. I think that will require CNAME config and DNS setup and magic to make it all work?
Unless someone steps up with a plan to make that all happen, I think just mapping purl.example.com to w3id.org will have cert issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants