>> 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 :)