Thoughts on using IPFS for serving static websites

I recently wrote an article about the good and bad points of serving static websites on IPFS and thought the community would be an interesting place to discuss. I won’t copy the contents here but you can read it here:

(If people are interested I’m also considering writing a tutorial for creating production-ready static sites on IPFS)

3 Likes

Good article. Thanks for sharing it here. I wonder what the guys in here will say about the issue of getting the MIME type of data without having to put a file in a directory. I don’t know of any solution, but hopefully someone can clarify if this is still true. Having to put every file in a directory to preserve it’s mime type just doesn’t seem ideal, but maybe there’s much less overhead than it seems.

1 Like

I would love to have a mime type included. Even relying on the file-extension is hinkey. Sure, it is unlikely that a gateway doesn’t have .js map to application/javascript in the near future but it does cause an issue with less common or new file types (for example it took a while for most webservers to learn a mime type mapping for webassembly files).

In the general case if we rely on the gateways to add critical metadata to data in IPFS we are creating a compatibility issue, both in the near and long term.

I’m not too worried about the performance, but if we could inline the mime type into the data blocks it would be very cool.

1 Like

Well “file systems” themselves only have the file extension as the way to determine types (no mime types/names), so it’s not that bad, but I know what what you mean.

As long as there’s minimal overhead with everything being a directory, maybe the upside is everything’s always “appendable”. That is: you can always publish an update to a folder (using IPNS) with new files added, which would be impossible if everything was “files” instead of “folders”.

It isn’t that bad. But generally for local filesystems the application knows what type it is, or the user can select to override the choice detected by file extension+content sniffing. There are also more modern operating systems that do store the mime type explicitly and I would argue that this is a better design :slightly_smiling_face:

And when talking about HTTP gateways browsers do really care about the Content-Type header, and they don’t care at all about the extension (except for legacy content sniffing). So in this context it is actually somewhat bad.

Now you can argue that web browsers generally know what type of content they are requesting anyways. But that road leads to legacy and security hacks that aren’t going to change any time soon. Plus there are nice benefits, such as being able to request and display an image without needing to know what type it is upfront.

I’m not too sure I see your benefit about being able to add more files. IPFS is largely built on immutable content-addressed data. You are right that with IPNS you can push “updates” but that would be more an argument for not allowing IPNS to sign directories, only files. I think that if you are signing something you plan to update sticking to a directory so that you can add more things makes sense. However for a javascript file it doesn’t really make sense to “add more”. Sure, an updated file can import other files, but the browser still only cares about the first one.

Thanks Kevin. That was a great read! Can you elaborate on what you mean by the following?

… If the IPFS native protocol takes off this could also become a global benefit without relying on third-parties due to IPFS’s peer-to-peer sharing.

What I meant by that is currently the “free CDN” feature is based on the existence of public gateways. This isn’t really a decentralized approach and relies on the good will of those offering the gateways.

However if a large majority of viewers were using the IPFS protocol directly they would also help serve the site (in IPFS’ default configuration) to other IPFS viewers so this feature would become available without public gateways.

So this is a problem founded in adoption that should resolve itself in time if IPFS becomes more popular.

1 Like

Ah, you mean the bitswap part, right? As you download a resource you serve chunks to other nodes?

That is correct. makethiscomment20chars

That is just lame and abusing of good intending public gateways imho.
People should be incentivized to install IPFS Desktop (or just IPFS and IPFS companion). And if they persist in abusing the gateway, throttle throttle their speed to 1 byte per second or so.

Now i’m no IPFS author or dev, but the “free cdn” in your article stings me a little.
IPFS is not a free dump whatever you want CDN. I think the requests arriving through the gateway aren’t even super long lived either (if someone could confirm this?).

The pesky thing is that people read your article and write their own articles about it (or youtube videos) and then subsequently blame IPFS for creating a mindset of it being a free unlimited dump all you can CDN and then be disappointed when it’s not working like that.

1 Like

If IPFS gets to have native browser support, the vast majority of people will have no clue, nor care, that they are using IPFS, anymore than most people care about Ethernet, IP, HTTP, etc. The only people that will need to interact with it directly will be web developers, system administrators, programmers, and similar types of people.

Until we get native browser support, most people not in the IPFS space will only ever interact with the gateways. There needs to be a balance between using the gateways to promote IPFS and prove it works, and abusing the gateways and having them drop out or block entire categories of content.

1 Like

Welcome to the IPFS community, kevincox, and thank you for your link and for considering creating a tutorial on how to create a static website.

If you do go ahead with that tutorial, I hope that you do it in such a way that you can publish one hash for the website, for people to find you, which remains constant, regardless of edits you subsequently make to the pages there.

By default, Brave Browser already offers to install IPFS companion.

If I understand the question correctly this can be done for any IPFS website by publishing the hash via IPNS (which gives you a stable has for updating content).

While this is definitely an improvement and something to be glad about, this is not what I meant by “native browser support”. Brave, Firefox, and the other browsers have native support for HTTP(S), meaning that you don’t have to install an extension for it to work; support is built into the browser and is tightly integrated into things like the browser cache.