New BSIP: Protected messaging

[OpenLedgerApp]

Add the protected Messaging functionality

Abstract

A user is able to send encrypted message to any other user in Bitshares.
This should be done as a separate custom operation.

The interaction with messages should be implemented via plugin, that should be configured to be loaded by default by all nodes.

Motivation

Currently, there is a possibility to pass information to a BitShares user. However, they might miss this information easily.

A new protected messages within the BitShares itself would provide the possibility to exchange information in a protected manner.
As well as to broadcast important information for a particular group of users.
Possibly, this may be useful to provide information about important BitShares updates or events.

Technical specifications

The following user stories should be implemented: List messages, Read a message, Send a new message, Reply.
Threading can be implementing via referencing the block_id of the previous message.
Then one can identify the previous message, and its ancestors.
Discussion - there is a possibility of similar messages from the same sender in 1 block. Then it could present a little problem. However, the probability is quite low.

Custom Operation specs:

struct custom_operation
{
    ...
    vector<char> data;
}

Where data could contain the following message in our case (data struct):

struct message {
    // Contains type/signature of message
    header;
    // list of encrypted keys for recipients
    keys;
    // message body
    body;
    // list of recipients public keys
    recipients;
    // sender pubic key
    sender;
    //block id
    block_id;
    //prev block id (for Reply and Threading
    prev_block_id;
}

The message::header is used to detect and filter different types of data. It can contain any service data.
Sender uses symmetric key_for_encryption to encrypt the message::body. Then this key_for_encryption is encrypted again - separately for each recipient (using recipient's public key).

message::keys contains encrypted key_for_encryption.

message::body is an encrypted message

Message plugin specs:

class message_plugin : abstract_plugin
{
...
}

message_plugin could be enabled/disabled for each node.
If it is enabled, plugin will subscribe to events from database for custom_operation during initialization.
During callback, the plugin filters operations and stores them in its own local storage (memory/hard drive). Then a user will be able to find, decrypt and read own messages.

Also message_api should be optional. This api provides functionality for messaging.

For Reply functionality message::recipients and message::sender could be used.

Side note

Bitshares UI is to be updated to show these transactions on a convenient separate page, similar to an Inbox of a typical email box.
The following user stories should be implemented in UI: List messages, Read a message, Send a new message, Reply.

CORE TEAM TASK LIST

• Evaluate / Prioritize Feature Request
• Refine User Stories / Requirements
• Define Test Cases
• Design / Develop Solution
• Perform QA/Testing
• Update Documentation

[cogutvalera]

imho this can be implemented as 3rd party app. Why we need to change BitShares core to integrate it ?

[cogutvalera]

I've got answer on my own question in this comment of @jmjatlanta #126 (comment)

[abitmore]

This feature doesn't update any consensus. For example, it can be done with a plugin which made use of custom_operation. If want the default UI to have such feature, we can set the plugin to be loaded by default and ask API nodes to do so.

[OpenLedgerApp]

Thanks, @abitmore . Plugins might be a good way to implement it. and then we don't need to update consensus!

[pmconrad]

Even if this does not change consensus it would be a good idea to publish a spec in the form of a BSIP. See #116 (review) .

[OpenLedgerApp]

@pmconrad thanks! we will publish a spec in the BSIP's format.

[jhtitor]

FYI, we have implemented a chat functionality using the BTS memo messaging mechanism, that doesn't touch bitshares chain at all. I shall share the "spec" if there's any interest.

Cons: it's stand-alone, i.e. there's no way to send messages from one server to another.
Pros: you can actually delete messages, as they are not stored on chain.