On 8/20/19, Bernhard R. Fischer <b...@abenteuerland.at> wrote: > I finally wrote a HOWTO on using OnionCat with v3 hidden services. I > also did some patches to OnionCat to have a better integration. > > https://www.onioncat.org/2019/08/onioncat-and-tor-hidden-services-v3/
Thanks. Rather than tor killing off v2 onions and HSDirs from the codebase, thus ending all the good useful carefully chosen and even required reasons people still use v2 and onioncat (some of which can be found by searching list archives for onioncat, P2P, VoIP, add more uses here)... tor could update the default to create v3 onions, and to require manual config of v2 onions, and to emit nanny warnings pointing to a v2 vs v3 comparison table on the wiki, update v2 to be as small a diff as possible from v3, modularize v2 support and HSDir operations. That way v2 and v3 users remain happy. It also seems possible that a solution to what onioncat provides via v2 onions (IPv6, UDP, IP transport services in the host stack out across onionland, some crazy routes between I2P, metrics ping, etc) could be designed for v3 onions. Perhaps some form of time expired or first come served 1:1 registration to HSDir hashring for lookups, a NameCoin like sidechain, or using one of the existing Tor / I2P native addressing enabled privacy cryptocurrency blockchains as lookup index, or some new and open network overlay DHT layer for everyone, or AF_WIDE, IPFS or other hash based storage network, etc. Even some tradeoffs in a solution to achieve a v3 onioncat might be acceptable... in the same way that some v2 "security risk" issues are accepted today by those needing what onioncat offers thus overriding that, or are not relavant because their application use model is not affected by such risk. -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
