Building the Lisk Voice Project

  • By AlinB in Apps
  • 10 Nov 2020
  • 6 min read

Introduction

It was an interesting challenge to put together a bunch of technologies that I have become familiar with. This occurred previously in 2016, when I was speaking at Defcamp Bucharest, about IPFS, and cybersecurity. In addition, I also expanded my skills by learning about networking and SSH tunnels. This occurred simultaneously whilst I was working as a C# developer, on the road to becoming a senior.

I believe online communication in general, particularly text and file messengers have a bright future. Therefore, I chose to build a POC text messenger with IPFS and the Lisk SDK.
 

Lisk Voice interface & its key features

  • Real time communication ( 5-10 seconds lag ). This is a good outcome for a home resources server ( CPU i7 2th generation, 4 GB Random-access memory ).
  • Only a login page and a main page exist, whereby the users contacts are located on the left side of the screen, and the messages are located on the right side which is similar to Whatsapp.
  • Built-in security, only the sender and the receiver can view their messages.
  • All the advantages associated with blockchain. Messages are public but are encrypted.
  • The first 100 messages are free. After this, charges will apply.
  • One of the 2 default contacts is yourself so you can store sensitive data safely. The other default contact is the administrator.
  • All strings are sanitized before encryption and also after decryption.
     
Lisk Voice

 

Lisk Voice

 


Technical set up

 

Lisk Voice

 

 

2 machines were used with a reverse persistent SSH tunnel in between.

  • Windows 2012 R2.
  • Ubuntu 18.

UI part ( Frontend & Backend ), is built with C# MVC and IIS server.

Business logic is built in NodeJS and is hosted on a different IP, exposing port 3999.

Lisk Voice messenger functions by encrypting the message from the sender twice. Firstly, with the public key of the sender and secondly with public key of the recipient. Both encryptions are added next to each other and are stored in a file that is uploaded to IPFS. Once the upload is performed, this will result in an IPFS hash. This respective hash is then stored on the chain and is public. The end result is a secure online messenger, whereby the security is built in from the core upwards.

Challenges that had to be overcome were related to multithreading and application speed. As soon as DB support for C# on the Windows machine was added, it was possible to optimize and resolve the threading problems.

The Windows server is completely independent from the Node.js server, there is no blocking or pending operations occurring  between them. The UI registers the jobs and returns within a few seconds, in order to check if the server has received any answers.

The encrypted passphrase is stored in the user browser, and the password to decrypt it is stored on the server.  Furthermore, SSL as well as encrypted SSH tunnels are deployed here.

After optimizing the UI design the end result was a nice working POC private online messenger, with about 5-10 seconds lag. As I use my own chain, every account receives a few tokens as part of the initialization process.  Any internet user can login and send messages to another Lisk address or to his own Lisk address.
 

IPFS

I began educating myself in IPFS in 2016 and am still in the learning phase. Juan Bennett and the team have so much good content about IPFS. This is a technology with many use cases. A distributed file system was the natural choice because it works on the same principles as blockchain. It took years to get my head around the advanced concept of IPFS, but basic usage such as adding a file and retrieving file content are easy to use with NodeJS.

A real life example is shown below:

User A : 8567373403155329896L

User B : 6735363876831372961L

User A sends the message “demo” to user B. The following string will result:

9cefbc53ba2a3dcdbceadde2a8789b8892b64622f6197c72:68aee
92039e113cacd532b61c294dafa4360b2d2f552a2ed:4a417be8b5
54f34c7f2ff29690afc835922402b6eaf3519a:c4b8ea4ce2a5c969cd
45a0f95185726ff666a2126313541

The above string is in format messageEncForRecipient:nonce:messageEncForSender:nonce and its length is dependent on the length of the content. The encryption is native to Lisk, and is done with the public key of the recipient. For example, in case the user sends messages to himself the message is going to be encrypted both times with the same public key, due to the fact that he is the sender and also the receiver.

The functions that perform the message encryption/decryption and work with Lisk SDK are shown below:

This is how the message is prepared for its’ final form, just before it is written to the file.

When adding a file to IPFS a hash is created to refer to it, instead of a file name. The above string will result in the following hash : QmfRu5qMZum3jbH6Vg3Wfi1iyoJhms1QWeXd8aQapo3P4G. You can check it out here. Also content length does not matter because IPFS will result in the same hash length regardless of content size.

Finally, this is how to add a file and retrieve the hash from IPFS:

Only this IPFS hash is stored on blockchain. This is because the messenger uses the Lisk SDK, as it also has a designated 64 bytes field in the transaction.

If the custom blockchain would reach production and be published, anyone can write a message in format messageEncForRecipient:nonce:messageEncForSender:nonce, add it to IPFS and add the hash to a transaction on the chain. Lisk Voice was designed to be like an interface for the blockchain. We sanitize the string to avoid any unwanted surprises coming from the wilderness of the internet.

 

Future improvements

  • File support, which will allow users to share files such as photos and videos, will be performed in the same way as the messages. The size of files is going to be limited just by the hardware resources, as the IPFS hash has the same size regardless of the content.
  • Offer apps for Android & IOS, because at the moment the messenger is not really usable in real life. Notifications are required as it is not practical to ask the user to bind their Lisk address to an email address, as that would violate the anonymity objective. Mobile is a good solution because the user can be up to date with his Lisk Voice account and notifications.
  • Publish Lisk Voice chain so I can list the token on various exchanges.
  • Make Lisk Voice distributed ( LiskVoice community to run more copies of the chain ), in order to actually make it a messenger that can’t be stopped.
  • Staking program ( design and develop ), to encourage users to hold tokens for 2 to 4 years.
     

Conclusion

It was a great experience to work with Lisk and to deep dive into the blockchain technology, alongside the Lisk community. I used a DEV environment ( WINDOWS-LINUX ), as well as a PROD environment ( WINDOWS-LINUX ). I am aware a UI coded in React would have made the architecture easier, however as the saying goes “the shortest path is the one you know”, so I decided to stick with the technologies I was most comfortable with.
 

Resources

If you feel inspired and want to build your own proof of concept blockchain application, check out the Lisk Builders program. More information about the program and the application procedure can be found on the Lisk webpage for the Lisk Builders program.

Disclaimer: This blog post was written by our community member, Alin (LinkedIn profile) as part of his participation in the Lisk Builders program.

 

AlinB

Alin is very passionate about programming and the blockchain industry. His main programming language is C# and he has significant knowledge about cybersecurity. He also owns a few startups that are still in their infancy stage. In his free time he likes to play around with blockchain.