SteemMessage - Bitmessage based distributed email and directory for Steem

Introduction

Steem is a blockchain based blog platform, but it currently lacks any kind of interface or system for email type messages. To remain in congruence with the distributed nature of the platform, a messaging and directory system also should not require central servers.

Bitmessage is a cryptographically secured message transport system, and even contains a lower latency message type, and given a reliable steem username to bitmessage address correlation, could broadcast updates of correct address, as well as a small set of fields for such things as general location, language preferences.

Individual nodes are built with bitmessage running as a service, and an sqlite database to store the current state of the directory data, and using a headless bittorrent client, publishes assembled current database files as well as the blocks propagated and certified by other SteemMessage clients.

By using a signature from the chosen bitmessage address as a memo in a token payment to Hive account@null, of 0.01 steem, other nodes can certify that they see correct proof of ownership and then within the SteemMessage UI, you can send and receive messages to other users by name, as well as find out what country and nearest large city to them, what languages they know... and also, using chans, create chatrooms as well.

Dependencies

SteemMessage is built upon the following systems:

1. Bitmessage

Bitmessage is used as the communications system. Each node sends out updates to all peers using the SteemMessage broadcast address. These include directory updates, and notifications about published sqlite directory .torrent files that other clients can then download and certify being true and current, and then propagate their signature certifying the veracity of the dump.

The complete raw message blocks from the beginning of the operation of the network also will be periodically updated and new blocks certified and signed, and available to sync by other nodes.

Using the directory, SteemMessage resolves Steem usernames to Bitmessage addresses, it can also show other data about the user they have broadcasted to the network. Because there is a linked bittorrent filesystem, this can include media files like photos, indeed it could be possible to build this out to store more data but it will primarily be used to distribute bigger data that the database should store, data only of interest to a smaller number of parties.

2. Piston

Piston enables linking the message and database system to the Steem accounts. Initially this will just be used to prove an account linked to a bitmessage address is controlled by the same person.

But later on it is intended that SteemMessage create broadcast addresses for advertising and stock management and for buyers to know what stock levels are. With Piston integrated, people will be able to arrange payments and communications and lodge feedback into another distributed database.

3. Bittorrent backend

In order to enable propagating larger blocks of data, a headless bittorrent client is used. When a node propagates a file, it sends the relevant info in a bitmessage broadcast or message, and the receivers can then subscribe and sync the data for whichever purpose.

This will initially be just the raw blocks, an index, and the parsed snapshot of all data up to date in sqlite format, which lightweight clients can download, and update patches as well as snapshots.

But later on, with the classified advertisment system, it can include media files that embed in the ad broadcasts, and when the lower latency short messages are also implemented for chat, this is how files can be privately shared between two users, and also as attachments for email.

Development Roadmap

1. Bitmessage message sending and subscription broadcast system with piston based verification

First thing to build is the Steem account verification protocol, the format for messages that announce updates to user records for name resolution, and the database schema and protocols for additional data.

At first the data is just independently compiled by nodes from the messages on the subscription channel. From these messages the nodes create entries in the sqlite database that allows the user to create messages to other users and view their profile data.

To prove control of an account, a user sends a minimum payment using piston to Hive account@null, signed by the secret key for the bitmessage address. When other nodes receive this, they search for the tx on the steem blockchain, and sign the txid of the payment using their BM secret key, and in the database there is a table for signatures, which accumulates until about 100 and then no more will verify.

At this point there will be no messaging or sync functions, just a search interface for finding other users names resolutions and additional entries like country and city, and you can see the BM address current for a Steem user.

2. Integrate email messaging, mailing lists associated with users, and instant messaging

SteemMessage will then implement an inbox with name resolutions, personal address books, sending messages to other registered Steem users Bitmessage addresses.

Bitmessage has a feature called "Chans" which use a pre shared key to allow two or more users to send short, quick messages. This will be extended to create an instant messaging interface, a faster, more transient variant of the regular email format.

3. Database and Blockchain Synchronisation, Certification and Bittorrent based File Sharing.

At this point integration with a bittorrent backend is done. A node makes a snapshot of its sqlite database and blockchain, generates the necessary file mappings and hashes, and then sends the info how to get it to the announce subscription address.

Other nodes can then download and certify the data is correct, and then propagate a followup message containing certification.

A node can choose to fully sync the blockchain, or only the snapshot and newer messages to update.

In anticipation of future automated monetary transactions, a node hosting a blockchain can charge some amount to other nodes to rapidly sync the blockchain, though the index will be available freely. Such could also enable vouchers for high priority direct queries of the blockchain for even lighter clients that sync nothing and go through a trusted third party.

Lastly, by use of the bittorrent backend, one to one or one to many file shares can be enabled. These can be whole filesystem branches also, and synchronised on demand.

Final Notes

Though not perfectly adapted for this purpose, by the use of these existing protocols, the application can be rolled out faster, and leverage the already very large number of Bitmessage, Bittorrent and Steem nodes, to speed testing and simplify adoption and accelerate development.

I will be working on more precise specifications such as database schema, message syntax, and yes, it will be written in Python, since all three platforms have very nice python interfaces.

---

We can't stop here! This is Whale country!

_{Loki was born in Australia, now is wandering Amsterdam again after 9 months in Sofia, Bulgaria. IT generalist, physics theorist, futurist and cyber-agorist. Loki's life mission is to establish a secure, distributed layer atop the internet, and enable space migration, preferably while living in a beautiful mountain house somewhere with a good woman, and lots of farm animals and gardens, where he can also go hunting and camping.}

_{I'm a thoughtocaster, a conundrummer in a band called Life Puzzler. I've flipped more lids than a monkey in a soup kitchen, of the mind. - Xavier, Renegade Angel}

*

_{All images in the above post are either original from me, or taken from Google Image Search, filtered for the right of reuse and modification, and either hotlinked directly, or altered by me
Uploaded images hosted at postimg.org}