Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
There is code for transport plugins from GSoC 2012 (thanks to chetan), but there are still problems which keep it from getting merged
If you want to help finishing transport plugins, please get in touch!
In future we would like Freenet to be able to run over TCP, because UDP may not be available.
We would also like it to be able to run over HTTP, in order to jump over application-layer-only firewalls.
And we would like to be able to disguise Freenet traffic as something else.
Voice over IP (possibly parasitic), streaming (e.g. RTP, but we'd want to mimic a specific application e.g. RealPlayer), HTTP, bunnycams, VPN, etc are all of interest. This would mean that traffic flow analysis is the only way to identify Freenet traffic.
In the long term, it should be possible to run Freenet over high latency steganographic transports.
This will take a fair amount of work.
It should be as easy as reasonably possible to create a transport plugin, the node should do as much as possible of the hard work. Hence we will need a new set of crypto protocols for link setup and packing, unpacking and authenticating messages on a stream-based transport (e.g. TCP); for stream-based transports, we will need support for much smaller packets (see e.g. message level streams) and the ability to turn off retransmission when registering a packet-based transport plugin (at which point we would also specify acceptable packet size and probably likely latency as well). We will also need the ability to deal with multiple connections between two nodes, and various other things.
This was planned for post-1.0, but its wild popularity on uservoice suggests quite a number of users need it to get through nasty firewalls.
Tor has an equivalent mechanism documented here.