This repository has been archived by the owner on Apr 16, 2021. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 48
Draft of 0.4.0 blog post #30
Closed
Closed
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,42 @@ | ||
--- | ||
date: 2016-01-10 | ||
id: 10-ipfs-0-4-0-released | ||
template: tmpl/layouts/post.html | ||
baseurl: .. | ||
breadcrumbs: | ||
- {name: "10-ipfs-0-4-0-released", link: "./" } | ||
tags: modules | ||
title: IPFS 0.4.0 has been released | ||
author: Kyle Drake | ||
collection: posts | ||
--- | ||
|
||
[IPFS 0.4.0](https://github.com/ipfs/go-ipfs/releases/tag/v0.4.0) has been released! Among the many changes are a revamped implementation of the IPFS communication protocols, increased performance, improvements to IPNS, many bugfixes, and a couple new features to make IPFS even more powerful. | ||
|
||
### On Breaking Changes | ||
|
||
This is a **breaking change** release, with a major refactor and upgrade to the IPFS networking protocol. Because of the refactor, **all IPFS daemons earlier than 0.4.0 will not be able to communicate with the newest version**. It is strongly recommended that everyone running an IPFS node upgrades to the latest version as soon as possible, as these nodes will, after a certain time, no longer be able to communicate with the majority of the network until they are upgraded. | ||
|
||
Refactoring the protocol is not something to be done lightly. But at this early stage, this is necessary to ensure we have the right design for IPFS in place for the future. It's better to improve the protocol now during this alpha stage of the project than when there are a lot more people running nodes across a lot of different implementations. | ||
|
||
One of the important changes that's been made to the protocol means that *there should never be a breaking change like this again*. This is due to a change to allow nodes to announce the version of the protocol they are using when connecting to other IPFS nodes. The goal is to roll any future protocol changes into the implementations gradually, so that we can still support legacy protocols for a period of time, making it easier to deprecate old versions over time. | ||
|
||
## Why we're changing the protocol | ||
|
||
The most important change was to allow IPFS implementations to use pluggable stream multiplexers, such as [yamux](https://github.com/hashicorp/yamux), [spdystream](https://github.com/docker/spdystream), or [muxado](https://github.com/inconshreveable/muxado). Instead of locking IPFS permanently into a single multiplexer that won't work for every language or situation, this change allows the implementations to implement the multiplexers of their choosing. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. "... and then nodes will negotiate which multiplexer to use between them during the initial connection handshake" |
||
|
||
This modularity with stream muxing makes it easier for certain languages to improve performance. For example, the Go programming language may have muxado and yamux implementations that are really good, but many languages lack good (or any) implementations of them. For example, Node.js works well with spdystream in testing, and it would be nice to take advantage of that. And then there are options like 'multiplex', which may not have the same performance, but are much easier to implement. | ||
|
||
So by supporting as many muxers as we can, we get to choose the best multiplexers for the job. It also makes it much easier to implement the IPFS protocols in a new language. And of course, if a better multiplexers standard comes along, it will be easier to upgrade IPFS to support it in the future. | ||
|
||
In addition to the multiplexers changes, the protocol revamp has also improved efficiency and performance in a few important ways, including the elimination of a double wrapping of the length prefixer, and the removal of some unneccessary round trips between nodes. | ||
|
||
The way object pinning (`ipfs pin add`) works has also been upgraded to be much more efficient, which will improve the overall speed of adding and downloading IPFS data. | ||
|
||
## Other improvements, fixes | ||
|
||
In addition to a major protocol improvement and upgrade, this release adds a lot of new functionality, performance speedups, and stability fixes that make this the best version of IPFS to date. | ||
|
||
This release also includes improvements to IPNS, the IPFS way to do mutable data. IPNS uses keypair encryption to allow users to point a pubkeyhash to an ipfs object in a way that is crytographically verifiable. By allowing users to change what the pubkeyhash points to, this provides users with a single hash they can give to users to get the latest version of their data. This creates a seamless way to use IPFS to verify content, and to distribute content via trustless nodes in a smart, safe way. This brings IPFS closer to the goal of being a global filesystem of data, that can allow everyone in the world to help serve the world's data in a way that enriches and empowers everyone. | ||
|
||
So please upgrade your IPFS nodes as soon as you can, so you can take advantage of the improvements! |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess breaking and changes shouldn't be capitalised for consistency. Sorry.