Sounds like a good job for community content creators, so ECC can put their devfund money to their dev work.
imo Zcash community media needs more funding. This doesn’t have to cost a lot to have a sizeable impact, if we start with a simple task like making clips.
There’s an av club bounty program in the back of my mind that could create some incentive to get this done. Will explore more throughout ZconV and especially focus on it this summer.
Is it? How, exactly?
It really is a good idea. All it takes is time. I volunteer @pkr.
I’ll even donate some shielded zcash if it happens.
@joshs You posted this above:
Something is amiss here, so I’m respectfully calling you out.
I’ve already made it clear that ZF is “prepared to collaborate with the ECC engineering team on a joint effort to create a separate CLI wallet (that uses zebrad as its back end) that can replace the zcashd built-in wallet for key users (e.g. exchanges).”
That is what ECC and ZF agreed last August during Zcon4, and we - Zooko, Alan Fairless (Bootstrap’s board chair), Andrew Miller (ZF’s board chair) and I - collectively drafted a blog post to announce that ECC and ZF “will collaborate to identify what functionality needs to be added to Zebra to address the necessary use cases, and to encourage and support key users to migrate to Zebra.”
@joshs - I appreciate that agreement was made while Zooko was CEO of ECC, so let me ask this: As ECC’s new CEO, are you willing to honor that agreement?
@Dodger ,
Thank you for your commitment to collaboration. It’s what we all want. We want to see zcashd retired as soon as possible so that we can all move faster and deploy more!
The post you reference is a high-level statement of commitment to collaboration. I do not see any specific commitments, including scope or dates. As I read it, to honor the agreement is to honor collaboration, which we continue to commit to.
I chatted with Alan and Zooko following our call last week. It’s my understanding that there was no commitment from ECC then that it would take on the responsibility of building a wallet for zebrad. That said, we have been working in good faith toward its retirement in a responsible way as you have communicated that the Zcash Foundation is unwilling to invest in a wallet for zebrad.
We have since been exploring different ideas for how best bridge the gap between zebrad and zcashd to support a transition. It would be helpful if you would specifically commit to the level of engineering resources and level of effort you are able to make. What will you provide? That would help us better understand the gaps.
We (me personally), have also begun contacting miners and exchanges about their specific requirements. I am unaware of any such efforts by the Zcash Foundation, but we’re happy to share this workload as well.
Today I requested that we allow the two engineering teams to meet, discuss the technical requirements, and recommend a collaborative path forward. Given the challenges we had with the last call, and for the sake of harmony, I suggested that neither you nor I attend those meetings so that we can get an objective and clear technical path forward as recommended by our teams. You accepted the idea of the ECC/ZF meeting but refused my request that neither you nor I personally participate.
However, I maintain this will bring the level of clarity and joint commitment we need, and I respectfully ask that you reconsider.
Regards.
I’d like to add some technical context to the issue of exchange support for Zebra and deprecating zcashd. There’s no point in a back and forth about who promised what. I could see both ECC and ZF, a year ago, reasonably thinking the other is the best party to make a wallet and getting annoyed its not getting done.
But the technical reality now, is very different. There’s a clear consensus on what is basically the only way forward: both groups have to pitch in.
Posting what I said in the same Telegram thread in response to Josh with some edits:
I think everyone should stop with the finger pointing about who promised to do what. Also stop arguing about timelines, and just work on progress. As Str4d, Daira, and Kris said on the special arborist call, building a exchange grade wallet service is hard. They have the experience to do so and also, more practically, exchanges aren’t going to just switch to zebra without some transition involving zcashd at a minimum. Its not something ZFND could do on its own. Remember, Zcash isn’t exchanges number one priority. Switching has to be made easy for them and that requires experience working with them and the existing wallet.
One thing that came out of the call is a stronger consensus that zcashd depreciation is the current blocker for ZSAs. The good thing is the work is being done. It can probably be accelerated with better coordination, but its being done.
Focus on progress and we can avoid questions about who was supposed to do what or posturing for blaming people when it doesn’t work. Because the actual progress is happening. I just wish it was faster, but that will come
Someone then asked me so “ZSAs confirmed?”
From the answers I heard on the call, the work for ZSAs itself and integrating them into Zebra is definitely being done and some audits are lined up. That should be ready mid summer, IIRC. The code will go in. The thing that will take slightly longer is deprecating zcashd. This requires both work in zebra and, perhaps surprisingly, work in zcashd. The thing thats not obvious here is it requires engineers with experience dealing with exchanges and the existing zcashd service wallet. Note, this is very different than a front-end wallet, its more of an API your website (e.g., Binnance, Kraken, etc) can use and exchanges are touchy about it because it handles potentially 10s of millions of dollars. Thats where Str4d Daira and Kris come in. Because there really is no one else who can do that in the zcash ecosystem. That work is happening. There’s some back and forth on if it can happen quicker.
With all that said, there is obviously work in Zebra that needs to be done too. And it seems we could have some better coordination. But thats not a question of “honoring an agreement.” It’s a garden variety project management problem.
I have a full-time job and would rather be playing golf than cutting clips. Thanks, but hard pass.
Who controls the trademark? Who builds the core protocol?
If you don’t care about your ideas enough to invest time in them, why should anyone else?
I have more important things to do in life than something that the dev fund can outsource to some drone on Fiverr.
Didn’t you used to work at ECC? Why didn’t you do it while you were there? 
Enjoy golf.
This.
Frankly, I don’t understand the animosity between ECC and ZF top management. I never have. Whenever there is the slightest difference in position it seems to escalate until yous are all but shouting at each other on public calls. This happened with Zooko and Josh Cincinnati; Zooko and Dodger; now Josh and Dodger. [Edit: to be clear, these four people are all very different, and I’m not drawing an equivalence between these relationships.] It’s incredibly frustrating, because the ZF and ECC engineers have never had this problem, and have always worked collaboratively to the best of our abilities within the resource and time constraints we’re under.
On the first call last Thursday, Kris explained that the effort that ECC has been putting into librustzcash has been working towards the necessary replacements for zcashd functionality all along. This is where the vast majority of ECC’s engineering effort has been going over the past ~two years (along with mitigating the sandblasting in the first part of that period, which overlapped in terms of the code affected). Zashi has been invaluable in testing that code, apart from its independent value as a wallet.
Granted, we could have communicated this strategy more clearly. It isn’t always obvious to us engineering folk what things management don’t know, since to us the changes to the code speak for themselves. (I understand that it’s part of my job now to communicate these things and that’s fine, I will.)
In any case, can we please just… tone it down a little? I’m autistic; raised voices and communications that are this fraught and emotionally laden are pretty inaccessible for me. Honestly it was a huge mental effort to try to parse the emotional and technical content of that first call simultaneously with figuring out what to say in order to help to fill in the communication gaps. The second call that day was so much better and, I thought, more productive, because of the calmer tone. Thanks in advance.
For whatever it’s worth, I agree 100% with Daira.
Back when I talked with the ZF board about taking the ED role, they asked me to write down what my vision for ZF was. Here is part of it, which many ECC folks will have already heard because I read it out during the last ECC All Hands call I attended:
I still believe everything I wrote there.
The ideal way to do this would be for the Zebra engineers (Alfredo, Arya and Marek) pair up with the ECC engineers (Daira, Kris and str4d) to work together (in pairs, to facilitate knowledge transfer) on components of the end solution, wherever those components might be (e.g. ECC crates, Zebra crates or the new application’s codebase).
This work would be the top priority for both teams, within reason (e.g. the Zebra team would continue to help QEDIT where necessary, the ECC team would respond to any bugs in zcashd, Zashi, etc.).
Here’s a strawman plan.
The deliverable is a new piece of software that uses Zebra as its back-end, and exposes the same wallet RPC endpoints that zcashd does (i.e. Zebra plus the New CLI Wallet become a drop-in replacement for zcashd, to smooth migration).
The scope is everything in the CLI Wallet Plan A: Build a new Rust CLI Wallet and zcashd plan A: Sunset the Zcashd node boxes in this diagram:
Dan, Pili and I can help with this too.
I’ve been sleeping very well since reading this!
A minimal, compatible RPC interface would be nice.
As a thought experiment, what would things look like without executives where the executive salaries (and perhaps other corporate overhead) were paid directly to developers? Maybe this could happen closer to the protocol and the devs could get more ZEC? What are the main benefits of the current corporate structures? Do these outweigh the costs? Perhaps the corporate entity structure(s) are needed for X or Y? What are these things?
Could the structures be minimized to send more value to engineers and waste less effort with politics? I’m not sure. I like drinking this koolaid from time to time: Aftok Founding Principles
What are the biggest barriers to reducing or eliminating the corporate structures that seem to provoke politics and bickering (while spending money that might be better sent to individuals contributing code)?
The issue is that a “compatible RPC interface” means essentially reimplementing the zcashd internal wallet — precisely the thing that most critically motivates deprecating zcashd from my point of view. It isn’t just the implementation of the internal wallet RPC calls that I consider broken and unmaintainable, it’s the fundamental design.
It’s possible to emulate that interface in a way that reproduces its design quirks and flaws with sufficient fidelity to be compatible. It would be far preferable from my perspective if its users just stopped using it and used something else. I don’t know whether that is realistic, but it is a high priority for us to talk to the major exchanges, mining pools, etc. that are using the zcashd internal wallet in order to determine whether it is, and as @joshs said, he has started doing that.
@Dodger. The engineering team is developing a more detailed scope and approach and will soon post it here in the forum.
Yes, ECC donated de trademark to ZF which now controls it. So what? Has ZF ever wielded the trademark to force something to happen (or not) that the community disagrees with? The trademark is only being enforced to take down obvious scams.
Who builds the core protocol? What do you mean? The actual protocol? Check the authors: do you see any ZF people in there? Or maybe do you mean the protocol implementation, which for the vast majority of nodes is still zcashd, maintained by ECC? Sure, the plan is to deprecate it, but to claim that “the project is still under the thumb of the foundation” is completely baseless. (And to be clear, I’m not implicating the project is under ECC’s thumb either)
Daira Emma is 100% right. The animosity between ECC and ZF top management is not the only reason, but was a major contributor to why I needed to step away from Zcash. Disagreement is valuable when it helps us find a better path forward, but that value is lost when it becomes accusatory and shows the public a lack of trust and collective vision. We’re all human and we all have emotions and they’re going to show somtimes, but we have to remember that we all care about the same thing.
