On Fri, Jun 12, 2015 at 12:02 PM, Zenaan Harkness <[1]zen@freedbms.net>
   wrote:

   On 6/12/15, Natanael <[2]natanael.l@gmail.com> wrote:
   > Den 12 jun 2015 10:19 skrev "Zenaan Harkness" <[3]zen@freedbms.net>:
   > Don't do F2F at the lowest network layer. Don't give away sociograms,
   don't
   > allow timing attacks, and avoid the whole NAT issue.

     Sorry, I'm thinking about it differently - like a physical layer.
     Let's name it differently: H2H - HUG node to HUG node, which might
     be
     overlayed over existing ISP/ centralized net, or might be your own
     PHY
     layer (e.g. local street-level wireless).
     So, treat this is a PHY layer, where everyone is expected to
     connect,
     relatively speaking, to their neighbours.
     A F2F (by terminology/meaning) would overlay on top of that.

   So like what CJDNS does? [4]https://en.wikipedia.org/wiki/Cjdns
   It can be compared to a kind of VPN, it creates an IPv6 addressed
   network in the private fc:: range where the addresses are based on
   hashes of public keys. The connections can go over the internet, or
   over meshnets, or over your local LAN, or over a RONJA link
   ([5]http://ronja.twibright.com/about.php).
   Then on top of that you could run anonymization like I2P and any other
   services you might want.

     The key that I2P (and Tor for that matter) are missing is fill
     packets
     - i.e., the nodes you talk to, promise to backfill their link to you
     (likewise you to them) any empty packet slots, so that the link
     maintains a continuous throughput (to hide all real traffic within)
     -
     the only thing a state-level adversary (or ISP-level for that
     matter)
     can do to analyse things is kill the link entirely (shock testing),
     which can correlate your traffic with "exit node" traffic, but is
     much
     harder to see anything when you are only operating within the dark
     net.
     This is now a very important feature which our anonymizing network
     software needs in order to provide any meaningful protection.
     Local PHY is now also very very useful to increasing network access
     anonymity. This urgently needs some research study/papers to
     analyse/
     determine the best ways (within eg onion routing context) to
     maximise
     advantage of off-net (private PHY layers).

   IIRC support for that already exists in I2P, although not yet
   implemented. The protocol already have support for a number of things
   like fake filler traffic.
   Anonymizing routing in local networks can be hard to achieve against
   timing attacks and other correlation attacks, in particular when
   assisted by DoS. The problem is that there's typically a limited number
   of local routes going outwards, poor interconnction and not many
   long-range links, and node-to-node links reflect human sociograms very
   well. Having I2P being able to support connections over both types of
   networks simultaneously would be an advantage.

     "Just use..." is very problematic! Please do not be so cavalier with
     your languaging as those without understanding might mistake your
     absolutist languaging for relevant fact (as opposed to intuitive
     sense
     or reasonable avenue for consideration depending on various factors
     .... etc etc)!

   I'm using "just" as a synonym for "doesn't need novel research, can be
   implemented by a any experienced programmer". As compared to requiring
   experts in the field to create new algorithms to make it possible,
   practical and secure. The difference between "needs time" and "needs
   brainpower".

     > I've done a lot of thinking on P2P social networks, I'll share
     later,
     Great. Looking forward to your thoughts. Please don't portend that
     there are easy conclusive "solutions". There are not!

   I'm aware there's a very significant amount of work required, see my
   comment above. I'm trying to gather the various things I've written
   about it now. There's a lot to write down. There's a lot of questions
   about how to make it work without massive overhead. I'm trying to
   figure out how it should work on each level of abstraction, from data
   encoding to routing to key management, etc... I want to see a mainly
   P2P oriented system that allows for server assistance (for distribution
   of signed data, storage, receiving messages on your behald when you're
   offline, synchronization / coordination, etc...). And I keep finding
   edge cases that would be messy with most of the potential solutions I'm
   considering, which is another reason for why I don't have a complete
   sketch written down yet.

References

   1. mailto:zen@freedbms.net
   2. mailto:natanael.l@gmail.com
   3. mailto:zen@freedbms.net
   4. https://en.wikipedia.org/wiki/Cjdns
   5. http://ronja.twibright.com/about.php