hosted by GitHub pages, aliased to my personal domain. In fact, you can see the entire source for the site, including drafts for any posts I might happen to be working on here. As I started getting interested in the decentralized webSee also: distributed web, immutable web, permanent web, etc.

, I decided to experiment with publishing this site via contemporary peer-to-peer protocols - which means, of course, this site will persist regardless of what happens to GitHub’s central servers.

Dat and IPFS are two of the most prominent protocols at the heart of the decentralization movement, which aims to develop alternatives to huge cloud-based companies like google and facebook, and return power and control over information to the user by abandoning the traditional client/server archiecture. In a decentralized world, in principle there are only peers.

Dat and IPFS (which stands for Inter-Planetary File System) have relatively similar aims – they both provide a protocol and tooling for sharing content-addressable information between peers, with no single point of failure. Dat was originally developed as a means for scientists to share large datasets, but the ecosystem has however grown quite a bit beyond this initial remit – see, e.g., the Beaker Browser. IPFS on the other hand was pretty much always intended as a distributed alternative to the web, and there’s already an extension to integrate modern browsers with the IPFS protocol. There are of course other technologies on the scene, such as scuttlebutt (which I’ll probably write about some other time), and Tim Berners-Lee’s new solid platform, but for now dat and IPFS seem the most mature.

and dat at dat://patrl.hashbase.io. There wasn’t any real necessity to publish this site on the decentralized web - after all, the number of users who are going to visit this page via dat/ipfs is probably vanishingly small – but I thought it would be a fun experiment, and an opportunity to learn a little more about emerging peer-to-peer technologies, which I think are independently quite exciting.

IPFS

First, I’ll talk through how I publish my site on the IPFS network to /ipns/patrickdelliott.com via DNSLink.

Running an IPFS node locally

Before doing anything else, I needed to install ipfs, initialize the repository, and start the ipfs daemon - you can follow the instructions here.On the off-chance you happen to be another NixOS user, this is as simple as adding the following line to your configuration.nix!

After starting the ipfs daemon, you can check whether or not you’re connected to the network by running ipfs
swarm peers, which should return the ipfs addresses of your peers.

Publishing on IPFS

First, you need to retrieve the peer ID of your locally running ipfs node, by running the following command:

On my local machine, the source for my website can be found at ~GitHub/patrl.github.io/_site/. I ran the following commands, which adds the website to IPFS and retrieves the hash of the directory root:

DNSLink

We can go a step further and ensure that someone running a local IPFS node with the IPFS companion browser extension is automatically redirected to view the site on the IPFS network. This can be achieved by adding a DNS TXT record via your provider (I use cloudflare) with the following content, pointing at your base url (in this case, patrickdelliott.com):

Dat

Before talking about dat, a little background: what got me started with this whole endeavour was an (in hindsight, overly ambitious) attempt to migrate this site from GitHub pages to a personal web server, and publish to both https://patrickdelliott.com and dat://patrickdelliott.com via homebase. I managed to get this working after jumping through quite a few hoops, but found that homebase wouldn’t reliably sync with my website’s dat repository, and the whole setup required too much manual intervention to be really worthwhile. I’ll take another look at homebase once it’s a bit more mature.

In the meantime, I decided that a much more manageable solution would be to continue to host my site at https://patrickdelliott.com, while simultaneously syncing it with a dat repository pinned at hashbase.io - dat://patrl.hashbase.io.

Installing dat

The first step is to install the dat cli tool, by following the instructions here.

Creating a dat repository

Next, we want to turn our published site into a dat repo. Ordinarily, this would be as simple as running dat init in relevant directory, but things are a bit more complicated with a static website - ordinarily, my site gets built into $HOME/GitHub/patrl.github.io/_site, but every time the site gets rebuilt, this entire directory gets wiped, including any metadata generated by dat. This would mean I’d effectively have to initialize a new dat repo with a new hash every time the site gets rebuilt, and we don’t want that.

Instead, I did the following: first, I built the site and copied it into $HOME/dat/patrickdelliott.com. I then navigated to this directory and ran dat
init to create the dat repository. Next, I went to https://hashbase.io and followed the instructions there to pin my dat repo to dat://patrl.hashbase.io. I then navigated to the local and run dat share --watch false to share the dat repo to the pinning service for the first time.

Whenever I want to update the dat repo and sync with hashbase, I run a script called deploy-dat, from my site’s git repo. This wipes everything from the local dat repo, except for the dat metadata, and copies in the newly built site, before syncing with the pinning service.

An alternative tool for publishing on the decentralized web, by the beaker devs.

]]>A note on if-questionshttp://patrickdelliott.com/posts/2016-10-15-ifQs.html2016-10-15T00:00:00Z2016-10-15T00:00:00ZIf-clauses are weird. They have a couple of prominent uses: as the antecedent clause in a conditional if…then… statement (see (1)), and as an embedded question (1).

If Britta is taking this class, then I’m not.

Jeff asked if Britta is taking this class.

Here, I’m interested in the latter cases, which I’ll call if-questions. Their distribution is constrained in some interesting ways. Under rogativeHeim (1982) classifies predicates that embed questions, broadly, as either rogative or responsive. Rogative predicates are those which may embed interrogative clauses, but not declaratives, like wonder and ask. Responsive predicates on the other hand may embed both interrogatives and declaratives, such as know and tell.

predicates, if-questions seem, more-or-less, to be in free variation with whether-questions.

Jeff {wondered|asked} {if|whether} Britta is taking this class.

Elsewhere however, the similarity between whether-questions and if-questions breaks down. Unlike whether-questions (and interestingly, much like that-clauses), if-questions aren’t permitted as the complement of a preposition.

Britta thought about {whether|if|that} she should attend class.

Furthermore, if-questions generally seem pretty bad as subjects, unlike both whether-questions and that-clauses, which are attested, under certain conditions, in this environment.

{Whether|*if} Jeff attends depends on whether Britta attends.

That Britta is attending class worries Jeff.

These facts are clearly telling us something interesting about the syntactic properties of if-questions vis a vis other varieties of embedded clause, maybe specifically about their case properties. I don’t want to speculate more about this here.

Moving on, if-questions show some extremely interesting behaviour under responsive predicates, such as know and admit. These facts were first uncovered and analysed in a 2001 paper by Adger & Quer (2001)This is behind a paywall (https://www.jstor.org/stable/3087030), but you can apparenly download the .pdf here for free.

, who claim that if-questions exhibit polarity sensitivity under responsive predicates. The judgements are subtle, but the following contrast is fairly illustrative.This isn’t much discussed much by Adger & Quer (2001), but (8a) is almost certainly acceptable under the reading that can be paraphrased as “If Britta left, then Jeff told me (that Britta left)”. I assume that this is a possible analysis of (8a), since tell independently allows Null Complement Anaphora, as in “Britta left. Jeff told me.”

*?Jeff told me if Britta left.

Jeff didn’t tell me if Britta left.

Adger & Quer develop a theory tailored to derive this kind of contrast. I have some issues with their account, but I’ll leave that for another post (maybe!). For the time being I just want to note that the predicate imagine poses an interesting problem for the distribution of if-clauses, and its certainly outside of the scope of Adger & Quer’s account. First, note that imagine doesn’t embed whether-questions at all (9). The polarity of the matrix clause doesn’t seem to make a difference (10). However, when the matrix clause is an imperative (11), or otherwise a request directed at the addressee (12), an embedded if-question is licensed, despite the fact that an embedded whether-question still isn’t.

Jeff imagined {whether|if|that} Britta left.

Jeff never imagined {whether|if|that} Britta left.

Imagine {*whether|if|that} Britta left.

Can you imagine {*whether|if|that} Britta left.

Adger & Quer of course don’t consider this kind of data, but it’s difficult to see how one could extend their account to this, since as far as I can see, they predict if-questions to be licensed in a subset of the environments that whether-questions are.

Zooming out a bit, how the hell do kids acquire these kinds of subtle distributional facts, given that whether-questions and if-questions seem, roughly, to mean the same thing?

More selectional puzzles soon! And, as always, my deepest apologies to the non-linguists.