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 <grarp...@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 > 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 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 :) > -- <https://about.me/carimachet?promo=email_sig&utm_source=product&utm_medium=email_sig&utm_campaign=gmail_api&utm_content=thumb> cari machet about.me/carimachet <https://about.me/carimachet?promo=email_sig&utm_source=product&utm_medium=email_sig&utm_campaign=gmail_api&utm_content=thumb>
