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

Different way to pass site / app CID from meta tags #1

Closed
Gozala opened this issue Feb 14, 2019 · 1 comment
Closed

Different way to pass site / app CID from meta tags #1

Gozala opened this issue Feb 14, 2019 · 1 comment

Comments

@Gozala
Copy link
Owner

Gozala commented Feb 14, 2019

At the moment meta tag is used to set the IPFS path for the site being hosted, however it's problematic because on first load SW will cache and there for CID updates do not propagate. Either way HTML and meta tag isn't ideal so here are couple of alternatives to consider:

DNSLink

It might be a better idea to use DNSLink in which case SW could lookup CID via /api/v0/dns/ to figure out what the CID is and cache it locally. Occasionally it could check if it was updated and take that into account.

Pros

  • No need to deal to generate anything, meaning all the every app / site could just point to static site returning same html / sw js.
  • config free!

Cons

  • Updating DNS records isn't necessarily an improvement. Use of IPNS might be a way to avoid however IPNS update in practice propagates even slower than DNS records do.
  • DNS Lookup requires a server in case of in-browser implementation.
  • Everything will need an origin in this instance.

CID in importScripts

At the moment lunet looks at the meta tag and passes query argument to SW script. Instead of meta tag however we could pass CID to importScripts instead in which case update of CID will in fact cause SW update as well.

Pros

  • Fixes the issue

Cons

  • Awkward way to configure / update

Just fetch index.html occasionally

We could leave everything as is. Just add some code to SW to quire index.html every now and then to pick up updates.

@Gozala
Copy link
Owner Author

Gozala commented Feb 19, 2019

I'm pretty convinced at this point that #2 is a better way to move this forward. So I'm closing this issue in favor of that solution.

@Gozala Gozala closed this as completed Feb 19, 2019
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

1 participant