Announcing Zingo!

@zancas when you use terms like platform/features it feels like you’re eluding to a “extensions/add-on/features” based development model? Where the “wallet” becomes a whole new Zcash apps ecosystem. I guess the intent is that new ecosystem, outside the control of ECC, would shift some of the authority away from ECC? Is that what you mean by “devolve central authority away from the ECC”?

Hey @zancas,

I agree with your point of having wallets be primarily devoid of any relation to a central Zcash authority. As nice as it sounds to have an officially sanctioned wallet built by the ECC with a strong UX focus, centralization is a real threat, and I personally feel the ECC might be spread too thin to tackle all of the other important initiatives + wallet development and maintenance (ECC’s North Star: Building a world-class UX for ZEC - Electric Coin Company).

At the same time, I don’t know how much work has already been started for an ECC wallet, and I can’t help but feel like there are plenty of wallets with varying degrees of user-friendliness already out there. Though none specifically marketed towards “DevUsers”, I’d be curious if you’ve done some rough estimation of how big the target market for this particular wallet implementation is?

The idea of having a wallet funded with an optional donation model is appealing. One thing that worries me is what happens if no one decides to pay the fee to Enhance Their Privacy? Would additional funding be requested from ZCG in follow-up grants?

For the feedback that is submitted by the in-app Privacy Enhancement Fee, will that be propagated anywhere or will it only be shared amongst your team? I can see some value of having a ZECPages like reply-thread on the submitted feedback wherein, maybe you charge a fee for people commenting on previously submitted ideas.

On the contrary, what happens there isn’t feedback coming in? Put another way, assuming everything is going well and people are content with your wallet (or in the worst case not using it), where will the future roadmap inspiration come from?

An SDK with those APIs that can and have (with zecwallet!), seems like a great idea as well. I’m a fan of the Rust/Typescript background from your team, but I notice that Jaunky is the only one with a UX/UI background. Second to security, UX is obviously the main reason why people choose a wallet. Do you foresee your team/organization ever ingesting currently developed wallets to reduce fragmentation in the wallet ecosystem (e.g. Nighthawk and Zecwallet become a subsidiary of Zingolabs)? Or will you always be a developer focused operation that 3rd party devs can rely on?

Is there anything shareable aside from the internal Android test-app? +1 on i18n. Very underrated in terms of growth.

3 Likes

I wasn’t speaking for the Foundation, and I didn’t say that.

I am a privacy and security engineer and researcher. I was offering feedback on likely privacy leaks in the Zingo design. I also noted some other design flaws, using the recipients you mentioned as examples.

I am an engineer at the Zcash Foundation. Engineers don’t handle the Foundation’s funding stream payments, or any other cryptocurrency donations.

It’s great that you’re open about what communication you’ve had with ecosystem participants. But I can’t speak to that, so please leave me out of it.

1 Like

I apologize. I was incorrect. The error is mine. You said:

2. Have you asked ECC and ZF if they want to receive hundreds or thousands of 1 Zat contributions?

I made inferences based on that question. I didn’t intend to mis-attribute your role/opinion/etc. Hopefully this direct quote, clarifies any confusion I unintentionally caused.

Also quoting you directly, to avoid confusion:

I very much appreciate that you took the time to do this.

Great questions @pkr !

To properly address them I need to start from where we are, rather than perhaps where we would like to be. This pre-amble is a bit windy but I promise it’s relevant.

It is not my intention to disparage anyone’s hard work, or present an unduly pessimistic narrative, but at the same time, we need to be clear about objective realities. I’d like to pre-emptively take responsibility for any errors.

I decided that I needed to initiate this project when my experience as a User of existing wallets (particularly zecwallet) demonstrated to me that there was no suitable tool for me to use zcash in the ways I hoped to.

To initiate the effort I forked the zecwallet family of codebases, primarily written by @adityapk00 with the abundant support of many community members in many forms.

Zingolabs was actively upgrading the core Rust source code to mitigate the many known vulnerabilities it contained, when @conradoplg reached out to us to direct our attention to a very thorough bug-report he posted on github. That bug prevented zecwallet from being compatible with the NU5 mainnet. With the help of @conradoplg and others we fixed that bug and published our fix before NU5 activated. Our fix was ignored for over a week, before zecwallet developers noticed our announcement, and copied it without attribution, to enable their wallet to return to service after an 8-day outage.

The point of this background is not to belabor the particulars of an unfortunate sequence of events in our community’s history. The point is that the zingo effort has in many ways been catalyzed by those events.

Our belief is that the underlying causes of the failure are not technical, but economic. The proposal you are asking about centers on economic innovations, because we believe those are the most valuable ways we can contribute. We think that by building on the technical marvels produced by other engineering teams in the space, we can produce small but significant improvements that make failures like we have just seen practically impossible (or at least far less likely).

To your first assertion:

“there are plenty of wallets with varying degrees of user-friendliness already out there”

With the above context, I hope it’s now clear why I say that there are not applications in the zcash space (degree of friendliness aside) that are robust to the kinds of failures that have recently damaged our economy. To be robust against the kind of negligence that has happened before, the zcash-based Application must itself innovate economically.

I don’t call zingo a “wallet”. This is an important point. We don’t think of zingo as just a wallet, though of course an orchard implementing mobile wallet is a critical component of it… oh that reminds me…

To this question:

Here’re some screen shots of our mobile-app exposing orchard addresses:

Viewing Key:

Private Key:

Unified Address:
image

Because the Privacy Enhancement Fee and the Direct Feature Bid make it more than that. It’s an Application that aims to pay its own way. So to your question about entering a field crowded with wallets, we have two responses: (1) it’s not that crowded (2) we’re not (just) a wallet

To your excellent question about the market we’re trying to reach… we don’t have a dedicated market researcher (much less team), but we do have the proposition that putting this kind of tech out there is probably the best way to gauge the response in the marketplace. Beyond that, I have abundant anecdotal evidence that many people want to be more directly engaged with this inspiring technology/movement. It’s our explicit intention to begin providing options that allow end Users to become more directly engaged (that’s our Direct Feature Bid story).

This post has become pretty long, I am going to split my answers to your remaining questions into a second post.

3 Likes

Starting from here, I am responding to the rest of your post here.

As a minor quibble the Privacy Enhancement Fee, which we intend to implement first, does not provide a feedback channel. The Direct Feature Bid is the abstraction (to be implemented second) that will provide a feedback mechanism.

Per your question about how the PEF will be distributed. We propose 1 zat to each of Zingolabs, the ECC, and the ZF. As has been noted above this is totally impractical in reality, but serves as a useful placeholder until we can determine more adaptive/reasonable/optimal amounts.

This kind of innovation is the sort of thing we hope to build “next”. I appreciate the idea.

In an absolute worst case scenario where no one uses zingo in any form, then we’ll all have learned that the particular experiments we attempted weren’t fit for the marketplace. At least we’ll have that market-research to build on moving forward. At this point we will have a library wrapping orchard that offers useful primitives for building things like PEFs and DFBs, perhaps the market will provide obvious fits for that library. We are hopeful that DFBs will facilitate inspiration Directly… if we can’t tune them to the realworld demand then we’ll look for other privacy-oriented ways of enabling cooperative ideation.

I don’t foresee us running out of ideas to try. PEFs and DFBs are themselves just place-holders for a vast number of possible experiments, starting with the actual amounts of the Fees!

This is the first time I’ve considered this! I can speak for ZingoLabs as a whole to say that we really enjoy collaborating, and we care about the wider well-being of our community. We benefit from the input of diverse community members every day.

Personally, I am interested in finding synergies wherever I can. That having been said, I don’t have any specific connection to any other wallet team, so I don’t know what their perspective is.

You propose a specific way of collaborating by “ingestion”… we’d probably be open to that, though it’s not a decision I could take by myself. We’d probably also be interested in all kinds of other synergies, and collaborations. We are acutely aware that we’re completely interdependent on/with the Rest of the zcash community. We want to encourage and facilitate wider vibrance and diversity.

“Or will you always be a developer focused operation that 3rd party devs can rely on?”

We intend to create a reliable thing that persists, PEFs and DFBs are part of that plan.

3 Likes

That’s a great story and bug discovery by @conradoplg. Bummer that it went overlooked. That context definitely helps me understand what your mission statement is more clearly. I get that you are trying to be more of an ecosystem, which is what is sorely needed on Zcash and I’ve been banging that drum to whoever wants to listen for far too long (let’s be honest, it’s usually @BrunchTime listening to me telling him to go all in on ZECPages, but I digress).

I can potentially see zingo being a “litmus” test to show how funding could be modeled within ZSAs (as I believe most ZSAs will have some economic incentive model built-in much like ZECPages does currently).

Thanks for sharing the Android app screenshots. Reminds me of zecwallet :wink:

What would be great is if zingolabs could develop various APIs for developers building things on Zcash. For example, I want to build something like ZECPages. I can right now go and look @ the code on github, and copy the code, or I can go to zingolabs (similar to: Stripe API reference – curl), see a demo of all the APIs: Creating a poll, Creating a message, Paying someone, [Insert new feature here built on top of ZSAs when they arrive], etc.).

If you expanded on the Direct Feature Bid concept and supported a real-time bidding system (ebay, liveauctioneers.com et al) that would be such a killer feature.

Don’t worry, I’ve got plenty of ideas. You could literally build the next stackoverflow where people get paid actual money to reply to a coding question (I know I would).

:100: Opportunities are everything and everything is an opportunity.

Overall sounds pretty damn interesting. Thanks for sharing (even though you spammed my ZCG classified! :joy:).

By the way is this an actual proposal or will there be one that follows?

3 Likes

You could literally build the next stackoverflow where people get paid actual money to reply to a coding question (I know I would).

Yes, quite right! Questions answered, tickets closed…

We’ve talked about a good handful of potentially very useful applications, but first we’ll be establishing a solid and relatively easy-to-use foundation, if all goes well.

2 Likes

Hi, I want to make sure that you feel satisfied with my responses.
I also want to clarify that these ideas are evolving, and adapting, so I consider these conversations to be a source of ideas.

Per your first set of questions:

It’s possible I misused the term “platform”, I will discuss our (evolving) concept, and then we can debate the correctness of “platform”.

To implement our own concrete targets (PEFs/DFBs), that we’re including in our App, we’re producing an open-source (MIT/BOSL) SDK that has higher layer abstractions (e.g. Bids and Fees) on top of the ECC’s Orchard Transactions.

Zcashers can come along and fork our App (as we have forked zecwallet -by- @adityapk00 ), add-or-subtract features, and their variant can interact with ours, or not.

Alternatively developers in others spaces, like @skyl from:

https://free2z.cash/

can take the version of the SDK that has compiled to WASM, and incorporate things like Bids and Fees into free2zcash.

Per the ECCs authority:

As I am thinking about this, I am realizing that the term “expertise” or “capability” might be more useful than “authority”.

The ECC has a great deal of expertise. They built the means for a future that includes consensual transactions. But for the ECC, authentic autonomy might well not exist!

A reasonable question is:

How can we efficiently spread that knowledge to empower more innovation?

I think zingo can be a part of the answer. We’re learning the orchard and librustzcash concepts. We’ve already contributed back in small ways. I anticipate that that process will accelerate. As an outside party that is acquiring orchard-based capabilities we are efficiently diffusing authority from the ECC.

As far as I am aware, this is in complete alignment with the ECC’s values and I expect that they’re excited to help us adopt their technology, build weird new things on top of it, and contribute back to it.

I think everyone will benefit from a vibrant zingo helping to expand our space in new and interesting dimensions.

3 Likes

Hah! I thought it was a legitimate topic to bring up in ZCG bids because I am a ZCAP voter, and…

Yes! There will be one, we are the process of compiling it now.

1 Like

In the short to medium term we intend to provide an SDK with abstractions on top of Orchard transactions. First we’ll implement a few concrete instances. First, Privacy Enhancement Fees and the Direct Feature Bids as we’re in the process of building these relatively simple Contracts we’ll notice and implement more general abstractions for the broader class of contracts.

Maybe @BrunchTime can use our in app DFB implementation to convince us to build things for zecpages… maybe the ECC will use DFBs to coordinate their efforts.

I love the stripe api examples.

2 Likes

That might be because we forked @adityapk00 's code! :wink:

I will forgive you but I will never forget!

:clap: Let’s be honest – despite the “bear market”, m̶o̶r̶a̶l̶i̶t̶y̶ (morale) has been pretty low in this community for awhile now. This interest from you and your team is actually inspiring and hopefully will attract more devs.

Oh, yes, I’m well aware ;]

Anywho…

ezgif-2-449d3613e4

Looking forward to it :slight_smile:

2 Likes

I’ll share this with the crew… it’s probably the fire we need!

2 Likes

You probably meant ‘morale’…but what you wrote may well be true (and is more amusing). :wink:

6 Likes

Any thoughts on pulling hanh’s ‘warp sync’ from Ywallet into Zingo? It’s crazy fast, worth the effort methinks.

3 Likes

First, let me start by saying that I applaud what you are doing, and the more wallet diversity, the better. We’ve seen before during previous upgrades having viable, functional wallet alternatives is critical.

That being said, I’ve never been a fan of the tipping model, and in my opinion, it’s not going to be anywhere near meaningful enough to be sustainable. Funding open-source software in this way simply doesn’t work. I also think the UX around tipping is plain bad. I’m all for experimentation with funding models, but this is exactly why I always strongly supported the dev fund (and, by extension, the ZOMG) to fund common goods work like this. I’d like to see experimentation with the ZOMG like funding deployed retroactively, which creates some interesting dynamics, but tipping as an experiment has been tried and has flat-out failed (if someone has a counter-example to this, I’d love to see it). Even within the ZCash ecosystem, WinZEC was a notable example of this. The direct feature bids are interesting, but I’d consider that a signaling mechanism rather than one of direct funding.

Your point that the ecosystem lacks a reliable external third party is well received, but surely giving the ZOMG more independence would be a better resolution - though that debate has been well hashed.

That’s a long way of saying, keep developing and apply for some real funding!

10 Likes

A more thorough investigation of warp sync to determine whether we want to switch and how much we want to prioritize it is on our todo list. Right now we don’t know enough about warp sync to have made a decision on this.

Zingo is currently using aditya’s ‘blaze sync’, which is not in the same ballpark as warp sync if the 300x number claimed here is accurate. I’m not sure how fast blaze sync is, the initial forum post claims >5x and I’m sure it’s been improved since, but I suspect not by a factor of 60.

I think this is worth looking into more than I have. It would probably be a large enough change that trying to do so before implementing sending/receiving of orchard transactions would delay that more than we’d like. It’s also possible that blaze sync could be improved to the point where it can match warp sync, or even that it has been and that wasn’t documented anywhere that I’m aware of.

Edit: Warp sync and blaze sync both seem to be relatively tightly integrated to their own wallet implementations. Switching out blaze sync for warp sync would I think be swapping out over half the zingolib codebase.

6 Likes

It’s nice to hear from you! I very much appreciate your perspectives. Thanks for taking the time to offer you feedback and encouragement.

I think there’s an important distinction to be made between a tip and a fee-for-service.

I believe that the word tip is applied to funding networked applications because it appeals to the intuition that it’s something that’s “Optional To The User”.

For example:

If I order a latte in a coffee shop, I may opt to pay a gratuitous extra amount in addition to the fee I pay for service (and am forced to pay in tax). That gratuity is colloquially known as a tip.

It is true that in both the case of using a networked service with opt-in fees, and paying a gratuity to a barrista, I can get the service without paying the fee.

But there’s a crucial distinction that needs to be made in order to talk about The Judgment Economy. In The Judgment Economy services are paid for by providing Judgeable Behavioral Data (JBD) to an algorithmic judge. That is to say, a fee is still paid.

I cannot walk into a coffee shop, order a latte, and walk out without paying anything!

When I log into Venmo (or Twitter/Facebook/etc.) I am paying for service with my (JBD) behavioral data.

Zingo aims to provide an alternative to that fee. Since that fee (or tax) is the analog of the Privacy Enhancement Fee, the PEF is NOT the analog of a tip.

In other words:

  • the Privacy Enhancement Fee (PEF) is an alternative to paying with Judgeable Behavioral Data (JBD).

I believe that this is a much wider concern than Zingo. We live in a Judgment Economy referring to explicit consensual fees as tips helps to propagate the myth that Behavioral Judgment fueled Apps are free.

They are not, we must be diligent and thoughtful with our language.

All that semantic quibbling aside. I take your point that the Privacy Enhancement Fee (PEF) may not be an economically viable strategy to heart. I believe that building it, and providing it in these specific circumstances is a valuable project, in it’s own right! The degree to which it succeeds-or-fails will provide us with valuable data that will enable us to more effectively Judge different strategies for Consensual Transaction.

Finally, PEFs are simply a “first experiment”, to be immediately followed by Direct Feature Bid (DFB)s… and… more!

1 Like

I really like this idea of an extensible platform where diverse actors can “load” their own Contracts.

I think this is a perfect example of the kind of feature that a:

Direct Feature Bid

could be used to bootstrap into.

Moreover, the idea of piling onto popular Feature Bid threads as part of the DFB interface is also interesting.

I imagine PEFs and DFBs as relatively simple/primitive contracts that open up a richly diverse space of possibilities.

1 Like