Maximizing results from the JS Core 2019 roadmap

[alanshaw]

These are most of the in-progress high value deliverables (in red) on the 2019 roadmap and their dependency tree.

It's ✨encouraging✨ that we're still actually working on P0 deliverables we said we'd work on this year, but we're approaching the year end and it's demoralizing to me to see that we're missing many of our other goals and even the deliverables in the diagram above that are in progress are starting to look in danger of not being shipped.

I've come to realise that I am invested in and trying to own many of these. I could push them all forwards a little before 2020 and ship nothing 😢...or with your help, we might be able to refocus a little, and conquer everything 🚀

Therefore, I have one ask for the JS Core team:

Can we come up with a plan to 🚢 these before 2020 to ensure we're building the best p2p file system the world has ever known?

Specifically, these 3 problems really need 1 or more people to pull over the line before the year end:

1. DHT
2. base32 cids (@alanshaw + @lidel)
3. UnixFS v1.5

@achingbrain @jacobheun @vasco-santos @lidel @hugomrdias @PedroMiguelSS
cc @vmx @mikeal @dirkmc @daviddias @momack2

[dirkmc]

This diagram makes it super clear what needs to be done ❤️

I am pretty busy with go-land bitswap, but happy to help review PRs.

[jacobheun]

and it's demoralizing to me

Don't be demoralized, this is a significant amount of work and doesn't encompass everything we've worked on this year. Regardless, I think refocusing is a good idea so that we're minimizing our individual WIP, and the diagram is very helpful.

The Libp2p refactor will help unblock the IPFS refactor. I would like to work on refactoring pull-streams and libp2p in IPFS as part of the libp2p RC to get some dogfooding in, and supplement the libp2p guides.

The libp2p refactor is also likely going to include support for connection(peer) priority. We're currently working on some definable Topology logic which should enable us to do this easily.

[mikeal]

This graphic is great! This is the clearest thing we can point to on how critical the async/await work is.

[lidel]

Count me in for base32 cids @alanshaw. I am spread bit thin, but I believe it is realistic goal to ship js-ipfs with functional support for base32 cids on BOTH /ipfs/ AND /ipns/ this quarter (without changing the default).
(I plan switching to CIDv1 as the default to be go/js P0 for 2020Q1)

ps. one of the first users of DHT will be embedded js-ipfs in Brave. Removing reliance on delegate nodes will be great 👌

[momack2]

THIS IS AMAZING!!! Love the dependency view!! However, instead of trying to sprint to make progress on everything at once, I’d like to see you identify the 1-2 most important top level red boxes to complete this quarter and focus all efforts on ensuring those are fully landed, with the ability to layer more on top once those are done. Keeping a high carrying cost of objectives results in churn and makes us move slower. Clearly async await is P0 to land. Unixfsv1.5 is also very high prio. Between DHT, base32 cids, and preload nodes, which will create the most value for users / set us on a great trajectory?

[alanshaw]

Thanks for all the positive responses! I'm going to focus on getting async await out the door and prioritise helping @lidel with the base32 CID work.