Re: [tor-talk] [onioncat] Onioncat v2

[grarpamp <grarpamp@xxxxxxxxx>]

On 3/8/16, Bernhard R. Fischer <bf@xxxxxxxxxxxxxxxx> wrote:
> "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?
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk