Context & Preface
I’d like to open the floor to discussing, gathering feedback on, and overall hammering out a core part of the web3 application stack:
Specifically, I would like to discuss the following points:
- The state of decentralized / web3 messaging.
- What is currently being done.
- My current approach / implementations of decentralized communication.
- Interoperability, security, & scaling.
- Crossroads with identity and desybiling issues.
The purpose of this thread is to get feedback for and discuss not just my personal project, but this topic as a whole. There is only so much I can tinker around with - which is why I need some brutally honest, constructive criticism in the hopes of making insurmountable amounts of progress around this topic this year!
Personal Project History & Current Status
I am no stranger to this topic. In fact, my first exposure into Substrate and Polkadot was through a Web3 Foundation Grant regarding a proof-of-concept Substrate-based messenger. It was called Uke, a p2p messenger that uses just Substrate to manage conversations and send messages between users. If you would like to view more technical details, I recommend reading that proposal, as I’d like to keep this post as concise as possible.
Initial mockups for uke.
It’s still live in this PoC stage for anyone to test as of the writing of this post over at: app.uke.chat.
This proof of concept allowed for a few key points to be demonstrated:
It was possible to have a backend for a traditional webapp based completely on Substrate, and nothing else.
A very crude form of “local authentication” was demonstrated here - with the identity being linked directly to the user’s account. This has obvious security issues, and should not be used in any sort of production setting, but for a PoC it works fine.
A dead simple identity system - leaves a lot to be desired, but allowed for users to have crucial public metadata available.
This sort of application is not far off to a real, scalable implementation. With some topology changes, as well as progression in other areas such as identity and de-sybling tactics, it becomes very possible to use in a real world application.
Initial Goals & Expectations
I had some initial goals and exceptions for Uke as a project, summarized below:
Obviously, no backend or intermediary servers. Everything is purely based off of Substrate, or other p2p layers.
In our designs, the use of DLT/blockchain is not shown - this is intentional, as it allows users to merely experience a secure messaging experience without the cumbersome interface. The end goal is to have this be as non-intrusive from a UI/UX perspective as possible.
It’s well known that popular messaging apps like Whatsapp have had a few major security incidents. Trusting “end-to-end” encryption, without actually seeing how that takes place has also proven harmful!
In the future, as the protocol becomes more defined, the goal is to develop a suite of SDKs and docs centering around secure and confidential messaging for any use case - with a Substrate-based chain being the core of the solution.
The primary goal for Uke is to allow for the development of a messaging protocol that does not require trust to use. All processes, from sign up, to identification, to the act of sending a message should be very transparent in how it works, whilst preserving the privacy of the user.
Privacy - each message sent is completely, and purely, peer to peer - no one else could access the message.
Fault Tolerance / Reliability - 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.
Anonymity - since each user is essentially just a cryptographic key paired with an id, user’s can easily stay anonymous on and off chain if they so wish to choose.
Problems With Current Implementation
The current implementation works - but it does a few things which after learning more, give me a certain ick:
All messages are sent as transactions. While for a blockchain application this may seem obvious, presents some next-to-obvious scaling and usability issues:
A high volume of messages may result in network slowdown at some point, i.e disrupting the block authoring process or introducing a significant amount of latency on the UX side when it comes to message delivery.
Each transaction being a signed extrinsic implies a private key having to be available for the duration of a conversation. From a UX point of view, this is unideal.
Message storage, arguably, should not occur on-chain. The chain should only be responsible for handling access control, identity, and for facilitating conversation logic. Message transmission, delivery, and storage should occur in an off-chain process.
There are no mechanisms to ‘de-sybil’ users, and currently, the network is spammable as a result of this. There are several ways to mitigate this, but I’ll leave that for discussion
Identity is still mostly undefined. What should identity look like in this context?
No real form of authentication - everything is dependent on a single private key, which could prove quite harmful.
I’d like to pose this question to the reader:
What should decentralized messaging look like? How could we create a common communication protocol that could thrive in a trustless enviroment? Is it something like uke, or is it completely different?
As I garner more research on this topic, I will update it as needed. I already have some interesting prospects that should solve a good chunk of the problems outlined above, so stay tuned!