Self-Sufficient Private Instant Messaging

Context

Everyone loves "FREE". Getting something from someone and not paying a cent for it is great. Unfortunately, more often than not, you end up paying somehow. However, I am not here to warn about the dangers of free or becoming a product, as it is not the main topic here. One thing that truly concerns me is ensuring the longevity and fairness of things that should be free with no strings attached.

You have most likely used a messaging app, such as WhatsApp, which is proudly owned by Meta and doesn't charge you a cent and it even has end-to-end encryption. Or maybe Telegram with its cool bots and features. Well, if you couldn't tell, I am not sold on either. It seems that we need to trade features for privacy. Let's go over both:

WhatsApp

  • End-to-end encrypted messages with metadata on the clear for Meta to look at and see when you are awake, with which numbers you talk, where you are, etc.
  • Funded by Meta (for Meta)
  • Malware-like behavior, especially on Android. Thanks Apple! Very cool!
  • Not open-source, although they use the Signal Protocol.

For context throughout the article, I invite you to take a look at the Signal Protocol.

Telegram

  1. Not end-to-end by default.
  2. Founded and funded by Russia's own Pavel Durov (funder of state-controlled VK). Although Telegram is currently operating from the UAE with no affiliation with the Kremlin, questions arise due to some allegations from Russian activists of their privacy/security being at risk and also the possible compromise of encryption keys (written in April 2023).
  3. Big groups, unlimited storage, great API and some other public enticing features make it compelling.

The Problem

There is no self-sufficient private instant messaging app. They all serve a bigger master, or they have low public confidence.

"Why do I need private? I have nothing to hide!"
It's not what, it's from whom you have nothing to hide. There is always someone, trust me.

"Why do I need Instant?"
Convenience doesn't need to be a trade-off.

"Why self-sufficient?"
So that no master is served.

Well, I lied when I said that there is no app that doesn't serve a bigger master. Signal. Signal couldn't serve a bigger master even if they wanted to (we will go over the technicalities later), but the folks over at Signal Technology Foundation and Signal Messaging LLC do an amazing job of maintaining an amazing protocol, great apps and servers.

Signal was founded by Brian Acton (co-founder of WhatsApp). He contributed himself $100 million towards the foundation, but donations take a big piece of their income. How much, you ask? 92.5% in 2020 (last available fiscal year data) with a total net loss of -$6,412,228. To check, click here.

With an estimated 40 million monthly users in 2022, is a great product loved my many. Does a vital service really need to live off donations to be free, not just monetarily but free as in freedom? Not in my book and a major weak link, if you ask me. What happens if the money stops flowing? The $100 million from Mr. Acton are in the form of a loan with 0% interest to be paid in 2068.

Solution

Blockchain has provided us with the possibility of monetizing things that were previously unmonetizable. It would be too expensive to keep your computer on, mining, or verifying Bitcoin transactions if it didn't had no monetary incentive, just for the love for the project, idea, community, or philosophy.

Signal currently spends the majority of their budget on servers and wages. What can we do to make this a self-sufficient endeavor? My proposal is to create a new messaging system using the Signal protocol that conceptually decentralizes the Signal servers to peer-to-peer (P2P) operators. Instead of verifying transactions like Bitcoin, these operators would act as routing and queuing nodes for the network in exchange for a token. Now, this is not an easy task and it has its own problems. Let's discuss some of them and the solutions I found:

"So you are suggesting passing private messages through third parties?"
Signal uses end-to-end encryption, a double-ratchet algorithm where each message generates a new key (moving the ratchet) and elliptic-curve cryptography for key exchange. If this is broken, your crusty white dog pictures are the least of my concerns. TOR uses proxies as one of their main suppliers of privacy.

"So another mining operation for another shitcoin, eating up Earth's resources?"
No. I am against using anything related to proof of work for many reasons one of them being the energy costs. Proof of stake has the problem of being linked to the value of the generated token, which can become problematic for the network in case of an agressive market downturn. Instead, I propose proof of authority, a rank-based system that considers various elements:

  • Node latency
  • Uptime
  • Node source code integrity
  • Users served

"What do you mean by 'the problem that it is linked to the value of the generated token'?"
Well, for the token to have monetary value and not just be Chuck E. Cheese tokens (game arcade tokens), trading pairs on exchanges need to accept the hypothetical token so people can convert it to real-world money. I would hate to see the messaging network deteriorate if a whale decides to engage in market manipulation and crash the token, especially at its inception.

"How would remuneration look like?"\

  • The amount of minted currency per time period would be based on network busyness and I propose taking into consideration the location of the clients so that resources are optimized, similar to an Uber surge situation. Thus, minting difficulty should be variable.
  • Remuneration should not be sensitive to the number of messages between users to reduce the likelihood of bad agents trying to exploit the network. Instead, an approach based on the number of P2P data exchanges per time period would be more suitable.

"How would routing look like?"
It would be similar to DNS propagation but using the nodes. Address ledgers would be kept in a minimum x number of nodes with the device address.

"And caching if the receiving client is offline?"
The entry node would replicate messages to a certain number of nodes until the user is online. Once the user is online, they would ping the network and the data would either be removed or simply overwritten. After 6 months, the data would be cleared.

"Okay, this is cool, but how does this solve the financing problem?"
Development of big projects needs to have a central foundation or entity, especially if it's open-source. Open doesn't mean wild like a wild animal. The community needs to reach consensus and overall guidelines need to be put in place. Therefore, we need a central agent with developers, a managing body with an overseeing board not on the direct payroll and support for legal and accounting matters. I propose that the entity or foundation managing the project becomes the beneficiary of a large portion of the token at inception. These tokens would not be immediately available to use but would be deposited into the foundation's wallet in increasingly larger amounts. Hopefully, over time, the foundation will achieve a net profit. At that point, or even before, allocation of captital towards projects that promote the network should be done.

Status

I have been experimenting with small implementations of the client-end services. However, I do not have the time or the skills to work on this endeavor on my own. I genuinely believe that the Signal Protocol is one of the great works of cryptographic technology, but it should not be left at the mercy of whether donations will continue to come in. Independence is the key here, both technologically and financial.

Thanks for reading :)