On 3/8/16, Bernhard R. Fischer
"Do we want to keep this nice automatic IPv6/Onion-ID translation feature?"
If NO: There's no problem. Everybody can setup his own hosts-file for the translation.
If YES: Independent of the final solution there is a need for a lookup-database/service of any kind.
This goes to two things... - the usage models you expect - the usage models you want to enable Let's keep in mind that the fundamental strengths of onioncat and reason that it exists are... - tor and other anonymous overlay networks often do not support full IP semantics, with tor it's TCP only, which cripples or eliminates certain apps. - anonymous overlay networks often do not support interfaces to the traditional IP stack of OS's, with tor it's onion only, which you can't bind(2) to, except via hack within the tor daemon... which only does tcp, which doesn't route, or packet filter, or VM, or... "NO" ... well, that's fine for individual people who meetup elsewhere and personally agree to exchange keys and addresses (or find such listed on the web, etc) in order to communicate. It scales only to the extent one can personally manage it, and it is not oppurtunistic as far as making random new introductions. "YES"... this is where the real potential lies. Lots of apps are p2p, or at least rely on central servers to tell them of their peers in real time. Bitcoin and bittorrent are purely p2p with peers coming in via the network itself at random. VOIP could be thought to be central yet random. This list of non-manual config apps is really long. Then evaluate which are popular in the opensource space whereby they're possibly not run by popular centrals like facebook, but by community (XMPP), or strictly p2p. It seems that NO would still serve a purpose and thus would be a call to making an onioncat v2. And that YES would be a very interesting project that needs to look at many potential solutions some of which people post ideas about on list.
IMO we should use an existing database and we should not try to
Yes if it is available, or willing to be developed and integrated by the overlays for such use.
establish a new system because this depends always on people willing to run these.
For example, it may be possible that the [transmission] bittorrent, and cryptocoin, communities might see a reason to run something separate if it gave them p2p access to anonymous transport layers.
I do not know about the userbase of OnionCat but we should assume that it is small, hence, not (yet) able to keep enough Onioncats up for running a DB (DHT or whatever).
Public usage is all in supply, demand, and advertising. Private usage has seen some successful onion/i2p like what.cd [nee i2p/onion] membership. Evaluating the needs of some VOIP and messaging protocols re IPv6 UDP and tun interface might be useful. We already know bittorrent needs udp and trackerless p2p to be efficient. Another way to think is... can the overall utility of anonymous overlay networks ever grow if they continue to be restricted to, say, TCP and their own proprietary addressing stacks? Are there RFC type proposals to interoperate / expand that among the community of overlay networks? And is onioncat a good place to enable that if either are no?