Creating a P2P, Messaging App on Web3 Using Substrate & Ionic - Introducing Uke - BOG#002

Forewarning: This piece is a little different from my more “applied science“ articles. It’s more theoretical in nature and based on past/current experiences and developments. I’m calling these “BOGS“, a more casual series of thoughts coming from yours truly.

A little over 2 years ago, I created a real-time messaging app on a private blockchain instance.

I used my blockchain’s of choice at the time, NEM, messages plus WebSockets to have an encrypted P2P chat between users – concepts that can be used today.

It was one of the first of its kind to be made. And now, I’m happy to say I did it again!

Fun fact – this used a local custom network consisting of three Raspberry Pis. I had just moved, and needed some quick access to a blockchain - so I hosted it myself.

Fast forward to now, I created Uke:

Uke - a p2p, completely distributed messaging protocol. It’s open source, and I’m hoping to source some help and contributions to ensure we have a community-built and trusted messaging replacement that we can all trust.

Uke Architecture

I’d like to explain why I chose Substrate as my blockchain of choice. I needed something highly customizable, speedy enough to perform something like messaging, and most importantly, something I could scale.

Substrate is a blockchain framework - meaning it comes with a bunch of modules already created (see: FRAME) for a blockchain to function out of the box.

Consensus, distributed networking, storage, and more are all handled already - meaning I can focus on purely implementing a native messaging module of my own for Uke.

In the case of Uke, we will create a custom module, or pallet, of our own. This will run live, with the blockchain, and will handle messaging to any client that submits a request to a network with it implemented.

We have a few concepts to unpack here:

• Conversations: Defined as having an initiator and recipient with a list of messages. Conversations can be marked as active or inactive. If the Conversation is active, it is added to the ActiveConversations StorageMap for both participants.

  
  

• Convo ID: A conversation id is how conversations are identified. It is the recipient’s and sender’s addresses hashed (right now, via SHA3-256), and is intended to be deterministic but unique.

  
  

• Messages: Defined as having a sender and receiver of a particular string of text.

  
  

• Usernames: Usernames are simple UTF-8 strings assigned to Account IDs for the purpose of human-readable identification of on-chain addresses. (inspired by the nicks pallet)).

With Uke, I had to rethink how messaging worked a little, but it essentially works like this:

Users can start conversations. The user to originally start the conversation is the initiator and specifies the recipient. Once this occurs, the blockchain knows that there is an active conversation between these two users, and has the appropriate mapping as such.

This allows us to fetch conversations without loading the entire conversation - good for our UX.

Usernames map to addresses and work like Discord IDs in a way. It’s much easier than remembering a long 64-character address.

Keep in mind - this is meant for pure peer-to-peer messaging, I hadn’t begun to consider groups just yet.

Andddd guess what… the code is all open source under Apache 2.0 here, so have a gander:

If you want to have a ready-to-run node to test out, go ahead and visit the uke-node repo:

Contributions, feedback, and more are very welcome!

Uke Frontend

For the frontend, I chose Ionic - mainly because I know Angular very well already, but also because their UI/UX is already built in the framework. This allows me to focus more on connecting it to my backend pallet.

The design for Uke is below - I had more lofty UX/UI goals for the app, but for now, this shall suffice:

Current Project Status

The blockchain/backend aspect is completed, as seen above with uke-pallet and uke-node.

As of this writing, the front end is being implemented and is on track to be done by the end of this month (by the latest). I can’t wait to share it publicly with you all and hopefully get some good, private conversations going using web3 tech and blockchain.

As always, I’d love any open-source support. Anyone is open to criticize, contribute, or help test this effort.

As always, the goal of a BOG is to ramble, and I think I succeeded yet again. If you’re interested in helping out with this project, have any questions, or the like - be sure to contact me via my socials in my Hackernoon profile.

Until next time, see ya!