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
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:
Where data could contain the following message in our case (data struct):
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:
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