Skip to content
This repository was archived by the owner on Oct 4, 2019. It is now read-only.
This repository was archived by the owner on Oct 4, 2019. It is now read-only.

ERC: Address-to-Address messaging system protocol #85

@Dexaran

Description

@Dexaran
ERC: <to be assigned>
Title: Address-to-Address messaging system protocol
Author: Dexaran, [email protected]
Status: Draft
Type: ERC
Created: 20-12.2017
Resolution: https://github.com/EthereumCommonwealth/Address-to-Address-messaging

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.

Methods

sendMessage

    function sendMessage(address _to, string _text)

Delivers a string message to _to address owner.

lastIndex

    function lastIndex(address _owner) constant returns (uint256)

Returns an index of the last message for the _owner address.

NOTE: This means that there are messages at 0 to lastIndex - 1 positions. There is no message at lastIndex position actually. This will be filled with the next message for this address. If the lastIndex is equal to 0 then there is no messages for this address.

getLastMessage

    function getLastMessage(address _who) constant returns (address _from, string _text)

Returns the last message for the _who address and the sender of this message.

NOTE: Message is actually at lastIndex(_who) - 1 position.

getMessageByIndex

    function getMessageByIndex(address _who, uint256 _index) constant returns (address, string)

Returns the message for _who address at _index position and the sender of this message.

getPublicKey

    function getPublicKey(address _who) constant returns (string _key, string _key_type)

Returns a public key of the _who address and a type of this key.

setPublicKey

    function setPublicKey(string _key, string _type)

Sets a public key and a description of key type for the sender address.

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions