As also raised in our internal primers on W3C Decentralised Identifiers and the DIF Sidetree protocol, one goal for Vereign SEAL will be to move toward a scaleable approach of self-hosted, corporate and service nodes as part of switching to what we internally have started calling “Mailtree protocol” as its design and function is very much influenced by the Sidetree protocol itself.
One of the core components of this kind of approach is the Interplanetary File System (IPFS) to store data in an immutable, decentralised and fault tolerant way. Switching to Mailtree will require all our clients – most importantly the Add-Ins – to connect to IPFS.
For the user experience, IPFS will play a major role especially in terms of speed and convenience.
So we need to get the integration of IPFS right and should dedicate a whole product cycle on this topic to make sure we understand all the implications, can measure the different performance impacts, and can make adjustments or develop best practices before the whole functioning of the entire system depends on this component.
To the layperson, Vereign SEAL – a.k.a. “verifiable credentials for email”, “digital provenance for email and attachments” – is effectively a better version of registered mail. Digital, decentralised, peer-to-peer, more convenient, cheaper, more efficient and with far higher value in terms of securing evidence.
That is why our marketing will highlight the idea of “Registered Mail 2.0” “Digital Registered Mail” and “Decentralised Registered E-Mail” as themes in order to help wider audiences understand what Vereign SEAL provides. Why do people send registered mail? Most often because they want proof that they provided, sent, did something.
Traditional registered mail is effectively only proving that someone sent an envelope. Vereign SEAL can prove WHAT was sent, including attachments. We can prove this by virtue of hashes which are part of the verifiable credential. But this approach requires that users provide the mail or file itself when trying to prove what was sent, exactly. Verification can either be done in the add-in, or requires manual generation and comparison of hashes.
That is not very convenient and may regularly prove too hard to follow for legal professionals that may be involved in judging whether proof has been provided.
Now imagine that the EMAIL ITSELF, as well as all its ATTACHMENTS were stored encrypted in IPFS.
As a result, the web verification app can display the email message that was sent, and provide the attachments for direct download. Because of the properties of IPFS and because of the way in which the verifiable credential itself is formed and secured against the blockchain, both the mail and its attachments would be GUARANTEED to be EXACTLY as they were sent.
In other words, someone trying to prove this is the contract they signed could just share the verifiable credential with the court and tell them: “Here is what I agreed to. Feel free to download the original contract directly from the receipt.” and it is GUARANTEED to be correct and identical, and extremely easy to use.
Because IPFS is content addressable storage that only distributes files on demand, we can do this in a way that is compliant, is not easily data mined, and will work in a globally decentralised fashion.
And not only would this be a feature that would add a lot of value to Vereign SEAL immediately, it would also allow us to build practical experience with IPFS, including its performance and how we can ensure that the overall user experience is good.
Because speed is of utmost importance, adding IPFS means we should add IPFS locally whenever possible. Doing so will make storage of data while sending a LOCAL operation, allowing mails to be sent faster, allowing the clients to proceed with sending more quickly.
Note: For cloud based services, the local device may be further away. So there it might be better to write to an IPFS instance run by Vereign in the corresponding cloud infrastructure - making it as local as possible. So each client will need to take its data flow patterns into account.
Some clients are therefore likely to need to support more than one approach, e.g. for Outlook on the desktop vs Microsoft 365. They should therefore have an order of preference and priority to use (highest priority / preference first) for SENDING:
- Local IPFS node in the same cloud, if cloud based – OR –
- Local IPFS node configured by administrator (e.g. for companies self-hosting)
- Browser based IPFS node, where possible and the browser offers it, e.g. IPFS Support in Brave
- Add-In IPFS Node via JS-IPFS
- Last fallback: Fallback IPFS Node operated by Vereign itself
For READING/VERIFYING we can start with the same list, but this is the case that is more likely to be slow, and we may need to play with this and tweak things to work as intended. So clients MAY in fact find themselves with a different approach / list for VERIFYING.
In any case, ALL clients – including the web verification app – should include JS-IPFS by default.
Other places we need to introduce changes for this feature
Storing the email and/or attachments into IPFS should be optional.
So we may need configuration of default behaviour, or a convenient way to toggle behaviour.
We will likely also need to allow configuration of preferred IPFS node to use, with sane default.
Sending with storage into IPFS means we need to
- generate symmetric encryption key (for AES-GCM, most likely)
- encrypt message / attachments with key
- store message / attachments into IPFS
- store encryption key into verifiable credential / SEAL
- store URIs of message body and attachments into verifiable credential / SEAL along with the file hashes we currently store
- send SEAL normally
The data schema for SEAL verifiable credentials therefore needs to be extended to support
- AES-GCM private key for content encryption
- IPFS URI for message in IPFS
- IPFS URIs for attachments in IPFS
The web verification app needs to see whether message body and / or attachments are available, get the key from the SEAL, retrieve the attachments and message, decrypt them, and
- display the message, if available
- offer the decrypted attachments for download, if available
Also, this process should be as non-blocking as we can make it.
I hope this explains the rationale and intended behaviour well enough to allow everyone to think it through and provide insights as to what might have been overlooked, as well as suggestions about how to implement, exactly, and how to split up the work.