docs: 2018 Q3 OKRs

[daviddias]

libp2p:

• Spreadsheet for 2018 2018 Q3
• PR for 2018 Q2 for reference

[ghost]

/ cc @jacobheun @vasco-santos @steverichmond

I want to try to connect this tab for js-libp2p OKRs with this tab for overall libp2p project OKRs.

By connect, I really just mean that generally the two should be aiming at the same goals. We can do this in a bottoms-up way, where we start with the ongoing work by the JS libp2p team and better align the overall goals to fit those plans. Or we can do it in a top-down way, i.e., start by getting to consensus on the overall libp2p goals and use that to set goals for js-libp2p. Thoughts?

[jacobheun]

@mgoelzer I think we are likely going to need to leverage both approaches. I see the direction of libp2p being heavily influenced by the community and the projects it integrates with. For example, we know that right now libp2p can be extremely difficult to troubleshoot errors. It takes up a lot of time doing so, not just for libp2p developers, but for its consumers as well. Making that easier to do as well as making the system more fault tolerant in general should be high priorities for us, because it will improve user experience and allow us to spend subsequent quarters focused more on feature development.

Where I see the more top-down approach coming into play is through event connections, market research, PL goals and general community outreach. What types of things are libp2p/ipfs users or potential users looking for that we can put into place? What support does libp2p need to continue to be successful, and are we growing at the rate we need to?

I think a lot of these can tie together pretty well. (More demos of work being completed that can be shared with the community, interesting proof of concept work with new features, etc.)

[jacobheun]

Here is a draft of a fairly large initiative I'd like to see for Q3. I think it's reasonable for this to be completed within 3 months.

Q3 OKR Proposal: Libp2p stability

One of the recurring themes of Q2 has been issues with error handling and troubleshooting.

There is an issue in js-ipfs, #1406, that discusses a roadmap for standardizing error codes across the ipfs ecosystem. I think this is going to be a huge improvement for diagnosing errors when they arise. In order to better leverage standardized errors and improve our ability to handle and diagnose them in the libp2p workflow, I think we should focus on making the following updates to libp2p modules.

State Machines

Make libp2p a state machine, #98

Along with allowing users to initiate libp2p transitions, rather than change state directly, this would also help to better diagnose issues. If we know what state/transition libp2p was in when an error occured, it should help us better understand how to replicate that issue. Right now we have to rely on stack traces (which are can currently be very unhelpful), or view the logs, provided someone was able to have them running when they hit an issue.

A clearly documented state machine, also has the benefit of better informing users of the underlying flows in libp2p. They'd be able to see all the available states, their transitions and what they transition to. As the libp2p connection workflow is a topic for the upcoming summit in Berlin, it's clear that this could be extremely helpful. I think the connection proposal in libp2p-switch is an example of how this could help clarify workflows, especially with additional comments.

Make libp2p-switch a state machine, including its connections, #24

There are two major things this lets us do.

1. It makes it easy to understand internal state and the state of connections. This allows us to better handle individual errors that occur for a given connection and translate its state accordingly.
2. It makes it easier for libp2p and the connection manager to understand what's going on with switch, so they can make more informed decisions. Notification of state transitions, and connection transitions, along with logging via debug of those transitions should also make it easier for users to diagnose issues.

Standard Errors

Standardize connection errors and add them to the ipfs initiative, #1406

This must be done to make the implementation successful.

Implement in interface-connection modules

By leveraging standard errors for all modules implementing the connection interface, the libp2p-switch connection state machines will be better able to respond to the errors appropriately.
Fatal codes could terminate connections outright and not cause libp2p or switch to crash the node. Unstable connections could be reported up to libp2p and the connection manager to handle. The connection manager could make decisions on which connections to keep, and/or potentially add dialing backoffs for connections (network outage, a restarting peer, etc).

[daviddias]

All in for improving debuggability! The other P0 objective should be supporting js-ipfs getting Connectivity Magic, namely interopable and reliable DHT + IPNS.

[vasco-santos]

@mgoelzer I agree that we should be synced between those 2 tabs. I agree with @jacobheun as the OKRs tab should represent the intended direction of the project as a whole, and GO and JS should follow them. Moreover, JS and GO implementations will probably have other aspects that are inherent to the current state of each project, and if those aspects are critical they should also be tackled.

Accordingly, I would like to know if there is an IMPLEMENTATION_STATUS.md, as we have for ipfs. I have looked for it, but I couldn’t find it and I think that this document could also be important for OKRs consideration.

Meanwhile, I have some suggestions for OKRs in the JS side that I consider to be important for the following quarter. I will describe them later in here.

[vasco-santos]

Here follow some suggestions that I consider relevant for the next quarter:

Error handling and debuggability

Taking into account the last quarter, it was recurrent during the weekly sync calls to have people who lost a considerable amount of time debugging problems, as a result of the errors not being properly handled and standardized. In addition, having some repos with CI red may create even more problems, when new features of fixes get merged.

All things considered, I think that providing a stable, reliable and performant libp2p is crucial for the developers' productivity, as well as to the community engagement. This way, I believe that this effort now will be important in the long run, since it will decrease considerably the time needed for diagnosing current and future problems. Moreover, we should have CI green everywhere.

Rreferences:

• #1406

IPNS

Regarding IPNS, I think that this is one of the most waited features in the community. In addition, it was part of the OKRs for Q2, but unfortunately, there is some work that needs to be finished in this new quarter. Namely, integrate the DHT routing, implement the IPNS over PubSub, finish the SPECS and guarantee full interoperability with go.

References:

• #209
• #1400

Awesome DHT Endeavour

Since the DHT is a really important part of libp2p and ipns, I consider that we should get all the libp2p related work for this endeavour done as soon as possible. Moreover, we should guarantee the full interoperability with go, the same way as with IPNS.

References:

• #856

Improve performance of mplex

This was an OKR in the previous quarter and since it was not finished, I believe that it should still be an OKR this quarter, as it can have a considerable impact on performance.

References:

• #73

Go even further with config

As the new config implementation got merged, I think that we should go even further with it, allowing the libp2p users' to have an even more customized node according to their needs.

References:

• Improve libp2p config #46
• new config #166
• Add support for Addrs {listen, announce, noAnnounce} #202
• Configure Protocol Muxing sequence #201

Triage js-libp2p issues

Having into consideration that I am working closely with libp2p for a short time, I still don't have a clear picture of the direction and priorities of several issues that I found on the js-libp2p repo. This way, I think we should triage all those issues, setting priorities to them, as well as closing / updating the ones that may not make sense at the moment.

Overview

I consider that the first 3 are the most import OKRs proposed. In addition, I have thought about the state machine issue and NAT Traversal, and they also seem important OKRs for being considered.

[daviddias]

Hi all, thank you so much for writing these. I've a feel that they are really close to what we will be writing in the spreadsheet at the end.

As food for thought, I wrote up -- ipfs/team-mgmt#654 -- to remind everyone that if we miss to understand our user and use case needs, we will only be able to see the needs that we see during the development.

If I were to name the most important objective is to nail down the DHT + IPNS implementations and respective interop. That will enable libp2p and IPFS in JS to achieve the connectivity magic that everyone expects from the project.

[daviddias]

@mgoelzer linking my comment to the libp2p 2018 OKRs here for reference -- comment. My point being that the language teams have some pretty specifics to handle that are aligned but different from a libp2p Core WG goals.

[daviddias]

Let's continue discussing the OKRs over the markdown, taking inspiration from the notes already shared in this thread.

I've defined 3 main objectives so far (rewording is welcome if you see the need) for this quarter which capture the most requested and needed features and bug fixes.

Let's shoot to get the final list of KRs by Wednesday, final review on Thursday and ship it on Friday.

[vasco-santos]

@diasdavid should we add IPNS parity and interoperability with go?

[daviddias]

Absolutely @vasco-santos, good call!

I've updated the OKRs list and started assigning some based on previous work. Please review:

• Check if wording makes sense.
• Check if they are achievable this quarter.
• Check the ones you will want to take the lead.

[vasco-santos]

I believe that we can achieve this list!!

I would like to take the lead on DHT interops with go-libp2p.
By the way, is there any issue for the network visualization tool? I think I would like to go with it as well.

[achingbrain]

Do you think it's worth having a 'technical debt' section? There was something about speeding the tests up here a minute ago but it seems to have been removed.

Feature parity with the go API would also be a good thing to shoot for.

[daviddias]

With this, I assigned the remaining to @jacobheun, hope you agree. I do think that we need to find more stuff to keep @jacobheun busy, otherwise he will be done in the first couple of weeks :D

[vasco-santos]

cool, thanks @diasdavid ! Then we sync about the tool 🙂

[achingbrain]

you are confusing js-ipfs OKRs with js-libp2p OKRS

Oops, yes. I've added the comment there.

[jacobheun]

@diasdavid haha, yes I'm good with taking the rest. I know NAT traversal was part of q2 but I'd like to make sure that gets done, as I think it's important to making libp2p the painless go to in p2p.

[daviddias]

rad!! And you are right, let's add NAT back in.

[vasco-santos]

IPNS is currently implemented in go-ipfs, so I think we should have go-ipfs interop for both IPNS KRs

[daviddias]

You mean anything different from what is already there?

[vasco-santos]

I mean:

IPNS works over PubSub (+ go-ipfs interop) - @vascosantos
IPNS works over DHT (+ go-ipfs interop) - @vascosantos

Since IPNS is implemented inside the scope of js-ipfs / go-ipfs

[daviddias]

@jacobheun how do you feel about adding and taking these. It would be pretty sweet and we would have the chance to model a lot of the things with regards to interop testing :)

[vasco-santos]

@diasdavid you missed a hyphen on my handle 😛

[daviddias]

All right, I think we are done here! \o/ @jacobheun, @vasco-santos, if you agree, I'll move these to the spreadsheet, assign priorities and wrap up this PR. 👍 this comment for YES!

[daviddias]

OKRs for 2018 Q3 are set! Godspeed team! And may the muxers be with you ⚡️

[ghost]

@vasco-santos:

Accordingly, I would like to know if there is an IMPLEMENTATION_STATUS.md

Yes, we're working on something similar for the project over here libp2p/libp2p#39. The idea would be to have our main KPI (meaning the thing we track long term, beyond just any single quarter) be %age completion of that list, which could grow over time. The list itself needs more cleanup -- it was copied out of https://github.com/ipfs/ipfs/blob/master/ROADMAP-TO-1.0.0.md (just the libp2p parts) and needs some further cleanup. You can see some comments from @diasdavid about parts that I've left out, and I also need to improve it's formatting.

[daviddias]

@mgoelzer IMPLEMENTATION_STATUS.md is a different doc from ROADMAP, check https://github.com/ipfs/ipfs/blob/master/IMPLEMENTATION_STATUS.md

[ghost]

@diasdavid Yes, right, I'm just pointing out that it's a similar type of document (list of things with emojis to indicate completion status).