Proposal multi recipients
Since the catalog, blocks and attachments are symmetrically encrypted an encrypted key found in the header, only the recipient with that async private key can actually decode the catalog, blocks and attachments. Not even the sender can decrypt the blocks after the symmetric key is destroyed. Therefore it's not trivial to have a system that deals with multiple recipients.
-
Each recipient gets their own header file, with the SAME symmetric key encrypted with the recipients public key. A client can send multiple headers to a mailserver, but each mail server will only send one single header to the destination mailserver.
-
When sending multiple headers, the consecutive headers are marked with header-001, header-002. We probably want to limit the number of headers to send to a specific number. (Sending large mailinglists would mean multiple uploads?)
-
sending mailservers will receive catalogs, blocks, attachments and headers in random order. It might be possible that we send a few headers first, then the catalog, some blocks, a few headers again, and finally an attachment. The sending server must deal with this but ALSO be able to start sending things when all info is present (when we have all the blocks, attachments and the catalog). This is done by sending the meta-information on what we are going to upload with a ticket. So if there are X blocks, there will be a definition of X blocks (their UUIDs) in the ticket. This will let the server know when all the blocks (+ catalog) are uploaded. At that point, whenever there are header files, it can start delivering complete messages.
-
There is currently no provisioning to deliver multiple headers to a mailserver. However, we can implement this in a later version. This would mean changes in the delivery but also in the sending. This is also a problem, because we can send multiple messages with only a single-proof-of-work.
- We have a worker pool of X workers that will deliver blocks (attachments, blocks or catalogs) either local or remote.
- When we receive data from a sender, we add the data to all the known headers on the worker queue.
- If we receive a new header we add all known blocks to the worker queue for that header.
- When we have received all headers, we close the connection (we know from the ticket)
- when we have received no data after 15 minutes, we close the connection (partial message received, but still delivered partially)
SENDER: create ticket (headers: 3, blocks: 2, attachments: 0)
SENDER: send header 1
SENDER: send catalog
SVR: queue: header-1 catalog (do pow for ticket-1)
SENDER: block 1
SVR: queue: header-1 block-1 (use cached ticket-1)
SENDER: send header-2
SVR: queue: header-2 catalog (do pow for ticket-2)
SVR: queue: header-2 block-1 (use cached ticket-2)
SENDER: send block-2
SVR: queue: header-1 block-2 - completed (use cached ticket-1)
SVR: queue: header-2 block-2 - completed (use cached ticket-1)
In this case, we send a message with 2 blocks to 3 different recipients. First we send the header 1 and the catalog. Since we have a block, and we know a header, we queue that block (catalog) and the header. The queue workers will pick up this data, and try to deliver it. Since it's the first connection, we need a valid ticket so it will create a ticket before sending. Note that AT THIS POINT, the recipient is aware of the message, even though we don't have any blocks delivered yet!
After sending the block-1 block, we add this to the queue as well (header-1, block-1). Since we have a cached ticket, we can use this ticket to send the data directly to the recipient.
Next, the client sends header-2, which means that at this point it can queue all the known blocks to the queue (header-2 catalog, and header-2 block-1).
When block-2 is delivered, we queue it for both header-1 and header-2.
after 5 minutes:
SENDER: send header-3
SVR: queue: header-3 catalog (do pow ticket-3)
SVR: queue: header-3 block-1 (use cached ticket-3)
SVR: queue: header-3 block-2 - completed (use cached ticket-3)
