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):
Of these, #1, #2, #4, #5 and #6 absolutely apply to IPFS sites. I am not sold on packing everything into a single page (#3) or completely eliminating site generators (#1), as can be seen by this multi-page website generated by hugo. #7 doesn’t quite translate to IPFS sites because the built-in replication can make the site available when the source server is down.
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.
The comment system consists of the following parts:
When you reload the page, the contents of comments.js is used to populate the comments section. It does a probe to determine available relays for comment submission. The script as written prioritizes 127.0.0.1:5001.
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 think this could expand into something useful because most programming languages have a way to call C functions.
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. Change the domain from ’localhost’ to ‘127.0.0.1’ and it started handling fetched pages correct.