Domain and deployment

[ghost]

Just quick questions for keeping track of infra things:

• Is this deployed through IPFS or github pages?
• Where's the domain registered? (We should move it to Gandi and DNSimple)

[mikeal]

• github pages
• iwantmyname.com, i can migrate it to whatever we like whenever we decide to do so.

[mikeal]

For the DNS migration, let's do that after DWeb but before we do any kind of public promotion about this resources.

[ghost]

Thanks! Yeah let's definitely do it only after DWeb Summit

[mikeal]

It's after DWeb :)

Let me know when it's a good time to migrate the DNS :)

[ghost]

Cool -- could you give me access to the account so I can just do it in one go, without coordination? If there's anything else in the account, I can also initiate a traditional domain transfer, and you'd give me the token, and later confirm the transfer.

---

Regarding deployment, you can do something like what PeerPad does: https://github.com/ipfs-shipyard/peer-pad/blob/master/ci/Jenkinsfile

The ci/Jenkinsfile triggers the build, and record sets a branch-recordname mapping, i.e. master commits will update /ipns/dev.peerpad.net and production commits will update /ipns/peerpad.net.

Regardless of any branch/record mappings, you get the website built and the link displayed via Github's commit build status.

[mikeal]

It's my personal iwantmyname.com account so I'd prefer to just walk through the transfer in a private channel (Slack?).

RE: Jenkins

I don't have any opinions about the deployment environment. I assume that, given I don't have access to infra, I won't be responsible for maintaining it, so whatever the people doing the work are comfortable with is fine with me. I would just prefer that:

• Master commits deploy to "production."
• Each commit/push gets an IPFS-only content-addressable deploy.

[ghost]

Okay get me a transfer authorization code :)

[ghost]

We'll have to wait until the domain is at least 60 days old: https://www.gandi.net/en/tlds/school/rules

[terichadbourne]

@lgierth @mikeal Is this issue still relevant? If so, has enough time passed for us to make the change and close out this issue?

Note that since this issue was first opened, what used to be a repo within the ipfs-shipyard org became its own org, and there are now additional repos for local chapters, all of which need to be able to deploy using GH pages. I don't understand the context of this issue well enough to know whether this is relevant. We also now use "code" instead of "master" as the main branch of the protoschool.github.io repo because of the way Vue and GitHub pages need to work together to deploy.

Note that we are launching publicly next Monday (Jan 14), so if we need to take any steps that could bring the site down I'd like to avoid that date please. 😂

[ghost]

This can wait, go launch the thing :):)

[terichadbourne]

Just chatted with @mburns to wrap my head around this one a bit more since it's not in my wheelhouse. I think there are two separate stages here which can be addressed separately:

1. Transfer the proto.school DNS/domain from @mikeal to PL, leaving the content hosted on GitHub Pages. This could be done Sooner™, and I believe it would unblock Redirect porto.school to proto.school  #145, redirecting porto.school to proto.school.

2. Move hosting from GitHub Pages to IPFS. (Since this issue was created, we got rid of Jenkins and moved to Circle - @olizilla may have assisted in that and have some insights when the time comes.) With Infra a bit stretched now, ProtoSchool still under development, and some gateway reliability issues to address for IPFS, I'd recommend doing this Later™. (I believe this step would ultimately unblock Feature: Use DNSLink #274 (using DNSLink).) However, when we get to it we need to remember that we've told our chapter organizers that they can use their GitHub repos to create websites using GitHub Pages and have them automagically appear on our domain.

[olizilla]

@terichadbourne your assement here is correct.

and...

However, when we get to it we need to remember that we've told our chapter organizers that they can use their GitHub repos to create websites using GitHub Pages and have them automagically appear on our domain.

Given that, we could do both! We can keep the site hosted on github, and all the free deployment automation that gets us including chapter pages, but we can also add the site to IPFS and update a DNSLink record during the CI build. Regular browsers would hit the github server. Users with companion installed would fetch the site via IPFS, and those that wanted to pin the site locally could do so with a ipfs pin add /ipns/proto.school. If we do it all in CI, then we can be sure that the DNSLink would stay up to date with what is deployed to github.

[terichadbourne]

Thanks @olizilla - good to know we could potentially have the best of both worlds when the time comes. If someone's browser tried to access the IPFS-hosted site and failed because of gateway issues, would there be any way to say to them "hey, wanna try getting this from that old-school internet"?

[terichadbourne]

Merging some conversation from #274 into this issue and closing that one in favor of continuing the convo here. Some relevant notes from that thread:

@Stebalien :

I'm not sure if this is possible but it would be awesome if proto.school could use DNSLink. I'm preparing for some potentially offline presentations and was able to simply "pin" dag.ipfs.io, explore.ipld.io, and cid.ipfs.io, but not proto.school.

@hacdias:

@terichadbourne I think this is a must: having ProtoSchool on IPFS itself would be awesome.
If I understand correctly, each chapter can publish to https://proto.school/, right? If so, I think it will be a bit harder to put this on IPFS, otherwise it should be rather simple.

@terichadbourne:

Yes that's right @hacdias, and we also have the issue where we're using hash-based routing within the whole Vue SPA, which I know can sometimes make it harder to host on IPFS.

@hacdias

Not sure if I'm understanding correctly, but Web UI also uses hash-based routing and it works perfectly when hosted on IPFS 😃

@terichadbourne :

Perhaps another issue would be how localStorage works? If there would be an IPFS-hosted and a "normally"-hosted version of the site, I assume the caching of the user's progress wouldn't be recognized unless they always visited it the same way?

@hacdias:

You are correct!

[zebateira]

Update on IPFS deployment

@andyschwab deployed to fleek so we could have the option to deploy to IPFS in the future, but the build is failing most likely because of our new use of the prerender-spa-plugin that uses puppeteer:

2:59:11 PM 07/27/2020: Error: Failed to launch chrome!
2:59:11 PM 07/27/2020: /workspace/node_modules/puppeteer/.local-chromium/linux-686378/chrome-linux/chrome: error while loading shared libraries: libX11-xcb.so.1: cannot open shared object file: No such file or directory
2:59:11 PM 07/27/2020: TROUBLESHOOTING: https://github.com/GoogleChrome/puppeteer/blob/master/docs/troubleshooting.md

So I'm guessing we'd have to tweak the build settings with a docker image to make this work (Puppeteer's Troubleshooting).

For now we will move to netlify because of time constraints to work in this issue, but in the future we should address this.

[terichadbourne]

Couple of quick new and old updates here:

• We've already transferred ownership of the proto.school domain from Mikeal to our infra team.
• We've transitioned from GitHub pages to Netlify to enable page-by-page metadata for improved SEO, a default branch that's not called master, previews, and history routing with successful redirects from the old hash-based URLs.

Left for this issue is a transition to hosting on IPFS via Fleek, which isn't urgent but has a couple of hurdles to overcome as noted in @zebateira's previous comment.

[andyschwab]

Additional note: when you're ready to host on IPFS, Fleek has offered to help develop a custom Docker image to support this use case.

[terichadbourne]

@andyschwab A few questions about Fleek and IPFS hosting before we pull the trigger...

• Will there be any weird IPFS URLs visible to the user, or will they only see https://proto.school/whatever?
• Will users ever get the very annoying and ugly "can't resolve" IPFS messages instead of our nice 404s?
• Is there some sort of "normal internet" fallback so the website will still work if the gateway goes down?
  (@zebateira's understanding is that Fleek has two options - normal internet with DNS and IPFS with DNSlink and we can flip a switch if the site breaks, but that the user won't be choosing.)
• Would the URLs be the same in both versions (causing two different versions of localStorage and breaking our progress indicators)? (@zebateira says no because the domain visible to the user won't change and localStorage won't care what's behind the DNS)

[andyschwab]

Great questions. I'll answer to the best of my ability!

TLDR: Most users will get exactly the same experience they get now. The users that may get a different experience will be those that are using IPFS Companion or intentionally accessing the site through an IPFS Gateway - but presumably they know what they're asking for.

1. The only people who will see beautiful IPFS URLs are users who have IPFS Companion installed or intentionally access it through a gateway. The new subdomain mapping makes this much more elegant (to my eyes, at least) regardless.
2. Fleek is using IPFS 0.6 right now, so the only way they should get the "can't resolve" IPFS message is if there is a serious deployment issue (Fleek has been amazingly responsive getting issues resolved when they do come up).
3. If I understand correctly, Fleek runs their own cluster to host their sites, and uses CloudFlare as a CDN to improve delivery. For most users most of the time, they'll be interacting with the CDN in keeping with a traditional web experience.

LocalStorage considerations are more interesting. Again, unless you're already using IPFS Companion or access sites through IPFS, this is a non-issue. Most users will use Web2 tech, and it will function identically to how it does now. However, when accessed over IPFS, there are two considerations:

First, the URL will depend on which gateway you access the site through (local, dweb.link, ipfs.io/ipfs, etc.). So long as you use the same gateway, all should be well - in the short term, at least.

Second, over the longer term - as the site is updated to new versions - the root CID will change. This will change the subdomain the browser sees when accessed through a local node or from dweb.link. @lidel is 1000x more knowledge about this challenge than I am, though, and may have some recommendations. When accessed through ipfs.io/ipfs or other non-subdomained gateway, it should still work - with the caveat that you're sharing userspace with every other site accessed this way (so maybe use very unique LocalStorage key names?).

[terichadbourne]

Thanks @andyschwab. Just to clarify, if we move to Fleek now, is there a box we can check that says "only serve this up on Web2, NOT on IPFS"? Or is it that as soon as we make the move, people who have IPFS Companion will get it on IPFS while others get it on Web2?

If it's the former, we're probably ready to pull the trigger, but if it's the latter we may not be.

[terichadbourne]

One more IPFS Companion question that affects this... if no one shares a special web3 link with you, and you visit https://proto.school with Companion installed, does it automagically notice that it's possible to get it on IPFS and switch you to the "beautiful" IPFS URL?

[terichadbourne]

Was just reminded of an issue about redirects not working on IPFS. Unclear to me whether this problem would affect us on Fleek as well.

[andyschwab]

@terichadbourne, @zebateira - are you currently dependent on redirects that functioned in the previous GitHub / Netlify build?

There is no switch in Fleek to turn off IPFS. However, we can choose not to implement DNSlink, in which case IPFS Companion will not know it is available on IPFS.

[zebateira]

@andyschwab we are not 100% dependent on it in regards to functionality (we have client-side redirects), but we need them for SEO scoring purposes.

Regarding DNSlink, I think we can proceed without it, and then when we are ready to make an IPFS version available we can discuss all the changes that need to be done in a new issue.
Basically we need proto.school to not show the ipfs version to IPFS companion users, but the regular version instead since the IPFS version is not yet fully functional.

[terichadbourne]

Agreed. We're ready to transition to Fleek without DNSlink enabled and are not ready to let IPFS Companion users see the IPFS-hosted version. I just opened issue #548 to track things that need to be changed before we can have the site function properly on IPFS with DNSlink enabled.

[andyschwab]

Got it. Taking a look at the Netlify config, the 404 redirects can be handled with an ipfs-404.html in the root. The functionality that would be missing is the chapters / events redirects (this could potentially be handled with manual redirect pages for each chapter).

#548 looks good for tracking IPFS-readiness.

[terichadbourne]

Closing out this issue in favor of continued discussion in:

• Chore: Move hosting to Fleek #524 for current move to Fleek (without DNSlink)
• Address blockers to enabling DNSlink and allowing discovery via IPFS Companion #548 for blockers to making ProtoSchool functional on IPFS and enabling DNSlink