Demonstration of a tinc network linked through Tor v3 onions
carimachet at gmail.com
Mon Apr 29 01:51:08 PDT 2019
Non corporate? >>> non navy how bout ? It has been analyzed that USG is
Authoritarian Capitalism and a hybrid of corp and gov ... > interlocked in
a special way ... hand in hand ... BFF... heart emojis
Why navy need you on tor network? Cover
On Mon, 29 Apr 2019 at 08:07, grarpamp <grarpamp at gmail.com> wrote:
> >> It can be communitied, or forked.
> > Seems unlikely.
> Either can work if people want them to,
> that is the very point of opensource if so merited.
> >>> Reported bugs have been closed without action.
> >> What ticket numbers are of interest?
> > https://trac.torproject.org/projects/tor/ticket/24902
> > https://trac.torproject.org/projects/tor/ticket/19966
> > https://trac.torproject.org/projects/tor/ticket/24973
> > I can't find the one where they explicitly said that it's not worth
> > v2-specific bugs.
> Statements always nice to have for reference.
> Bugs not needing architecture rework should be fixed.
> >>> Fetches of v2 rendezvous descriptors fail, and so OnionCat services
> are "unavailable".
> > Analysis? Not really, just lots of notices logs. Basically the same
> stuff as
> > in #19966. Lots of it.
> Any tickets should be revalidated using current release
> on unix, then bumped if still valid to get them fixed.
> The version issues below can be gamed as needed if applicable.
> > how tinc uses onion circuits vs how OnionCat does.
> They're just apps bound to onions, no special knowledge of tor.
> There can be things like layer 2/3/+ keepalive packets, etc
> going on depending on the app. Circuit timeout settings, etc.
> See also OnionBalance regarding overall subject.
> > Or maybe v3 onions work better than v2 onions, either because
> > they're better designed, or better supported.
> v2 is still in the code and will be for a long time,
> even possibly modularized for third parties indefinitely.
> So if there are v2 problems, ticket them, join together,
> and get them fixed.
> > It's also possible that I've tested them differently. With OnionCat, I
> > using Freenet. And with tinc, I've used bittorrent. So maybe Freenet and
> > bittorrent have different enough packet dynamics.
> Tests should only change one variable at a time.
> > I initially picked that IPv4 range because of ChaosVPN. But maybe it'd be
> > better to integrate with dn42, and use IPv6
> IPv4 is dead, IPv6 gives much more room for people to play
> without colliding with each other or other things... lots of
> people's stacks and private usage treat RFC1918 as their own,
> not that of some third party apps (which really need to use their
> own space outside of RFC1918, etc). So you need more space.
> Overlays can use either 4/6 on clearnet and emulate either
> 4/6//N-bits for internal use, and can also setup separate instances
> integrating into each. IPv6 has some space options, and lots
> of unallocated slack space. But also search "AF_OVERLAY"
> for a grander more universal overlay interop scheme than
> even IPv6 can ever provide.
> > What worries me is that the Tor community will see this
> Though exit is and should be a priority in tor at the moment
> given the gamut of todays overlays, tor does not, should not,
> and won't have exclusive claim to that functionality in both other
> currently developing and future overlay networks.
> > as DDoS, and implement blocks.
> tor-0.3.2.9 was the last version without some statistical blocking
> changelog 0.3.2.10: "denial-of-service mitigation"
> > I wonder whether they've done that with OnionCat.
> No. Tor can't pick out apps like that, only patterns,
> those can be really hard for an overlay (like tor) to
> discern, and impeding of many false positive users.
> Fork tor if tor censors people (they've already tried to
> censor relay operators and posters for speaking freely).
> Say to a non-corporate more globally volunteer opensource tor.
> Or simply support the development of and migrate to
> better more resistant overlay networks going forward.
> Diversity in designs, and with more deployed overlay
> networks in live competition, are important.
> Anyway, happy hacking :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 6843 bytes
Desc: not available
More information about the cypherpunks