Make website template use relative asset URIs

[dariusk]

This PR changes the templates for new Dat sites to use relative paths.

I think it's important to encourage people composing sites in Beaker to use relative paths for assets at all times. Specifically with things like homebase, I can make an https mirroring service that mirrors these sites from any subdirectory of a pinning host. This would break a site with absolute paths but a site with relative paths would still work. Obviously we can't enforce this coding style but encouraging it by providing this style in the template is a start.

(The js file listed in the website template already uses a relative path so I didn't have to change it.)

[pfrazee]

I'm 👍 to merge

I've historically pushed against pinning services that host dats under subpaths on https. The rule that I've always advocated (and implemented in homebase/hashbase) is that dats can only be mounted to their own subdomains.

Two main reasons for that are:

1. Because you do end up with this relative paths problem.
2. Because it breaks single-origin policy and so invites security problems.

My two reasons may not be enough to worry about in some cases but I'd keep an eye on them. I think you can mitigate item 2 with good CSPs.

[dariusk]

Hmm, this does align with the whole .well-known/dat working on a one hash per domain level, meaning that I could provide a .well-known/dat file for everything just like hashbase does...

[pfrazee]

@dariusk Yeah, you can get a wildcard cert from letsencrypt now, so it's pretty painless to setup the subdomain behavior.

[dariusk]

My very specific issue here is that the domain I'm using to pin already supports wildcard certs for other hacky reasons, but that's neither here nor there. I could probably do mypinnedsite.dat.friend.camp and call it a day.