Mailservers and proof-of-uptime
===
## Problem

For a user to connect to a mailserver they need to have some assurance that the mailserver had
been gathering messages or synced the messages for the period of time they are interested in.

## Initial idea

Mailservers will keep a blockchain synchronized with the relevant proof-of-uptimes.

Mailservers will have 2 functions, one serving as validators of proof-of-uptime for the network, while the other is to
provide historical messages to users.

Every time a new mailservers wants to join the network, it will first have to manage to get at least one proof-of-uptime
encoded in the blockchain, hourly each mailserver will want to ask for a proof-of-uptime as well.

The process to acquire proof-of-uptime is as follow:

1) The new node connects to other nodes and starts gathering messages
2) Each mailserver publishes at a random interval (less than one hour) some check envelopes. These are just normal envelopes
not distinguishable from normal, signed and encrypted with a symmetric key.
3) Once a new node as gathered messages for long enough (i.e one hour for example), it will initiate a request for proof-of-uptime
4) Based on some random non-manipulable selection (ethereum block number/hash), it will select a subset of mailserver that had a proof-of-uptime encoded in the blockchain in the past hour (What if they are offline? they can stake for availability maybe)
5) The selected mailservers will challenge the new mailserver with the envelope id, and if the envelope is produced, it will reveal the symmetric key and a signature certifying the operation has been completed.
6) The mailserver that has passed the proof-of-uptime will propagate this through the network, and other mailservers will append it to the blockchain.

Client side:

1) Client will sync the blockchain only for the past x days (we should check how much data it is)
2) Client will select a mailserver that has passed their proof-of-uptime consequently for the desired period (i.e. 24 hours for example)
3) This data can be checked against other ms for consistency

## Potential issues

1) Why should mailserver forward messages at all, or at least why should they forward messages to competitors.
2) How do we prevent cartels? (Mailserver only forwarding to friendly mailservers)(possibly given that verifiers of proof-of-uptime are chosen randomly no more proof-of-uptime would be issued if that is the case.)
3) How do we prevent a mailserver to pull envelopes from other ms when a proof of uptime is issued? (broadcast challenge, so nodes know not to forward that envelope id, still possible to have dark mailserver collecting data and passing it on to friendly mailservers that had been challenged. We could require a proof of delivery for each envelope, but gets complicated)