Why I Built an Entire Messaging Layer for Pingify

When I set out to build Pingify, I knew messaging would be crucial. Someone finds your lost backpack, scans the NFT tag, and needs to contact you. Simple, right?

Not quite.

The Problem with Existing Wallet-to-Wallet Messaging

I started by evaluating existing decentralized messaging solutions. After all, wallet-to-wallet messaging already exists in the web3 ecosystem. Why reinvent the wheel?

Well, it turns out the wheel had some pretty serious issues.

Issue #1: Scalability

Current decentralized messaging services propagate each message through an entire network. This doesn't scale. As networks grow, they become congested and sluggish, even with solutions like sharding it will always struggle to compete with the speeds we are used to.

Issue #2: Metadata Privacy vs. Speed

Existing solutions faced a brutal trade-off. Either they operated as open networks where metadata could leak, or they obfuscated metadata by bundling messages together, which required fetching data through less efficient, slower methods. Neither option was acceptable for me, I even integrated Push protocol (formerly EPNS) in the first version, but in my experience it was too slow and unreliable for this use-case. I wanted a snappy performance that made the user not even have to notice the work being done.

I realized there was only one solution: build your own blockchain-based, wallet-to-wallet messaging service that fixed these fundamental issues.

Enter Moki Chat

Building an MVP

In tech, we often refer to the term MVP when building products. It literally means Minimal Viable Product, the most simplistic version of a product that is viable for product. As a serial builder who gets excited by many ideas, I learnt this the hard way over many years, often starting ideas that grew and grew until momentum and interest faded. I knew what I had to do this time.

Build only what is needed and iterate afterwards!

That is exactly what I did, the MVP is not the full blockchain solution I started getting excited about, but it includes all the security, speed benefits and functionality it needs to be the ideal solution for Pingify.

Core Features:

• End-to-end-encryption

• Wallet identity (EVM based)

• Avatars and Usernames

• Notification Gateway (this is how Pingify turns NFT tag activity into a "Ping" on your phone)

The Performance Challenge

And what about speed?

I knew I wanted to challenge myself with this project. There are always many solutions available, and the default is usually to stick to your comfort zone. For me, that would be JavaScript, where I have the most experience and knowledge of tooling, not to mention the array of web3 libraries that would make development fast.

But I knew this wasn't the most performant choice, which ultimately led me to... Rust.

So I set out to build the MVP message service in Rust, researching heavily on each decision to come up with what I thought was the most performant way to solve the problem.

Designing for Simplicity and Speed

My approach was to design for simplicity, in my opinion, it makes sense to design a system based on what features you expect in the future, however, overthinking can also lead to overdesign. Specs can change in the future, you can't always predict them, but it is usually much easier to add in complexity once features have matured with the growth of a product.

With this mindset, I wanted the storage solution for my database to be simplistic, blazing fast. Instead of traditional SQL/NoSQL I decided a key-value storage engine was the best option, this is essentially just a flat key value file storage. Super simplicity, speed, and already used for most blockchains.

Then there is the data itself. Despite storage getting cheaper by the year, it still costs bandwidth between nodes and the smaller the data model the smaller the barrier for running a node, and ideal situation for a blockchain based project.

So the question was:

How can I store data with dynamic lengths and optimise it down to the byte, throwing away literally anything I can?

This is where SCALE encoding comes in.

What is SCALE encoding?

It's a lightweight binary serialization format originally developed for Substrate blockchain runtimes. Unlike JSON or other verbose formats, SCALE produces incredibly compact encodings without self-describing metadata. A struct that JSON might encode in 50+ bytes can be encoded in SCALE using just 7 bytes.

The Result

The careful design considerations paid off. Running this on my laptop alone, I was getting responses between 2-8ms in most scenarios, nothing like what I'd experienced before with more "traditional" API design and databases.

What is next for Moki?

So the MVP is there, and it's currently live, powering all messaging in Pingify. Every time someone scans a Pingify tag and sends a message to an item's owner, they're using Moki, whether they realize it or not.

The next stage is decentralization. I'm designing and building the first node implementation along with the ecosystem and incentives to ultimately encourage participants and grow the network. This is where things get really interesting, creating economic models that make honest node operation more profitable than attempting to cheat, designing verification systems that work at scale, and building tooling that makes it easy for anyone to run a node.

The beauty of starting with a working, fast MVP is that I now have a solid foundation to build upon. I know the core messaging works, I know the performance is there, and I have a live integration for feedback. Now it's about taking those lessons and transforming it into a truly decentralized system that maintains all those benefits while adding the transparency, resilience, and censorship-resistance that blockchain technology enables.

If you're interested in following along with Moki's development or want to try it in action stay tuned, there's a lot more to come as it moves toward full decentralization.