6.9 KiB
Kubo changelog v0.21
v0.21.0
- Overview
- 🔦 Highlights
- Saving previously seen nodes for later bootstrapping
- Gateway:
DeserializedResponsesconfig flag client/rpcmigration ofgo-ipfs-http-client- Gateway: DAG-CBOR/-JSON previews and improved error pages
- Gateway: subdomain redirects are now
text/html ipfs dag statdeduping statistics- Accelerated DHT Client is no longer experimental
- 📝 Changelog
- 👨👩👧👦 Contributors
Overview
🔦 Highlights
Saving previously seen nodes for later bootstrapping
Kubo now stores a subset of connected peers as backup bootstrap nodes (kubo#8856).
These nodes are used in addition to the explicitly defined bootstrappers in the
Bootstrap configuration.
This enhancement improves the resiliency of the system, as it eliminates the necessity of relying solely on the default bootstrappers operated by Protocol Labs for joining the public IPFS swarm. Previously, this level of robustness was only available in LAN contexts with mDNS peer discovery enabled.
With this update, the same level of robustness is applied to peers that lack mDNS peers and solely rely on the public DHT.
Gateway: DeserializedResponses config flag
This release introduces the
Gateway.DeserializedResponses
configuration flag.
With this flag, one can explicitly configure whether the gateway responds to deserialized requests or not. By default, this flag is enabled.
Disabling deserialized responses allows the gateway to operate as a Trustless Gateway limited to three verifiable response types: application/vnd.ipld.raw, application/vnd.ipld.car, and application/vnd.ipfs.ipns-record.
With deserialized responses disabled, the Kubo gateway can serve as a block backend for other software (like bifrost-gateway, IPFS in Chromium etc) without the usual risks associated with hosting deserialized data behind third-party CIDs.
client/rpc migration of go-ipfs-http-client
The go-ipfs-http-client RPC has
been migrated into kubo/client/rpc.
With this change the two will be kept in sync, in some previous releases we updated the CoreAPI with new Kubo features but forgot to port thoses to the http-client, making it impossible to use them together with the same coreapi version.
For smooth transition v0.7.0 of go-ipfs-http-client provides updated stubs
for Kubo v0.21.
Gateway: DAG-CBOR/-JSON previews and improved error pages
In this release, we improved the HTML templates of our HTTP gateway:
- You can now preview the contents of a DAG-CBOR and DAG-JSON document from your browser, as well as follow any IPLD Links (CBOR Tag 42) contained within them.
- The HTML directory listings now contain updated, higher-definition icons.
- On gateway error, instead of a plain text error message, web browsers will now get a friendly HTML response with more details regarding the problem.
HTML responses are returned when request's Accept header includes text/html.
| DAG-CBOR Preview | Error Page |
|---|---|
Gateway: subdomain redirects are now text/html
HTTP 301 redirects from path to subdomain no longer include the target data in the body. The data is returned only once, with the final HTTP 200 returned from the target subdomain.
The HTTP 301 body now includes human-readable text/html message
for clients that do not follow redirects by default:
$ curl "https://subdomain-gw.example.net/ipfs/${cid}/"
<a href="https://${cid}.ipfs.subdomain-gw.example.net/">Moved Permanently</a>.
Rationale can be found in kubo#9913.
Gateway: support for CAR parameters of IPIP-402
The gateway now supports partial CAR export parameters as indicated in IPIP-402.
ipfs dag stat deduping statistics
ipfs dat stat now accept multiple CIDs and will dump advanced statistics
on the number of shared blocks and size of each CID.
$ ipfs dag stat --progress=false QmfXuRxzyVy5H2LssLgtXrKCrNvDY8UBvMp2aoW8LS8AYA QmfZDyu2UFfUhL4VdHaw7Hofivmn5D4DdQj38Lwo86RsnB
CID Blocks Size
QmfXuRxzyVy5H2LssLgtXrKCrNvDY8UBvMp2aoW8LS8AYA 3 2151
QmfZDyu2UFfUhL4VdHaw7Hofivmn5D4DdQj38Lwo86RsnB 4 3223
Summary
Total Size: 3326
Unique Blocks: 5
Shared Size: 2048
Ratio: 1.615755
ipfs --enc=json dag stat's keys are a non breaking change, new keys have been added but old keys with previous sementics are still here.
Accelerated DHT Client is no longer experimental
The accelerated DHT client is now the main recommended solution for users who are hosting lots of data. By trading some upfront DHT caching and increased memory usage, one gets provider throughput improvements up to 6 millions times bigger dataset. See the docs for more info.
The Experimental.AcceleratedDHTClient flag moved to [Routing.AcceleratedDHTClient](docs/config.md#routingaccelerateddhtclient).
A config migration has been added to handle this automatically.
A new tracker estimates the providing speed and warns users if they should be using AcceleratedDHTClient because they are falling behind.