Communication Delivery Graph (CDG)
Last updated
Last updated
The Communication Delivery Graph (CDG) is beoble's unique graph or network to deliver communication that will serve the future of beoble. The purpose of building a separate network for delivering communication is to ensure privacy and decentralization.
Before we get into details on how beoble CDG works, first, let's look at how Web 2.0 messaging systems deliver messages.
One of the most typical ways of building a messaging system is to build it cloud-based. There might be centralized servers and databases where users can connect to the servers to access their data and deliver chats to other users. As a cloud-based system, the performance could be typically fast, while it could have some security concerns, as data and message operations are both centralized. Some typical examples of such infrastructure include Telegram and Facebook Messenger.
As cloud-based systems contain some issues regarding security, some of the more secure messaging systems are built based on the peer-to-peer (P2P) model. There are still centralized servers but no centralized databases; instead, all the data are stored in user devices. Given devices might have risks of getting damaged or lost, often P2P messaging systems allow users to back up their chat history to specific backup databases to which users have private access. Still, the message operations are pretty much centralized, which also contains a certain level of security risk. Some typical examples of such infrastructure include Whatsapp and Signal.
On-chain messaging on existing layer-1 blockchains, like Ethereum, Polygon, etc., would be the most straightforward design to achieve a "decentralized" messaging system. It can be achieved by deploying a smart contract that delivers messages to other users. However, many challenges are involved here, including but not limited to privacy problems, gas fee issues, and single-chain dependency. Especially regarding the privacy issue, as, in public blockchains, anyone could quickly look up any ongoing transactions, the public might quickly figure out the fact that wallet 0xA from the above figure is sending messages to wallet 0xB. Eventually, this could result in colossal privacy issues, as the sender and receiver aren't protected from the public's monitoring.
Given that such a model doesn't seem ideal, what kind of infrastructure might achieve a decentralized but privacy-preserving messaging system?
Given both cloud-based messaging and the p2p messaging system of Web 2.0 don't provide the highest level of security and privacy due to centralization risk, beoble decided to design a fully decentralized and privacy-preserving design of delivering communication called Communication Delivery Graph (CDG).
Wallet: Refers to Web 3.0 wallet of any existing layer 1.
End-to-End-Encryption: A security method that keeps your communications secure that doesn't allow any third party to read your message contents, using chatroom participants' public keys.
Multi-Layered Encryption Method: A security method to provide multi-level access control to different parties on a single encrypted object.
Delivery Path: A path in the graph where a single beoble message is delivered within the nodes in the graph
Decentralized Storage: Storage that offers decentralized storage; typical ones currently include IPFS and Arweave. Also, beoble is aiming to bring a more beoble-tailored decentralized message storage for beoble's efficiency.
Wallet 0xA logins to beoble
Client 0xA uses beoble's client SDK to prepare message delivery
beoble SDK discovers available nodes (from the above image, nodes A, B, C, D, and E)
beoble SDK figures out a proper path that is secure and deliverable (from the above image, path B -> A -> C -> E)
beoble SDK encrypts the message using multi-layered encryption, encrypting the message in order using the recipient's public key, node E's public key, node C's public key, node A's public key, and node B's public key.
Based on the preparation, Client 0xA initiates message delivery to node B.
Upon receiving the message, node B starts processing the message.
Node B decrypts the message using its private key and figures out the next destination, which is node A (node B cannot decrypt further, thus cannot know the destination after A)
Node B initiates the transfer of the message to node A.
Node A and C conduct the same processing.
Node E receives the message, and after processing, it knows that the path only has the final destination 0xB left, thus delivering the message to 0xB.
Client 0xB uses its private key to decrypt the message.
Both clients 0xA and 0xB can back up their new message to decentralized storages, maintaining their chat data reliable.
Privacy-Preserving: Delivery paths are mangled from the client SDK and encrypted in a way that each node only knows the next destination of delivery; thus, the privacy of the message sender and receiver is preserved.
Decentralized: Anyone could possibly get involved in operating the CDG nodes; thus, there aren't any centralized operators of message delivery.
Scalable: As there are more and more CDG node operators, the performance of message delivery on CDG scales.
Performance Efficient: Delivery of messaging relies more on encryption and path settlement rather than consensus nor any sort of proof-of-work, thus, being highly performance efficient.
User Data Ownership: CDG is just a delivery system, like your food or package delivery, and all the final data comes from you - you are able to fully manage and take ownership of your data.
