Skip to content
This repository has been archived by the owner on Feb 12, 2024. It is now read-only.

⚡️ v0.35.0 RELEASE 🚀 #1826

Closed
48 of 50 tasks
alanshaw opened this issue Jan 17, 2019 · 7 comments
Closed
48 of 50 tasks

⚡️ v0.35.0 RELEASE 🚀 #1826

alanshaw opened this issue Jan 17, 2019 · 7 comments
Assignees
@alanshaw
Labels
topic/release Topic release

Comments

@alanshaw
Copy link
Member

alanshaw commented Jan 17, 2019 •
edited
Loading

Small, acyclic and flexible, just the way you like it

🗺 What's left for release?

🔦 Highlights

✂️ Huge bundle size cuts!

One of the biggest goals for JS IPFS is to enable the distributed web in the browser. Part of that is being a good web citizen and minimising the amount of code we ship, to ensure IPFS downloads quicker, npm install's quicker, loads quicker and utilizes fewer resources. It's especially important on resource constrained mobiles and IoT devices.

The good news you want to hear is that we've now chopped around 26% off the bundle size of JS IPFS since 0.33, that's a reduction of over a quarter of the code we were previously shipping! This is an amazing improvement and a great reason to upgrade.

🌳 DAG HTTP API

The HTTP API now has endpoints for DAG operations like get, put and resolve. Hooray! It was actually super easy so we just decided to do it spontaneously. I know, we're so zany.

On a more serious note, this brings JS IPFS another step closer to feature parity with Go IPFS. We're pushing forwards with this in every release 🚀 - stay tuned!

🙉 Multiple address listening for API and Gateway servers

The HTTP API and the HTTP Gateway started by your IPFS node can now listen on multiple addresses. It's a backward compatible change, all you have to do is change the value of Addresses.API or Addresses.Gateway in your JSON config file to be an array of multiaddrs instead of a single string multiaddr. Here's an example:

{
  "Addresses": {
    "API": [
      "/ip4/127.0.0.1/tcp/5001",
      "/ip6/::1/tcp/5002"
    ],
    "Gateway": [
      "/ip4/127.0.0.1/tcp/8080",
      "/ip6/::1/tcp/8080"
    ]
  }
}

🔭 Recursive DNS link lookups

DNS link TXT records like dnslink=/ipns/domain.com can now be recursively resolved until they hit an IPFS hash like /ipfs/QmHash. Even better, that's the new default. 👌

🏗 API Changes

  • CLI
    • The global flag --local was renamed to --offline
    • Added flag --enable-preload to jsipfs daemon command to allow users to enable or disable content preloading
  • Core

    • ipfs.util.isIPFS and ipfs.util.crypto have moved to static exports and should now be accessed like:

      const { isIPFS, crypto } = require('ipfs')

    • ipfs.types.* have moved to static exports and should now be accessed like:

      const { Buffer, CID, multiaddr, multibase, multihash, PeerId, PeerInfo } = require('ipfs')

    • ipfs.resolve now supports resolving to the middle of an IPLD block instead of erroring. Given:

      b = {"c": "some value"}
a = {"b": {"/": cidOf(b) }}

      ipfs resolve /ipld/cidOf(a)/b/c should return /ipld/cidOf(b)/c. That is, it resolves the path as much as it can. Previously it would simply fail with an error.

    • ipfs.dns now resolves recursively by default, set the recursive options to false to prevent this behaviour

  • HTTP API
    • Added the following DAG endpoints:
      • /api/v0/dag/put
      • /api/v0/dag/get
      • /api/v0/dag/resolve

✅ Release Checklist

❤️ Huge thank you to everyone that made this release possible

In alphabetical order, here are all the humans that contributed to the release:

🙌🏽 Want to contribute?

Would you like to contribute to the IPFS project and don't know how? Well, there are a few places you can get started:

⁉️ Do you have questions?

The best place to ask your questions about IPFS, how it works and what you can do with it is at discuss.ipfs.io. We are also available at the #ipfs channel on Freenode.
@alanshaw alanshaw pinned this issue Jan 17, 2019
@alanshaw alanshaw added the status/ready Ready to be worked label Jan 18, 2019
@alanshaw alanshaw self-assigned this Jan 18, 2019
@parkan parkan mentioned this issue Feb 19, 2019
Closed
@daviddias
Copy link
Member

daviddias commented Mar 12, 2019 •
edited
Loading

What's missing to have this one released?

Are there instructions on how to enable the DHT in the browser?

Btw, it might be useful to differentiate a Full Node DHT vs a DHT client. js-ipfs is now using delegated content routing, correct?

@alanshaw
Copy link
Member Author

alanshaw commented Mar 12, 2019 •
edited
Loading

What's missing to have this one released?

Right now, the new DHT allows the JS IPFS node to discover so many peers that it cannot process them quickly enough and this is causing an issue with the node using 100% CPU and eventually running out of memory. The connection manager isn't doing a good enough job of disconnecting peers when over the threshold and the 100% CPU usage uncovered a bug in the repo lock file implementation which is being addressed here moxystudio/node-proper-lockfile#74

We're also waiting on libp2p/js-libp2p-switch#309 to address an issue with peer-mux-closed events being fired even if there wasn't an established muxer (should help the connection manager actually count open connections properly) and we have an open PR which simply optimises our dials a little so we don't request a new stream if we've previously discovered the peer before and a connection is already established. #1914

Essentially there's a bunch of fallout from the DHT work that we're addressing. Our e2e and interop tests did not pick these issues up as you only really see them in a long running process when a node acquires many many peers. We're working to make sure the node is stable before we release. We've made good progress already but we're not there yet.

Are there instructions on how to enable the DHT in the browser?

Not specifically but that's a good suggestion and I'll add them to the release notes and the README.

Btw, it might be useful to differentiate a Full Node DHT vs a DHT client. js-ipfs is now using delegated content routing, correct?

Delegated content routing made it into js-libp2p but I don't know if there's a public node running that is setup with it turned on that JS IPFS can use (@jacobheun?). We should get an example together for IPFS or perhaps even enable by default?

@jacobheun
Copy link
Contributor

@alanshaw I am following up on the nodes that should be available for delegated routing, ipfs/infra#426 (comment). There is an existing browser based example of configuring libp2p and js-ipfs for delegated routing at https://github.com/libp2p/js-libp2p/tree/v0.24.4/examples/delegated-routing. It currently references an old branch for the http api in go-ipfs needed for delegated routing.

@alanshaw alanshaw mentioned this issue Mar 20, 2019
Merged
@alanshaw
Copy link
Member Author

Update: we have one failing test that needs to be fixed up and then I need to do some quick browser testing so that I can adjust the default connection manager limits to something a little more appropriate for the browser (DHT will be disabled by default in the browser for now but if users decide to turn it on we don't want 🔥!).

After that's done, it's on to the release process \o/ 🚢🚢🚢

I've been running 0.35.0-rc.1 most of the day today and things are looking stable - around 500-600 peers with reasonable CPU usage (still higher than I'd like but not 100% so 🥳). It's possible we have a small memory leak but that needs to be confirmed, I've also noticed a problem where a daemon doesn't always stop on SIGINT but these are not blockers for the release.

I'm currently aiming for release mid-end of next week.

@dirkmc dirkmc mentioned this issue Mar 29, 2019
Closed
@jacobheun jacobheun mentioned this issue Mar 29, 2019
Merged
This was referenced Mar 29, 2019
Closed
Closed
Closed
Open
Merged
@alanshaw
Copy link
Member Author

alanshaw commented Apr 4, 2019

Update: we've been squashing bugs in the libp2p switch like no tomorrow. We fix one thing and another issue arrises. Since the last update the following PRs were created/merged:

In a nutshell, we fixed the 100% CPU issue by introducing a dial queue in libp2p but we needed to arrange the queue in such a way that dials to connected peers or peers we've previously been connected to are prioritised. This is so that we don't end up losing all our existing peers because we're spending all our time dialing out to new, slow or unavailable peers.

I'm now waiting on #1976 and then another RC will be released and we'll continue the release process. Thank you all for your patients ❤

@alanshaw
Copy link
Member Author

alanshaw commented Apr 10, 2019 •
edited
Loading

Update: we've made the hard decision to cut enabling the DHT by default from this release. There are still problems that need to ironed out and we can't delay any further. Apologies to anyone who was looking forward to this, but we simply can't release it as is.

We'll be including all the latest and greatest improvements we've made to libp2p into this release but the DHT will be disabled by default. You can turn it on, but your mileage may vary.

Providing the interop tests pass you can expect the release later this week.

Waiting on #1982 before release process can continue.

@alanshaw
Copy link
Member Author

If you're interesting in the full journey and what's happening right now with the DHT then please have a read: #1984

@jacobheun jacobheun mentioned this issue Apr 12, 2019
Closed
16 tasks
@ghost ghost removed the status/ready Ready to be worked label Apr 12, 2019
@alanshaw alanshaw unpinned this issue Apr 12, 2019
@alanshaw alanshaw added the topic/release Topic release label Aug 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@alanshaw alanshaw

Labels
topic/release Topic release
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@alanshaw @jacobheun @daviddias