A distributed verifiable censorship resistent e-mail service on top of Factom!

7 min readMar 4, 2020

A lot of people have asked me over time what Factom and it's related technologies like FAT, PegNet are and how W3C standards like Decentralized Identifiers and Verifiable Credentials fit in. Recently whilst discussing a proposal of a technical community member about creating another token to combine some work which is already present or almost ready in Factom, it became clear to me that I need to write more for people to get what the Factom Protocol is about.

At Sphereon we have a long term vision for both Sphereon, it's partners, the Factom Protocol and it's use cases. Since we cannot disclose everything at this point in time, let me just grab a 'little' example of what we believe should be possible with Factom based technologies, to hopefully make it clear to people that Factom is a bit more than only hashes or proofs. This example is a bit of a stretch, isn't fully thought through, so people can probably shoot some holes in it. If it were completely thought through and if we had enough people, it would already exist ;) It does show the order of magnitude we are thinking for some projects within Sphereon and Factom. It also hopefully inspires some people to think out of the box, as I could write several similar services, products or even business plans using Factom based technologies.

Decentralized e-mails really?

Let's say I want to use an e-mail service as a company, I can fully trust, which isn't run by a single company, is censorship resistant and above all can prove an e-mail is not altered at any point in time, as well as prove that the e-mail existed at a certain point in time and me being the author of the e-mail, optionally encrypting the contents. Would be cool huh?

Shopping list

Ok let's start with some building blocks we certainly will need:

Decentralized Identifiers

Decentralized identifiers are the next form of identities for Persons, Devices, Objects based on public/private keys. See some other blog posts of mine for more details. For now it is important to remember that you can compare DIDs to a website URL like https://sphereon.com, only then for a document on Factom that describes attributes about an identity. See the W3C site for more technical details: https://www.w3.org/TR/did-core/

E-mail signature and proofs

How can you prove an e-mail is not altered and have it timestamped at the same time? Simple an e-mail has a well defined structure. The most important part you want to prove are the body, attachments, subject and recipients. All parts of an e-mail you can quite easily grab. When the sending e-mail server or even the mailclient would use this data, generate a hash or series of hashes, maybe even in a tree (merkletree), you simply have to generate a signature with a private key associated to a DID you control. You publish the data in a predefined location, or a location people can lookup from your DID document in the Factom blockchain and anybody that knows your DID or public key could verify the message at a later point in time.

This proves the e-mail has not been altered. Every single change to the subject, recipients, or contents would invalidate the signature and hashes. It also proves that the e-mail existed at a specific point in time. In theory the e-mail could exist before the point in time, but the content certainly existed at the moment it was anchored in Factom. Since you are the sender of the e-mail and your DID also is associated to your e-mail adress, people can also trust it was really you that send the message (DID-dns/web associates your e-mail address and/or domain). You could use your or recipient keys as well to encrypt data, depending on the use case.

Verification

Verification could be done in multiple ways. Recieving mail servers could already do checks and insert results in the headers of the e-mails along the way, even using their Factom based DIDs. It is simply verifying whether the DID from the sender is correct and whether the signature can be verified based on the subject, content, sender and recipients. If something like this would become the norm, you could create a reputation system based on it, making spam way harder.

Obviously for end-users it is easier to have some plugins for Outlook, Office365, Gmail or on your mobile phone. Basically it uses the same process as desribed above.

E-mail Authentication

Sending and receiving e-mails uses authentication protocols, ideally these would be integrated with DID-auth on Factom in the future. Meaning passwordless authentication, using private keys stored in a personal wallet/vault, with you deciding when/where they can be used. This however would require support by both the sending mail (SMTP) server as well as mailbox server (IMAP, POP3, MAPI). Definately possible, but would require writing custom modules in some open-source projects like for example Postfix (SMTP) and Courier (IMAP/POP3). It would allow you to decrypt mails on the fly, or ask you to confirm on your mobile phone and sign the mail before sending it out. Eradicating almost completely the posibility of somebody else sending in your name.

Censorship resistance

What about the censorship resistence you mentioned? Well Factom with it’s commit-reveal scheme is already censorship resistant itself. Basically you pay with a hash for a spot in the blockchain. The content you will post later and nodes are required to anchor the data (oversimplified). Since the whole idea here was to be able to prove mails have not been tampered with, as well as being able to verify that every step of the way, it means every party in a mail interaction or in the distributed mail service would be able to verify the data to be correct. If a bad actor would have found it’s way into the system, it would be quite easy to make a consensus or reputation system that would kick out the actor eventually. The last party in the network touching the mail would be the problem, but eventually even that one is verifiable externally.

Decentralized or distributed much?

"Ok Niels, although a bit technical, I think I can follow you to this point. But what about the above makes it decentralized?" Good question….absolutely nothing ;)

To make it decentralized you will have to make it distributed first and at the same time ensure people are incentivized to run mail-services for you. Otherwise you get the problem of Torrents. People wanting to leech their files, without giving back (seeding) to the rest.

Registry

First you need to have a registry based system where people providing e-mail services for sending (SMTP) as well as storing (IMAP/POP3). This could be created on top of Factom, together with DIDs. Obviously it would need some work to figure that out completely. But given you can create (virtual) chains for all your data on Factom it should be doable. For arguments sake let's assume people can register their sending servers (SMTP) and storing services (IMAP/POP3) in a system like that on Factom, together with addresses for receiving tokens.

Whenever a new "customer" registers, it submits it's registration data to a FAT smart contract. Providers that fit the requirements and that are in the registry would automatically provision infrastructure upon the first payment. The registry would be updated, DNS entries would be created (I leave DNS out of scope in this article, as that is a bit of a project itself :P) to make sure you can receive e-mails, as well as make sure that other mailservers would accept mail from you.

Subscription and incentives

The end-user would be paying a monthly subscription based on a currency of choice in PegNet (stablecoin network). Different plans for storage retention and sizes could be created. Internally a special FAT token will be used, this ensures parties are incentivized to run the services and keep them up. As long as the end-user keeps paying the nodes providing the services are required to provide SMTP services and store e-mails (IMAP/SMTP). Obviously you want to create shards and redundancy in the network as it grows, and rebalance when nodes would drop out. A FAT smart contract would ensure the tokens paid by the end-user get distributed to the parties running the services for the end-user. By including a reputation system, parties providing reliable services (uptime) and/or for a long time (duration) get relatively more rewards. Rewards are locked up and paid out over time, with a weight more towards the end, to ensure providers do not run after a payment.

The token would very much like PegNets only free floating token PEG be valued by the market. What are people willing to pay for a service like this and what would infra providers want to receive? They also have Entry Credit costs to cover, besides the obvious infra costs. Would you trust a system handling your e-mails when there is no central party? Would you trust parties to not read mail? I guess it is a nice thought experiment whether a system like this would be economical viable. Obviously I haven't done the math and for the e-mail case would be skeptical. The part up to the decentralization chapter is the easier part and not dependent on decentralization at all.

I am just presenting this as an example of combining Factom related technologies to create a distributed solution and to let you hopefully think outside the box when you start to combine several Factom and W3C technologies. Nope Factom is not about hashes alone ;)