New BSIP: Protected messaging
- Dominant language
- No language data
- Stars
- 59
- Forks
- 86
- PR merge metrics
- No merged PRs in 30d
Description
# 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 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
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.