From online to on-chain, the evolution of digital communication

Abstract: The article explores the state of legacy communication platforms that we use and depend on every day while proposing a new alternative. It offers insight into the work of Dr. Režun and his team, spanning the past five years, as they innovate a novel approach enabling immutable, non-custodial, permissionless, and decentralized communication and data ownership retention.

My name is Tali Režun, I’m head of R&D at Block Lab’s Luxembourg, and a co-founder of 4thTech, PollinationX, W3XShare, and Blockchain Recorded Podcast.

I wrote this article as a collection of thoughts that accumulated during the past five years. Before we continue, I would like to take this opportunity to thank my co-founder Denis Jazbec for all the dedication, while my gratitude goes to the entire team of Block Labs for all the hard work and simply for believing that we can change something for the better. My deepest thanks also go to David Tacer and his team for their innovation in the development of W3XShare and PollinationX. I strongly believe that we need an alternative to legacy digital communication and I hope that we now have a viable solution. Today we will talk about digital communication and data ownership, more specifically we will talk about the possibility of permissionless, non-custodial human on-chain communication.

The heart of the problem

Let’s take a step back and try to understand the current state of digital communication and online data management. When I’m talking about digital communication I’m talking about emails, messaging, data file transfers, and online data or content sharing in any shape or form. I’m talking about the communication that we use every day, every hour, every minute. The communication that we depend on and rely on to be confidential, private, secure, or even intimate. The communication that we rely on to be kept between us and the person on the other end. But I can not stop wondering, is the information that we share using existing “free” legacy systems secure, private, and confidential?

While the majority of users have no problems accessing legacy email, messaging, or data file-sharing platforms, the “permissioned access” issue still remains. Enforced usually on the basis of censorship misbehavior, de-platforming cases are well known leading to various cases of access restrictions. The fact remains, that the current legacy communication platforms are designed to grant permission for every email or message that we send based on pre-approval mechanics, there is no point pretending otherwise.

There is also the matter of data ownership. Did you know that the moment you attach any data file to an email attachment or share it via any “free” messaging service or data file-sharing app there is a big data ownership loss possibility?

With so many open questions, let’s first take a minute and dive deeper into the “free” aspect here. Did you hear about the saying “If you are not paying for the product you are the product”? I don’t know if you noticed but the word “free” is disappearing from the legacy communication platforms. It’s more than obvious by now that we are paying dearly. It’s not just metadata, it’s much more than that. We are paying in; sharing our behaviour; our history; our content, and; our lives. We are giving away our essence to be used within hostile ad/surveillance models.

So to finish my point, the communication that we use every day is not private or secure and it is not confidential, and there is no way to preserve data ownership because its centralized models are designed around users’ data acquisition. These are facts, some people are aware but most are not.

Can blockchain empower the transformation of digital communication?

Blockchain always offered the promise of enabling secure, robust, permissionless, non-custodial on-chain communication, while retaining data and identity ownership, it is by design the right tool for the job. However, it could never really take off due to the scalability and cost constraints of early-generation blockchains. I believe that with the rise of new-gen blockchains with fast finality and low transaction cost, privacy awareness, and coming Web3 mobile and Web3 adoption in general, on-chain communication could become dominant and as such can become the future standard. The benefits exclusive to Web3 are just too good to be overlooked.

Blockchain technology can change the narrative and the core concept of legacy digital communication; from custodial to non-custodial; from centralized to decentralized; from permissioned to permissionless, and; from “free” but mined to payable but yours. Furthermore, the issue of digital data ownership retention can be solved by P2P (i.e. peer-to-peer) W2W (i.e. wallet-to-wallet) E2EE (i.e. end-to-end encrypted) on-chain communication powered by smart contracts, blockchain networks, and decentralized storage.

Solution Proposal

So how can communication evolve to serve its core purpose without being exploited? I can tell you that we, the team at Block Labs, are on a mission to enable resilient, permissionless, non-custodial, and immutable on-chain communication while bringing data ownership and control back to the people. We are on a mission to enable users to always have the freedom to move and access their communication or data between dApps, while the developers always have permissionless access to build them.

Block Labs spent the last five years developing foundations for Web3’s first on-chain communication infrastructure. It manifested in the form of the OCC (i.e. on-chain communication) Framework. The technology utilises; smart contacts; blockchain networks; encryption, and; decentralized storage, to retain data ownership and enable OCC use cases. I am talking about the technology secured by cryptology where;

• one email, message or data file transfer = in one L1/L2/L3 transaction, and where
• not your keys = in not your email, message or data

Technical Explainer: While various integration use cases are possible, let’s use dMail (i.e. decentralized email) and dChat (i.e. decentralized messaging) as examples. Encrypted W2W message exchange happens “on-chain” as one short message represents one L1 or L2 blockchain transaction. As dMail is data heavier, lite encrypted JSON objects are created to hold dMail metadata. The link to this metadata and checksum is recorded on the chain as a blockchain transaction. The same goes for the W2W data file transfers use case where; 1 data file package transfer = 1 L1/L2-TX.

At its core, the OCC Framework prevents identity and data theft, Web2 data tracking, or mining, while it is impervious to invasive ad/surveillance campaigns. Due to the open nature of the public blockchains, the communication transaction metadata created between the user's wallet and the dApp is still vulnerable to being mined. One way to solve it would be for a user to enable a “mixnet” such as HOPR. HOPR’s decentralized, incentivized mixnet obscures all metadata, including IP addresses, making it impossible to tell anything about who is communicating and what data they’re sending. Another way to approach this would be to use one of the privacy-enabled blockchains, where transactions are not publicly visible. This is still an open issue and time will tell, which solution is the most viable.

The OCC Framework architecture was designed to be as lightweight and modular as possible while retaining core decentralization primitives. No personal data whatsoever is collected, while the only party with access to communication data is the user himself. Code is law principle applies!

To enable “true” self-custody, data ownership retention, and communication transaction immutability, every email, message, or data file transfer is represented as an L1/L2 transaction. Communication is E2E encrypted and fractionally or fully stored on a blockchain, while encrypted attachments and big data files are stored on decentralized storage.

Connected by the OCC SDK, four main legos complete the on-chain communication framework; (1) the protocol; (2) blockchain network; (3) encryption, and; (4) decentralized storage.

Part 1 of the solution; The OCC Protocol

I would like to start by saying that we are taking the first steps toward true decentralization of communication. While the platform legos follow decentralization primitives to the letter, some parts are just not there jet. The OCC Protocol follows mathematical methods embedded and enforced by smart contracts and can not act in a malicious or harmful manner (e.g. breaking its code primitives by granting access to communication transactions in any way or form). The methods within OCC Protocol smart contracts (i.e. Mail, Chat, Users, AppFeeManager, Lock, TierManager) set simple but strong rules enforcing its core primitives such as; immutability and transparency within P2P decentralized communication. Protocol governance is currently based on “social consensus” with Block Lab’s factually driving the development. This is usually the common case with protocols in development, where the early evolution and innovation are driven by the founders before being taken over by community developers. In this stage, the OCC Protocol is not ossified jet so that it could be released once and never changed again. There are just too many unknowns at this level, so the protocol must retain its dynamics so it can be adapted to support the fast-evolving blockchain infrastructure. As I see, there are two possible protocol governance scenarios. The first would be to evolve the current version to be as interoperable and as developed as possible and to lock the smart contracts into an immutable state. In this scenario, the protocol would operate within its programming and would be impervious to any human meddling. If a new version is needed, the protocol could be forked and a new updated version released. The second governance scenario could evolve into a DAO-like form, where the protocol updates were coordinated by the community. As both are all more or less conceptual scenarios it is impossible to determine now which would fit best.

Dive deeper into the OCC Protocol and the SDK by exploring the “Human on-chain Communication Dedicated Protocol & SDK” article.

Part 2 of the solution; Blockchain networks

While Block Labs developed and innovated the OCC Protocol, its deployment is a job for a Level-1 integrator (i.e. Immu3). The plan is simple and includes deployment of the protocol on many next-gen EVM blockchains making it available and permissionlessly accessible to dApp developers from various ecosystems. Because the protocol operates on a “one email/message = one L1/L2 transaction” basis, the transaction finality matters. Some blockchains already offer fast transaction finality with high transaction throughput but may lack decentralization. Others may come with strong decentralization but lack speed. In the end, it will be a user’s choice. Our job is to make it accessible in all interoperable L1/L2/L3 ecosystems. There is also a matter of congestion. We know from experience that congestion can stall the network, making it unusable. This was the case on Solana in Q1 2021. Due to Solana’s fast transaction finality, we deployed the first on-chain messaging protocol on Solana. The Solana congestion at the time made the protocol practically unusable, as it was almost impossible to execute a successful transaction due to endless transaction timeouts and network errors. This brings us to block space access. Reliable block space access and transaction execution are crucial, without it the on-chain communication just can not work. It would be like sending a message that would not be delivered. Given the unpredictability of future congestion on multi-purpose blockchains and the inherent uncertainty of securing block space access, the most viable solution for the future is to build a dedicated on-chain communication AppChain.

AppChain testing is already in progress using the Tanssi Rust-based Substrate framework. The AppChain acts as an EVM smart contract Layer 1 blockchain that offers reliability, scalability, and security needed within use cases of on-chain communication, while It inherits block finality (consensus) from Polkadot RelayChain. I will dedicate an article exclusively to the AppChain use case so more on that later.

Part 3 of the solution; Encryption

Encryption is another crucial Lego forming the OCC framework. There are several encryption options available within the OCC SDK; custom encryption; AES-randomly generated secret key, and; AES-secret key produced by ECDH. The majority of centralized legacy communication platforms offer E2E encryption, but while your conversation could be end-to-end encrypted, the encryption is not self-custodial, meaning you don’t hold the encryption keys. It may be end-to-end encrypted to the outside world, but the intermediary platform still holds the keys. To change the narrative, future communication encryption needs to be 100% under the user’s control. I’m talking about a non-custodial peer-to-peer encryption layer that is enabled and maintained by the user on each end of the conversation. As we are talking about on-chain communication, a wallet is a part of the needed infrastructure. To enable popular wallet interoperability with the OCC Framework encryption, ECDH (i.e. Elliptic Curve Diffie Hellman) secret key exchange is used within the specially developed Encryptor Extension.

To enable the OCC Framework encryption interoperability, wallets should enable; computeSharedSecret(otherPublicKey) and; add permission for executing the calling method. While this could be the case in the future, in reality, it is easier to adapt to existing infrastructure than trying to change it. To solve this challenge and to enable P2P W2W E2E encryption in on-chain communication, Block Labs developed Encryptor Extension. The Encryptor Extension is open-source, fully self-custodial, and enabled by choice. It adds an encryption layer currently not supported in major wallets and it is used to enable the ECDH key agreement protocol. It creates an elliptic curve key pair and computation of the shared secret key of the receiver/sender. While the Encryptor Extension adds to the adoption complexity, it is currently a simple out-of-the-box choice for end users and dApp developers.

Explainer: The calculation is made using the receiver Encryptor Extension public key and sender Encryptor Extension private key. Content is encrypted with AES encryption and shared between wallet client A and wallet client B. The Receiver decrypts the content using a calculated shared secret key. The secret key is calculated with the receiver Encryptor Extension private key and the sender Encryptor Extension public key.

Part 4 of the solution; Decentralized Storage

Decentralized storage offers the comfort of cloud storage but with a big difference. It enables permissionless data availability and data self-custody, both lacking in legacy cloud storage systems. Furthermore, decentralized storage systems have no need for intermediaries, users access their data directly. Decentralized storage is the key to secure on-chain communication and data ownership retention.

But how does it work? To try to paint a picture, let’s say that, the same as plant spores are distributed from one flower to another, your files are split into smaller pieces, encrypted and dispersed between various decentralized storage nodes, while data reunification is possible only with the user’s private key! So again we can come back to one of decentralization primitives; not your keys, not your data.

To be able to support the majority of OCC use cases, we had to develop PollinationX, which adds a layer between decentralized storage networks and end users. We managed to package the storage within various sizes of dynamic PollinationX NFTs, so the users can control and manage their storage in a self-custodial manner. The NFTs represent the storage unit, while the NFT image reflects the real-time storage capacity state.

PollinationX currently supports the BTFS decentralized storage network which is still in the early Alpha. Despite its infant state, we have not experienced any notable issues. While Crypto native users will have no problems interacting with the storage NFTs, crypto-non-native users will have a harder time adapting to specific self-custodial UI/UX.

Is on-chain the future online?

I’m sure that up to now you are wondering, but how will this work in regards to block space access? Do we need to pay for every message and every on-chain communication transaction? The answer is yes and no. It all depends on the model. As every on-chain communication represents one L1/L2 transaction, this transaction needs gas to be confirmed. Use cases are already emerging where transaction gas is being shared with dApps, which could result in lower end-user costs. Tron, for example, already enables users to stake TRX and in return offer free bandwidth with practically gasless transactions. Arthera blockchain subscriptions can streamline the user experience and offer predictable costs for businesses, while they enable subscription models where users will be able to purchase transactions bulk in a 1$ monthly subscription package. LightLink is another EVM blockchain that enables organizations to pay a monthly fee to simplify user experiences when transacting using ERC20 and ERC721 smart contract standards, this mode can bypass native gas costs and highly reduce barriers to entry. There are numerous Ethereum improvement proposals (i.e. EIP-758, EIP-1337, EIP-4885, EIP-5643) being written that could enable subscriptions on the blockchain. According to the EIP-1337 summary, monthly subscriptions are a key monetization channel for the legacy web, and arguably they are the most healthy monetization channel for businesses on the legacy web especially when compared to ad/surveillance-based models. Out-of-the-box, the OCC Protocol v.1 enables PAYGO transaction models, where users need to settle and confirm every message. While this approach can cause a barrier to entry for Crypto non-native users it is still very native to the Web3 ecosystem as it provides much-needed transaction transparency and platform clarity lacking in legacy systems. As the blockchain space will evolve to enable subscription-based transaction access, so will OCC Protocol v.1.

We are still very early and block space subscription is still evolving. It may look complicated and costly to access your block space now but it will become more accessible. It’s the same as with internet access, we don’t think any more about the MBs cost, we just use it. The same will be with block space, as blockchain evolves, access will become more organic, easy, and accessible, so a statement such as “on-chain is the future online” would fit here perfectly.

State of the OCC Framework

Deployed currently on Sepolia, Mumbai, Edgeware, Arthera, Metis and Immu3 AppChain TestNets, the OCC Protocol is already available to developers. With many new deployments coming, the builders will be able to choose where to build (i.e. check OCC Protocol v.1 deployment table) according to the preferred environment of blockchain networks.

The accompanying OCC SDK provides abstractions to assist on-chain communication dApp builders with interacting with the OCC Protocol v.1 smart contracts in a Typescript/Javascript environment. The OCC SDK also simplifies the encryption process and remote storage access. To enable seamless integration, there are tests available (e.g. dChat example) within the SDK framework, that enable the testing of the correct functioning of methods, but on the other hand, provide insight into how a certain method is used.

To clarify, a permissionless Level-2 integrator license is available via Level-1 integrator Immu3 and is perfect for teams wanting to build their own on-chain communication dApps. Enterprise Level-1 integrator license is available via Block Labs [4thTech] and is meant for traditional businesses or offices, L1s, wallets, and existing applications. The general legal framework is available and applicable worldwide. Tailored use cases are handled on the individual level.

Use cases

With Web3 social on the rise, on-chain communication remains one of the last undiscovered frontiers. Until now, there was no permissionless developer-friendly infrastructure to enable out-of-the-box on-chain communication application development. Hopefully, with that out of the way, the developer community can now focus on building communication applications with Crypto-specific features and use cases. The OCC SDK enables various use case iterations. Arthera chain for example exploring possibilities of integrating the on-chain messaging as a part of their native wallet, enabling Web3’s first on-chain messaging subscription. There is also work being done on integrating on-chain messaging into a decentralized OTC platform. While there are many interesting OCC use cases being explored, the main focus of pioneer integrators goes to; dMail; dChat, and; data file transfers dApps.

We can refer to dMail and dChat as decentralized, self-custodial, E2E encrypted, immutable, and permissionless on-chain email and messaging applications. Build with the OCC SDK and based on the OCC Protocol v.1, Encryptor Extension, PollinationX decentralized storage, white-label framework, and powered by blockchain networks, the Immu3 dMail & dChat UIs showcase the UI/UX for future on-chain communication. 4P is another project building on top of the OCC infrastructure. They are introducing a set of smart contracts on top of the dMail & dChat framework that will enable different right-to-access models and propose enhanced functionalities for their native FOUR token holders. W3XShare changes the way large and sensitive data is transferred. It leverages OCC Protocol v.1, encryption framework, PollinationX decentralized storage, and blockchain networks to provide a secure and self-custodial solution for encrypted data file transfer between wallets.

These are all crypto-native use cases designed for crypto-native users. To bridge the gap, R&D is in progress towards a stand-alone desktop application that would enable users to send or receive E2E encrypted emails via an underlying blockchain network using their existing traditional email client applications such as Microsoft Outlook or Apple Mail. We call it a “Broadcasting Web3 dMail to SMTP client”. Built with the OCC SDK, the desktop client is designed to add blockchain and encryption layers to the legacy email enabling blockchain decentralization, immutability, and security while users pay for the transaction packages using a credit card.

Conclusion

We are changing the core concept and perspective of digital communication, from custodial to non-custodial, from centralized to decentralized, from permissioned to permissionless, and from free but mined to payable but yours. Every change is hard, but this one is needed. It can be a change or it can be a choice.

Access to permissionless, secure, self-custodial, not-minable digital communication should be available to all. With the help of advanced blockchain protocols as an underlying infrastructure, Block Labs leads the way in R&D towards this goal. As on-chain communication is one of the most significant use cases that need to be solved by Web3, other projects are trying to solve the same challenge, but more or less with simpler Web 2.5 solutions. Block Labs‘s “one email/message = one L1/L2 transaction” approach is unique, but also the most challenging to develop.

We find ourselves swimming against the current, changing the digital communication concept and narrative. It is hard, but let’s not forget that we are utilizing blockchain to prevent users’ data mining and revive long-lost ideas of conversation privacy on the internet. It is time for permissionless, self-custodial, privacy-enabled, secure, and immutable on-chain communication.

Let me close with a thought; Electronic communication is too valuable to be entrusted to an intermediary. The time for permissionless on-chain communication protocols is now.

Disclaimer

All content provided herein, including but not limited to text, graphics, logos, and images (the “Content”), is the property of Block Labs Luxembourg S.a r.l., a legal entity established under the laws of the Grand Duchy of Luxembourg, registered with R.C.S. Luxembourg under N B263508 at the following address: 41, rue du Puits Romain, z.a. Bourmicht (Atrium Business Park), L-8070 Bertrange, Luxembourg (the “Company” or “we”). It is protected by copyright and other laws that protect intellectual property and proprietary rights. You are granted a non-exclusive, non-transferable, revocable license to access and use the Content for the sole purpose of obtaining information about the 4thTech technology and other educational purposes. We have done our best to ensure that the Content is accurate, updated, complete, and provides valuable information, but neither do we guarantee nor take any responsibility for its accuracy and/or completeness. The Content is not intended as, and shall not be understood or construed as legal, financial, tax, or any other professional advice, sale or offer for sale of any securities, and/or crypto-assets. The Company is not engaged in rending of and/or is not licensed to render any of the crypto-asset services and/or financial services, such as investment or brokerage services, capital raising, fund management, or investment advice.