[tor-dev] Freenet + Onioncat: Is the traffic welcome?

[George Kadianakis]

konstant at mail2tor.com writes:

> [ text/plain ]
> I posted steps on how to connect Freenet nodes over Onioncat and Garlicat
> for Tor/I2P. I am looking to scale it into an Opennet inside Tor with a
> lot of peers:
>
> https://emu.freenetproject.org/pipermail/devl/2016-June/039056.html
> https://emu.freenetproject.org/pipermail/devl/2016-June/039059.html
>

Hello konstant,

this is an interesting approach! Thanks for putting time on this :)

I find the security properties of high latency anonymity quite intriguing and I
have indeed hand-waved about integrating such systems with Tor in the past.

Unfortunately, I'm not very familiar with Freenet and its security
properties/assumptions. It would be great if you could sketch out a small
document explaining the benefits of this integration in high-level terms:

- What use cases are enabled by integrating Freenet with Tor? Who would use this?
- What benefits do Freenet users get by this integration?
- What benefits do Tor users get by this integration?
- What's the end game here?

> Is the extra traffic desirable in Tor? Reading asn's comment, I was under
> the impression that you are interested in adding higher latency traffic
> such as Freenet or mixnets for better anonymity:
> https://blog.torproject.org/blog/crowdfunding-future-hidden-services
>

As Roger suggested, we should be aware of how much load this project adds to
the Tor network. This means that adding metrics to estimate the extra load that
"Freenet over Tor" causes should be high priority here; especially so if we
think this is going to rise quickly. How easy would it be to introduce such
metrics?

That said, in the short term and as long as the extra load is manageable, I
think we should welcome this experiment as yet another new hidden service
application and see where it takes us. Who knows what kind of use cases might
be created through this!

---

Finally, as grarpamp pointed out, the current onioncat design will fail
horribly once we deploy Next Generation Hidden Services (prop224), which will
happen in the medium-term future (i.e. in a year or two). You should be aware
of this drawback and try to think of ways to make this idea survive in the
future :)

Looking forward to see where this goes!