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)
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.
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.
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
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.
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.
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.
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.
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.
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.