[20] Messaging

[wmbutler]

Allow for a messaging platform within the BTS wallet. Many potential uses including announcements, marketing, p2p communications. Since transactions cost BTS, this would self-regulate spam. BTS network earns fees in the process.

Establish JSON object for MEMO field:

{
  "subject": "Hello",
  "body": "This is the body of the message"
}

Other thoughts:

• [ ] Variable user-selectable fee, greater fee implies greater importance.
• [ ] Inbox can be sorted by time, fee (importance), from_account
• [ ] How can we flag messages as read/unread (on chain would be better in case browser Localstorage get hosed)?

[btsfav]

probably related to https://github.com/bitshares/bitshares-ui/issues/233

[startailcoon]

I've had this idea before but never actually posted about it, nice to see that it wasn't just me :+1:

You could build a messaging/e-mail application on top of the bitshares platform. The question is how expensive this will be to use for messaging. Instant messaging is pretty much no go I think, because of the fees.

[btsfav]

maybe of interest https://github.com/DECENTfoundation/DECENT-Network/releases/tag/1.1.0

decent added messaging in their latest fork.

[calvinfroedge]

Is this feature currently supported in core?

[svk31]

No it isn't. There are memos however which serve a similar purpose. The way I understand Bill's idea is that this requires a brand new message operation that does not transfer value, only a memo. That will require updates to bitshares-core and a hardfork.

[wmbutler]

Actually, I was thinking that it would just be a send operation and we would insert JSON to specify the message. The sender could determine the importance of the message by paying more or less BTS to send it eventually, but initially, it would be the bare minimum BTS fee + cost per KB, calculated for the user before send. Moving this to a later Sprint since it requires more conversation.

[gibbsfromncis]

@wmbutler idea looks nice. But I'm not sure that use of simple "transfer" as messages nice idea. This may cause new bugs and misunderstandings. For e.g. if I want to see only real transfers of money on "Recent Activity" why I should see a ton of transfers for 0.005 BTS? I have experience of idea like "add new feature on front-end but use a backend of another feature and recognize the type of feature by some additional field" And it was really bad experience and I suppose if we think a little bit more I'm sure we can find a lot of potential issues. Hierarchically it's bad idea.

So it's better to design like a separate operation and than use it. I can take a front-end part when backend will be ready and design it on front-end

[wmbutler]

Designing a separate operation is a core thing. I do see your point as it relates to activity logs.

[abitmore]

Since it's not a consensus feature, we can get use of custom_operation, however we need a plugin to notify the receiver, and perhaps store / cache the message, since messages can get lost very fast if this feature relies on analyzing account history.

Another option would be tracking the messages with ES plugin.

[gibbsfromncis]

@abitmore nice idea. So lets wait before ES plugin will be delivered and lets start @wmbutler I can work on this when backend guys will delivery ES.

[wmbutler]

I think the ES plugin is the way to go.

[AustinAmoruso]

I'm willing to help on the messaging UI. Let me know what we would want to build, maybe even do a bundling system to send multiple messages at once so you don't have to over pay for the messages. I have worked on messaging systems before in the past at prior companies as well.

[abitmore]

If use custom_operation, need to define message format which will need to be encoded. E.G.

{
  "category":"message",
  "type":"to-single",
  "to":"1.2.3", // "from" is omitted since it's implied by `fee_payer`
  "encrypted":true,
  "message": { // format same to encrypted memo
    "from_key":"BTS5Axxxxxxxx",
    "to_key":"BTS6Syyyyyyy",
    "nonce":31415926535,
    "message":"0a1b2c3d4e5f6789"
   }
}
{
  "category":"message",
  "type":"to-multiple",
  "to":["1.2.3","1.2.4"],
  "encrypted":false,
  "message":"hello"
}
{
  "category":"message",
  "type":"to-group",
  "to":["9.1.12345"], // need to define group somewhere else
  "encrypted":false,
  "message":"this is a message to a group"
}

We can document the specification in Wiki even in the BSIPs repo.

[ahdigital]

@wmbutler Can you explain a bit more your vision for this:

The sender could determine the importance of the message by paying more or less BTS to send it

If you think about an inbox where messages are ordered chronologically, what will having an importance weighting do? Is it just to bypass the standard messages and appear at the top in a 'featured/hot/important' section?

[wmbutler]

Importance could be represented in relative terms visually depending on the amount of BTS allocated to the message. Maybe there is a column that displays the value and allows the user to sort by that value in its simplest form.

[AustinAmoruso]

Please release this one I'm not certain if I will have time on this one at this point.

[calvinfroedge]

@wmbutler I will follow up here with both UX and research on custom operation calls.

[wmbutler]

I'm starting to think this is a bit out of scope for the wallet. We have so many other tasks that are better suited for a financial application.