We can integrate tor into a future version. I donāt think tor is an absolute must for v1. Our team has integrated tor into p2p/crypto applications in the past, so it wouldnāt be an issue to add it in.
1 Like
Considering that Satoshi worked on bitcoin 15 years ago, thatās really impressive.
Oh - they mean - in total? 
1 Like
Our team has 20y experience working on p2p crypto projects. You guys are just trolling us at this point haha
2 Likes
Waitā¦ what? How?
1 Like
Weāre a team of 4. Each member on avg has 5y experience in crypto.
1 Like
More seriously, I donāt think it takes 4 senior devs to do this project 6 months.
Check out these projects for example:
https://www.youtube.com/results?search_query=gmail+clone+cs50
They were done by CS students.
Slap in some rpc to zcashd and voila.
1 Like
At this point, weāve pretty clearly established that @hanh and @SexDrugsAndZcash vote to pass on the proposal. What does everyone else think?
2 Likes
Iād rather have a ZIP that defines how messaging uses the precious 512 bytes of memo and add an inbox/outbox to an existing mobile wallet.
That said, it wouldnāt get much use - for example there are only 2600 messages on ZECpages & thatās been around for ages & is well known.
I would vote no.
1 Like
To me this sounds like using Zcash memos as a messaging primitive with an atomically included micropayment. Iām definitely in favour of that.
For one thing, itās always been my impression that one of the primary motivations for cryptocurrency in the first place was to enable micropayment systems for messaging. At least I personally have always had it in mind, before BTC even, that digital currency will have āarrivedā when we can do that. Maybe thatās just an artefact of my coding theory background, I donāt know.
If ZCash isnāt scalable enough for the micropayment use case, then I suppose there are two responses: decide that Zcash isnāt going to be āthat kind of cryptocurrencyā, or continue to aim for it. I donāt have enough technical knowledge at this point to evaluate how attainable this level of scale would be, or if itās going to impose too much of a trade-off for other use cases, So maybe Iām being naive. But I have a lot of faith in our ability to figure out how make it work if we want to.
5 Likes
I like it, cool!
3 Likes
I 100% support this idea and would like to see it come to life.
Zemo would appeal to the general public because of the name (itās catchy and easily understandable) and its simple use-case. Sure, wallets can send memos but most people wouldnāt understand how to do it without being told they actually can. Most people who use their crypto wallets are generally receiving or sending crypto. Zemo is message-based-first on the zec blockchain so anyone who installs this application will know it is specifically for messages. Imagine when you can integrate this app with other zec-based apps? Or even our favorite apps like twitter or Instagram? Unstoppable.
Zemo could even take out the normal e-mail system simply because of the fact that a transaction is involved to send a message. Companies and influencers would love it. For example, under many instances, influencers receive unsolicited DMāsā¦. Why not get paid in ZEC with a simple messaging app to receive them in the first place?
Keep wallet and messaging separate. Itās a lot more organized imo. There is a lot of possibilities that can go about this idea.
P.s. I love Zcash. Thankful for the hard work and support of the whole community.
5 Likes
When it comes to the monetizable inbox, thatās an interesting idea, which has been done by Facebook and LinkedIn, but with them keeping the profits. Audience engagement platforms exist using SMS, such as Subtext, but having a crypto-based system with variable messaging cost set by the recipient could prove valuable for Zcash adoption, especially if the UX is really nice.
For persisting private messages permanently on a blockchain, itās worth keeping in mind that there is the potential issue of quantum computers being able to decrypt messages at some point in the future; private messages are more of a sensitive area compared to financial transactions in my opinion, and if this data can safely be stored in an encrypted form on a central server, thereās less chance of it hanging around 15 years in the future. Also, re the scaling question, it could be worth exploring the idea of using a Filecoin/IPFS database as off-chain storage; considering people would be paying per message, the transaction fee could include a Filecoin fee to host the message say for one year, and Zcash memos could be used as pointers or key rotation (just a quick thought, might be a stupid idea 
, would need to be audited). This would resolve the issue of the 512 bytes limit too.
6 Likes
Absolutely. This is exactly our vision.
See my thread here:
especially if the UX is really nice.
We have a full-time UX/UI designer on our team that has designed a p2p chat app with 150,000+ users. Our team is very strong when it comes to UX design and branding. V1 may not be perfect due to some technical limitations, but we do expect the UX will be very good.
For persisting private messages permanently on a blockchain, itās worth keeping in mind that there is the potential issue of quantum computers being able to decrypt messages at some point in the future; private messages are more of a sensitive area compared to financial transactions in my opinion, and if this data can safely be stored in an encrypted form on a central server, thereās less chance of it hanging around 15 years in the future. Also, re the scaling question, it could be worth exploring the idea of using a Filecoin/IPFS database as off-chain storage; considering people would be paying per message, the transaction fee could include a Filecoin fee to host the message say for one year, and Zcash memos could be used as pointers or key rotation (just a quick thought, might be a stupid idea
Interesting points to consider for sure.
3 Likes
Hi @Ziga,
I love your enthusiasm for Zcash and your proposals for making Zcash applications 
One question I have is, could you do a compare and contrast with the Zbay project that was funded by ZF already? It seems like there is some overlap between Zemo and Zbay and making sure the wheel doesnāt get reinvented would be helpful for me to understand the full picture of messaging using the Zcash blockchain.
Thanks!
3 Likes
Thank you, David. Zcash has been my favorite project for many years now. I hope my efforts can help the privacy movement.
My understanding is the the product offerings are significantly different.
Zbay is built for public community chat ā Zemo is for private person to person messaging.
Zbay is a desktop only app ā Zemo is a mobile app (Android and iOS).
Zbay doesnāt save messages to the Zcash blockchain ā Zemo does.
I may have mixed up some details here regarding Zbay. If I have, someone please correct me.
4 Likes
Is the plan to build Zemo with native Android/iOS code or a mobile framework like react/flutter?
Note: using a framework ends up adding 50MB+ to the APK download size and restricts users who donāt want to install yet another messaging app.
Would you be open to contribute to existing wallet app codebase to add the Zemo/Zubscribe specific features? As duplicating & maintaining the underlying wallet app can be a huge challenge, especially with the frequent network upgrades of Zcash.
4 Likes
Weāre planning to build the app in react native. Extra download size is a small issue imo. Moving faster and supporting both platforms out of the gate is more meaningful . Plus weāll produce a nice RN codebase that is open source and can be used by other teams.
From a product/UX point of view, Iām not a big fan of this approach. My view is we need Zcash mobile apps that have different use-cases that are branded differently and speak to different audiences. Adding everything into one or two wallets makes for a clunky UX.
3 Likes
React Native is pretty good in terms of being lightweight and performant (provided you optimise your code properly, and avoid the native bridge bottleneck). How we reduced our production apk size by 70% in React Native? - DEV Community š©āš»šØāš» ā you can get React Native apps down to 8MB it seems.
Would be helpful to know how much experience a team has with React Native, as itās quite different from React web, and thereās a number of performance considerations like using FlatList and Animated (or React Native Reanimated) well, ability to debug, familiarity with Java/Swift/Objective C for developing or maintaining native modules, and doing manual linking.
3 Likes
Using aab bundle is a standard practice when publishing on Google Play Store. It strips unused dependencies, yet the standard react based mobile app has a larger footprint when factoring in the custom app codebase.
2 Likes
Our mobile dev specializes in React Native. Heās been making RN apps since 2016. Very very senior. Weāll find ways to optimize the the app size as much as we can.
The cost and time to build and maintain native apps across both platforms would be significantly more expensive.
2 Likes