Summary: We're trying to improve the site's availability (ensuring it can never be offline) and make it more censorship-resistant; people who adopt IPFS can make that happen while tackling the "bloated Web" and "centralised Internet" issues -- all at the same time

JUST over a month ago we hooked up with data-centric security folks who had offered help with Techrights. Having faced legal threats over the years (for exposing corruption), we're always looking for ways to avert or discourage such attempts (ideally, even if we're forced to go offline or remove something, we want that to be outside our control, i.e. inability to comply, even if there's a will to comply). We don't typically just repeat what other sites say, we have many exclusive stories and we publish leaks (unseen beforehand).

Now, less than a month later, we have a pipeline for publishing the site both as text and over distributed protocols. The Techrights IPFS node over here (at home) now exceeds 50GB in traffic, just 3 weeks down the line (after introducing people to it, i.e. 'going public'). Not bad considering how young it is. It's always active, offering full site access. There's no single point of failure, no HTTP, no WWW, no HTML. It's very text-centric and thus compact, portable and so on. No bloat associated with exporting/importing images, fonts, JavaScript and so on.

Earlier today we published many pages of internal EPO material; we need to get those sorts of things backed up, as EPO management can be litigious and threatening (they tried it on us several times). Techrights is home to many other important bits of material; months ago we published old debian-private archives (1990s only); those were accessed nearly 30,000 times in this past week alone. Giving Debian better transparency 2.5 decades later can't be a bad thing. In fact, nobody contacted us regarding removal or redaction. Those mailing lists are pretty harmless and barely even embarrassing. Due to their age, they don't present/pose a threat to anybody's career.

"In other words, the more people participate in this network, the more robust and censorship-resistant it'll become. This, in turn, can attract more high-profile whistleblowers with high-profile leaks."Now, on to the 'beef' of this post...

This past autumn we spent time coding and testing a bunch of stuff (at the back end for the most part). First we made everything in the site accessible in/as text. Plain text. Nice and simple. Then, we explored a number of distribution systems. At the end we went ahead of IPFS, seeing that it is decentralised and Web-agnostic (its protocols aren't connected to the Web, unless a gateway is set up). We already have a number of devices pinning and serving the site's pages (or objects) upon request by CID.

How can readers help? They can become nodes. The material itself isn't sensitive (everything in it is public anyway), but it's precarious in the sense that takedown requests can be attempted against our main servers; we want to make it very clear upfront that it's an exercise in futility because many copies of the articles are already 'out there', being distributed by peer, not from a single point (of potential failure).

In other words, the more people participate in this network, the more robust and censorship-resistant it'll become. This, in turn, can attract more high-profile whistleblowers with high-profile leaks.

An informal manual was typed up by one of us as a sort of primer for those wishing to set up their own node. It ought not be hard to achieve (by just following the series of steps). Those instructions were written for a Raspberry Pi with Debian, but the hardware and the distro ought not matter much because we use the binaries rather than repos.

"I'm going to outline a pragmatic setup that you can use to get going with IPFS on any host," said the manual's author. Here's the recipe:

---

SUMMARY

Make user + group for IPFS. All further steps are to be performed under IPFS user's "~/" (home directory).

Download and extract latest Go binaries available from official tarball.

Symbolic link Go binary executables, from tarball, into "~/bin".

Download and extract latest IPFS binary available from official tarball.

Symbolic link IPFS binary executable, from tarball, into "~/bin".

BEGIN IPFS BASIC USE GUIDE SUMMARY

What's covered:

IPFS conceptual overview.

Help from the `ipfs` command itself.

Initialise ipfs for your IPFS user.

List pinned IPFS objects.

Add/pin IPFS objects.

Remove pinned IPFS objects.

Run garbage collector for IPFS objects.

Check IPFS stats.

Check a file's CID without adding/pinning to IPFS.

SETUP DETAILS

Make a dedicated user and group for IPFS on your machine. This will keep things manageable, down the line. Everything should be done under the IPFS user's home directory "~/".

Grab the latest Go binary you can find. Set it up in the home directory of your IPFS user. You can find the latest Go binary here. There are builds for a wide array of operating systems and CPU architectures.

Extract the tarball; look in "/bin" in the tarball for the binary executables. Right now there are two binaries, "go" and "gofmt".

Create a symbolic link in "~/bin" for the binary executables you find in the Go tarball. You should be able to run `$ source ~/.profile` to make sure "~/bin" is in PATH, for the IPFS user.

This completes the Go setup.

Next, we tackle the IPFS setup.

Download the latest binary you can get for go-ipfs from here. This binary should be packed in a tarball.

Extract the tarball.

"go-ipfs" is the name of the binary executable. Create a symbolic link for this binary in "~/bin". You don't need to use the setup script provided. It'll just mess with things that don't need messing.

IPFS BASIC USE GUIDE

Think of IPFS as a filesystem that lives on the Internet. Each file is an IPFS object denoted by a hash called the CID (content identifier).

`ipfs --help` includes help for commands and subcommands. Always double-check with this to make sure that anything you read on the Internet about IPFS matches up to the binary you actually are using on your system.

Before you do anything with ipfs, make sure to run `ipfs init`. This will populate "~/.ipfs" for you. That's all you need to do for initial setup.

You can "deploy" ipfs locally with `ipfs daemon`; this process will be running in the foreground and print to the terminal (probably stdout). You can just put it in the background and redirect stdout and stderr to a log file to manually monitor what it's doing. Killing this daemon will mean your IPFS node is no longer online. Feel free to control this daemon in whichever method you choose. This guide is kept as abstract as possible to enable deployment in maximum number of environments.

Files from your host can be added to IPFS as something called IPFS objects. The ipfs command for this is, unsurprisingly, called `ipfs add`. `ipfs add path` will add the specified file or directory to IPFS.

By default, `ipfs add` "pins" objects in your local IPFS datastore. What is a "pinned object"? A pinned object is an IPFS object in your local IPFS datastore that doesn't get garbage-collected.

`ipfs pin ls` is a good way to view your pins. `ipfs pin rm` can be used to remove pins; if you try to remove the wrong type of pin, IPFS will get mad and yell at you because it's probably a recursive pin (you'll see what kind of pin an IPFS object is in the output for `ipfs pin ls`); a top-level pin will probably be of type "recursive" (so you'll need to remove that to get rid of all the pinned objects that are associated).

You can check bandwidth status with `ipfs stats bw`. Good way to keep track of your precious bandwidth. ipfs comes with some default pins. You might want to get rid of those with `ipfs pin rm` to save on bandwidth. Those pins are documentation, however, so it's up to you if you want to keep them around or not.

Just removing a pin is not enough to ensure pin(s) are no longer is eating up your local IPFS datastore space. `ipfs repo gc` will run the garbage collector to get rid of all the unpinned IPFS objects.

The default IPFS configuration is pretty sane. You can find the default config file for IPFS in "~/.ipfs/config"; the config file is formatted in JSON. See `ipfs config --help` for further details.

Remember: always check `ipfs <command> <subcommand> --help` for definitive guidance on your binary's implementation. `ipfs --help` should be skimmed, in full, before you do anything with IPFS; you will likely find commands to help you with what you want to do. Don't forget that `ipfs <command> --help` and `ipfs <command> <subcommand> --help` are always available for you as well.

Consuming IPFS objects is straightforward. Just look at `ipfs get --help` and `ipfs cat --help` for instructions.

To check what a file's CID is, without adding/pinning to ipfs, just run `ipfs add -n /path/to/file`; see `ipfs add --help` for details. This is going to be a very important operation if you want to do any automation. It helps knowing what a file's CID will be before doing any operations live IPFS operations on it.

You should now be able to independently navigate the Internet for further information on IPFS. Official, online, documentation available here. Remember to always cross-check `ipfs version` and `ipfs <command> <subcommand> --help` to ensure what you read on the Internet is applicable to the IPFS binary executable on your system. ⬆

Image attributions: Font Awesome (Creative Commons Attribution 4.0 International) and IPFS project (Creative Commons Attribution-Share Alike 3.0 Unported)