[![Screen Shot 2016-11-18 at 9.20.19 PM.png](https://s18.postimg.org/6vb882xa1/Screen_Shot_2016_11_18_at_9_20_19_PM.png)](https://postimg.org/image/4182umv3p/)

**Note- this is a working Alpha product for testing.** 

I'm very excited to announce the alpha release of our newest development - SteemMsg.  

https://www.steempower.org/steemmsg 

SteemMsg is a fully encrypted private messaging system built on top of the Steem blockcain. The current 'Memo Field' requires you to send a small amount of funds to send someone a message. SteemMsg does not require that, nor do we require your owner or active key. 

Anyone can send you messages, but unless you login to https://www.steempower.org/steemmsg, it will not spam your Steemit.com inbox or show on your Steemd.com page. 

I am monitoring my inbox now, send a message to 'charlieshrem' :) 

[![Screen Shot 2016-11-18 at 9.19.05 PM.png](https://s18.postimg.org/f3d5t2p6h/Screen_Shot_2016_11_18_at_9_19_05_PM.png)](https://postimg.org/image/wgng7xkhh/)

## Process flow - sending

When the send_private_message cap (see our API documentation to find out more about our capabilities/caps system) is invoked the web app does the following:

 1. Basic sanity checks (user actually exists, cap is valid etc)
 2. Lookup the profile info for the user the message is being sent to and grab their public posting key
 3. Derive the shared secret and encrypt the message content
 4. Pass the encrypted message content and the public key along with the sending user's private key to a backend process
 5. Forget the posting key - we never store your posting key on disk for obvious security reasons, it lives in RAM only while a request is served

The backend process is connected to either via the loopback interface or via an encrypted SSL connection, upon receiving the request it does the following:

 1. More basic sanity checks and authentication
 2. Construct the custom_json operation and the surrounding transaction
 3. Sign the transaction and then lose the private key
 4. Pass the serialized transaction off to a steemd node for broadcast
 5. Return to the web app confirming everything was sent correctly OR (hopefully not) with an error message

After broadcast, our server also caches the transactions for every user - this cache will be used for running AJAX updates soon too.
No sensitive data is in the cache - it's simply our way to locate messages quickly without crawling the whole blockchain.

[![Screen Shot 2016-11-18 at 9.20.02 PM.png](https://s18.postimg.org/v0bxpshkp/Screen_Shot_2016_11_18_at_9_20_02_PM.png)](https://postimg.org/image/54s76lfqt/)

## Process flow - reading

Due to the cache mentioned above this is fairly simple, we grab data from the cache to build your inbox and outbox, organize it into conversations
and sort by the time sent. While building the response to send to your browser we use your private key to decrypt them and then forget it.

Remember, our system only has access to your private key when your browser makes a request - the caps URL itself has the key in an encrypted format.

## Shared secret deriviation

Here I must give credit to @xeroc for his highly useful python-steemlib. Anything on SteemPower that requires signing transactions relies on this library to do the serialisation and signing.

For SteemMsg in particular there's another function used from python-steemlib: the memo encoding and decoding. Although intended for use in transaction memos, this still works fine for encrypting arbitrary messages between 2 users with public/private keypairs.

Essentially the code in python-steemlib offers a useful function that takes a private key and a public key and creates a shared secret suitable for use in AES. It also provides facilities for serialisation and deserialisation of the message.

Using this shared secret, we encrypt the message content and store it in the msg field, read below for the full process.

[![Screen Shot 2016-11-18 at 9.20.34 PM.png](https://s18.postimg.org/64ii2auwp/Screen_Shot_2016_11_18_at_9_20_34_PM.png)](https://postimg.org/image/64ii2auwl/)

# How SteemMsg works [Technical] - Written by @garethnelsonuk 

First of all, the most important thing to note is that we do NOT use the existing send_private_message functionality in cli_wallet. I investigated this approach and found that it required using people's active keys and SteemAccess currently only supports the posting key - this is by design, we do not want your active key and you should not want to give it to us.

Instead we use a custom JSON operation, and if you look at my or charlie's page on steemd.com you'll find a few from testing.

The custom_json operation is quite cool for our purposes as it allows inserting arbitrary JSON into the blockchain and only requires your posting key. Aside from this, JSON fits neatly into the development workflow as it's far simpler to manually manipulate as needed.

In the custom JSON operation we send just 2 fields: "to" and "msg". While it should be self-explanatory what these fields are for, let's look more closely at the contents of the "msg" field.

## Coming soon - AJAX and notifications and bears oh my

Well this doesn't need a lot of explanation: we've got a nice async notification service with websockets support that will be used to send
typing notifications and such and to update messages in realtime.

Sadly we do not have a lot of bears - it appears that it is not in fact possible to serialise actual bears into JSON objects - perhaps msgpack?

Being serious, what comes after the notifications is further integration with SteemDeck - another product launching very soon.

Please feel free to make feature requests to either myself or Charlie and thanks for reading.

-----

Help keep SteemPower running! Voting for us as witness pays for the development of apps and tools for Steem.

Vote for us as a witness the following way:

https://steemit.com/~witnesses click the arrow next to "charlieshrem"