Chat mobile app powered by Zcash blockchain

Community Grants Applications
1

Hello everybody. My idea is to create chat mobile application that is powered by Zcash blockchain. I already did PoC of this approach. You can look at it here. Here is my proposal how to progress from PoC stage to the final product which can be used by users and other developers.

Title:

Chat mobile app powered by Zcash blockchain

Pitch: A one-liner elevator pitch version of your proposal

Implement a mobile chat app (and mobile SDK) that uses the Zcash blockchain to encrypt and transfer messages.

Applicant background:

I started with iOS development in 2008 right after the first iOS SDK was released. Throughout my career, I have gone through a lot. I learned how to start new projects and I also learned how to join big projects which are already in progress. I also experienced different roles throughout my career. I worked at different companies in different positions (iOS Developer, iOS Tech leader, iOS Team leader).

I worked for the ECC from October 2022 until May 2023. My main responsibility was to take care of the Zcash iOS SDK. During that time I designed and implemented the new architecture concepts the current SDK builds upon. Thanks to this I know this technology very well.

I don’t have much practical experience with Android development. But lately, I studied Kotlin a bit and I think I can deliver what I’ve described in this proposal.

Description of Problem or Opportunity:

I spent some time with the Zcash SDK and realized it can be used to build a simple chat app (Messenger). It started as a fun project but at some point, when the prototype was done, it was obvious not only it can be done but there’s a huge potential in it. With some help and support from friends and later Zcash community members, the pile of ideas and possible road map convinced me to push the project even further. This proposal builds on mistakes and experiences gained from the work on a prototype (https://www.youtube.com/shorts/qFgqpj0weWc) of the messenger and takes it a huge step forward with much bigger potential and possible use cases.

Proposed Solution: Describe the solution at a high level.

Each Zcash transaction has a memo field. It is possible to send any arbitrary data in this field. My idea is to use this memo field to attach chat messages to the transactions. Then the chat app can read data from the memo field and visualize them as chat messages, not as a feed of transactions. Users see a list of chats and a list of messages in each chat as in any other messenger instead of a list of raw transactions. The cost of each transaction is only a network fee. Using this app isn’t free but the cost is very low. And any user gets a high level of security.

Solution Format: What is the exact form of the final deliverable you’re creating?

The prototype is a standalone iOS app which means no Android app and no one can reuse it or simply integrate it into their apps. Therefore I decided to build:

  • iOS SDK that provides API which allows any other app to implement chat functionality. This SDK also includes a configurable UI (ready for both SwiftUI and UIKit) so the 3rd party apps can integrate the chat with as little code as possible (as close to one line of code to integrate as possible).
  • iOS messenger app using this SDK.
  • Android SDK that provides API which allows any other app to implement chat functionality.

Note: Android Messenger is out of the scope of the proposal, the goal is to provide the Android SDK and leave the door open for either a different proposal or contributors. It should be easy when following the principles of iOS Messenger and use of iOS SDK

Technical Approach: Dive into the how of your project. Describe your approaches, components, workflows, methodology, etc. Bullet points and diagrams are appreciated!

Transaction’s memo field is used to transfer chat messages and any information required by the chat. I defined a very simple protocol that is used by the chat application. Each message contains 22 bytes of protocol header and the rest of the available memo bytes can be used to send the message itself (or any data in general). Thanks to that protocol the chat application can then uniquely identify messages, group messages into the right chat and sort the messages.

The protocol header looks like this:

  1. ZIP-302 arbitrary memo byte
  • 1 bytes
  • Value 0xff is defined in ZIP-302.
  1. Prefix
  • 3 bytes
  • “}b.” - three unique characters used to identify chat transactions. A wallet can contain a mix of financial transactions and chat transactions.
  1. Version
  • 1 byte
  • Protocol version.
  1. ChatID
  • 8 bytes
  • Unique identifier of one discussion between two people.
  • This is used to correctly group messages into chats.
  • This is generated by using timestamp and random number.
  1. Timestamp
  • 5 bytes
  • A moment when the messages were created.
  • This is used to correctly sort messages.
  1. MessageID
  • 3 bytes
  • The random number that is part of the message unique ID.
  • When MessageID and Timestamp are combined then unique ID is generated.
  1. Message type
  • 1 byte
  • Next to the visible user messages the chat app also sends some “invisible” messages. For example initial message with a verification code that marks the start of the chat. So it is necessary to have a mechanism how to recognize different type of messages.
  1. Message content
  • Rest of the memo field.
  • Actual content of the message.

Verification problem

With Zcash it is not possible to verify who sent the transaction. This creates a problem how to verify that the person on the other side of the chat is the expected person.

I built a verification mechanism that solves this.

Let’s say that Person A wants to create a chat to talk to Person B:

  1. Person B gives the unified address of his/her wallet to the person A.
  2. Person A creates a new chat and uses person’s B unified address.
  3. When a new chat is created unique verification code is generated for that chat.
  4. Person A now sees in the chat app a newly created chat with a verification code.
  5. Person B now sees in the chat app a new unverified chat.
  6. Person A sends (by some different communication channel) his/her unified address together with the verification code for the new chat to Person B.
  7. Person B inputs A’s address and verification code into the app. If both information is right new chat is now verified. And both parties can be sure that the right person is on the other side of the chat.

Dependencies: What external entities is your project dependent on? What involvement is required from ZF, ECC, and/or other external organizations? Who would have to incorporate your work in order for it to be usable?

I must make a small change in the Zcash SDK. I can make the change on my own. I only require support from ECC to integrate this change into the Zcash SDK upstream. Other than that my project isn’t dependent on any 3rd party.

Execution risks: What obstacles do you expect? What is most likely to go wrong? Which unknown factors could jeopardize success? Who would have to incorporate your work in order for it to be usable?

I already did prototype of this project. So I know that it works in principle. There shouldn’t be any major blockers which could tank the project delivery.

To make my usable the iOS chat application must be released to the Appstore. Or any other app must use chat SDK and integrate it.

Unintended Consequences: What are the negative ramifications if your project is successful? Consider usability, stability, privacy, integrity, availability, decentralization, interoperability, maintainability, technical debt, requisite education, etc.

Zcash network performance

If this chat is used by a lot of users it increases the number of transactions in the Zcash network by a lot. Can the network handle this? Won’t be the network overloaded?

Quantum attack

A disadvantage of using blockchain technology for chat is that chat messages are stored in the blockchain forever. If somebody can crack Zcash encryption by using a Quantum computer (or any other method) then that person can read all the messages that were ever sent.

Evaluation plan: What metrics for success will you share with the community once you’re done? In addition to quantitative metrics, what qualitative metrics will you commit to report?

All the that I write will be available in public git repository under MIT license. During development anybody will be able to see my progress. And when I am dony anybody will be able to use all my code.

Budget

Hardware/Software total budget:

$0

Please provide justification for the total hardware/software budget:

N/A

Services total budget (cloud, hosting, etc.):

$0

Please provide justification for the total services budget:

N/A

Compensation total budget:

$83200

Please provide justification for the total compensation budget:

This covers me as one engineer on this project. Cost is $100 per hour. Each milestone is scheduled for one month. And I plan to deliver 80 hours of work each month. This doesn’t apply to the Milestone 9 (Android SDK). It will take me more time and more learning to deliver Milestone 9. Therefore Milestone 9 is scheduled for three months and the cost is $80 per hour.

Schedule and Milestones: What is your timeline for the project? Include concrete milestones and the major tasks required to complete each milestone.

How was the project timeline determined?

I divided whole project to the smaller tasks. Then I estimated how long will it take to implement each task. Then I put tasks that can together take 80 hours to make into each milestone.

How did you learn about Zcash Community Grants?

I worked for the ECC in past and I learned there about Zcash Community Grants.

Milestones

Milestone 1 - delivery date (month of a work, 80 hours of work per month)

Month after the project start.

Milestone 1 - Payment

$8000

Deliverable 1.1

  • Design iOS SDK API and architecture.

Deliverable 1.2

  • Extract everything related to the chat protocol from the iOS prototype and include it in the iOS SDK. Update the code from prototype quality to production quality.

Deliverable 1.3

  • Update the existing code from prototype quality to production quality. And implement what is missing to have first of the first iOS SDK with basic functionality.

Milestone 2 - delivery date

Two months after the project start.

Milestone 2 - Payment (month of a work, 80 hours of work per month)

$8000

Deliverable 1.1

  • Update Zcash iOS SDK upstream. Some small updates are required by the chat SDK.

Deliverable 1.2

  • Cover the iOS SDK with tests.

Milestone 3 - delivery date

Three months after the project start.

Milestone 3 - Payment (month of a work, 80 hours of work per month)

$8000

Deliverable 1.1

  • Design and prototype configurable UI that will be provided by the iOS SDK

Deliverable 1.2

  • Prepare a project for the iOS Chat app that will use the iOS SDK.

Milestone 4 - delivery date

Four months after the project start.

Milestone 4 - Payment (month of a work, 80 hours of work per month)

$8000

Deliverable 1.1

  • Implement start screen for the iOS app (create new/restore account).

Deliverable 1.2:

  • Implement “create new account” UI and flow for the iOS SDK.

Deliverable 1.3:

  • Implement “restore account” UI and flow for the iOS app.

Milestone 5 - delivery date

Five months after the project start.

Milestone 5 - Payment (month of a work, 80 hours of work per month)

$8000

Deliverable 1.1

  • Implement a “chats list” UI for the iOS app.

Deliverable 1.2

  • Implement a “new chat” UI and flow for the iOS app.

Deliverable 1.3

  • Implement a “messages list” UI for the iOS app.

Milestone 6 - delivery date

Six months after the project start.

Milestone 6 - Payment (month of a work, 80 hours of work per month)

$8000

Deliverable 1.1:

  • Implement a “chat verification” UI and flow for the iOS app

Deliverable 1.2

  • Implement additional smaller screens for the iOS app. For example about or debug screen.

Milestone 7 - delivery date

Seven months after the project start.

Milestone 7 - Payment (month of a work, 80 hours of work per month)

$8000

Deliverable 1.1

  • Finalize the iOS app. Use all the functionality that is provided by the iOS SDK.

Deliverable 1.2

  • Add support for biometric authentication (FaceID/TouchID) to the iOS app.

Milestone 8 - delivery date

Eight months after the project start.

Milestone 8 - Payment (month of a work, 80 hours of work per month)

$8000

Deliverable 1.1

  • Add additional features to the iOS SDK and use those new features in the UI.
    • Soft delete of the messages or chats.
    • Making chat aliases (names) permanent.

Deliverable 1.2

  • Start with preparations for the Android SDK. Setup the project.

Milestone 9 - delivery date

Eleven months after the project start.

Milestone 9 - Payment (3 month of a work, 80 hours of work per month, 160 hours total)

$19200

Deliverable 1.1

  • Implement the Android SDK with all the functionality that the iOS SDK has.
4 Likes
2

Hi @Chlup - Welcome to the forum, and thank you for submitting your grant proposal! We will review it in the upcoming weeks and reach out if we have any questions.

In the meantime, if you have any questions for us, you can post them to this thread or DM us at @ZcashGrants.

Zcash Community - We want to hear your feedback on this grant! You can post your comments to this thread or DM us at @ZcashGrants if you’d like to provide feedback in private.

Thanks!

3 Likes
3

FYI: I had read this grant a few days ago and I was waiting for it to be published here to comment.

TL;DR; I think this is a decent idea

Long answer: I have (unsolicited) opinions! to explain why this could work. (where others didn’t)

There have been many attempts to create applications of this kind. They didn’t make it far for different reasons.

I think there’s a use case for messaging through blockchain and it’s not about chatting with friends about the last football match, but to shortly communicate with people you are specifically transacting with.

Zcash users choose ZEC because of it privacy features. They will transact with trusted and un-trusted parties. Both parties do* trust one thing: Zcash. Why should they engage through a different platform like Telegram or Signal to transact with Zcash?

I think one flaw previous Zcash messaging apps proposals had that it was always pointed out was the throughput needed to make a ZEC-powered Slack (like Zbay was), Signal, whatsapp you name it.

As I pointed out there is a use case here. If I want to buy cookies from the Venezuelan Pastry maker that accepts ZEC. I probably will just have 2 or 3 round-trip convo about how many cookies, how much and pick-up / delivery and that’s is. That’s a sensitive convo that if I pay with ZEC then it makes sense to have through ZEC.

This grant addresses an existing problem: message verification.

This protocol is simple and works around something we are lacking: a simple way to generate a signature that can be embedded to a memo that proofs that the sender has spend authority over a specific address.

The proposed verification protocol suffices for a brief shielded chat app like this one, and it points out a requirement that is absent from the currently available features in Zcash. In order to make shielded memo “actionable” by software, they should be verifiable. It is unsafe to code a logic around a memo format without the app being able to verify that the sender is someone that it is trusted. In this case the it is the user who visually makes the verification. If we wanted to code systems that use shielded memos then we will need this verification to happen non-interactively

There is a proposal for implementing ZIP-304 for signing Sapling addresses but it hasn’t been merged.

Follow up ideas
This apps could be incubator for a small SDK that wallets can use to leverage ZEC messaging as a UX feature.

4 Likes
4

I’d suggest that the shop generates a diversified address (unique) and gives it to you.
Then they would know that messages they receive to that address must come from you since you are the only person who has it.

1 Like
5

Yes that’s a great idea. Also that is useful for customer management for the merchant as well.

6

It is how the integration I have made for btcpayserver works.
Every invoice gets a new diversified address.

7

Hi @Chlup

I like the idea of a messaging app for Zcash, however I believe it is outside the scope of ZCG, for the reason that if this was fertile ground for such a product to exist then someone should build it without a grant, make it proprietary, and introduce a fee rake on each message, or make money from advertising banners or something…

3 Likes
8

@zkcroc Thanks for the feedback.

9

Looking at the suggested protocol, I think there are more standard methods for message authentication that could be leveraged.
But generally speaking, I think there is not enough interest in a new chat message service when signal, session, Whatsapp etc. are free options.
I would use one of them and diversified payment uris for identifiable transactions.

1 Like
10

I appreciate your idea. But my question is why a chat app on a money network. Do you like to make the chain bloated. There are plenty of options out there outside blockchain to chat. Please don’t feel bad, may be you can contribute to the protocol with something different.

11

@Steelzec No hard feelings. I appreciate constructive feedback.

My thinking originally was: “Hey. There is a tech that may allow people to communicate securely. And also it may give one more practical purpose to ZEC.” So I built a PoC of this to see if it can be done and I liked it. As @pacu wrote something like this won’t ever be mainstream chat that people use to talk about their lunch with others. It is a specific tool that offers a high level of security and because of that, it has some limitations in comparison with other chat applications.

My expertise lies more on the frontend side. So if Zcash devs or community (or both) decides that using Zcash blockchain like this is not a good idea then I won’t do it. I don’t like to make chains bloated. On the other hand, I am not doing anything “illegal” to the blockchain. Just sending transactions with memos. It is probably something that was Zcash blockchain designed for. At least that is my expectation. Maybe I made some wrong assumptions.

1 Like
12

@Chlup Thank you for your submission. After consideration from @ZcashGrants and sufficient time for the community to provide feedback on the forum, the committee has decided to reject this proposal.

The committee appreciates your grant submission efforts and encourages you to continue as an active member of the Zcash community going forward, both here on the forum and in the below avenues as well:

1 Like