Solid responses!! Kudos @Ziga. If I were on the committee I would approve this grant.
3 Likes
I honestly think & believe Zemo is going to bring best UX to Zcash ecosystem.
For the record, I’ll start using it & share with my friends to onboard them to Zcash.
3 Likes
Hi @Ziga, really good answers to the questions above from Hudson, i had similar concerns which you’ve addressed well.
I love the enthusiasm you bring and onboarding new devs to the ecosystem is something we need.
I’ve been reviewing the previous thread to re-familiarize myself with the discussions from back then and I have a couple of questions.
Collaboration:
@aiyadt mentioned reaching out to the Light Client Working Group, via Discord or the regular calls, have you had any interactions with this working group yet?
The Cost:
Originally the staff cost was $288,000 for 4 people for 6 months, or $12,000/person/month, or ~$75/person/hour (assuming 40 hour weeks for 24 weeks).
In this proposal the staff cost is $180,000 for 2 people for 6 months, or $15,000/person/month, or $93.75/person/hour (assuming 40 hour weeks for 24 weeks), which is a 25% increase.
My question, would you consider bringing this down to the original average rate of $75/hour, which would result in a total staff cost of $144,000 for 2 people for 6 months. I personally think that it would be worth taking a chance on at this rate*.
*Obviously I don’t make any decisions here, just voicing my opinion.
3 Likes
Great questions and I look forward to see the answers.
I think this conversation will help clarify ZCG’s position on what they’re willing to fund and why.
Best of luck with the proposal @Ziga.
4 Likes
Community can do market research on what the hourly pay looks for experienced & specialized devs. https://geomotiv.com/blog/software-engineer-hourly-rate-in-the-usa/
Also it’s a good opportunity for grant committee to hire someone or use market data to come up with comperitive hourly rate for working with Zcash for different roles (one that matter to us).
2 Likes
I love the enthusiasm you bring and onboarding new devs to the ecosystem is something we need.
Thank you!
I’ve been reviewing the previous thread to re-familiarize myself with the discussions from back then and I have a couple of questions.
Collaboration:
@aiyadt mentioned reaching out to the Light Client Working Group, via Discord or the regular calls, have you had any interactions with this working group yet?
We haven’t joined the conversations yet. If Zemo becomes an app the committee and community decided to support, then we’ll be excited to participate in the conversations.
The Cost:
Originally the staff cost was $288,000 for 4 people for 6 months, or $12,000/person/month, or ~$75/person/hour (assuming 40 hour weeks for 24 weeks).
In this proposal the staff cost is $180,000 for 2 people for 6 months, or $15,000/person/month, or $93.75/person/hour (assuming 40 hour weeks for 24 weeks), which is a 25% increase.
My question, would you consider bringing this down to the original average rate of $75/hour, which would result in a total staff cost of $144,000 for 2 people for 6 months. I personally think that it would be worth taking a chance on at this rate*.
Great question. The previous proposal was drafted for a 4 people team. Chris and I were both on the original team. Of the two other team members, one lived in a country with a significantly lower cost of living and the other was a designer with less experience with lower salary requirements.
The avg. hourly cost per person for the initial proposal was quoted at $75. Chris and I were going to be making higher than $75 per hour, while the other 2 were making roughly $50 an hour. Both proposals work out to about the same cost per hour for Chris and I.
4 Likes
My 2zats about why this project excites me.
Onboarding users! How much is a new user worth? Investing $100,000s with the hope of educating and introducing 100,000s of new users to Zcash sounds like a shoe in to me!
Let me explain. When I tell my IT friends about Zcash this is how the conversation goes…
– “hey you should install this crypto wallet and I’ll send you some tokens! It’s private blah blah…”
“Cool, I won’t do it now but Ill definitely look into it…”
Here’s how I hope Zemo will help onboard my IT friends…
– “Hey you should install this new messaging app. I was kinda annoyed that I have to allow signal to see my phone number so thought we should give this a go. Zemo works with public keys not phone numbers. I’ll send you some tokens…”
“Cool! I always like trying new messaging apps. Give me a sec to install it.”
But even better I can now onboard my family. I swear at least once a month they’ll have a mini freakout about some data leak reported on the news.
“did you hear about the recent XYZ big company data leak?”
– “oh yeah this is why I don’t use Facebook”
– "hey you should install this new secure messaging app. It doesn’t use your phone number/contacts like WhatsApp/Signal. Just send me your user ID key once you’ve installed it.
“Ok I’ll install it now”
So I’ve onboarded all these people. Then what? They inevitable stop using it? Nope! I introduce them to new usecases.
– “Thanks for lunch!” $10
If we all do this I can imagine this will help introduce 1000s of new people to Zcash every month. Over 12-18months that’s 100,000users!
Note: I have no evidence this will happen it’s just a dream. Can Zemo make this happen?
5 Likes
I love it @gguy. Thanks for sharing your ideas!
– “hey you should install this crypto wallet and I’ll send you some tokens! It’s private blah blah…”
“Cool, I won’t do it now but Ill definitely look into it…”
I’ve personally onboarded dozens of people (friends and family) to invest in Zcash. Whenever I tell them to install a wallet and try a real shielded payment, they’ve also put it off and mostly never come around to it.
There can be many new use cases that emerge from Zemo. And I think @gguy hit on some of them well.
One idea I like is… imagine a presenter at a conference puts their Z-addr on their final slide and tells the audience to private message him/her on Zemo about what they thought of the presentation. The ability to receive private messages from an audience, without having to expose your email address or signal handle to everyone, could be very useful.
Also, if we eventually have a Zcash podcast, the producers of the show could create a new user profile on Zemo for every episode released. The avatar would be a cover photo from the episode and the display name would be the episode number. Fans could privately send comments, thoughts, feedback to the podcast hosts for each specific episode.
I don’t know for sure what use case will be the most compelling for Zemo, but I think there’s enough creativity in our community to find a way to grow it. The best part is we’ll all be using shielded transactions more too.
5 Likes
Hi, Ziga and Grant Committee,
As you know, I am very supportive of the Zemo project, but I want to clarify why that is and what my specific interests are – what would make this proposal pop out to me.
I think it is critical to understand what the potential of messaging with cryptocurrency is, why it could be superior to something like Signal, and why Zcash. Strong cryptographic guarantees of privacy are essential in messaging, but beyond not requiring a phone number, the reason that this would be far better than current encypted messaging is because of micropayments. As alluded to above, having to pay for messages is a feature, not a bug. Historically, using micropayments to improve messaging was one of the original motivating factors for even inventing digital cash in the first place.
How do micropayments improve messaging? By solving the spam problem. What is most needed in imo is to define a simple protocol for message payments that disincentivizes spam. It could be as simple as by default not displaying messages that cost less than a threshold, and always sending back an Ack for the value of the threshold to approved parties.
So, for example, suppose you and I are connected[*]. I always send you a messages for 0.01 ZEC (a default below which you do not read memos), and because we know each other, you always automatically refund me. This serves as a receipt, gets me over your spam threshold, and reduces my cost to the transaction cost unless I am a spammer. If someone tries to send you spam over the threshold, it’s prohibitively costly because you don’t refund them. You won’t need to “block” a user. Set their payment threshold to infinite so the app never displays their messages, just keeps the cash.
[*] This immediately presents an authentication problem for Zcash, because there is no proof of sender. Therefore, I think the development needs to include designing some kind of signature / handshake to establish “connection” for the purposes of automatic refund, and this may need cryptography expertise to model.
I also think Zemo should be working with whatever the new standard protocol is that ECC is developing for a wallet, rather than on ZECwallet.
Basically, I think the priority of development should be in how the messages and payments are handled at the protocol level so that any app could be made to interact with Zemo. In other words, the app itself is just one implementation of the protocol to showcase how it can work. The protocol design development makes or breaks success of this use case for Zcash as much as the usability of the app, in my opinion. I used to think about micropayment messaging a lot in the days before Bitcoin, and I’m willing to advise on protocol design if you want.
So what I would like to see is something like the first milestone being an RFC on establishing trust and message ack / refunding, and then building the app to implement the protocol with a pretty UX. Then maybe there could be other more complex features later like automatically splitting long messages to fit into memos and re-merging them on receipt, or figuring out how to have multi-way conversations.
6 Likes
Messaging on special purpose social networks like LinkedIn, etc is not free. So I agree with Amber that paying to message is a feature (in defined contexts).
Given user needs ZEC to use Zemo, Zemo network could be Zodler network.
6 Likes
Great thoughts, Amber! Thank you for chiming in.
As alluded to above, having to pay for messages is a feature, not a bug.
How do micropayments improve messaging? By solving the spam problem. What is most needed in imo is to define a simple protocol for message payments that disincentivizes spam. It could be as simple as by default not displaying messages that cost less than a threshold, and always sending back an Ack for the value of the threshold to approved parties.
Another super interesting use case for Zemo. I love it.
Basically, I think the priority of development should be in how the messages and payments are handled at the protocol level so that any app could be made to interact with Zemo. In other words, the app itself is just one implementation of the protocol to showcase how it can work. The protocol design development makes or breaks success of this use case for Zcash as much as the usability of the app, in my opinion. I used to think about micropayment messaging a lot in the days before Bitcoin, and I’m willing to advise on protocol design if you want.
I’d like to echo this point, Zemo is intended to be the first application on the messaging protocol. We hope our app will inspire additional devs to fork Zemo and create different messaging apps, while ensuring there is interoperability across all of them.
A big selling point vs say Signal, is you can import your seed phrase into a forked version of Zemo, benefit from different UI features, all without being tied down to a single provider. This is the true beauty of Web3 messaging.
So what I would like to see is something like the first milestone being an RFC on establishing trust and message ack / refunding, and then building the app to implement the protocol with a pretty UX. Then maybe there could be other more complex features later like automatically splitting long messages to fit into memos and re-merging them on receipt, or figuring out how to have multi-way conversations.
I’m glad you brought more attention to the protocol design process. On our end, Chris has started working on handshake concepts. I’ve asked him to chime in here with more details when he has a chance.
What I think could potentially be helpful here, Amber, is if you feel comfortable, it may make sense to appoint you as the point person to lead the process of creating the RFC. There’s a good amount of work to write the specs, coordinate with stakeholders across different projects, etc.
I feel it would be best to open a separate grant proposal for this line of work. Regardless of if Zemo gets funded, the RFC would be a valuable contribution to the community. Is that a process you would be interested in leading via a separate grant?
7 Likes
Haha. I walked right into that one.
Possibly. Maybe I could chat with you and Chris about it offline.
4 Likes
@Ziga - Thank you for the detailed responses you provided to our questions and concerns. We appreciate the lively dialogue here from the community and are working on some responses for the questions you raised about our views of Zemo. We think it would be very beneficial to create a spec that addresses the protocol design which the community could use for interoperability between wallet implementations. We like ambimorph’s suggestions and are interested in seeing a proposal from ambimorph or inclusion of a spec initial milestone into the Zemo grant. More to come from us soon hopefully by mid-week. Thanks for your patience!
5 Likes
I feel like there would be some overlap (in terms of work) between Elemental Zcash and this project. One of my plans with Elemental Zcash is to modularise some of the ZECwallet React Native/Electron codebase to make it more portable for use in other apps.
Also, my hope with Elemental Zcash is that it would save developer time by reducing the amount of work needed to manage a React Native codebase, and an Electron codebase, by abstracting away styling/platform differences.
If you’d be interested in the idea of using Elemental Zcash (or say a few of the UI components or locales), I’d be happy to spend some time on helping with some integration or discussing possibilities.
I feel that for devs to fork a project, the project needs to be heavily modularised and be built up of open-source libraries that are decoupled from the original app. A naive fork will end up diverging from the original codebase relatively quickly and build up a high technical debt; there would need to be a good developer ecosystem for other developers to build apps on top of the messaging protocol.
Possibly. Maybe I could chat with you and Chris about it offline.
Yes, sounds good!
1 Like
Sounds great, thank you!
One of my plans with Elemental Zcash is to modularise some of the ZECwallet React Native/Electron codebase to make it more portable for use in other apps.
I just checked out your website and it looks like Elemental Zcash is still a ways out from being finished. I’d be happy to take a closer look once you have something more concrete.
Keep in mind that Zemo will require new UI patterns due to it being a messaging app.
I feel that for devs to fork a project, the project needs to be heavily modularised and be built up of open-source libraries that are decoupled from the original app. A naive fork will end up diverging from the original codebase relatively quickly and build up a high technical debt; there would need to be a good developer ecosystem for other developers to build apps on top of the messaging protocol.
I guess it would depend on what the devs are trying to accomplish. UI libraries are nice for speed, but can end up being too restrictive to fulfill unique use cases. If a library emerged that fulfilled our needs, we’d be happy to consider integrating it into Zemo.
3 Likes
The library is currently in a usable state, there’s just a lack of documentation and web/React Native example code. I can create a proof of concept messaging app soon as an example of how the library can be incorporated. Will be posting an update on the project in the next week.
Sounds good 
. I’m fairly critical of UI libraries myself, which is why I set out to work on an unopinionated alternative to MUI, React Native Paper, etc. I’m building on top off styled-components and styled-system, which are widely used in the React ecosystem, and the API is heavily inspired by GitHub’s Primer Design System: https://primer.style/react .
A library should only be used to save dev resources and time, freeing up more time to work on core functionality/logic.
Am excited to see how the protocol design specification develops. I’m especially interested in seeing whether existing protocols like the memo.cash protocol could be used together with shielded memos and how these could interop between different wallets.
Sorry if I’ve missed this, but I’m interested in how verifying the identity of a message sender could work – for profile icons, threaded replies, etc, is this something that would be incorporated, or would it be anonymous messages with optional/unverifiable Reply-To addresses like ZECpages?
3 Likes
Handshakes were mentioned above, but no specific details yet.
1 Like
I feel like this is going to play out like Thorchain grant. Part funded by community grant & part by other good actors.
*edit. Clarification: Barry announced on Twitter he might fund it if needed. Zcash grant review committee thinks the project cost is high. Hence, I made the comment above, where a project can get partial funding from grant committee.