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 <[1]grarpamp@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?
     > [2]https://trac.torproject.org/projects/tor/ticket/24902
     > [3]https://trac.torproject.org/projects/tor/ticket/19966
     > [4]https://trac.torproject.org/projects/tor/ticket/24973
     > I can't find the one where they explicitly said that it's not
     worth fixing
     > 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 was
     > 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 [5]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 :)

   --

   [sig?u=carimachet]
   cari machet
   [6]about.me/carimachet

References

   Visible links
   1. mailto:grarpamp@gmail.com
   2. https://trac.torproject.org/projects/tor/ticket/24902
   3. https://trac.torproject.org/projects/tor/ticket/19966
   4. https://trac.torproject.org/projects/tor/ticket/24973
   5. http://0.3.2.10/
   6. https://about.me/carimachet?promo=email_sig&utm_source=product&utm_medium=email_sig&utm_campaign=gmail_api&utm_content=thumb

   Hidden links:
   8. https://about.me/carimachet?promo=email_sig&utm_source=product&utm_medium=email_sig&utm_campaign=gmail_api&utm_content=thumb