One of the directions of development of Horizen is secure communications. This article describes the initial messaging features implemented in detail and charts a course for their extension in the future. To ensure inter-application compatibility we base ZenChat messaging on a well-defined protocol so that future apps (wallets/chat clients etc.) are compatible with each other. A messaging functionality running on a blockchain seems counterintuitive at first, considering the limitations in transaction throughput. But we believe that our scaling efforts will allow messaging on the blockchain to be feasible in the near future.

The value of our messaging protocol doesn’t just rely on regular user communication, but also on the communication between different nodes and/or applications on the protocol level.

Examples of messaging scenarios:

• 1-on-1 and group messaging – in the former case two entities chat with each other (classic chat case). In the latter case, many users send messages to a common “channel”. New users may be added to the channel.
• Messages with identifiable senders and anonymous messages – in some cases users wish to prove their identity to the recipients. In other cases, users wish to remain anonymous.

Based on the above we get four major uses case combinations (1-on-1 / group) combined with (anonymous/identifiable senders). The term user ought not to be strictly understood as a human user. We could easily imagine scenarios where AI/bots etc. use the messaging protocol.

### Users

A user may have multiple ZEN messaging identities that he presents to other users (as public information). The messaging client/wallet/GUI is responsible for maintaining these identities. A messaging identity needs to have the following information:

• a nickname that is arbitrary and user specified
• a send- and receive-address specifically created or designated for the messaging identity. It is used to send and receive messaging transactions.
• a sender-ID T-Address used to sign messages before sending (specific to the messaging identity)

Optionally a user is free to include other details, such as his first and last name and contacts like his email, phone number or Twitter handle. The way users share their identities to establish contact is not strictly defined. You can implement this in different ways:

As an initial implementation, GUI wallets/messengers allow users to import/export/copy/paste their ZEN identity or a contact’s identity as a JSON object. Users share their ZEN identities either privately (via other channels) or as a convenience on a dedicated ZEN slack channel.

Once user A imports user B’s identity, the respective GUI client could ask user A if he wishes to send his identity to user B as a ZEN special message. This is possible only if the message can fit in one Z→Z transaction (for ZEN messaging protocol version 1). Then user B’s GUI client will prompt him to import user A’s identity from the message.

Later a new (unfortunately centralized) “ZEN messaging server” could be implemented where users may publish their ZEN identities. The messaging GUI clients will access the server via some standardized interface. Users can publish or search identities on the server.

The desired long-term solution is a distributed registry of ZenChat identities on the Horizen blockchain!

### Messaging Protocol

ZEN user messages are transported as a part of T→Z and Z→Z ZEN transactions in the memo field. The memo field has a maximum length of 512 bytes and when specified on a command line needs to be in HEX format. There are currently some limitations in JoinSplits/→Z transactions that complicate the design of the protocol somewhat:

When a Z-Address receives an incoming transaction the recipient sees the date/amount/memo but does not see the sending T/Z-Address. This is the case for both T→Z and Z→Z ZEN transactions. When a transaction is sent from a Z-Address, it is not recorded in the sender’s wallet.dat

The limitations require that a sender’s identity is established at the level of the messaging protocol (by signing the message with a T-Address). Every sender of a message (taking part in ZEN messaging) needs to have two addresses:

• Z-Address to send and receive the messaging transaction (used for “transport” only)
• T-Address to sign the actual message sent and prove the sender’s identity (for the use case when the user is not anonymous).

A sender (human) may (potentially) have multiple messaging identities/contact details but for every identity/contact details a pair of Z+T-Addresses are to be created/designated for use. Every ZEN message is sent as one Z→Z transaction from a sender to a recipient in the first protocol version.

A message (“zenmsg”) in ZenChat is comprised of a data field indicating the version (“ver”) of the protocol that the program runs, the address of the sender (“from”), the actual message and a signature (“sign”). With this messaging format, the effective maximum length of a user message (“message”) is approx. 340 characters. Future protocol versions may allow larger messages by sending one message split into multiple transactions. When a user sends a message, the T-Address signs the text message of the sender and includes the signature in the message. There is no need to include a recipient because the information about the recipient is included in the signature.

{
"zenmsg":
{ "ver": 1,
"from": "znn9wRVAkgNnKCYJvsHu9nm4Q7c6AxLE2qR",
"message": "Actual chat message is here etc. whatever",
"sign": "H5L3vhCQ+3EAz7BRrpNqy2x42VF+oY1WowGxCwEJkMlcbfX+GLU3PWOzPwJK+BUBY5YoDk/hAkF4GwtqyWWOngI="
}
}


### Anonymous Messages

When a user sends a message anonymously the structure is slightly different. When user A sends the first ever message to user B - the GUI client generates a unique thread ID for the messaging direction (User A → User B), and stores it permanently. All subsequent unsigned messages (User A → User B) will come with the same persistent ID. The GUI client will present all anonymous messages it receives with the same ID, as coming from the same anonymous sender. An anonymous message does not contain a sender of any kind.

{
"zenmsg":
{
"ver": 1,
"message": "Actual chat message is here etc. whatever",
}
}


The difference between anonymous chat threads and chat threads with identified users is that a thread ID replaces the signature and sender. Because the sender is anonymous the recipient will not be able to respond to the message in a 1-on-1 conversation. Additionally, the message can include the sender’s Z-Address in the first (only the first) message sent (in the direction User A → User B). User B can then respond, all responses will use the same thread ID.

The new field, return address, may reveal a user’s identity (indirectly or otherwise) and weaken the anonymity. In addition, thread ID is not 100% reliable as an indication that messages come from the same user, especially in group messaging scenarios (other users may see and fake it).

{
"zenmsg":
{
"ver": 1,
"message": "Actual chat message is here etc. whatever",
}
}


A message is either signed with a T-Address or it is anonymous and has a thread ID, but never both.

### Special Message

One type of special message carries the details of a messaging identity in the first message. The sender uses this message to inform the recipient of the sender’s identity, so the recipient would not need to import this data in some other way. The message contains the user’s credentials in this special type of transaction.

### Group Messages

Group messaging involves multiple users sending messages to a single channel/group. Messages are visible to all users involved. The channel has a Z-Address that all users send messages to. Messages may have identifiable senders or they may be anonymous. To let other users know his identity details any user may send to the channel the special message mentioned above containing his identity details. If a user does not send this message other users will know their T-Address but will not know who is behind it.

Obtaining a Z-Address for a messaging channel is specific to the implementation of the messaging platform. The best way to obtain the Z-Address while maintaining convenience is to let users use a common phrase, such as a #hashtag. Each user individually converts this phrase into a Z-Address and imports it into their wallet/GUI client.

### Summary

A messaging feature is a valuable addition to the functionality stack of our blockchain platform. It does not only allow users to communicate 1-on-1 or in groups/channels, but also different software clients, wallets and applications. Users can create as many messaging identities as they wish and can choose to communicate anonymously or openly. A message in the ZenChat application is a transaction with the message attached in an additional data field. Messages via our ZenChat application allow for about 340 characters.

While users have to exchange their messaging identities externally at the moment, it is the desired long term plan to have a distributed registry of messaging identities on the Horizen blockchain. In order to create a messaging channel, a common phrase or #hashtag can be converted into a Z-Address.

Why don’t you try the ZenChat messenger out for yourself? Download our Flagship App Sphere by Horizen, activate the Full Mode in the Settings and send your first message. If you don’t own any ZEN yet, visit our Faucet where you will receive a small amount of free ZEN so you can start playing around.