Skip to content

Releases: ipfs/kubo

v0.9.0

23 Jun 02:00
@aschmahmann aschmahmann
v0.9.0
This tag was signed with the committer’s verified signature.
aschmahmann Adin Schmahmann
GPG key ID: D7A248B705EE4F69
Learn about vigilant mode.
179d1d1
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
v0.9.0

go-ipfs v0.9.0 Release

We're happy to announce go-ipfs 0.9.0. This release makes go-ipfs even more configurable with some fun experiments to boot. We're also deprecating or removing some uncommonly used features to make it easier for users to discover the easy ways to use go-ipfs safely and efficiently.

As usual, this release includes important fixes, some of which may be critical for security. Unless the fix addresses a bug being exploited in the wild, the fix will not be called out in the release notes. Please make sure to update ASAP. See our release process for details.

🔦 Highlights

📦 Exporting of DAGs via Gateways

Gateways now support downloading arbitrary IPLD graphs via the /api/v0/dag/export endpoint. This endpoint works in the same way as the ipfs dag export command.

One major thing this enables is ability to verify data downloaded from public gateways. If you go to https://somegateway.example.net/ipfs/bafyexample you are using the old school HTTP transport, and trusting that the gateway is being well behaved. However, if you download the graph as a DAG archive then it is possible to verify that the data you downloaded does in fact match bafyexample.

Additionally, it was previously quite painful to download things other than UnixFS (files + directories) using gateways. It is now possible to download arbitrary IPLD graphs from gateways, making them useful as a general-purpose alternative to p2p transports.

This opens exciting opportunities in areas like thin clients, mobile browsers and IoT devices, which now can delegate IPFS resolution to any public gateway, and have ability to verify that the data received matches the requested hash.

☁ Custom DNS Resolvers

Resolution of DNS records for DNSLink and DNSAddrs means that names are sent in cleartext between the operating system and the DNS server provided by an ISP. In the past, the only way to customize DNS resolution in IPFS stack was to set up own DNS proxy server.

There is now the ability to customize DNS resolution and override the default resolver from the OS with DNS over HTTPS (DoH) one. We made it really flexible: override can be applied globally, or per specific TLD/FQDN. Examples can be found in the documentation.

👪 Support for non-ICANN DNSLink names

Building off of the support for custom DNS resolvers it is now possible to create DNSLink names not handled by ICANN and choose how that domain name will be resolved. An example of this is how ENS is supported, despite .eth not being an ICANN TLD you can point .eth to any ENS resolver you want (including a local one).

While go-ipfs may have some DoH defaults for a few popular non-ICANN DNSLink names (e.g. ENS), you are free to use any protocol for a naming system and as long as it exposes a DNSLink record via a DNS endpoint you can make it work.

🖥️ Updated to the latest WebUI

Our web interface now includes experimental support for pinning services, and various updates to Files and Peers screens.

Remote pinning services added via the ipfs pin remote service add command are already detected, one can also add one from Settings screen, and it will appear in Set pinning interface on the Files screen.

Data presented on the Peers screen can now be copied by simply clicking on a specific cell, and a list of open streams gives better insight into how a local node interacts with a specific peer.

See release notes for ipfs-webui v2.12 for screenshots and more details.

🔑 IPNS keys can now be exported via the CLI without stopping the daemon

ipfs key export no longer requires interrupting ipfs daemon ✨

🕸 Experimental DHT Client and Provider System

An area of go-ipfs that has been historically tricky is how go-ipfs finds who has the data they are looking for. While the IPFS Public DHT is only one of the ways go-ipfs can find data it tends to be an important one. While since go-ipfs v0.5.0 the time to find content in the network has dropped significantly the time to put/get IPNS records or for a node to advertise the content it has still has much room for improvement.

We have been doing some experimenting and have an alternative DHT client that essentially trades off some resources and in return is much more performant. We have also included with the experimental DHT client a bulk provider system that takes advantage of the new client to more efficiently do many advertisements at a time

This work is quite new and still under development, however, the results so far have been promising especially for users with lots of data who have otherwise been having difficulty advertising their data into the IPFS Public DHT

As described in the experimental features documentation the experimental client can be enabled using the command below (or modifying the config file).

ipfs config --json Experimental.AcceleratedDHTClient true

A few things to take note of when AcceleratedDHTClient is enabled:

  • go-ipfs will likely use more resources then previously
  • DHT queries will not be usable (i.e. finding which peers have some data, finding where a particular peer is, etc.) for the first 5-10 minutes of operation depending on your network conditions
  • There is an ipfs stats provide command that will help you track your provide/reprovide usage, if you are providing lots of data you may want to consider how to reduce the amount you are providing (e.g. Reprovider Strategies and/or Strategic Providing)

See the documentation for more details.

🚶‍♀️ Migrations

Migrations are now individually packaged

While previously the go-ipfs repo migration binary was monolithic and contained all migrations from previous go-ipfs versions the binaries are now packaged individually. However, the fs-repo-migrations binary is still there to help those who manually upgrade their repos to download all the individual migrations.

This means faster download times for upgrades, a much easier time building migrations for those who make use of custom plugins, and an easier time developing new migrations going forward.

Configurable migration downloads enable downloading over IPFS

Previously the migration downloader built into go-ipfs downloaded the migrations from dist.ipfs.io. While users could use tools like ipfs-update to download the migrations over IPFS or manually download the migrations (over IPFS or otherwise) themselves, this is now automated and configurable. Users can choose to download the migrations over IPFS or from any specified IPFS Gateway.

The configurable migration options are described in the config file documentation, although most users should not need to change the default settings.

The main benefit here is that users behind restrictive firewalls, or in offline/private deployments, won't have to run migrations manually, which is especially important for desktop use cases where go-ipfs is running inside of IPFS Desktop and Brave.

🍎 Published builds for Apple M1 hardware

Go now supports building for Darwin ARM64, and we are now publishing those builds

👋 Deprecations and Feature Removals

The ipfs object commands are now deprecated

In the last couple years most of the Object API's commands have become fulfillable using alternative APIs.

The utility of Object API's is limited to data in UnixFS-v1 (dag-pb) format. If you are still using it, it is highly recommended that you switch to the DAG ipfs dag (supports modern data types like dag-cbor) or Files ipfs files (more intuitive for working with dag-pb) APIs.

While the Object API and commands are still usable they are now marked as deprecated and hidden from users on the command line to discourage further use. We also updated their --help text to point at the modern replacements.

X-Ipfs-Gateway-Prefix is now deprecated

IPFS community moved towards dedicated Origins (DNSLink and subdomain gateways) which are much easier to isolate and reason about.

Setting up Gateway.PathPrefixes and X-Ipfs-Gateway-Prefix is no longer necessary and support will be removed in near future.

Proquints support removed

A little known feature that was not well used or documented and was more well known for the error message Error: not a valid proquint string users received when trying to download invalid IPNS or DNSLink names (e.g. https://dweb.link/ipns/badname). We have removed support for proquints as they were out of place and largely unused, however proquints are valid multibases so if there is renewed interest in t...

Read more
Assets 50
Loading

v0.9.0-rc2

28 May 00:20
@aschmahmann aschmahmann
v0.9.0-rc2
This tag was signed with the committer’s verified signature.
aschmahmann Adin Schmahmann
GPG key ID: D7A248B705EE4F69
Learn about vigilant mode.
4d31ec1
Compare
Choose a tag to compare
v0.9.0-rc2 Pre-release
Pre-release

Tracking Issue: #8058

Assets 47
Loading

v0.9.0-rc1

14 May 13:27
@aschmahmann aschmahmann
v0.9.0-rc1
This tag was signed with the committer’s verified signature.
aschmahmann Adin Schmahmann
GPG key ID: D7A248B705EE4F69
Learn about vigilant mode.
01ef535
Compare
Choose a tag to compare
v0.9.0-rc1 Pre-release
Pre-release

Tracking Issue: #8058

Assets 44
Loading

v0.8.0

19 Feb 00:38
@aschmahmann aschmahmann
v0.8.0
This tag was signed with the committer’s verified signature.
aschmahmann Adin Schmahmann
GPG key ID: D7A248B705EE4F69
Learn about vigilant mode.
ce693d7
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
v0.8.0

go-ipfs 0.8.0 Release

We're happy to announce go-ipfs 0.8.0! This release is focused on making it easier to work with pins. We have some snazzy new features around being able to ask remote services to pin data for you, and modifying large pin sets is much faster than ever before.

🔦 Highlights

🧷 Remote pinning services

There is now support for asking remote services to pin data for you.

This comes with a redesign of how we're thinking about pinning and includes some commonly requested features such as:

  • Pins can have names (and coming soon metadata)
  • Data can be pinned in either the foreground or background
  • Pins can be searched by name, CID, or status

Command-line users benefit from ipfs pin remote commands, which simplify remote pinning operations. The built-in pinning service API client executes all the necessary remote calls under the hood. HTTP API users have access to new commands under /api/v0/pin/remote.

As long a service supports the vendor-agnostic IPFS Pinning Service API, it can be used directly in go-ipfs.

Examples include:

ipfs pin remote service add mysrv https://my-service.example.com/api-endpoint myAccessToken
ipfs pin remote service ls --stat # confirm service mysrv is available

ipfs pin remote add /ipfs/bafymydata --service=mysrv --name=myfile  # will block until status is pinned
ipfs pin remote ls --service=mysrv --name=myfile
ipfs pin remote rm --serivce=mysrv --name=myfile

ipfs pin remote add /ipfs/bafymydata2 --service=mysrv --name=myfile2 --background  # queue pin request and finish instantly
ipfs pin remote ls --service=mysrv --cid=bafymydata2 --status=queued,pinning,pinned,failed
ipfs pin remote rm --serivce=mysrv --cid=bafymydata2 --status=queued,pinning,pinned,failed

More examples can be found under ipfs pin remote --help

A few notes:

  • Remote pinning services work with recursive pins. This means commands like ipfs pin remote ls will not list indirectly pinned CIDs.
  • By default, only finished, successful pins are listed. To list or remove pending/failed pins, pass explicit status: --status=queued,pinning,pinned,failed
  • While pinning service data is stored in the configuration file it cannot be edited directly via the ipfs config commands due to the sensitive nature of pinning service API keys. The ipfs pin remote service commands can be used for interacting with remote service settings.
  • An OpenAPI ipfs-pinning-service.yaml makes it easy to create or generate a compatible client/server. Anyone can implement it and allow for pin management.

🏠 Remote MFS pinning policy

Every service added via ipfs pin remote service add can be tasked to update a pin every time MFS root changes:

$ ipfs config --json Pinning.RemoteServices.mysrv.Policies.MFS.Enable

To avoid flooding remote service with many updates, go-ipfs will send them at most once every five minutes.

Details about customizing behavior of this feature can be found in configuration docs.

📌 Faster local pinning and unpinning

The pinning subsystem has been redesigned to be much faster and more flexible in how it tracks pins. For users who are working with many pins this will lead to a big speed increase in listing and modifying the set of pinned items as well as decreased memory usage.

Part of the redesign was setup to account for being able to interact with local pins the same way we can now interact with remote pins (e.g. names, being allowed to pin the same CID multiple times, etc.). Keep posted for more improvements to pinning.

🔒 DNSLink names on https:// subdomains

Previously DNSLink names would have trouble loading over subdomain gateways with HTTPS support since there is no way to get multilevel wildcard certificates (e.g. en.wikipedia-on-ipfs.org.ipns.dweb.link cannot be covered by TLS wildcard cert for *.ipns.dweb.link). Therefore, when trying to load DNSLink names over https:// subdomains go-ipfs we now forward to an inlined DNS name. Since DNS labels cannot contain . in them they are escaped using -.

/ipns/en.wikipedia-on-ipfs.org →
ipns://en.wikipedia-on-ipfs.org →
https://dweb.link/ipns/en.wikipedia-on-ipfs.org →
https://en-wikipedia--on--ipfs-org.ipns.dweb.link 👈 a single DNS label, no TLS error 🔒

Note: The last redirect is specific to HTTPS, and is triggered only when X-Forwarded-Proto: https header is present.
Recipes for setting up your own public gateway can be found in configuration docs.

💨 QUIC update

QUIC support has received a number of upgrades, including the ability to take advantage of larger UDP receive buffers for increased performance.

Linux users may notice a logged error on daemon startup if your system needs extra configuration to allow IPFS increase the buffer size. A helpful link for resolving this is in the log message as well as here.

👋 No more Darwin 386 builds

Go 1.15 (the latest version of Go) no longer supports Darwin 386 and so we are dropping support as well.

Changelog

Full Changelog
Read more
Assets 44
Loading

v0.8.0-rc2

29 Jan 06:59
@aschmahmann aschmahmann
v0.8.0-rc2
This tag was signed with the committer’s verified signature.
aschmahmann Adin Schmahmann
GPG key ID: D7A248B705EE4F69
Learn about vigilant mode.
4080333
Compare
Choose a tag to compare
v0.8.0-rc2 Pre-release
Pre-release

Tracking Issue: #7707

Assets 44
Loading

v0.8.0-rc1

09 Dec 18:07
@aschmahmann aschmahmann
v0.8.0-rc1
This tag was signed with the committer’s verified signature.
aschmahmann Adin Schmahmann
GPG key ID: D7A248B705EE4F69
Learn about vigilant mode.
02d15ac
Compare
Choose a tag to compare
v0.8.0-rc1 Pre-release
Pre-release

Tracking Issue: #7707

Assets 44
Loading

Release v0.7.0

23 Sep 00:15
@aschmahmann aschmahmann
v0.7.0
This tag was signed with the committer’s verified signature.
aschmahmann Adin Schmahmann
GPG key ID: D7A248B705EE4F69
Learn about vigilant mode.
ea77213
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
Release v0.7.0

We're happy to announce go-ipfs v0.7.0, it has a number of user facing changes so if you're wondering what happened to SECIO or why you're starting to see more peers with peerIDs that don't start with Qm checkout the highlights.

🔦 Highlights

🔒 Secio is now disabled by default

As part of deprecating and removing support for the Secio security transport, we have disabled it by default. TLS1.3 will remain the default security transport with fallback to Noise. You can read more about the deprecation in the blog post, https://blog.ipfs.io/2020-08-07-deprecating-secio/. If you're running IPFS older than 0.5, this may start to impact your performance on the public network.

🗝️ Ed25519 keys are now used by default

Previously go-ipfs generated 2048 bit RSA keys for new nodes, but it will now use ed25519 keys by default. This will not affect any existing keys, but newly created keys will be ed25519 by default. The main benefit of using ed25519 keys over RSA is that ed25519 keys have an inline public key. This means that someone only needs your PeerId to verify things you've signed, which means we don't have to worry about storing those bulky RSA public keys.

Rotating keys

Along with switching the default, we've added support for rotating keys. If you would like to change the key type of your IPFS node, you can now do so with the rotate command. NOTE: This will affect your Peer Id, so be sure you want to do this! Your existing identity key will be backed up in the Keystore.

ipfs key rotate -o my-old-key -t ed25519

📦 Key export/import

We've added commands to allow you to export and import keys from the IPFS Keystore to a local .key file. This does not apply to the IPFS identity key, self.

ipfs key gen mykey
ipfs key export -o mykey.key mykey # ./<name>.key is the default path
ipfs key import mykey mykey.key # on another node

#️⃣ IPNS paths now encode the key name as a base36 CIDv1 by default

Previously go-ipfs encoded the key names for IPNS paths as base58btc multihashes (e.g. Qmabc...). We now encode them as base36 encoded CIDv1s as defined in the peerID spec (e.g. k51xyz...) which also deals with encoding of public keys. This is nice because it means that IPNS keys will by default be case-insensitive and that they will fit into DNS labels (e.g. k51xyz...ipns.localhost) and therefore that subdomain gateway redirections (e.g. from localhost:8080/ipns/{key} to {key}.ipns.localhost) will look better to users in the default case.

Many commands will accept a --ipns-base option that allows changing command outputs to use a particular encoding (i.e. base58btc multihash, or CIDv1 encoded in any supported base)

📮 Multiaddresses now accept PeerIDs encoded as CIDv1

In preparation for eventually changing the default PeerID representation multiaddresses can now contain strings like /p2p/k51xyz... in addition to the default /p2p/Qmabc.... There is a corresponding --peerid-base option to many functions that output peerIDs.

🧮 dag stat

Initial support has been added for the ipfs dag stat command. Running this command will traverse the DAG for the given root CID and report statistics. By default, progress will be shown as the DAG is traversed. Supported statistics currently include DAG size and number of blocks.

ipfs dag stat bafybeihpetclqvwb4qnmumvcn7nh4pxrtugrlpw4jgjpqicdxsv7opdm6e # the IPFS webui
Size: 30362191, NumBlocks: 346

🔌 Plugin build changes 🚨

We have changed the build flags used by the official binary distributions on dist.ipfs.io (or /ipns/dist.ipfs.io) to use the simpler and more reliable -trimpath flag instead of the more complicated and brittle -asmflags=all=-trimpath="$(GOPATH)" -gcflags=all=-trimpath="$(GOPATH)" flags, however the build flags used by default in go-ipfs remain the same.

The scripts in https://github.com/ipfs/go-ipfs-example-plugin have been updated to reflect this change. This is a breaking change to how people have been building plugins against the dist.ipfs.io binary of go-ipfs and plugins should update their build processes accordingly see ipfs/go-ipfs-example-plugin#9 for details.

Changelog

Full Changelog
Read more
Assets 47
Loading

v0.7.0-rc2

10 Sep 19:45
@aschmahmann aschmahmann
v0.7.0-rc2
This tag was signed with the committer’s verified signature.
aschmahmann Adin Schmahmann
GPG key ID: D7A248B705EE4F69
Learn about vigilant mode.
fafec57
Compare
Choose a tag to compare
v0.7.0-rc2 Pre-release
Pre-release

Tracking Issue: #7560

Assets 47
Loading

Release v0.7.0-rc1

26 Aug 23:09
@aschmahmann aschmahmann
v0.7.0-rc1
This tag was signed with the committer’s verified signature.
aschmahmann Adin Schmahmann
GPG key ID: D7A248B705EE4F69
Learn about vigilant mode.
901c58b
Compare
Choose a tag to compare
Release v0.7.0-rc1 Pre-release
Pre-release

Tracking Issue: #7560

Assets 47
Loading

Release v0.6.0

19 Jun 23:52
@aschmahmann aschmahmann
v0.6.0
This tag was signed with the committer’s verified signature.
Stebalien Steven Allen
GPG key ID: C125ECFD1713943C
Learn about vigilant mode.
d6e036a
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
Release v0.6.0

This is a relatively small release in terms of code changes, but it contains some significant changes to the IPFS protocol.

Highlights

The highlights in this release include:

  • The QUIC transport is enabled by default. Furthermore, go-ipfs will automatically run a migration to listen on the QUIC transport (on the same address/port as the TCP transport) to make this upgrade process seamless.
  • The new NOISE security transport is now supported but won't be selected by default. This transport will replace SECIO as the default cross-language interoperability security transport. TLS 1.3 will still remain the default security transport between go-ipfs nodes for now.

MIGRATION: This release contains a small config migration to enable listening on the QUIC transport in addition the TCP transport. This migration will:

  • Normalize multiaddrs in the bootstrap list to use the /p2p/Qm... syntax for multiaddrs instead of the /ipfs/Qm... syntax.
  • Add QUIC addresses for the default bootstrapers, as necessary. If you've removed the default bootstrappers from your bootstrap config, the migration won't add them back.
  • Add a QUIC listener address to mirror any TCP addresses present in your config. For example, if you're listening on /ip4/0.0.0.0/tcp/1234, this migration will add a listen address for /ip4/0.0.0.0/udp/1234/quic.

QUIC by default

This release enables the QUIC transport (draft 28) by default for both inbound and outbound connections. When connecting to new peers, libp2p will continue to dial all advertised addresses (tcp + quic) in parallel so if the QUIC connection fails for some reason, the connection should still succeed.

The QUIC transport has several key benefits over the current TCP based transports:

  • It takes fewer round-trips to establish a connection. With the QUIC transport, the IPFS handshake takes two round trips (one to establish the QUIC connection, one for the libp2p handshake). In the future, we should be able to reduce this to one round trip for the initial connection, and zero round trips for subsequent connections to a previously seen peer. This is especially important for DHT requests that contact many new peers.
  • Because it's UDP based instead of TCP based, it uses fewer file descriptors. The QUIC transport will open one UDP socket per listen address instead of one socket per connection. This should, in the future, allow us to keep more connections open.
  • Because QUIC connections don't consume file descriptors, we're able to remove the rate limit on outbound QUIC connections, further speeding up DHT queries.

Unfortunately, this change isn't without drawbacks: the QUIC transport may not be able to max out some links (usually due to poorly tuned kernel parameters). On the other hand, it may also be faster in some cases

If you hit this performance issue on Linux, you should tune the net.core.rmem_default and net.core.rmem_max sysctl parameters to increase your UDP receive buffer sizes.

If necessary, you can disable the QUIC transport by running:

> ipfs config --json Swarm.Transports.Network.QUIC false

NOTE: The QUIC transport included in this release is backwards incompatible with the experimental QUIC transport included in previous releases. Unfortunately, the QUIC protocol underwent some significant breaking changes and supporting multiple versions wasn't an option. In practice this degrades gracefully as go-ipfs will simply fall back on the TCP transport when dialing nodes with incompatible QUIC versions.

Noise Transport

This go-ipfs release introduces a new security transport: libp2p Noise (built from the Noise Protocol Framework). While TLS1.3 remains the default go-ipfs security transport, Noise is simpler to implement from scratch and will be the standard cross-platform libp2p security transport going forward.

This brings us one step closer to deprecating and removing support for SECIO.

While enabled by default, Noise won't actually be used by default it's negotiated. Given that TLS1.3 is still the default security transport for go-ipfs, this usually won't happen. If you'd like to prefer Noise over other security transports, you can change its priority in the config (Swarm.Transports.Security.Noise).

Gateway

This release brings two gateway-relevant features: custom 404 pages and base36 support.

Custom 404

You can now customize 404 Not Found error pages by including an ipfs-404.html file somewhere in the request path. When a requested file isn't found, go-ipfs will look for an ipfs-404.html in the same directory as the requested file, and in each ancestor directory. If found, this file will be returned (with a 404 status code) instead of the usual error message.

Support for Base36

This release adds support for a new multibase encoding: base36. Base36 is an optimally efficient case-insensitive alphanumeric encoding. Case-insensitive alphanumeric encodings are important for the subdomain gateway as domain names are case insensitive.

While base32 (the current default encoding used in subdomains) is simpler than base36, it's not optimally efficient and base36 Ed25519 IPNS keys are 2 characters too big to fit into the 63 character subdomain length limit. The extra efficiency from base36 brings us under this limit and allows Ed25519 IPNS keys to work with the subdomain gateway.

This release adds support for base36 but won't use it by default. If you'd like to re-encode an Ed25519 IPNS key into base36, you can use the ipfs cid format command:

$ ipfs cid format -v 1 --codec libp2p-key -b base36 bafzaajaiaejca4syrpdu6gdx4wsdnokxkprgzxf4wrstuc34gxw5k5jrag2so5gk k51qzi5uqu5dj16qyiq0tajolkojyl9qdkr254920wxv7ghtuwcz593tp69z9m

Gossipsub Upgrade

This release brings a new gossipsub protocol version: 1.1. You can read about it in the blog post.

Connectivity

This release introduces a new "peering" feature. The peering subsystem configures go-ipfs to connect to, remain connected to, and reconnect to a set of nodes. Nodes should use this subsystem to create "sticky" links between frequently useful peers to improve reliability.

Use-cases:

  • An IPFS gateway connected to an IPFS cluster should peer to ensure that the gateway can always fetch content from the cluster.
  • A dapp may peer embedded go-ipfs nodes with a set of pinning services or textile cafes/hubs.
  • A set of friends may peer to ensure that they can always fetch each other's content.

Changelog

Read more
Assets 47
Loading