Hosting a POD on Github Pages? Yes, it is "possible"!

1

A while ago, I released a Solid App to display read-only Solid data. The idea was that you could create a container in your POD, make it publicly readable, and share the url with your friends to explore the data with a nice UI.

When I announced this, I got a comment wondering if this would work with static assets. At the moment, I said that it should be possible, given that from the application’s perspective there is no such concept as “static assets”. The application just issues a request and reads the response, it doesn’t know whether the content is static or generated by a script.

And that’s where I left it at the time.

Today, I thought I’d give it a shot and I did it for real. It was easier than I expected! I created a repository on Github with a bunch of turtle files, and I’m serving them through Github Pages. That’s it! It worked without doing any modifications in my app, which is nice.

This is just a proof concept, and I don’t intend to do more things like this. I still believe it’s better to use full-fledged PODs. But it is food for thought nonetheless, and I thought I’d share it here in case you find it interesting as well.

Here’s the repo with the static turtle files: https://github.com/NoelDeMartin/favorite-movies/

4 Likes
2

That’s pretty cool nice job man. I did the same type of thing but a little different about a year ago. Portal – Solid Home

Mikeadams1.GitHub.io/Solid-Pod

1 Like
3

Interesting, but unfortunately github does not send the correct content-type (text/turtle) but content-type: text/html; This will probably be an issue for most clients, that rely on content-type to decide e.g. what parser to use

4

Yeah I noticed that, so it’s not 100% spec compliant. But something I thought while I was trying this is that I think Solid Apps should be as much forgiving as possible.

In this case, they should use the Accept: text/turtle header and do the appropriate request following the spec, but if the server response is invalid but still parseable it should work. I compare this to Javascript/HTML “forgiveness”. For example, in HTML you may write <h1>Hello World<h1> and while that’s invalid, the browser will still render the page (I don’t even know if this HTML behaviour is described in the spec or it’s just something browsers do, but I think this kind of thing is valuable for interoperability).

Of course, it’s better if every server follows the spec 100% of the time. But, when they don’t, I think it’s useful to have this sort of behaviour.