deb0x

Inspiration

Our passion for privacy, decentralization, censorship resistance and community governed protocols inspired us to come up with deb0x (decentralized inbox). Our goal is to offer an alternative to the current email (SMTP) protocol which is not secure, vulnerable to spamming and so far led to centralized providers that can read and censor communications.

What it does

Deb0x is a privacy end-to-end encrypted email protocol that is also decentralized, has built-in economic incentives and is intended to be fairly launched. We believe that deb0x is better than current centralized privacy email providers (like Protonmail or Tutanota). It is also a lot more convenient than running self managed private email servers.

For end-to-end encryption, as opposed to the burden of managing PGP keys, deb0x uses the built-in public key infrastructure available to any Ethereum user to send and receive encrypted messages super easily.

No central authority can stop users from sending or accessing messages because the transmission is realised through nodes and smart contracts on EVM compatible blockchain networks. No single party can change, forge or delete the messages as they are safely encrypted and pinned on IPFS by incentivised validators. There is no central server or cluster that manages transmission and storage of messages.

Users receive token rewards for sending messages which grants them shares from future network fees. Users pseudonymously pay small per message fees with cryptocurrency instead of monthly subscriptions with credit/debit cards. The fees are embedded at the network level and naturally discourage spamming.

The token distribution algorithm is pre-programmed and can never be changed as there are no admin keys. There are also no premines, no treasury allocations, no private sales, no dev fees!

And there’s also governance to enable token based voting to update message sending fees.

As an open source community, we believe that fairly launched public goods like deb0x have a better chance of adoption and growth.

How we built it

A solidity smart contract manages transmission (record keeping) of messages. Either directly, or through our UI, a user picks an address to send a message to. The public key of the recipient address is picked from the blockchain (if it ever sent a transaction on a network like Ethereum). Then, through our frontend, that public key is used to store the message on IPFS. The CID of the message is then passed as a parameter and stored by the smart contract along with the recipient Ethereum address. The sender pays the fee in the native coin of the network. The receiver of the message queries the contract to fetch all the IPFS CID records that were sent to the address and picks a message to read. The receiver uses its wallet (e.g. Metamask) to decrypt and read the message.

The above smart contract can be deployed on an EVM compatible network (not exclusive to Ethereum). The senders pay the fee in native token. Senders receive DBX (ERC20) rewards for using the network. The total per block rewards are distributed according to a negative S-curve formula - rewards decreasing gradually. The early block rewards are higher to incentivise adoption. All fees paid in native coins by senders are distributed proportionally among DBX holders.

We plan to implement an IPFS pinning incentive with block rewards received if and only if, IPFS node runners prove that they store the encrypted messages. Our future proof of pinning implementation will only require to demonstrate that they pinned a part of the messages sufficient to ensure a replication factor. Currently all nodes must prove they store all the messages that were ever sent. The nodes risk losing staked amounts (slashed) if they do not provide fresh proofs of storage/pinning.

Challenges we ran into

Ethereum wallets do not support shared key encryption. Only one to one message can be sent so far.
Metamask’s encryption works with a derived version of the Ethereum public key. We had to initialize “inboxes” first by registering the wallet’s public key with the transmission contract first.
Lack of a decentralized pinning mechanism for small content (like email messages). Filecoin deals are good for large amounts of data, but even so, it was difficult to find a way to integrate lotus with our node to satisfy end user driven distribution of incentive to storage providers.
Designing Proof of Pinning to ensure that providers actually offer endpoints to read data.

Accomplishments that we're proud of

We have managed to implement what we planned for phase one of the project. That is - a prototype to demonstrate the viability of the deb0x concept. We have the smart contracts, functional frontend and ipfs upload/download.

What we learned

Decentralized storage is harder than we thought. We learned the technical details about how IPFS and Filecoin works. We also shared the knowledge in our local Ethereum meetup recently: https://www.meetup.com/cluj-ethereum-developers/events/284021441/

What's next for deb0x

Finish and polish the hackathon prototype.
Implement the Proof of Pinning and integrate with stake in contract.
Message MIME types / attachments.
Apply for grants to fund development and adoption programs.
Improve cryptographic scheme (multiple recipients)
Client libraries to implement apps.
Launch the network/protocol on a mainnet.
Offer support for client implementations.
Connect and showcase deb0x to information privacy communities.
Implement bridges with trad email servers so that deb0x users can send and receive emails to and from normal (SMPT) addresses.