

Ask HN: Advice on secure email system - sigkill

I&#x27;m writing a spec for what I hope, replaces email. But like I mentioned in a comment, it&#x27;s the asynchronous nature that puts things in a state of confusion.<p>Would you rather it behave like traditional mail where if the receiver is offline, the sender is notified to try three times at a later time?<p>Would it be better if there&#x27;s a central server that &#x27;holds&#x27; the message (encrypted) for X days and when the receiver joins the network, it notifies him &quot;Hey, by the way you have a message, here it is&quot;.<p>I&#x27;m in two minds between having something like an announce server (like a torrent tracker), but that would mean the tracker has everyones IP, or have it completely peer to peer like Bitmessage.<p>Or is there any other obvious method that I&#x27;m currently not considering?
======
Ihmahr
Hybrid.

Notice that the current bitmessage implementation has scalability problems
(and they do not seem to care).

Consider a p2p message system like this one: Messages are divided in headers
and bodies. Headers are less than 0.1kb and messages can be as large as you
want. Headers contain a micro-message or they point to an id of a body or to a
url. Like bitmessage, you have to generate a poof of word (POW) in order to
send a message. The headers contain a 'to' address field. This can be
partially filled out, or left blank.

Strong clients:

Receive everything and hold everything (for a day). They help their peers.

Mobile clients:

They have a 'light' address. They make the first n bits of their address
public to their peers. Then they receive only the headers where the to address
is partially disclosed and the leading bits match. The more bits of your
address you disclose, the 'lighter' your address is. This is also the way to
scale for a few billion people. Bodies can be downloaded similarly or even
with specific id. Mobile clients never send any content to their peers, nor do
they retain other people's messages.

Hybrid.

So far this is p2p. But nobody wants to be a peer of a mobile client, or they
might want an excellent connection to one peer. This is where more central
services come in. They accept payment for a connection and provide high-speed.
They also accept the useless mobile/light clients. Also these services could
calculate the POW for the light clients. What happens if one or all such
services go down? Not much, because the services were just high-speed peers.
The network can continue as a normal p2p network.

I have a lot more ideas on how to improve this design.

~~~
sigkill
I read the bitmessage's whitepaper and he has a section on scalability. He
proposes child nodes, but I don't know how well that would scale.

Your concept sounds interesting. Could you, by chance fill your about page on
HN (a bitmessage address will do too) so if I want I could PM you.

~~~
Ihmahr
BM-GuDKGJFRhq6o1B6SM7xiHUq7HtQFT2hH

The proposed 'streams' for scalability have not been implemented yet, and
there is no clear method to implement them. There is currently some discussion
on the BM forum on how to scale without streams.

~~~
sigkill
In that case I don't see any way without a central or multiple central
announce servers.

------
malandrew
Read this on De-anonymizing alt.anonymous.messages. The linked to PDF
discusses many of the attacks that can be performed on a secure messaging
system. It's very thorough.

[http://ritter.vg/blog-deanonymizing_amm.html](http://ritter.vg/blog-
deanonymizing_amm.html)

~~~
sigkill
Thank you. I'll do that today evening, although I do have a rough idea now
which direction I'm heading.

