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).
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:
~/" (home directory).
~/bin".
~/bin".
ipfs` command itself.
~/".
/bin" in the tarball for the binary executables. Right now there are two binaries, "go" and "gofmt".
~/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.
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 --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.
`ipfs init`. This will populate "~/.ipfs" for you. That's all you need to do for initial setup.
`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.
`ipfs add`. `ipfs add path` will add the specified file or directory to IPFS.
`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).
`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.
`ipfs repo gc` will run the garbage collector to get rid of all the unpinned IPFS objects.
~/.ipfs/config"; the config file is formatted in JSON. See `ipfs config --help` for further details.
`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.
`ipfs get --help` and `ipfs cat --help` for instructions.
`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.
`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. ⬆