Today I checked in on cjdns to see where the project was. It looked about like it did the last time I checked it several months ago. While reading doc/bugs/policy.md I noticed a link that went to archive.org because the original site was dead due to domain name expiration. Thinking about how IPFS could have kept sites like this alive even when the original owner abandoned the site, I dove down a rabbit hole and ended up with a mirror of the site.
I was reading thru the latest posts at No Tech Magazine and saw this article on designing web pages to last a decade. A lot of what is covered very much applies to websites on IPFS. Here is the list from the article (which you should read):
Return to vanilla HTML/CSS Don’t minimize that HTML Prefer one page over several End all forms of hot-linking Stick with the 13 web safe fonts +2 Obsessively compress your images Eliminate the broken URL risk Of these, #1, #2, #4, #5 and #6 absolutely apply to IPFS sites.
Yesterday, I threw together a proof-of-concept comment system for use with IPFS websites. You can find the demo here. I expect this link to become unreachable once I transition from a proof-of-concept to a production system.
How it Works The comment system consists of the following parts:
The web page with comment submission form. This is hosted on IPFS using IPNS for mutability comments.js that contains the existing comments. pubsub-comment.js contains functions for submitting comments with AJAX and updating the static page to include existing comments A pubsub relay server.
About 26 hours later, and somewhere between 10 and 14 hours of programming in a language I had not used before, I have a libipfs at a Proof of Concept stage. I have a program written in crystal (because I am familiar with it and it lets you right C bindings in crystal) that initializing an IPFS node, connects to the bootstrap nodes, and downloads the CID from the ipfs-as-a-library example.
I have had an idea floating around for a while now about a C interface to IPFS. Today, I stumbled upon this thread about using ipfs as a library. I remembered the C-library idea and was able to find this article about how to make go libraries that can be called from C. And thus I dove head-first down the rabbit hole and spent the next two hours creating a proof-of-concept C bindings for go-ipfs.
I will not be doing the server maintenance that I was planning on doing this weekend, because of poor planning on my part. Can’t find high-percent isopropyl alcohol in the stores in my area, so I’m going to have to wait for the 99% bottle from Amazon (Jeff Bezos, International Man of Monopoly) to arrive. From where I’m sitting I can reach out and grab a bottle of 70% that I bought several years ago, but I don’t really want that 30% water near sensitive electronic components.
I saw this thread at the IPFS forum today, talking about creating a search index for IPFS sites that I will be looking into, because I think it is a good idea and I think my ipfs scanner could have a crawler and indexer added to it without too much effort.
Today, to both see if it could be done and to make dealing with all my source code easier, I setup a set of git repositories that automatically publish to IPFS when a “git push origin” is run.
First, I setup the file structure to keep things organized.
./publish ./public/ ./public/ipfs-auto-repo.git ./public/ipfs-scanner.git # et cetera To initialize the repo being published, I did the following.
git init cd public/ipfs-auto-repo.git git init --bare vim hooks/post-update This was then entered into post-update:
The scanner may be causing problems with my IPFS node. I’ve had to forcibly restart the IPFS daemon on my server several times in the past couple of days since I started running the IPFS scanner continuously. It may be coincidence, because during this time I also started writing this blog somewhat regularly, but the scanner hits the node pretty hard. I am going to try a couple of things over the next few days to see if I can figure out what is happening.
I found why the scanner was only producing two pages: HTTP 301 Redirect.
If you look at the Release Notes for v0.5.0 of IPFS, you will find a section labeled Subdomain Gateway that details a feature where the HTTP gateway will generate a redirect to a subdomain when accessing /ipfs/$HASH and /ipns/$HASH using localhost, but not when using 127.0.0.1. My code was checking for a status code of 202 and treating everything else as a failure.