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 trust. all 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: ) for a blockchain to function out of the box. FRAME 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 , 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. pallet We have a few concepts to unpack here: : 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. Conversations : 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. Convo ID : Defined as having a sender and receiver of a particular string of text. Messages : Usernames are simple UTF-8 strings assigned to Account IDs for the purpose of human-readable identification of on-chain addresses. (inspired by the )). Usernames 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: https://github.com/Uke-Messaging/uke-pallet?embedable=true If you want to have a ready-to-run node to test out, go ahead and visit the repo: uke-node https://github.com/Uke-Messaging/uke-node?embedable=true Contributions, feedback, and more are welcome! very 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 and . uke-pallet 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!

This story contains new, firsthand information uncovered by the writer.

Polkadot

Apache

BUNCH

Dapp

Fetch

Introducing the Uke Alpha - The First Wallet-less Blockchain Chat App That's Going to Break Web3

Accommodating Data-Based Networks on the Blockchain

follow my twitter.

Nominated for 2022 - Tech Tutorial Teacher of the Year

Too Long; Didn't Read

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

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

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

A Normie Intro to Web3 in 2023 (And How it Differs from Web2)

(1/100) Crypto Countdown: Golem

A Research Report on the Trader $JOE DeFi Platform

07/03/2018: Biggest Stories in the Cryptosphere

05/02/2018: Biggest Stories in the Cryptosphere

A Normie Intro to Web3 in 2023 (And How it Differs from Web2)

(1/100) Crypto Countdown: Golem

A Research Report on the Trader $JOE DeFi Platform

07/03/2018: Biggest Stories in the Cryptosphere

05/02/2018: Biggest Stories in the Cryptosphere

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps