Announcement

Ethereum Classic address-to-address messaging system release. Messaging system represents a smart-contract basic on-chain communication service wich allows to contact any other participant of the network absolutely securely.

The Messaging System allows crosschain interoperability, which means that you can send message from ETC chain to the owner of ETH, UBQ, EXP, Musicoin, RootStock or PIRL address. ETC smart-contract system acts as the core component of the system. Messaging System supports off-chain encryption via the asymmetric encryption algorithms.

Launch date: 29 Jan, 2018 - contract deployment date.

Originally this messaging system will be implemented at ClassicEtherWallet. Initial version will include a possibility to send and receive simple text messages between addresses.

Advanced functionality, such as message encryption, public key import/export will be added at further releases.

References

Education about building of crosschain services: read this article

Original implementation of the messaging system smart-contract by Ethereum Commonwealth: https://github.com/EthereumCommonwealth/Address-to-Address-messaging

Address-to-Address messaging system code at Ethereum EIPs: ethereum/EIPs#802

Abstract

The following describes the details of the smart-contract based messaging system which aims to allow Ethereum users to directly contact the address owner without having to know who hi (she) is.

Motivation

Ethereum lacks a central messaging system that will allow to contact an address owner directly. You can send him a transaction with ASCII message attached as data but it is likely that address owner will not even try to recognize it as a text message. As the result there is no viable way to deliver a message to address owner directly.

This service is necessary in some circumstances, for example:

1. You sent someone a token, the existence of which this person does not know. It is likely that a person will spot an incoming ETH transaction, but there is no way that a person will spot an incoming token transaction or the fact that his balance of this token increases. You need to contact the owner of this address and ask to send your tokens back.

2. You sent ETC into someone's ETH address. The same situation as with tokens. It is likely that a person will not recognize an incoming transaction of an alternative currency. But he definitely can access it and send it back (or just go and sell it).

3. You spotted that someone have deployed a contract that is proven to be vulnerable. If you're a good guy then you want to contact an owner of the "vulnerable contract" and warn him that he is going to use a contract that contains vulnerability and his funds are at risk in this case.

4. You spotted that someone has hacked something. You would like to contact a hacker and kindly ask him to send everything back but the hacker likely will not respond if you will try to contact him via forums. I suppose that it is the most important case. On-chain methods of communication are the only way to securely contact a hacker or to respond if you are the hacker.

Specification

Basic address-to-address messaging smart-contract.

This is a simple smart-contract that stores messages mapped to addresses by id and a mapping that represents the last message id for each address. Last message id increases for the receiver address when this address receives a new message (there is no message at last_message_id in fact... this represents a numeric id that will be filled with the next incoming message in fact). If the last_message_id is equal to 0 then there are no messages for this address. If last_message_id is equal to 2 then there are 2 messages at positions 0 and 1 for this address.

There is no possibility to edit, change, delete messages. This contract is not a messenger or a chat. This contract is an emergency way to contact an owner of a certain address when there is no possibility to contact him off-chain. As the result, editing and deleting messages has no reason because it will still be available via history of transactions.

Basically, there is no way to encrypt message on-chain because there is no way to hide an input call data. As a result, there is an additional field for attaching a public asymmetric encryption key. If the owner of a certain address has a desire to allow someone to contact him privately, then he can publish his public key at this contract and describe what type of key he has published at the "Key type" variable (for example PGP public key or RSA 2048 bit public key). Anyone else is allowed to look at the public key in the contract, encrypt the message outside the network and send an encrypted message on this contract.

Resolution

Obviously, this contract can not guarantee that an owner of the address will receive a message. It requires to be supported by UIs. It is likely that an owner of a certain address will see a message if MyEtherWallet, MetaMask or Mist will display messages somehow (for example a certain number of last messages).

Also, it makes sense to standardize possible public key types. Ideally, UI should have a button "Send message to address" and "Send encrypted message to address" and distinguish public key, key type and then encrypt message automatically.