IPFS is a new hypermedia distribution protocol, addressed by content and identities, aiming to make the web faster, safer, and more open. In these posts, we highlight some of the development that has happened in the past week. For anyone looking to get involved, follow the embedded hyperlinks, search the wealth of information on GitHub or join us on IRC (#ipfs on the Freenode network).
If you would like to get this update as an email, sign up for our weekly newsletter!
This weekly covers the last month. Here are some of the highlights for the February sprints!
Our friends and users at ConsenSys wrote an excellent "Introduction to IPFS", which starts with a less-technical preface, and then dives deep into a full explanation of how the IPFS object model works. It walks through multiple examples, including directory structures, version control systems, and blockchains. This is a great post to familiarize yourself with how the low level IPFS objects work, with graph visualizations and in-depth explanations. It also features a fantastic cover image! Thanks @ChrisLundkvist and @ConsenSysAndrew!
ipfs/go-ipfs. Give it a try:
docker run -i --net=host ipfs/go-ipfs. The new image is built automatically for every commit, and has automatic tags for the coming releases. It's also a few MB smaller, and doesn't require mounting a volume for the IPFS repository anymore. Instead, if there's no volume mounted, it'll generate an ephemeral identity and configuration which will be lost when the container exits. This is ideal for testing or just trying something out real quick. Images for go-ipfs 0.3.x are not provided, because the Dockerfile shipped with these version isn't suitable for Docker Hub automatic builds.
go-ipfscompatible with vanilla
go getinstallation. Hope to have more tangible results to show by end of the month.
@whyrusleeping shipped a PR that introduces the use of a tool called
gx, for vendoring our project dependencies. Previously we used godeps, and saved all of the code required indirectly to build ipfs in the go-ipfs repository itself. This was very difficult to work with for a few different reasons, first off, it made the size of the repository bloat way more than the original size of our codebase, causing clones to take longer, and making CI slower all around. Second, updating these dependencies was a hassle: this was partially the fault of go's poor package management choices and partially that we found godeps UX to be unfriendly. To solve the problem, @whyrusleeping create gx. Gx is a package management tool based on ipfs. Package references are all hashes linked in a merkletree, and resolving all the dependencies of a given project is as easy as an ipfs fetch. Now that we are using gx, the main go-ipfs repo is much smaller, dependencies can be easily fetched and installed (and shared across projects), and we also get to essentially bootstrap ipfs with ipfs.
From the average users perspective, there are a few small changes;
go get is no longer a viable way to install ipfs, and users will now need to run
make install as is common on other large golang projects (docker and kubernetes among them). You can read more about gx over here at its repo: github.com/whyrusleeping/gx and about gx-go (the subtool of gx specifically for go) here: github.com/whyrusleeping/gx-go.
@RichardLitt improved the
gx README document to better explain its goals, and help people get started. Take a look and give us feedback through an issue if you think anything could be improved.
@whyrusleeping wrote a tool called
ipns-pub to allow people to publish IPNS entries to the network without actually running a node. You can generate keypairs with ipfs-key and then use those keys to publish any ipfs path you like. Be aware though that entries published with this tool expire every 24 hours, so to keep them alive on the network, the tool has a
--daemon option that will republish your entry every twelve hours automatically.
The IPLD spec was merged, after months of thoughtful design. The bulk of the work was achieved by @mildred and @jbenet, with lots of comments and design opinions from many other contributors. The IPLD spec. The "thin-waist" Merkle DAG format, defines merkle-links, -dags, and -paths, as well as the IPLD Data model and formats. In short: JSON documents with named merkle-links that can be traversed. Stay tuned for more information in the future.
@RichardLitt finished logging all existing
ipfs commands for the HTTP API Spec. This means that if you have any questions about how the HTTP API should work, you can see them either in master or as open PRs to that issue. If you are interested in how the HTTP API should work, or have any specific questions, please see the current version, and explore the open PRs on that repo.
@diasdavid improved registry-mirror performance and robustness by removing the dependency on registry-static. The few necessary parts were copied in. This is a huge step in reliability and performance cloning the registry with registry-mirror.
@dignifiedquire fixed drag and drop file uploading, and some dependency issues. So go ahead and try it out.
@dignifiedquire rewrote the generation script and cleaned up the code so that now the data is consistently reproducible and fully stored on IPFS. This ensures that geoip lookups over IFPS will work in all future releases.
@chriscool improved important tests for fs-repo-migrations -- tests verify more edge cases when migrating forward and backward, through various sample workloads.
ipfs-hyperlog, and ipfs-compatible fork of hyperlog, a DAG that replicates based on scuttlebutt logs and causal linking.
ipfs-hyperlog is a drop-in replacement for @mafintosh's
hyperlog. Its key difference is that it creates a Merkle DAG that is binary compatible with IPFS objects. This means any node of any DAG built using ipfs-hyperlog can be replicated to and from the IPFS network as well!
Across the entire IPFS GitHub organization, the following people have committed code, created issues, or made a comment on GitHub between February 1st (noon, GMT) and February 29th. We're autogenerating this list using this tool and this other tool, so please let us know if your name isn't here.
This newsletter is also a community effort. If you have cool things to share for the next weekly, drop a comment about it in [the weekly repo](//github.com/ipfs/weekly! The more people mention items they want to see in the weekly there, the easier it is to make this and send it out.