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@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>