Open OpenLedgerApp opened 5 years ago
imho this can be implemented as 3rd party app. Why we need to change BitShares core to integrate it ?
I've got answer on my own question in this comment of @jmjatlanta https://github.com/bitshares/bsips/issues/126#issuecomment-441713299
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.
Thanks, @abitmore . Plugins might be a good way to implement it. and then we don't need to update consensus!
Even if this does not change consensus it would be a good idea to publish a spec in the form of a BSIP. See https://github.com/bitshares/bsips/pull/116#pullrequestreview-190793846 .
@pmconrad thanks! we will publish a spec in the BSIP's format.
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.
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