Pepper-Sync

I’d say that, because of the Price Correction the amount of ZEC I requested is now roughly half what it was.

Or.. to put it another way 4M what? You seem to have forgotten to represent the currency that dominates your perspective.

Of course, it’s a lot less ZEC than we spent, but I agree with (my characterization of) @thowar2 's position, that the cost of a thing is only relevant to its value, inasmuch as cost somehow is represented as a desirable thing to the consumer.

But there’s something else, going on here.. something interesting.

You use the word “unreal” as a rhetorical device. It’s purpose is (guessing here) to express that the proposal is outside the bounds of rational dialog. As such it stops the argument, before it starts.

If that’s your intent, then I am left shrugging. If you don’t want to dialog, then you don’t.

Per this:

I think you intend it for other eyes than mine. I’ll make sure it’s not missed.

Inasmuch as “Putting My Team At Risk” is an assertion about your voting position, I don’t grant that I am responsible for your vote.

I’m not saying that you are making the following argument, but it’s possible that you are:

Za didn’t offer me the voting option I wanted, therefore I he forced me to vote against my true intentions.

I reject that argument whole clothe. Your vote is your Own.

I’ve also heard the argument that:

If the value of the technology is proportional the value of Zcash, then shouldn’t the ECC be entitled to more?

My answer to that is: “Obviously yes.”

If the ECC asked for the whole lockbox, I’d vote in favor.

They didn’t so I am operating as if they didn’t.

Does YWallet use GPUs for sync?

No

Does YWallet support spend-before-sync?

Yes

Is it true that YWallet has received the LEAST funding of Zashi, Zingo, and YWallet from Dev Fund sources?

Not less than itself.

Since you brought me into this conversation, here’ s my opinion.

Is the value of pepper sync to the ecosystem worth 2M or even 300k?

No. It is slower than existing sync methods and provides no usable additional benefits. It took time to develop for sure, but I am talking about results not effort.

If the dev was done by a company, the employees would have been paid. The company itself would incur a loss and maybe run out of business. In this retroactive grants, we should be clear about how we assign resources. To me, pepper sync is not much useful.

The grant would go to the Zingolabs treasury.

That’s where it is confusing. You want to treat it as a retro active grant to the total work of Zingolabs. If so, you should ask for retro active grant on zingolibs, etc.

I would still vote for no but for a different reason. AFAIK, you have received grants for that.

The charge is 2M (or 4M) because the price of ZEC has increased

This seems to come from the fact that you would have paid (or paid) the devs in ZEC and it took a big chunk of you ZEC that you want to recoup now. No one has a time machine.

This is a currency exchange risk that your team took by trading in ZEC. You can frame it as “we believe in ZEC when it was down so we used ZEC”, but that’s not how the rest of the world works. Everyone has adjusted their prices.

I think the work of Zingolabs around zingolibs and in the Spanish speaking community is valuable though.

1 Like

Thanks @hanh I’m always interested in your opinion, though I usually disagree!

Now that I have more clarity on what pepper-sync is, my thoughts are as follows:

  • Speeding up syncing is a worthy goal for the ecosystem as one (of several) user experience problems when using Zcash
  • Building tools that speed up syncing sounds useful for the whole ecosystem
  • But what are the results?
    • Pepper-sync has some benchmarks. Competitor Ywallet has some benchmarks. Both are faster than Zashi.
    • As far as I can tell, no 3rd party developer outside Zingo has integrated pepper-sync, which tells me that so far, no other developer has found the tool useful
    • Do the Zingo wallets attract more users because of faster syncing? As far as I can tell, no. Most of the anecdotes I hear about using Zingo wallets are negative.
  • Counterfactual on fast sync usefullness: Zashi has high praise and is experiencing high usage. It seems like slower syncing has not prevented them from achieving results. From my own use, I can tell that they’ve focused on making the UI maximally useful and engaging, without up to date history. This suggests that faster syncing on its own is not actually creating value or results for Zcash.

Given the information I have right now, please provide counterfactuals if they exist:

  • lack of user adoption in pepper-sync wallets
  • lack of developer adoption of pepper-sync library

I conclude that the results of building pepper-sync do not justify spending the requested amount.

1 Like

Thanks for your persistent inquiry @thowar2 .

In regards to developer adoption:

The following parties (external to Zingo Labs) are publicly known to use pepper-sync :

Additionally we’ve signed a letter of intent to support MFKDF2 from @multifactor .

@dorianvp and @Juanky are core Zingo Labs contributors who have been integral to the development of pepper-sync and as mentioned by @aquietinvestor in the “Crosslink Workshop” post they are integrating it into the Crosslink Demo (including substantial UI design work).

Of course I am not at liberty to disclose other partnerships without partner consent, and couldn’t disclose the CrossLink Demo work until today for the same reason.

With regard to User adoption

I can’t speak to the specifics of the negative anecdotes you’re hearing, and am NOT claiming that unfinished work on the upcoming demo constitutes a claim on retroactive funding for pepper-sync.

Nevertheless your line of questioning requires me to assert that there’s active UI work in progress. Otherwise readers might be left with the incorrect belief that UX based on pepper-sync is fixed. This is not the case.

Finally, with regard to the utility of “fast sync”, this property is high has high variance. My guess is that your sample is biased to freshly-or-recently installed instances of Zashi, where indeed sync speed is less important.

About the utility to UX of sync speed

Sync speed is more important the older the funds are, this value increases non-linearly for wallets older than the “sandblast” because of the shape of transactions in that epoch. Therefore you may in fact have a biased sample with respect to the usefulness/useability permitted by faster sync.

2 Likes

To be clear, I only offered details about fund distribution to the Zingolabs treasury because @chmod incorrectly believed that retroactive funds would go to individual developers.

Zingo Labs is the organization that incubated pepper-sync as such it would be the recipient of retroactive funding which means those funds would be controlled by the Zingo Labs developers who (after all) all participated to different degrees in the development of pepper-sync.

Any funds disbursed would be to the Zingo Labs treasury.

We have not previously received any funding for the development of pepper-sync.

I don’t believe that, but I understand why you think so. Let me rephrase what I wrote,

If this is approved, you say that it’s going to fund 10 developers for 20 months. Does that mean we won’t receive any more grant requests for the next 20 months? Because the grant application seems to suggest otherwise:

btw, would you have applied the same logic if ZEC cratered to USD$1? No need for a philosophical answer here, just a straight yes or no would suffice.

Thank you for providing this.

It seems like the dev integrations are for early stage products, which is a good sign that the developer ecosystem values this.

I do understand the utility of UX sync speed for older wallets and that is a pain point that frustrates me.

However - I can’t see a direct or indirect line from any of these early stage product integrations and the general utility of pepper-sync to the upside created in ZEC. Though it may achieve that in the future.

Not everyone may see this the same way as me, but given the general feedback in this forum you may want to consider adjusting the amount you are asking for to an amount you think the token voters would think is an appropriate value.

2 Likes

As coinholders are (hopefully) aware it seems that @joshs is skeptical of support for Proof Of Stake.

As mentioned here we are collaborating on a User-facing application to support the radical decentralization of control that Delegated Staking will offer.

This means, de facto, that a vote for this proposal is a vote in favor of delegated staking, which is now a contested priority. My belief is that delegated staking allows everyone access to participation in the security of the protocol.. a long-held objective of the Zcash community.

Additionally Unstoppable has announced support for pepper-sync.

1 Like

Yes, definitely.

To be clear, I stated my opinion and am not claiming it reflects the opinions of others at ECC. While we are all of one focus, we are not always of one opinion.

5 Likes

Okay, thank you. Did you apply the same logic to the previous grants? If yes, I missed that sorry. If no, why? Either way imho Retroactive Grants should always be made in stablecoin equivalents.

Thanks for the clarification. I used the qualifier “seems” in part because I was uncertain about whose opinion it was. I will edit the post, to be more accurate.

1 Like

Isn’t this supposed to be a retroactive grant, i.e. a grand awarded for past, complete and verifiable work?

Sure, but what’s your point?

@joshs declared that he didn’t support Cross Link over the weekend.

The value of the completed verified work is a function of the current environment, that environment changed in a very relevant way.

Were you promised a retroactive grant in exchange for this work by someone? You seem to feel entitled to it in a way that is inappropriate for this type of grant.

I’m quite confused as to why you have undertaken this effort without a pre-approved grant.

No, no one promised us funding.

We wanted to improve Zcash. We knew it was likely retroactive funding for valuable innovations would become available. I was under the impression that the purpose of this program was exactly that.. to stimulate innovation, and encourage risk by providing an upside upon success.

That brings me to this quote:

I thought “this type of grant” was designed for exactly this purpose..

If the value of ZEC had gone to $1 between when we did the work and now, everyone would agree:

Too bad! You took a risk, and the price cratered… sometimes you make a bad bet, and have to eat the cost.

If the value of ZEC had stayed the same, folks might say:

well.. here’s enough to cover your costs thanks for building something.

Evidently if the value of ZEC goes up, folks (in this thread) are saying:

Nice work! Thanks for betting on Zcash… but we don’t think you should feel the upside.

I think this grant should reward the foresight we had to bet on ZEC when it was down.

I will continue to argue this position (popular or not), because I think it’s right… until I am persuaded that it’s incorrect.

That is to say, I am arguing that:

This type of grant is to stimulate innovation by retroactively rewarding it.

I feel like @thowar2 is being inconsistent when he at some point in this thread opines that the amount is out of line, and at another point states that the argument for funds is “inappropriate” for the grant type.