PEP-35: The v0 Optimization, LeanPocket

[shane]

@BenVan

team can’t be bothered to submit a PR or even show the code to the team who is supposed to fix it and support it from now on.

I was under the impression at InfraCon that the code had been shared with the team. At the start of this proposal I was under the impression that active QAing of that code was underway with the team. I had then later assumed that the feather branch was created from the LeanPocket code. Consider me now trying to put everything into how I see it now.

@addison

Poktblade created a design doc, and Andrew implemented a prototype

I originally thought this proposal was for a code complete client. Then @luyzdeleon shared the link to the feather branch, a code complete client that was done by Andrew… but I still assumed it was an ported from the LeanPocket code. Now I realize that what was shared with the team was a design spec by @poktblade and not actual code.

So the coding/engineering for the feather client prototype, which is in QA, was done entirely by Andrew. That is an important detail to me.

@addison

The 5% is a sign of good faith as they are helping us with this endeavor. They are already compensated to develop pocket protocol. This is a two-sided effort.

To be fair, this proposal sounds like a two-sided effort with a enormous one-sided reward. These are the questions that come up with your framing:

1. Is the ask that the DAO choose to greatly favor the team who did the incomplete design spec and partial prototype, over the team who finished the design spec, code-complete prototype, and lead the QA efforts?

2. Is the DAO suppose to grant reward favor to the TH team because the other devs get salary wages already?

3. Doesn’t TH have income already too from being the 4th largest node provider and the original OTC market? Why would the DAO not consider TH income for this proposal and only consider the salary wages against the PNI developers?

I’m sorry but 5% does not sound like “good faith” from the DAO. The DAO is supposed to be impartial to all contributors which is the argument I’ve been trying to make. I feel that for the DAO to have good faith towards contributors, it needs to consider all contributions involved when providing rewards.

@addison

Per our proposal, validator functionality is a component of the final deliverable.

Again this makes it sound like validator functionally is something your team is going to be doing in the final deliverable, but as @BenVan correctly stating, Andrew already did all the work with Tendermint for you. I do not agree with your framing here.

I’m also confused on what the final deliverable is. @luyzdeleon laid out exactly how the core-team will work with you to integrate and QA the prototype… and so far his entire post has been ignored.

Are you going to be releasing LeanPocket as a competing client to the pocket-core feather branch? Are you asking the DAO to pay for what is now an incomplete, 3rd party client that requires the team to complete, QA, and maintain? Or is your team going to be working with the core-team on bringing the feather branch to production?

I think it’s important that we get into the weeds here, as these details matter.

@addison

This light client has taken a significant amount of my attention away from school, my business and all the fruits of my labor to do something that was deemed impossible.

I don’t believe the team ever said this was impossible, but @Olshansky did state that it would likely be a large undertaking and detract from v1. I appreciate that your team took this challenge upon yourselves to start the ball rolling with the initial design. I’m also thankful that the core-team took that initial design to heart and created a code-complete prototype which they want to work with your team to QA in a collaborative manner. That is how open-source software works… the community shares in it’s development for the benefit of all. TH will be saving millions of dollars a year on infrastructure costs, along with the rest of the ecosystem.

@BenVan made some important points and distinctions. I understand where he is coming from because I’m still piecing things together myself. I’m glad these details were brought to light so we can give the proper credit to every contributor involved and better define what this proposal is for.

While I still feel confused, this post is my attempt to piece together the important details in a good faith, constructive way

Suggestions

1. Share the design spec with the community that was given to the team.
2. Open-source the LeanPocket client since the core-team already open-sourced their code-complete prototype (though I’d suggest a disclaimer that LeanPocket is not production ready)
3. Clarify if this proposal is to produce a 3rd party client to compete with pocket-core, or if the feather branch of pocket-core will be the focus.
4. If it is a 3rd party client, then define if the core-team is expected to continue to contribute to it’s development and help with QAing.
5. Restructure the proposal to represent the sacrifices put into the creation of the design spec and PocketLean code.

I truly am greatful for your contributions that have now impacted pocket-core. I hope to be able to vote on a proposal that addresses each sacrifice your team has made and give credit to each contributor involved