F2F UDP mesh net prototype proof of concept "Covfefe Net"

[John Young]

With respect for gold diggers, how is it decades after setting up the 
internet by officials and their consultants there continue to be 
dreamy and futile efforts to use the "lawless" tool without being observed.

Its like the shrewd peddlers of picks, axes, pans and pussy to 
obsessed diggers of land salted with tiny nuggets and dust and comely 
STD lasses, licensed assayers arrayed to measure the findings and 
spread hope via whispers, leaks, news rags, bars, whores and as ever 
lawyers licensed by the state to regulate the mayhem, avarice, 
cheating and taxable land at every higher rates.

California a prime real estate Ponzi of this charade from the Gold 
Rush to Silicon Valley to Forever War Production. Cypherpunks a 
California dream of outwitting The Man which made early adopters 
wealthy, arrogant and notoriously seductive with Pretty Good Crypto 
freely available to avid challengers of authority, cosmeticized with 
official prosecution, glorified and exported as if Western Movie-made Outlaw.

MS, Google, Apple, Amazon, Boeing, Lockheed Martin, Los Alamos, 
Berkekley, Nevada Test Site, Supermax, Hollywood, E Frontier F, on 
and on, theology of Home on the Range without fences, censorship 
workarounds, no matter cellphones and IoT tracking rascals online and off.

Keep digging fabulous fortunes and reps being reaped regularly as the 
5-Eyes et al, national laboratories, WMD enforcement marshals, DoJ 
and IRS keep careful watch and BOP continues to expand Guantanamos 
for the Jims, Julians, Jeremys, Chelseas, Pseudos and Anons.

Has there ever been as effective a gelt-planted sting as WikiLeaks, 
cpunks conceived? Yes, PKCalifornia.



At 05:58 AM 10/20/2019, you wrote:
>On Sat, Oct 19, 2019 at 03:52:30PM +1100, Zenaan Harkness wrote:
> > On Fri, Oct 18, 2019 at 09:06:09PM +0100, Steven Schear wrote:
> > > Isn't that why networks like i2p exist?
> >
> > There is at least 1 attempt to rewrite I2P, and he is not even
> > interested in the core improvement - chaff fill.
> >
> > Tor is fundamentally compromised, as Juan correctly points out:
> >
> >  - TCP, not UDP, as base protocol
> >
> >  - no chaff fill
> >
> >  - independent "core router" operators, e.g. Jacob Applebaum, have
> >    been purged from Tor core group - in a rather brutal public
> >    lynching manner (classic CIA psy op)
> >
> >
> > I2P is not government funded, and so "new user/ high speed internet/
> > low latency" experience, is not enticing to said new users.
>
>This ought be fixable with a suitably compelling design.
>
>
> > A fundamental difference from Tor's "core high performance routing
> > nodes" and TCP (connection base mode) compromises (along with chaff
> > fill), are:
> >
> >  - mesh network
> >  - UDP connectionless base network
> >  - chaff fill
> >
> > For any network, your entry nodes are a fundamental privacy problem/
> > issue.
> >
> > Tor settled on "choose 1, stick with it for a few months or more,
> > since the more you hop, the greater the chance you hit a compromised
> > entry node anyway".
> >
> > A fundamental difference for an alternative needs to be F2F - friend
> > to friend connections. You -must- find meat space humans who join in
> > your freedom/liberty network, if you want the possibility of not
> > being immediately GPA statistically sniffed.
> >
> > I'll have a look see...
>
>
>OK, most of the bits I am comfortable with, although it will take
>some weeks to code up a Java GPL3 Linux based proof of concept.
>
>This shall be an attempt to establish what we need to know, so will
>almost certainly be rewritten at least once, as we figure out what we
>didn't know, and need to do, to make something approaching a "proper"
>design and implementation.
>
>See https://github.com/zenaan/covfefe if you wish to follow along
>with this exploration.
>
>
>Some basics:
>
>   - UDP base protocol
>     - at least initially
>     - (lower/ higher/ HTTP tunnel bridges etc later)
>
>   - 100% P2P, no central auth needed
>
>   - trust metrics for "friends" (the F in F2F)
>     - configure default provision/ reservation of available bw for
>       friends/ various "trusted peer" levels of trust
>     - the rest can make do with the rest of the available bw
>
>   - TUN/TAP based, Linux is comfy here (OpenVPN has Windows drivers),
>     this allows ready userspace development iteration
>
>   - back of envelope calc for 24/7 connection at 8 Kibit/s (1 KiB/s):
>     https://en.wikipedia.org/wiki/Data-rate_units
>
>     seconds / day = 60*60*24 = 86400
>     bytes / day   = 86400 * 1 * 1024 = 88,473,600
>     MiB / day = (bytes/day)/1024^2 = 84.375
>     GiB / month = ~2.5
>
>   - end user node originated routing (similar to Tor)
>     - implies a node needs to know about other nodes
>     - peer nodes provide info about their immediate peers
>       - possibly also about peers they've been informed of
>
>   - peerInfo contains asserted trust metrics
>     - third hand trust is below first hand trust
>
>   - meat space trust assertions are primary trust source
>
>   - with Tor Browser and no local node, user is with high certainty
>     exposed to deep pocketed GPAs running majority of entry nodes
>     - you NEED at least 2, possibly more (need thought on this)
>       "trusted" peers to have sane net entry
>
>   - Sybil attacks:
>     We are out-competed in any trustLESS network (well funded GPAs);
>     - so we have no option but to establish at LEAST 2, possibly at
>       LEAST more than 2 (idk yet), meat space "trusted" humans, at
>       least for certain or most network entry
>     - in a very real way, in this way CovfefeNet will mirror real
>       relationships in our day to day life
>     - yes, you may choose to trust someone you've never met, but have
>       built a long term communication relationship with online for
>       example - you must decide who and for what purposes, you trust
>       any individual
>
>   - initial F2F connection is a control socket (UDP) and one or more
>     uni- or bi-directional data sockets (UDP)
>
>   - If you have NO one you can trust in meat space, you're Shit Outta
>     Luck, sorry... your #1 job is to engage with real live humans and
>     establish actual relationships - you might have to go through a
>     few dozen - or a few 100 - to find the gem you can trust. There
>     is no other way. Sorry about that, but reality is our tutor by
>     default.
>
>   - serialization (of e.g. control messages), some combo of:
>     - YAML, or a YAML subset
>     - protobufs
>
>   - DJB's nacl crypto
>     - possibly Linux LUKS volumes for local store
>     - LUKS supports also Veracrypt for Windows compat
>
>   - STUN etc NAT router port busting libs and protocols
>
>   - if you want something approaching "secure", don't even consider
>     MS Windows or MacOS
>
>   - available node bandwidth us known/configured, and/ or established
>     over time
>     - available node bw may drop off a cliff, e.g. when shaped by ISP
>     - available node bw may suddenly rise, e.g. when unshaped by ISP
>
>   - strict bw control qdisc (Azureus Vuze seems to do rather well)
>     - strict priority queueing for control sockets
>     - possible "realtime" data socket qdisc (QoS) for e.g. phone
>       calls
>     - preference for Friend peers
>     - reserve headroom X KiB/s for friend peers
>     - hand out remaining [CONFIGURED KiB/s] to incoming requests
>
>   - connect to known contacts/ peers/ "friends"
>     - peer provides set of 1r (once removed) peers, they provide 2r
>       (twice removed) peers etc
>     - additional connections may be made to additionally known peers
>     - maintain peers (metrics) db over time
>
>   - "friendly" control / intention notifications, optional
>     - "I intend to stay online until T time"
>     - "I seek 2.5 hours at 10KiB/s rt QoS" (e.g. phone call)
>     - "I am about to go offline, in D duration"
>     - possible friend response request "Please give me +10 minutes"
>     - possible responses ACK, NAK, or no response
>
>
>Has anyone here coded, or knows someone who's coded network stream
>queueing and shaping code for bittorrent or similar?
>
>I'm not clear on how best to individually shape (i.e. strictly
>control) a few thousand UDP connections - think data structures.
>   - Not reading from a peer's incoming port will presumably cause the
>     sender's queue to block up, but we're doing a "request BPS bw for
>     T time period" model, so we can do much better than relying on OS
>     queueing, namely we can stay below "known bandwidth" of our
>     respective (local) physical links
>
>Short of direct answers as to functional ADTs (maps, rings, cascading
>priorities, etc), I shall investigate torrent clients and bone up on
>qdiscs.
>
>Keep in mind, at least primary routing decisions are all made by the
>origin peer - although the possibility of mid-hop multi path stream
>setup of some sort might be useful (but imagine your GPA killing your
>lone origin connection to establish that yes, it's you
>sending/receiving that particular stream in the middle):
>
>   Multipath TCP: an overview [2013]
>   https://lwn.net/Articles/544399/
>
>   Upstreaming multipath TCP [2019]
>   https://lwn.net/Articles/800501/