-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > it is you that are advocating that we abandon a messaging layer > that by your own admission you haven't even looked at?
Rejecting something with cause after actually looking at it makes sense, and is reasonable. You haven't looked at the options, at least not to the degree necessary to understand how they work. I am perfectly fine if there's a reason not to use either Tor or I2P. > simply making ad hominem remarks about how little I do or don't know > about Tor or I2P illuminates nothing other than your poor rhetorical > skills. I'm not saying you suck, I'm saying you're making things up. There's a difference (though people who make things up in tech arguments to make a point suck [there's your ad hominem]). You are saying things which you don't know as if they were true. Those things are also, in fact, false, which would be trivially known if you looked into them. That is why I am calling you on them. > If you want to explain exactly what part of my reasoning is false, > then that might be a useful contribution to the discussion [...] > I have better things to do than trawl through this already tedious > discussion As do I, especially if you're not going to bother to read what I write when I explain things to you. Check the list for an explanation. > Back to the point: Are you denying that Tor ORs are trivially easy > to harvest? Tor > Tor ORs. No, of course, ORs are trivially easy to harvest, but OPs are not. You may have spoken with arma several years ago, but several years is an eon in bleeding edge tech. Things change, new ideas come about, lessons are learned. Its ok not to know things. No one will think less of you if you stop pretending to be up to date. In fact, they'll have more of a reason to believe other things you say. > > * Economics > > That is an equally valid reason why I2P should switch to use our > messaging layer, maybe if you had looked at our messaging layer you > would decide that its a good idea. All things being equal, I agree. However, according to toad, your messaging and transport layer isn't done. I2P's is. The messaging layer has been deployed for the last two years, and the latest transport has been deployed for the past few months. Its had a pretty reasonable number of people breaking it in lots of neat ways. Moving to something which isn't done, which may or may not work for what I2P needs, just doesn't make sense. Even you'll agree with that, right? > > * Risk. > There are 'ifs' in 0.7, as there are in any application that has not > yet been deployed. This is true. Its why people in the business world want COTS instead of custom builds most of the time. Its less risky. Reuse is good. > One thing that isn't an 'if' about I2P is that its harvestable, > which makes it unsuitable for our purposes. I've probably replied to this a dozen times, none of which you seem to have read. I'll just leave it as a "whatever". > > * Anonymity. > > That is a great argument for I2P to adopt our messaging layer, > doesn't really help your argument though. As with the economics point above, I agree in theory. If it was already deployed and was learning from some at least some minor scars, and if it met I2P's needs, it would make sense to consider it. This isn't the case however. I2P's comm layer already works, and has worked for 2 years of end users breaking things in new and interesting ways. (why do I talk about breaking things all the time? because things break, thats reality. its how they get better. If things never start breaking, either the coder is really incredible, or there are demons hiding still) > Freenet 0.7's messaging layer was developed and tested for > another project, Dijjer - and imported into Freenet's code base. > If you knew as much about Freenet 0.7 as you seem to think I > should know about I2P, then you would probably have known that. I did, which is why I said "I did browse through dijjer in the spring when I was designing I2P's though" The "though" at the end there should have been a tip that the statements were related. I'm not sure how field tested dijjer's comm is though, as the project doesn't seem too active (at least, not on the lists publicly available). I do recall reading Toad suggest that he'd have to do a lot of revamp though, and then there's that whole beast of a meta state-machine framework just to avoid threads... > > I did browse through dijjer in the spring when I was > > designing I2P's though, but didn't seem relevent, as the > > interfaces were too tightly coupled to the algorithm. > > I don't see how. Care to provide any specific examples of this? If I remembered every line of code I've ever read, I'd, well, wouldn't be me, anyway. So no, I don't recall offhand a specific LOC, but I remember looking through it to see if I could reuse it. Do you remember a few years back when I was pushing for some changes to Fred's transport layer to support what was then to become I2P? I had to actually go out and implement a stream to messaging transport adapter for you to understand the issue. I know tight coupling when I see it. From my experience explaining such issues to you, you may not see them as rapidly. In any case, Toad and I have been having a fairly productive chat on irc, hopefully we can find some further room for collaboration. =jr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDUC7KWYfZ3rPnHH0RAmhOAJ9MXNKFNJRAX5u2BiNtc1xpNNxF/gCbBR+x tFyvhJNBxNWDhVi6j9CcnXA= =JFS0 -----END PGP SIGNATURE-----
