On Tue, Dec 24, 2013 at 5:01 AM, danimoth <danimoth@cryptolab.net> wrote:
In these months there was a lot of talking about "metadata", which SMTP exposes regardless of encryption or authentication. In the design of this p2p system, should metadata's problem kept in consideration or not? IMHO exposing danimoth@cryptolab or my <key> it's the same, as there is a function between them. I2P and/or Tor adds complexity to avoid such mapping to any non-state-level adversary.
From - As with today, this may or may not end up being authenticateable by the recipient. Since the net itself would seem to need to be anonymous, then it is
I'd assume the design will rightly provide complete end2end encryption between your source spool and your recipients spool over whatever bits are in between, as a result of having the key, equivalent to the node, equivalent to the address. Store and forward might need to expose only the destination key to the storage and routing net. A direct circuit would not. All the legacy 'received' headers are gone by definition. A full raw message might contain some required bits for continued use with your favorite mail tools post handoff to you: likely not. Nor is it a problem if it is... you just generate yourself a new node if concerned. To, Cc, Bcc Date Subject Message-ID [Threading] Body Antispam/antivirus becomes responsibility of the sender/recipient so no headers there. No legacy dkim, spf, etc, either. There may be a new set of transport preference headers if the design calls for it. ie: You might be able to use the net with full mail clients like mutt, thunderbird. Or with a light 'messaging' client protocol. Each of which might have a slightly different interface into and out of the node. Addresses might look like: [user/function or protocol/arbitrary string]@[node pubkey/hash] I've no idea, only to see if interested people think some sort of nextgen P2P/DHT system is actually possible at scale.