What Is Uke?
The Uke Protocol is a p2p, completely distributed messaging protocol. It utilizes local cryptography and a Substrate blockchain instance to verify, send, and receive messages in real-time — just like any other conventional messaging protocol, and can be used to construct messaging apps or any other application in which secure, private, real-time messaging is needed.
The difference with many other protocols is Uke adheres to a concept that I’ve upheld since I started developing on blockchain:
No intermediary servers allowed!
All message propagation, user identification, and authentication take place through the node instance. Each message is encrypted and stored in the node storage as well — this way, it’s a very robust way to ensure that messages never get lost.
It does this without using any wallets. The client side takes care of managing user keys and encryption and doesn’t require any cryptocurrency to operate.
Part of my motivation in creating this project was to show exactly that — uses of this technology beyond pipe dream projects.
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:
https://github.com/Uke-Messaging?embedable=true
Why Uke? Why Blockchain? What About Scalability?
If conventional, regular messaging solutions work just fine, why create another? Furthermore — why is blockchain necessary?
Uke has a couple of primary goals and standards to upkeep:
-
Privacy — each message sent is completely, and purely, peer-to-peer — no one else can intercept or decrypt the message.
-
Fault Tolerance / Reliability - it shouldn’t go down. ever (in production, at least).
By using DLT, we remove the need for a central server, meaning as long as an amount of nodes are kept online, users can still talk to one another. This is especially useful in emergency scenarios, as users can even opt to run their own nodes to ensure 100% runtime.
Besides technical robustness — Uke is a peer-to-peer chat. No one can ban you from using it, all conversations are private, and the nature of it using blockchain allows for that to be transparent concurrently.
Of course, there are some issues here — mostly to do with scalability. The current setup probably isn’t ideal for a ton of users. Blockchain shouldn’t store a lot of data, but rather just references and pointers to it.
It still needs a lot of work, but it’s a step in the right direction for providing purely user-controlled private chat.
Uke’s Architecture — The Backend (Substrate)
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, a custom module, or pallet. It handles messaging to any client that submits a request to a chain that integrates it.
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, as there was a blockchain involved, 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 defines 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 or Twitter 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.
The code is all open source under Apache 2.0 here, so have a gander if you wish! PRs are welcome:
https://github.com/Uke-Messaging?embedable=true
If you want to have a ready-to-run node to test out and play with, go ahead and visit the uke-node repo:
https://github.com/Uke-Messaging/uke-node?embedable=true
Uke’s Architecture — The Frontend (Ionic)
I chose Ionic for a few reasons — 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.
Ionic also handles user creation, authentication, and encryption.
For now, most authentication occurs locally — meaning it depends on the keys stored in local storage for now. Eventually, having a pallet to handle this logic along with some other cryptographic magic would be beneficial.
Project Status — Try It Out!
I’m pleased to announce that as of this article, Uke (at least the web version) is ready to test out!
You can check it out here: app.uke.chat; keep in mind it’s subject to network resets, bugs, and some downtown — consider it a pre-alpha :)
It’ll be some time before it makes it to the stores, but hopefully sooner than later.
Longer Term Goals
This is just the beginning. There are loftier goals planned for this protocol, for both scalability and usability.
- Develop separate Identity, Account Filter, & Messaging Pallets for common Substrate use.
- Implement an encrypted pub-sub protocol directly into the Substrate node — this way, relying on purely extrinsics for messaging is unneeded.
- Develop client-side appropriate modules for business use
- “Disappearing”, or temporary secure messaging
- Optional payment integrations for users, if applicable.
- Custom Substrate Uke network implementation for private or public use
Conclusion (Huge Thanks to the Web3 Foundation!)
Thank you all who supported up until this point — this is only the beginning of building something truly great.
Communication, and ensuring it’s always available, will become increasingly important in the coming years.
Uke provides a way for anyone to, not only use a web3 chat without cryptocurrency, but also truly adhere to the philosophy of giving users control back over the data they propagate over the Internet.
In the short term, I plan to do the following:
- Gather initial feedback for the app
- Immediate planning to streamline the protocol
- Design
ukeSDK and developer docs for others to use
- Demonstrate uses of web3 beyond cryptocurrency
- Look for contributors / potential team members
I’m happy to say I’ve had support from the Grants Program from the Web3 Foundation for this project — besides the grant, the feedback was extremely valuable. You can actually read the original proposal for this project on GitHub if you like.
As always, I’d love for any open-source support. Anyone is open to criticize, contribute, or help test this effort.
Until next time, stay safe!
Also published here