Note: this project description was initially drafted earlier this year as a ZCG RFP, however, as ZCG is not currently committed to funding Shielded Messaging and therefore not actively soliciting bids, I am posting this here instead for discussion and posterity, as something we may be willing to fund in the future.
See also previously rejected but similar grant submission Zemo: Shielded Messaging
Motivation:
Zcash presents the opportunity, via its memo field, to provide secure, private messaging, arguably superior even to Signal, and other alternatives which, although end-to-end encrypted, have centralization dependencies, man-in-the-middle susceptibilities, and spam potential. However, there are constraints making it not immediately obvious how best to use the memo field in this way: space, time, cost, and connectedness of messages (eg. threading).
The envisioned project deliverables would include
- a detailed design document outlining a protocol addressing specific features described below,
- security and usability analyses where appropriate,
- a demonstration of implementation on an existing wallet
(Rather than building a new, standalone app, I suggest a smaller iteration as a proof of concept that can be used on existing infrastructure, but could later be the basis of a message-focused app. This is partly because the shielded messaging use case will depend for adoption on solving current syncing and scaling issues, and partly because ZCG prefers to allocate funding for protocol development and apps/wallets separately.)
Space:
The memo field is limited to 512 bytes, so by itself cannot carry long messages or high-information-content images. The protocol design should specify standard ways to either combine messages, or optionally to use out-of-band file storage and operate by transmitting capabilities to files, such as with IPFS, Magic Wormhole, or Tahoe-LAFS, and demonstrate how this would work in practice.
Time:
Zcash transactions are fast, but not real-time. This limits usability in situations where essentially instantaneous turnaround time is a user expectation. However, it is compatible with more asynchronous communications. In communications where such time gaps exist, there is an increased likelihood that response chains are heavily branched due to “simultaneous” responses, especially in multi-party contexts. This may impact threading intuitions. Innovative protocol design that copes with delays, as is seen in space communications (eg. [1]) may be desirable.
Cost:
Some community members have expressed skepticism that people would be willing to adopt a messaging system that entails a transaction cost, no matter how small. However, many are coming to realise that most information systems we currently use exact their costs in privacy and data access, as well as content moderation and manipulation. But beyond willingness to pay for such freedoms, the inherent micropayment associated with memo transactions can be seen as a feature, not a bug.
In particular, using micropayments on messaging systems has historically been a suggested mechanism for coping with unsolicited messaging–spam and phishing, by making the cost of broadcasting messages infeasible[2-4]. Not only could it be prohibitively expensive to send unwanted messages, but voluntary extra fees could be used as a filter, such that the recipient is not even alerted about messages that do not meet a threshold of payment [2]. The protocol could also implement an ACK system that returns voluntary excess payment to senders whose messages have been accepted, but not those whose messages are unwelcome.
The shielded messaging protocol design should make use of the transaction cost such that it is clearly providing value to the participants, rather than being an unfortunate side effect.
Connectedness:
A feature that is considered fundamental in messaging systems is threading. This entails recognizing that messages are from the same sender, and intended as responses. Sender authentication is beyond the scope of this proposal (covered in the Zcash Memo Field Secure Messaging Extension RFP), but threading is an important feature to be standardized.
Potential Dependencies:
- Syncing and scaling: because of the expectation of real-time interaction in messaging, messages over the Zcash blockchain may be more comparable to email or file-transfer/sharing systems than text messaging, however, if syncing times are decreased even with high transaction rates, this gap would narrow.
- Secure message authentication of senders: the would relieve the need to address authentication as part of this protocol
- Oblivious message retrieval: as with payments in general, messaging lookup is susceptible to traffic analysis (see Oblivious Message Retrieval)
[1] Braiding – A novel approach to supporting space/ground communication under signal latency)
[2] Cypherpunk mailing list (2005): Re: How to Stop Junk E-Mail: Charge for the Stamp
[3] Peer-To-Peer: Harnessing the Power of Disruptive Technologies Chapter 16: Accountability (2007)
[4] Bitcoin Forum (2012): Topic: include messages in transaction, alternate use: anti spam email
