On 15/12/13 01:47, Tom Sparks wrote: >> On Sunday, 15 December 2013 12:18 PM, Ximin Luo <[email protected]> wrote: > <snip> >> Hello! Yes, I will be looking into this. Our basic objectives were to make the node do as much of the work as possible, so that it's easy to write a plugin, while still allowing a wide range of plugin implementations. So the API was pretty minimal, with the intention that registration-time flags and multiple interfaces could allow plugin authors to implement e.g. flow control if they want to. > <snip> >> Of course, Freenet is datagram-based. However, in the long term, Tor also >> wants >> to support a datagram-based underlying protocol, at which point they will >> need >> PTs to also support datagram-based traffic. >> > DTN is not datagram-based but bundle based (think of mine email / epub) If you can get funding for sorting out transport plugins that'd be great. There's lots to do, there's a range of possibilities from simple fake packet headers and streams through to emulating full protocols, encapsulating data in part of a real stream, transport-determined/steganographic timing/bandwidth (including opportunistic data transfer to make efficient use of this), and so on. Some of this is also required for DTN.
There are plans for DTN but it's a rather longer term project IMHO. It will require some fairly radical design work, notably full pub/sub support and probably some sort of long term requests; it may require a new database, better darknet support etc. Some of that will require finishing some important core changes. Also, there are different kinds of DTN: - I have a slow but realtime connection, and I can also exchange large amounts of data once a day via USB keys / phone rendezvous. (Easiest to support) - I have an intermittent realtime connection (e.g. because of steganographic requirements). - I can *only* exchange data via USB keys. For the last case, I am not necessarily opposed to implementing it in Freenet, but there are important theoretical issues to deal with e.g. how to assign locations, and the tradeoffs may be different to those that Freenet assumes. Generally the view is that high-latency means publish/subscribe or non-scalable broadcast based architectures (like Haggle). I'm not entirely convinced of that; IMHO long-term requests are possible, and may be useful (though pub/sub is of course crucial). But I haven't looked into what other people are doing in depth. Haggle implements this in an "opennet" manner, i.e. equivalent to asking around on a bus who has a copy of a particular subversive document. IMHO Freenet should stick to darknet. Clearly nobody is going to fund us to reimplement Haggle (Serval/Rhizome is also worth looking into, it looks like their site is down at the moment), but we may be able to build something which is more appropriate for some use cases. > The best outcome would be if we can unify Freenet transport plugins and Tor > pluggable transports, so that both projects can benefit from the shared > research that has already been done. Definitely worth investigating, there is probably stuff we can do together in spite of e.g. language barriers. E.g. maybe a common API for external plugins; most plugins probably won't be written in Java. > :) > <snip> >> Tom, it would be very very useful if you could tell me how much funding you >> have available to sink into this effort, and any logistics / paperwork-type >> information. You can send this to me by private e-mail if you so wish. > I do not have the funds yet, > as I am in research and pre-proof-of-concept stage > i'll hopefully be getting the funds next year when I go into proof-of-concept > stage :) >> Ximin
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
