* Do JMS providers already provide the transports you list? * We already pad messages (well, we pad files anyway) * Currently, we layer an encrypted session over the TCP connection. All messages are therefore encrypted to the destination node. * "Polling HTTP" is insufficient. We need arbitrary other who have been passed our node's address to be able to connect to us. If we cannot receive incoming connections, this is obviously rather difficult and all likely solutions would seem to involve varying degrees of potentially unsafe behaviour, like being easily able to find a node that is connected to the node we want to connect to. * We do not on the whole give a damn about J2EE etc. We use java because we have used java from the beginning, and because it is a reasonable compromize. Is OpenJVM available to other languages that fred might be reimplemented in? * Freenet always uses unicast, because of firstly the fact that that is simply the way the protocol works (read the paper; there are NO broadcast searches in freenet), and because we need to encrypt the connection to the node on the other end. * I am skeptical about dealing with flooding below the level of Fred... * "More storage capacity due to more nodes being able to participate in the network" is probably a negligible effect. * Freenet has pretty high timeouts as it is, but obviously things like email can be even slower. * Messages are already routed based on the node's identity. If the node's IP address changes, we may see it through normal traffic, or we may try to look it up via an Address Resolution Key. * What are these "JMS routers"? Are they a big fat semi-central point of failure, can they be used to detect and connect to all nodes in a given network, do they need to be set up independantly of fred? * Steganography is something that we have always planned to implement via an alternate transport after 1.0. * We also intend to use mixmastered first two hops to reduce the amount that a hostile node can learn about a node from its messages and their Hops-To-Live values, amongst other things. This may be before 1.0. * All messages are already encrypted. * I very much doubt that it will generate many more users. * Additional transports are a post-1.0 thing, but you are welcome to experiment. You will need to maintain a CVS branch for them however since we will not incorporate other transports in 1.0. * "Once FRED supports JMS, it is likely that no other transports will be introduced down the line (other than possibly IPC), as JMS should fill all of those transport needs without need for modifying FRED" - I doubt it, but we will see. * "Configure/extend a JMS provider to breach firewalls, proxies, and NATs" - umm, if the existing JMS code doesn't even do that then I don't see what the point of all this is. * LOL, I remember that roadmap :). It's way out. We have no intention of implementing searching, steganography, streaming, "web of trust", etc, before 1.0. Ignore it. * Safely jumping over NATs that cannot be reconfigured is definitely a post-1.0 issue and may be very difficult, for various reasons, the main one being that we absolutely must be able to accept connections from any node that has obtained our reference. * JMS support will NOT be shipped in Freenet 1.0. You will need to work on a separate branch. * NAT is not that common for end-user machines at the moment. And those who do have it can reconfigure it. There is the problem of detecting the outside address accurately, but this is possible and not too difficult and will be implemented at some point. If you are behind a NAT that you cannot reconfigure, odds are that running a freenet node will be prohibited or dangerous. Freenet will not work in a really hostile environment, because any node will eventually discover a very large number of other nodes. * We already support "silent bob". It is not supposed to be possible to prove that there is a freenet node running, and certainly not to actually talk to it, unless you know the node public key. * We cannot beat an advanced attacker, for the reasons outlined above. We are further down the line that most other networks, but we still have a very, very long way to go. 1.0 will not function effectively in truly hostile environments. * Fred is already fairly modular code. However protecting against attack X is probably very difficult or impossible.
On Sat, Feb 22, 2003 at 08:25:56PM +0000, jrandom wrote: > ev'nin y'all... > > I just felt like being more of a pain in the ass and tossing some more > work on my plate. If you have a moment, please jump on freenet and > over to SSK at yGfgfgDGAMBVyStTGrwGtkrPJ-wPAgM/freenetOverJMS/2// > > Its a proposal for a modification I know some of you will hate or > think is way too much work to fit into the current release schedule > (will the roadmap be coming back? on the old site it was listed from > the old old site [google for > freenetproject.org/oldsite/index.php?page=roadmap]) > Well, if you hate it for reasons *other* than because its too much work, > or if you have any feedback at all, please let me know. > > If it seems familiar, thats because I proposed a similar solution to the > same problem a month or so ago (check the archives for the thread titled > "http/fcp bridge idea" [a poor title, since I was really referring to an > http/fNp bridge]). However, the problem hasn't gone away, and I think > there's a really workable solution in the proposed project. There's a > lot of text in there (and one butt ugly MSPaint diagram), and yes, its > a bit geeky, but I think I cover a lot of questions y'all might have. > > Thanks in advance for any feedback > > -jrandom > > !+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+ > CryptoMail provides free end-to-end message encryption. > http://www.cryptomail.org/ Ensure your right to privacy. > Traditional email messages are not secure. They are sent as > clear-text and thus are readable by anyone with the motivation > to acquire a copy. > !+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+ > > > _______________________________________________ > devl mailing list > devl at freenetproject.org > http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl > -- Matthew Toseland toad at amphibian.dyndns.org/amphibian at users.sourceforge.net Full time freenet hacker. http://freenetproject.org/ Freenet Distribution Node (temporary) at ICTHUS. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20030304/40e6dab9/attachment.pgp>
