++There are a handful of cryptographic algorithms in use within I2P, but we have +reduced them to a bare minimum to deal with our needs - one symmetric algorithm +one asymmetric algorithm, one signing algorithm, and one hashing algorithm. However, +we do combine them in some particular ways to provide message integrity (rather than +relying on a MAC). In addition, as much as we hate doing anything new in regards to +cryptography, we can't seem to find a reference discussing (or even naming) the +technique used in I2P/ElGamalAESSessionTag (but we're sure others have done it). +
+
+We use common primes for 2048 ElGamal? encryption and decryption, and we currently only +use ElGamal? to encrypt the IV and session key in a single block, followed by the +AES encrypted payload using that key and IV. Specifically, the unencrypted ElGamal? +block is formatted (in network byte order): +
+
+
+ |_______1_______2_______3_______4_______5_______6_______7_______8 + |nonzero|H(data) + | + | + | + | | data ... | + ++
+The H(data) is the SHA256 of the data that is encrypted in the ElGamal? block, +and is preceeded by a random nonzero byte. The data encrypted in the block +can be up to 222 bytes long. Specifically, see +[the code]. +
+ElGamal? is never used on its own in I2P, but instead always as part of +I2P/ElGamalAESSessionTag. +
+The shared prime is the + +[Oakley prime for 2048bit keys] +
+ 2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 }
+
++Using 2 as the generator. +
+
+We use 256bit AES in CBC mode with PKCS#5 padding for 16 byte blocks (aka each block is end +padded with the number of pad bytes). Speficially, see +[the CBC code] +and the Cryptix AES + +[implementation] +
+For situations where we stream AES data, we still use the same algorithm, as implemented in +[AESOutputStream] +[AESInputStream] +
+For situations where we know the size of the data to be sent, we AES encrypt the following: +
+
+ |_______1_______2_______3_______4_______5_______6_______7_______8 + |H(data)| size of data (in bytes) | data ... | rand | ++
+After the data comes an application specified number of randomly generated padding bytes, and +this entire segment (from H(data) through the end of the random bytes) is AES encrypted +(256bit CBC w/ PKCS#5). + +
+This code is implemented in the safeEncrypt and safeDecrypt methods of +[AESEngine] +
+
+Signatures are generated and verified with 1024bit DSA, as implemented in +[DSAEngine] +
+
+ +
+ 86108236b8526e296e923a4015b4282845b572cc ++
+ 33 ++
+
+
+ 9C05B2AA 960D9B97 B8931963 C9CC9E8C 3026E9B8 ED92FAD0 + A69CC886 D5BF8015 FCADAE31 A0AD18FA B3F01B00 A358DE23 + 7655C496 4AFAA2B3 37E96AD3 16B9FB1C C564B5AE C5B69A9F + F6C3E454 8707FEF8 503D91DD 8602E867 E6D35D22 35C1869C + E2479C3B 9D5401DE 04E0727F B33D6511 285D4CF2 9538D9E3 + B6051F5B 22CC1C93 ++
+
+
+ A5DFC28F EF4CA1E2 86744CD8 EED9D29D 684046B7 ++
+
+
+ C1F4D27D 40093B42 9E962D72 23824E0B BC47E7C8 32A39236 + FC683AF8 48895810 75FF9082 ED32353D 4374D730 1CDA1D23 + C431F469 8599DDA0 2451824F F3697525 93647CC3 DDC197DE + 985E43D1 36CDCFC6 BD5409CD 2F450821 142A5E6F 8EB1C3AB + 5D0484B8 129FCF17 BCE4F7F3 3321C3CB 3DBB14A9 05E7B2B3 + E93BE470 8CBCC82 ++
+
+Hashes within I2P are plain old SHA256, as implemented in +[SHA256Generator] +
+
+TCP connections are currently negotiated with a 2048 Diffie-Hellman implementation, +using the router's identity to proceed with a station to station agreement, followed by +some encrypted protocol specific fields, with all subsequent data encrypted with AES +(as above). Down the line, we will want to use session tags like we do with +I2P/ElGamalAESSessionTag to avoid the 2048bit DH negotiation. +
+We would like to migrate to a more standardized implementation (TLS/SSL or even SSH), but: +
+
+The basic TCP connection algorithm is implemented in establishConnection() (which calls +exchangeKey() and identifyStationToStation?()) in +[TCPConnection] +
+However, this is extended by +[RestrictiveTCPConnection] +which updates the establishConnection() method to validate the protocol version, the time, and +the peer's publicly reachable addresses (since we don't support restricted routes yet, we +refuse to talk to those who other people can't talk to as well). \ No newline at end of file diff --git a/pages/how_garlicrouting.html b/pages/how_garlicrouting.html new file mode 100644 index 00000000..17c90bcc --- /dev/null +++ b/pages/how_garlicrouting.html @@ -0,0 +1,51 @@ +
+As briefly explained on the I2P/Overview, in addition to sending +messages through tunnels (via I2P/Tunnel), I2P uses a technique called +"garlic routing" - layered encryption of messages, passing through routers +selected by the original sender. This is similar to the way Mixmaster +(see I2P/OtherEfforts) sends messages - taking a message, encrypting it +to the recipient's public key, taking that encrypted message and encrypting +it (along with instructions specifying the next hop), and then taking that +resulting encrypted message and so on, until it has one layer of encryption +per hop along the path. The only significant difference between that technique +and I2P's garlic routing is that at each layer, any number of messages can be +contained, instead of just a single message. + +
+
+
+In addition to the cloves, each unwrapped garlic message contains a sender +specified amount of padding data, allowing the sender to take active countermeasures +against traffic analysis. +
+
+I2P uses garlic routing in three places: +
+There are also significant ways that this technique can be used to improve the performance of the network, exploiting transport latency/throughput tradeoffs, and branching data through redundant paths to increase reliability. +
+
+The encryption of each layer in the garlic message uses the ElGamal?/AES+SessionTag? algorithm +(as outlined at I2P/ElGamalAESSessionTag), which avoids the cost of a full 2048bit ElGamal? + +encryption for subsequent messages (using instead a random previously specified SessionTag? plus +256bit AES encryption). +
+
+The term garlic routing was first coined by Michael Freedman in Roger Dingledine's freehaven +[masters thesis], which was derived from +[Onion Routing]. The main difference with I2P's garlic routing +is that the path is unidirectional - there is no "turning point" as seen in onion routing +or mixmaster reply blocks, which greatly simplifies the algorithm and allows for more flexible +and reliable delivery. \ No newline at end of file diff --git a/pages/how_networkdatabase.html b/pages/how_networkdatabase.html new file mode 100644 index 00000000..f00120c8 --- /dev/null +++ b/pages/how_networkdatabase.html @@ -0,0 +1 @@ +[not yet written overview of the I2P network database, old content at http://wiki.invisiblenet.net/iip-wiki?NetworkDb] \ No newline at end of file diff --git a/pages/how_tunnelrouting.html b/pages/how_tunnelrouting.html new file mode 100644 index 00000000..afc560f7 --- /dev/null +++ b/pages/how_tunnelrouting.html @@ -0,0 +1,165 @@ +
+As briefly explained on the I2P/Overview, I2P builds virtual "tunnels" - +temporary and unidirectional paths through a sequence of routers. These +tunnels can be categorized as either inbound tunnels (where everything +given to it goes towards the creator of the tunnel) and outbound tunnels +(where the tunnel creator shoves messages away from them). When Alice +wants to send a message to Bob, she will (typically) send it out one of +her existing outbound tunnels with instructions for that tunnel's endpoint +to forward it to the gateway router for one of Bob's current inbound +tunnels, which in turn passes it to Bob. +
+
+
+ +
+
+
+
+
+
+
+Routers performing the three roles (gateway, endpoint, participant) are given different pieces of data to accomplish their tasks: +
+
+
+
+In addition, there are a series of options that the creator of a tunnel sends when requesting a router +to join a tunnel, such as the expiration date. In I2P 3.0, options specifying the pooling, mixing, and chaff +generation settings will be honored, and limits on the quantity and size of messages allowed during the tunnel's +lifetime will be implemented earlier (e.g. no more than 300 messages or 1MB per minute). +
+
+ +As mentioned above, each client requests that their router provide tunnels to include at least +a certain number of hops (plus other criteria that aren't honored yet, such as bandwidth limits, etc). +The decision as to how many routers to have in one's outbound and inbound tunnels has an important +effect upon the latency, throughput, reliabilty, and anonymity provided by I2P - the more peers that +messages have to go through, the longer it takes to get there and the more likely that one of those +routers will fail prematurely. The less routers in a tunnel, the easier it is for an adversary to +mount traffic analysis attacks and pierce someone's anonymity. +
+
+With no remote routers in a tunnel, the user has very basic plausible deniability (since no one knows +for sure that the peer that sent them the message wasn't simply just forwarding it on as part of the tunnel). +However, it would be fairly easy to mount a statistical analysis attack and notice that messages targetting +a specific destination are always sent through a single gateway. Statistical analysis against outbound 0-hop +tunnels are more complex, but could show similar information (though would be slightly harder to mount) +
+
+With only one remote router in a tunnel, the user has both plausible deniability and basic anonymity, as long +as they are not up against an internal adversary (as described on I2P/ThreatModel). However, if the adversary +ran a sufficient number of routers such that the single remote router in the tunnel is often one of those +compromised ones, they would be able to mount the above statistical traffic analysis attack. +
+
+With two or more remote routers in a tunnel, the costs of mouting the traffic analysis attack increases, since +all remote routers would have to be compromised to mount it. +
+The router will by default use 2-hop tunnels, at least in the main distribution. Prior to the 0.2.5 release, +all tunnels are 1-hop by default. +
+
+[explain tunnel pools, how we keep a free inbound pool, an outbound pool, and a client inbound pool, and how the +pools are refreshed every minute or so, using the router's default settings] +
+
+All tunnels are periodically tested by their creator by sending a DeliveryStatusMessage? out the tunnel and bound +for another inbound tunnel (testing both tunnels at once). If either fails, both are marked as no longer functional, +and if they were used for a client's inbound tunnel, a new leaseSet is created. Other techniques can be used to test +tunnels later on, such as garlic wrapping a number of tests into cloves, testing individual tunnel participants +seperately (and using the tunnel configuration key to update the next hop to work around failures), etc, but that is +not implemented at the moment. +
+
+Tunnel creation is handled by garlic routing (see I2P/GarlicRouting) a TunnelCreateMessage? to a router, +requesting that they participate in the tunnel (providing them with all of the appropriate information, as above, +along with a certificate, which right now is a 'null' cert, but will support hashcash or other non-free certificates +when necessary). The message also includes a SourceRouteReplyBlock?, which allows the router to encrypt their +TunnelCreateStatusMessage? into a SourceRouteReplyMessage?, which is sent to another router (specified in the +SourceRouteReplyBlock?), who then decrypts the rest of the SourceRouteReplyBlock?, reads out the delivery instructions +contained therein, and forwards the TunnelCreateStatusMessage? accordingly. (the delivery instructions can specify +delivery to a specific router or can point at a tunnel) + +
+
+
+--> You are now talking on #iip-dev +--- Topic for #iip-dev is IIP Meeting - logfiles: + http://wiki.invisiblenet.net/?Meetings - http://www.invisiblenet.net/research/ +<al-jebr> it's 21:13 +<-- wilde has quit (Ping timeout) +--- Trent@anon.iip gives channel operator status to UserX +<nop> ok +<qriff> !time +<Ambience> al-jebr: 00:21 here +<nop> I believe everyone has settled +<hezekiah> Let's go. :) +<jrand0m> 11:06 here +<nop> let's start +<nop> anyone get my agenda +<nop> so they can play it back +<nop> I forgot the order +<-- leenookx has quit (Ping timeout) +<Ambience> my clock is 15 minutes ahead :) +--> hifi (~MetroPipe@anon.iip) has joined #iip-dev +<hezekiah> <nop> on the agenda +<hezekiah> <nop> 1) Welcome +<hezekiah> <nop> 2)Our Goodbyes +<hezekiah> <nop> 3)IIP development now +<hezekiah> <nop> 4) IIP development restructuring proposal +<qriff> actually its xx:13 everywhere... +<hezekiah> <nop> 5) Recruiting for services to aid with IIP +<hezekiah> <-- Delly has quit (Ping timeout) +<hezekiah> <nop> 6) comments suggestions and people who want to help +<mids> 23:05:28 <@nop> 1) Welcome +<mids> 23:05:38 <@nop> 2)Our Goodbyes +<mids> 23:05:43 <@nop> 3)IIP development now +<mids> 23:05:56 <@nop> 4) IIP development restructuring proposal +<mids> 23:06:16 <@nop> 5) Recruiting for services to aid with IIP +<mids> 23:06:53 <@nop> 6) comments suggestions and people who want to help +<nop> wow, flood in here ;) +<nop> pl +<LeerokLacerta> Out goodbyes? +<hezekiah> lol +<hifi> TROLLS !!! +<nop> Ok, welcome all +<nop> let's settle down now :) +<hifi> . +<Ambience> settled +--> wilde (~anon@anon.iip) has joined #iip-dev +<hifi> settled +<al-jebr> anyone logging? +--> thecrypto (~thecrypto@anon.iip) has joined #iip-dev +<hezekiah> I am (sort of). +<luckypunk> mids should be. +* jrand0m logs at all times +<al-jebr> let's go! +<nop> ok +<hezekiah> nop: Agenda item number 2? +<nop> Our goodbyes +<LeerokLacerta> Bye! +<thecrypto> where is the livelog? +<nop> Ok, mids has come to a point where he is moving to other projects +--> Phiberoptika (~none@anon.iip) has joined #iip-dev +<mids> After having worked for IIP for more than I year now, I have decided to + resign as IIP developer. +<LeerokLacerta> Awww. +<mids> It has been fun and an educative experience +<mids> but it is time to move on, refresh the spirit and shuffle the cards. +<Rain> Will you still be online/around? +<mids> I'll keep running Trent as long as needed and possible. +<mids> Yes, I do plan to stay around as user +--> ntk (~blob@anon.iip) has joined #iip-dev +* nop is in the corner sobbing +<nop> oh, ah hem +<jrand0m> many thanks mids, iip w/out trent would be a pita +<LeerokLacerta> It's so sad. +<nop> yes +<nop> thank you mids for all your workup +<nop> work +<mids> Although I'll be off on vacation soon :) +<mids> . +--- mids removes channel operator status from mids +<luckypunk> :D +<luckypunk> Seem's like you've done a great job. :) +<Rain> ..how symbolic.. +<nop> we love you mids!!! +<nop> you hear that +<nop> that was my window opening +<thecrypto> we all do! +<nop> fan base out there +--> w (~w@anon.iip) has joined #iip-dev +--- nop is now known as we +<luckypunk> lol, yep. +<luckypunk> :D +* we love you mids +<Rain> Go mids go! +<jrand0m> rofl +--> leenookx (~leenookx@anon.iip) has joined #iip-dev +--- LeerokLacerta has changed the topic to: IIP Meeting - logfiles: + http://wiki.invisiblenet.net/?Meetings - http://www.invisiblenet.net/research/ + | We love you mids! +<Rain> weeeeee are the chaaaampins, my frieeeennnndd... +<Neo> yes mids, thanks for all your input, collaboration and hard work in code + and doing general developer things for IIP. +--- we is now known as nop +* mids bows +* Ehud stands up and gives a standing ovation to the commitment, perseverence, + effort, and good hard code that mids has given the project. +<hifi> yeah mids take your toys and go to tigertown lol +<nop> and don't forget the PR and web management +<nop> he's been a vital aspect to IIP +<nop> getting it this far would have been hard without his work +--> ChZEROHag (hag@anon.iip) has joined #iip-dev +<hifi> hifi bitches with mids over trolling issue +<-- hezekiah has quit (Ping timeout) +<mids> heh hifi +--> hezekiah (~hezekiah@anon.iip) has joined #iip-dev +--- Trent@anon.iip gives channel operator status to hezekiah +<hezekiah> Back. :) +<luckypunk> Yay. +<hezekiah> (And in case anyone doubted, Hezekiah == Ehud.) +<hifi> i never used frucking trent and don't know what mids did . i only troll . +<nop> obviously your hezekiah@anon.iip gave it away +<-- Ehud has quit (Ping timeout) +<hezekiah> Ugh +<hezekiah> Item number 3? +<hezekiah> (If we're all done sobbing yet ...) +<hifi> and i never was pingouted in my life . I am the most disciplined user of + IIP . +<mids> 3)IIP development now +<luckypunk> heh +<luckypunk> Ok everyone! Shhh. Back on track! +<hifi> BUT I CRY that MIDS GO !!! +<hifi> ok +<hifi> . +<luckypunk> IIP development. Whats the current status of that code snapshot + release? +<luckypunk> That was supposed to happen today? +<hezekiah> Well, unless UserX has an objection to the tarball I made, + it's done. +<luckypunk> Ok. Post it on the wiki? +<hezekiah> UserX? Were there any problems with the tarball? +<UserX> no problems with the tarball +<luckypunk> Yes, but are there any windows compilations? +<hezekiah> OK1 +<hezekiah> http://invisiblenet.net/hezekiah +<hezekiah> Get your tarballs there! +<UserX> there hasn't been a windows compilation on the windows version yet +<luckypunk> hm +<LeerokLacerta> "tarballs" sound like some sort of food... +* luckypunk will try and make one. +--- hezekiah has changed the topic to: IIP Meeting - logfiles: + http://wiki.invisiblenet.net/?Meetings - http://www.invisiblenet.net/research/ +- tarballs of the 'unstable' development release are at + http://invisiblenet.net/hezekiah | We love you mids! +<luckypunk> They are. For GCC. +<luckypunk> lol +<Rain> Sticky food. +<hezekiah> There is one 'documented bug'. +<nop> I can compile a win32 version if you'd like +<Rain> So, could you give a quick describtion of what is new in this release? +<hezekiah> If you run isproxy, and it fails to bind the port, then it will + /not/ abort. It will just sit there wasting memory. +<hezekiah> Rain: That's too much for me to handle (not to mention I don't + even _know_ all the differences). +<Ambience> this one I assume: iip-1.2-dev1.tar.bz2 01-Jul-2003 01:45 + 292k tar archive ? +<hezekiah> UserX could give a much better description +<hezekiah> UserX? +<nop> hezekiah/UserX can we get a changelog of the differences by chance +<nop> that may be a day before that gets done +<hezekiah> Ambience: Yup! Or the Gziped one. There the same tarball. +<nop> because there are a log of changes +<Rain> Oh, and has the expired IIP signing-key been replaced? +<Ambience> hezekiah: ok +<hezekiah> nop: I joined IIP after the development branch was already in + progress. +--> Ehud (~hezekiah@anon.iip) has joined #iip-dev +<hezekiah> Rain: No. I had to use my GPG key. +<nop> no one has tested the compile of this dev branch in win32 have they? +<luckypunk> Hey, is this src is CVS? +<hezekiah> Rain: I couldn't contact anyone who had the IIP release key. +<hezekiah> luckypunk: Yes. +* luckypunk has, but his system didn't work for it. +<Rain> hezekiah: Ok, roger. +<UserX> changes: multi-threading, bignum support via openSSL or GMP, numerous + inmprovements to the memory management system +<hezekiah> luckypunk: Right now that tarball is a copy of what you get when + you check out the hezekiah-dev branch from CVS and run 'make dist-bzip2'. +<luckypunk> Gah! I hate windows. +<Rain> UserX: niceties ;) +<hezekiah> And of course there are other internal changes that only the + developers see. :) +<qriff> just as a question for the qurious... what defines the holder for "Trent"... +<hezekiah> One simple thing is that now that BigNum is implemented using + either GMP or SSL, login is a LOT faster. +<Rain> May i mention a IIP quirk i noticed earlier today? +* luckypunk guesses its a yes. +<hifi> at wiki search button is absent . only window to type in but nowhere to + click lol . +<luckypunk> hit enter. +<qriff> and what about channel/nick expiration... +--- Ehud is now known as logger +<qriff> registration that is... +<Rain> Ok, it seems to me like you cannot start isproxy from a /path/to/isproxy + command, but intead have to do a cd /path/to and then do a ./isproxy +<hezekiah> Rain: Let me guess ... you get a configuration screen or a request + for entropy, right? +* jrand0m has a feeling this will be a very.long.meeting +<Rain> Is that intentional, or just some quirk of my local system? +<Rain> hezekiah: yes. +<hezekiah> Rain: You need to make a .iip subdirectory in your home directory. +<Rain> It claims that the conf-file is not found. +<Rain> with my .conf file? +<hezekiah> Rain: If no such directory exists, isproxy will always look for + the config files in the current directory +--> AmishOne (amishone@anon.iip) has joined #iip-dev +<Rain> Ahh. Of course. +<hezekiah> OK ... +<hezekiah> nop? Was there anything else for item 3? +<nop> have we tested it for win32 +<nop> compile wise +<hezekiah> I haven't. +<nop> UserX: ? +<UserX> no +<nop> I will test it this week then +<hezekiah> luckypunk, tried doing hezekiah-dev recently and complained for + compile errors. +<nop> that's key to maintain portability +<hezekiah> I suspect there might be problems. +* luckypunk tried, it balked. +<hezekiah> Yup. There are problems. +<Ambience> I'll have to leave for the more dominant one is ordering me to + and I have no choice here. So I'll be off to bed, but will be logging #iip-dev + for future reference. +<Ambience> see ya guys! +<lonelynerd> later +<qriff> bye +<hezekiah> Bye, Ambience. :) +<luckypunk> i'll be back. +<Ambience> <--gone (log on) +<nop> ok +<nop> this topic is done +<nop> next on agenda +<nop> what's 4? +<hezekiah> 4) IIP development restructuring proposal +<nop> ok +<nop> we had a meeting about a discussion and proposal brought to us by jrand0m + for the future development +<nop> and as well +<nop> I have had a lot of privmessages directed at me +<nop> for requests to focus on an arbitrary framework, instead of IRC specific +<nop> aka a framework that supports IRC + a whole lot more +<nop> so the want is obviously there +<nop> and the developers definitely want to go there as well +<hezekiah> Amen! +<nop> the question of how to go about doing it +<nop> and how to make the most productive use of our developers +<nop> is up in the air +<ChZEROHag> XML +<mids> is his framework site available to everybody? +<nop> this isn't specifically about language +<ChZEROHag> create a communications protocol +<nop> ok, please let me finish +<ChZEROHag> I've started on that somewhere... +<nop> then we can comment +<ChZEROHag> My apologies +<ChZEROHag> I'm a bit in and out at the moment +<nop> ok, +<nop> no prob +<nop> We are at a stage where there is discussion of an arbitrary communications + protocol +<nop> specifically for anonymous and secure communication +<nop> at this point jrand0m, any chance we can post the logs of #iip-future + meeting +<jrand0m> sure +<jrand0m> perhaps those zips I sent you so people don't have to struggle + through freenet for the other pages too +<nop> ok +<nop> hold +<nop> please +<jrand0m> (btw, the logs were unedited, so expect the usual occational banter) +<hezekiah> lol. Yup! You'll get to see exactly how much I DON'T know about + p2p networks! lol +<jrand0m> heh +<hezekiah> (And they'll probably have my conspiracy theories about nop + too! So be sure to read the logs! ;-) ) +<-- logger has quit (Ping timeout) +<hezekiah> Ugh +<nop> ok +<Neo> the logs will be a lot to read. can someone summarizze for the meeting + what was covered and some key points of all this? +<nop> http://office.invisiblenet.net/iip_future.zip +<nop> and +<hezekiah> At this point, the 'stable' release is being more unstable than + the 'unstable' one!! Urg. +<nop> http://office.invisiblenet.net/meetingPrepnotes.zip +<nop> http://office.invisiblenet.net/jrand0mnetwork_protocol.txt +<jrand0m> meetingPrepnotes.zip is a small doc that summarizes the meeting, + and the meeting was basically "ok, any thoughts?". +<-- Delly has quit (EOF From client) +<jrand0m> essentially, the proposal is to get going on a generic secure + anonymous message based system, and run iip on top of that +<mids> is there a zip with anonCommFramework too? +<nop> I didn't see that +<nop> jrand0m can you zip and send I'll post to site +<jrand0m> sure, h/o +<-- Phiberoptika has quit (* ciaito mua mua *) +<Neo> what is anonCommFramework? +<jrand0m> uber-quick summary of the meeting in iip_future.zip is "ok, + here's the proposal, any comments?" and comments were basically "ok, can IIP work + as planned on this? +<jrand0m> if you're on freenet, anonCommFramework is at + SSK@MQNd5lT-X5wHA4vONvtVadi6q1IPAgM/anonCommFramework/2// +* jrand0m is sending nop a zip of that momentarily +<Rain> Did you discuss support for PGP-based nyms? +<nop> ah hem, this is early discussions +<-- ChZEROHag has quit (Ping timeout) +<jrand0m> no, endpoints in the framework are not nym based, they're idents +<Rain> Right. So nyms an higher level. +<Rain> are +<jrand0m> (and for lots of reasons, they shouldn't be long term idents + like nyms) +<jrand0m> yes +<Rain> I was just thinking of something like trent with PGP signarute auth. +<mids> trent is central +<mids> central=bad +--> logger (~hezekiah@anon.iip) has joined #iip-dev +<jrand0m> briefly, anonCommFramework is a meta-network. a generic set + of protocols & structures that an anonymous communication network could use to + interoperate to provide militant grade anonymity +<wilde> what's the one sentence explanation of your ideas on network topology? +--> ChZEROHag (~hag@anon.iip) has joined #iip-dev +<ChZEROHag> that was fun +--> Delly (dedede@anon.iip) has joined #iip-dev +<Rain> mids: Yea. I meant similar services. +<lonelynerd> what about having to pay with hashcash to send data? couldn't + that help against flooding? +<jrand0m> wilde> heterogeneous. no one answer solves all problems. + interoperate, balancing latency, bandwidth, anonymity, and reliability to provide + the user's needs +<Delly> still in 4) ? +<hezekiah> Delly: Yup +<Delly> thx +<ChZEROHag> I think when the ircd is removed from the equation, we'll have + far better options than (hash|think|real)cash +<nop> jrand0m: any luck sending +<nop> ;) +<jrand0m> uploading to hush now. +<jrand0m> ChZEROHag> anonCommFramework has built in support for providing + network use authorization credentials +<Rain> There has been a lot of talk of IIP-Freenet interoparability. Will that + fit into the framework, or are we talking application-level again? +<ChZEROHag> come again? +<jrand0m> app level +<jrand0m> what we're discussing is splitting iip into two parts - the irc + part, and the message based secure anonymous network +<wilde> one solution could be: +<Rain> jrand0m: k. +<wilde> Application <-> SOCKS5 Proxy Interface <-> Onion Wrapper <-> Onion Router + 1 <-> ... <-> Onion Router N <-> Exit Relay <-> Public Server +<jrand0m> building a DHT on top of the message layer should be fairly easy +<hezekiah> DHT? +<jrand0m> distributed hash table +<jrand0m> (ala freenet) +<nop> ok, jrand0m let me clarify +<ChZEROHag> wilde: I think the plan is to design it such that the 'public + server' could be removed from the equation at some point +<nop> are we talking about splitting irc, or merging to focus on anonymity + framework +<jrand0m> well, given unlimited # of developers, splitting and doing both + (well, 3 things ;) in parallel. +<nop> what I mean is that the irc part is application layer +<jrand0m> given reality, there's prolly only enough dev time to get the + comm system running first, then iip on top +<jrand0m> right exactly +<nop> and since we have a somewhat viable network working with IIP +<jrand0m> irc is just another app running on it +<nop> then the idea should be +<nop> is to have developers start focusing on framework aspects +<wilde> ChZEROHag: ok, what I suggested is an anonymizing layer for regular + internet traffic, not a seperate network +<hezekiah> (This could get fun.) +<nop> wilde there are weaknesses to that +<nop> just to let you know +<nop> aka the clear text on the outer ends +<-- AmishOne has quit (EOF From client) +<wilde> nop: yes, so all connections should be encrypted to the ends +<nop> we have an effort as well to have anonymous web browsing possible with + this network +<jrand0m> yes. it must be able to operate without ever leaving the mixnet +<nop> but it is not as real time direct as your proposal wilde +<nop> it uses some time delay tactics +<nop> with caching etc +<nop> timing attacks are a serious threat to anonymity +<hifi> I WANT ANONYMISER BASED on IIP !! I DON"t TRUST OTHER ANONYSERS THEY ARE + FBI TRAPs !! +<mids> http://mids.student.utwente.nl/~mids/anonCommFramework/ +<nop> hifi, this isn't changing IIP, this is moving us forward +<nop> thanks mids +<jrand0m> heh word mids, my moz is hanging +<nop> ok +<wilde> although independant mixnets are cool, the real killer apps will probably + be general ip traffic anonymizers +<nop> wilde, they are myths +<wilde> killer apps? +<nop> no +<-- thetower has quit (EOF From client) +<jrand0m> wilde> that could be a service built on top of the comm layer +<nop> general ip traffic anonymizers +<wilde> or ip traffic anonymizers? +<nop> so far they don't exist +<nop> they exist in papers only +--> thetower (none@anon.iip) has joined #iip-dev +<jrand0m> if you build an anonymizing service on top of the comm layer, + however, your outbound routers will get shut down quickly +<thetower> Haha, I just noticed I wasn't port forwarding. +<thetower> Oop, sorry, wrong chan +<wilde> nop: what about the ZKS system? +<nop> is it still around? +<nop> and working +<wilde> nope, bad business +<wilde> few people paid +<wilde> but the framework seemed to work, but all nodes were ZKS:s paid relays +<nop> wilde but they were internal and it wasn't complete +<nop> it still had certain vulnerabilities +<nop> it was a start +<nop> I met Ian Goldberg at CodeCon 2k2, and he himself admitted it was incomplete + to what he desired +<wilde> yes, everything has vulnerabilities, we just raise the cost of tracing + dramatically +<jrand0m> right, after the mixnet is up and running, i'd like to see wilde + offer generic outbound proxy services. that'd be cool +<jrand0m> (sincerely) +<nop> jrand0m: but again the ultimate would be using that magic mirror concept + for optimum protection +<ChZEROHag> Probably the hardest option, but wouldn't freenet be a good + framework to build from? +<nop> wilde, maybe you and I can discuss this in another forum at some point +<jrand0m> but in any case, the network must be built first +<ChZEROHag> Or is that not what we're discussing? +<jrand0m> ChZEROHag> no. +<jrand0m> freenet doesn't provide hard anonymity +<ChZEROHag> aah +<ChZEROHag> I should try paying attention +<nop> ok, moving forward +<nop> UserX you still here +<wilde> nop: yes, if you have decided on topology there is no need to discuss + this in public +<UserX> I'm still here +<nop> well it's application layer, so that comes after net design etc +<nop> ok +<nop> where did we leave off at #iip-future meeting +<-- hezekiah has quit (Ping timeout) +<nop> let's start there +--- logger is now known as Ehud +* nop is catching up on the meeting logs +<jrand0m> [04:31] <jrand0m> I think we're back to your question. can / + should the irc functionality move forward as its going or move towards this mixnet. + there are significant benefits to move towards the mixnet, but some aspects of + the irc side seem to require some redesign to operate on it. +<jrand0m> [04:31] <jrand0m> the right way for the irc development to go is + not for me to say +<Ehud> Basically, UserX had some thinking to do about wether IIP could run + satisfactorily on the mixnet. +<mids> nite all +<-- mids (mids@anon.iip) has left #iip-dev (mids) +<ChZEROHag> Would it not be an idea to create a replacement irc in parallel + with a mixnet? +<ChZEROHag> After all it's going to be damn hard to use a normal ircd +<jrand0m> ChZEROHag> given infinite # devs, yes +<nop> ok ChZEROHag silence please :) +<ChZEROHag> Assume infinite devs +<ChZEROHag> Oh is this not a question bit? +--> hezekiah (hezekiah@anon.iip) has joined #iip-dev +<nop> not yet +<UserX> Unfortuantlely I haven't had time to seriously sit down and think about + how your proposal would fit in with IIP +<ChZEROHag> oh +<ChZEROHag> oops +<nop> just want to get into the discussion +<nop> well +<jrand0m> UserX> think of the mixnet as a socket +<nop> let me suggest something +<nop> do we agree that our goal is not just IRC ? +<lonelynerd> well +<Delly> it's a great idea sure +<hezekiah> nop: Beyond all doubts, I agree that the goal is an anonymous + network. +<lonelynerd> doing something traffic-intensive would have the potential to + ruin the whole project +<hezekiah> nop: IRC is just a starting point. +<nop> ok, well what we should look at is this +<jrand0m> NOT doing something traffic intensive has the potential to get + us to overlook problems :) +<nop> instead of saying IIP doesn't fit +<nop> or it does fit +<nop> let's look at what modifications need to be made for irc to fit with this + mixnet, whether it's a mod to the mixnet itself +<lonelynerd> jrand0m: hmm +<nop> for instance +<nop> UserX has a vision of using channels as endpoints +<nop> Jrand0m calls them idents +<nop> are they having subtle differences +<nop> or are they largely different +<jrand0m> there's substance to those differences. +<nop> can we review that +<nop> on both sides +<nop> from jrand0m and UserX +<-- hezekiah has quit (EOF From client) +<nop> actually +<nop> read the log +<nop> nevermind +<jrand0m> ;) +--> hezekiah (hezekiah@anon.iip) has joined #iip-dev +<jrand0m> the hesitancy I have w/ sending messages to a channel ident and + having that channel redistribute it to members is that the channel gets plaintext +<nop> how does it get plaintext? +<jrand0m> instead, I'd suggest having a channel contain just the channel info + (modes, users, topic, etc) +<jrand0m> the channel is just an application running on one (well, 3+) + routers listening to one (well, 3+) identities. when you /msg a channel, you + send a message to that identity (application). it then resends it out to the N + users in the channel, encrypted to each +<nop> well +<nop> I had a proposal for that +<nop> that would have the channel not contain plaintext +<nop> directly +<jrand0m> at least, without adding a channel key (which would be managed + by the channel application itself, which defeats the point) +<nop> well +<nop> we were having channel keys +<nop> for private channels +<nop> and pub channels are public anyway +<jrand0m> right. there may be ways around it. y'all know more about irc + than I do. there are other ways that don't require going this route though +<nop> see the neat thing with message channels is this +<nop> you scale slightly better than trying to find all idents to send to directly +<-- luckypunk has quit (Ping timeout) +--> dd0c (dd0c@anon.iip) has joined #iip-dev +<jrand0m> I'm not sure you scale better, but you do redistribute the load +<jrand0m> (we can find idents via O(log(n))) +--> sahara (~sahara@anon.iip) has joined #iip-dev +<jrand0m> but thats neither here nor there, this is application layer + design ;) +<nop> right +<jrand0m> all we need to do, imho, is find some workable ways that *could* + operate on the comm layer and then leave it to the wayside until we get there +<UserX> jrand0m: messages sent to channels are encrypted with a channel key that + is different to the channel's identity. a channel server can't decrypt a message + unless it has come across the key by othermeans +<sahara> did I miss the meeting? +<jrand0m> you've got some ways that could work, it sounds like, right? +<jrand0m> UserX> how does a user joining a channel get the key? +<hezekiah> sahara: Nope. You're right in the middle of it! :) +<nop> it's a key exchange +<jrand0m> with whom nop? +<jrand0m> brand new user joining #anonymous, and the app containing the + list of users on #anonymous doesn't have the key (As userx said) +<jrand0m> (all I'm saying is there's a way to get all the functionality + and still avoid having a channel key) +<UserX> jrand0m: with public channels it is derived from the channel name. with + private channels the user either creates one or a someone gives them the keys to + the channel +<jrand0m> 'k, cool +<jrand0m> so apps managing public channels can read the plaintext (by + deriving from the channel name) +<jrand0m> (which is prolly fine) +<nop> right +<wilde> jrand0m: if the apps encrypt the plaintext to each recepient, will it + scale well? +<jrand0m> yes wilde, perhaps better (depending on the algorithm used to + nominate channel managers) +<jrand0m> (though it will potentially have a nonserialized delivery) +<jrand0m> ((though i think thats the case with normal irc anyway)) +<-- thecrypto has quit (Ping timeout) +<jrand0m> but, getting back on to the question - +<jrand0m> nop, what do we hope to have decided by the end of the discussion + of #4? +<-- Neo has quit (Ping timeout) +--> d (~sahara@anon.iip) has joined #iip-dev +<nop> well +<-- sahara has quit (EOF From client) +<hifi> simple site , problem is i am tech blond but want good things lol +<nop> I was hoping that we could re-organize, but this is gonna be a discussion + for later +<hifi> sorry OOPS +<nop> UserX +<-- d has quit (Client exiting) +<nop> how long will you need to think about certain aspects, and maybe doc them + up as a concern list +<UserX> hard to say. maybe a week +<nop> what I'm thinking jrand0m is that a lot of this needs sorting out, rather + than just plowing into it, or we'll end up at the beginning with nothing to show +<nop> so let's push a week into this +<nop> and see what concerns are coming into play +<nop> because again +<nop> we want an adaptable mixnet +<nop> any application should be able to survive +<jrand0m> absolutely +<jrand0m> thats the point of the anon comm framework +<-- wilde has quit () +<nop> ok, so let's put this off a week, and focus on some realistic proposals + that can fit all of our needs +<jrand0m> you say "send message M to location L" and it magically, securely, + anonymously gets delivered +<nop> but magic is one thing +<nop> science is another +<nop> of course you know that :) +<jrand0m> the magic is from the app level's perspective ;) +<nop> yes +<nop> understood +<jrand0m> the science is in that 15 page anonCommFramework/2// ;) +<nop> ok +<hezekiah> lol +<nop> UserX, if you can get that in a week that would be helpful +<nop> ? +<jrand0m> I'll aim at revamping the docs & getting comm layer network design + ready for then so we can hit the ground running +<nop> well +<nop> we haven't agreed on certain aspects +<nop> I think that still should be hashed out +<jrand0m> what, in the network layer, haven't we agreed on? +<nop> personally I agree that maybe you post your anonCommFramework on iip-dev +<nop> and have it reviewed and commented +* jrand0m isn't on iip-dev +<Rain> So, meeting again next tuesday, same bat-time, same bat-channel? +<nop> what haven't we agreed on is whether it can support all applications +<hezekiah> jrand0m: Just post to iip-dev@invisiblenet.net . +<hezekiah> Rain: We are on item #4. There are still other items to go. :) +<jrand0m> its ~800k. if someone could post the URL to mids' mirror that'd + be cool +<Delly> argh +<Delly> re +<Delly> about services, i think if IIP become more easier and friendly, we will see + more users and more nodes. it's why i'm making script for mIRC user, one is a Trent + script, allowing to use Trent and Anonymail with the mouse, the other is a script + allowing to transfer file over iip, staying anonymous (using uuencoding). The + "protocol" used is easy and could be done for lot's irc clients with scripting + support. And so everybody could transfer little files, even between di +<jrand0m> nop> I'm 100% certain it can support all applications. +<Rain> hezekiah: Right. My missunderstanding. +<jrand0m> this layer has been used for over a decade in hundreds of industries +<Delly> was my thought of the day +<nop> well then where do we not agree +<nop> if Irc is an issue, then how is it adaptable? +<jrand0m> it isn't an issue +<jrand0m> y'all just don't understand the layer's abstraction ;) +<lonelynerd> Delly: i have a perl script that allows one to use ssh/telnet/etc + over irc +<jrand0m> (really, think of it as a socket) +<Delly> lonelynerd, the goal was just to enhance mirc +<Delly> for iip network +<lonelynerd> Delly: yeah, but if you use base64, i think it's compatible with + this one +<Delly> could be possible tu use it +<jrand0m> ok, we ready for #5 yet? +<hezekiah> nop? +<-- hezekiah has quit (Client exiting) +<Delly> oups i thought it was 5) ! +<ChZEROHag> There's a 5? +--> hezekiah (hezekiah@anon.iip) has joined #iip-dev +<-- hezekiah has quit (Client exiting) +--> hezekiah (hezekiah@anon.iip) has joined #iip-dev +<nop> sorry +<nop> delly +<nop> you guys +<nop> this is off topic +<nop> please reserve your conversation outside this channel +--> hezekiah_ (~hezekiah@anon.iip) has joined #iip-dev +<-- hezekiah has quit (EOF From client) +<nop> well +<nop> jrand0m +--- hezekiah_ is now known as hezekiah +<nop> before I agree to go to 5 +<nop> the problem I'm seeing is +<nop> UserX has a voice +<nop> as well +--- Trent@anon.iip gives channel operator status to hezekiah +<jrand0m> of course +<nop> and if he sees logistical problems +<nop> I believe they should be heard +<nop> so you can't just say, hey it's gonna work +<nop> it has to be "solidly" agreed on both ends +<nop> aka he needs convincing +<jrand0m> right, but I'm not going to sit on my thumbs waiting for him + to doc them up. if he does come up with some problems in a week, fantastic, + and we'll revise accordingly +<nop> or he needs to convine you +<nop> but the idea is this +<nop> what I'm trying to propose with this +<nop> is to reorganize our dev team to get on your bandwagon +<nop> with that +<nop> it would put our energy in working on the network design +<nop> that's the idea +<nop> thus helping all of us get somewhere specific +<nop> I'm not trying to slow down +<jrand0m> right, i don't expect to have a V1.0 final protocol spec next week. + last night I downloaded about 50 new articles off citeseer to do some more research +<nop> ok +<nop> so can we post your proposal to iip-dev +<nop> and get some review +<jrand0m> coo' +<nop> also I advise on your own to propose it on cryptography@metzdowd.com +<nop> which will get some serious review +<jrand0m> sounds good +<nop> ok +<nop> UserX, you there +<UserX> i'm here +<nop> ok, so jrand0m will work on protocol spec, and can I assume you'll come + up with a concerns list or some additives to the protocol? +<UserX> yes +<nop> ok, let's resume this in a week +<nop> what was 5? +<nop> sorry If I'm being a pain +<nop> just want to organize it +<nop> to make sure we're all on same page +<jrand0m> recruiting for services...? +<hezekiah> 5) Recruiting for services to aid with IIP +<nop> ok +<nop> yes +<nop> since mids departure +<nop> and cohesions return +<nop> we are possibly looking for others to contribute to IIP in some aspect +<nop> this does not mean you have to be a hardcore core developer +<nop> but additives like maybe a web maintainer would be good, +<nop> some PR would be good +<hezekiah> luckypunk volunteered to manage the website. +<hezekiah> <luckypunk> I wanna help/take over the IIP website. +<hezekiah> <luckypunk> :D +<nop> and if more people would like to hop on with the upcoming project that + jrand0m is proposing +<jrand0m> wikked +<nop> even if you just want to review the protocol +<nop> that is more than enough help +<nop> the reality is this +<nop> we have a lot of developers with real time jobs +<nop> and it is consuming them at the moment +<nop> and any additional help is wanted +<nop> since this is a huge endeavor +<nop> to take IIP to where it needs to be +<nop> aka InvisibleNet at some point +<nop> real life jobs ;) +<nop> anyway +<nop> the idea is +<nop> it would be cool if people would love to add to this project in some ways +<nop> using their skills, and I know their are some programmers out there +<nop> and a few that have some spare tiem +<nop> time +<nop> luckypunk's reliability will have to be reviewed, no offense, I've had + him offer before with help maintaining a freesite, and no luck there +<hezekiah> nop: I can understand that one. ;-) +<hezekiah> nop: He just asked me to forward the offer along because he + wouldn't be here. +<nop> ok +<hezekiah> nop: I did. My part's done. :) +<nop> well, either way, anyone who wants to join in +<nop> contact one of us +<nop> either at iip@invisiblenet.net +<hezekiah> One of whom? +<nop> or just by nick, +<nop> hezekiah, userx, nop, +<jrand0m> I hear anyone who volutneers to help iip gets free hookers and blow +<hezekiah> What are 'hookers and blow'? +<hezekiah> ... or do I not want to know? +<jrand0m> heh +<nop> hezekiah: don't ask +<hezekiah> OK. +<hezekiah> I don't want to know. :) +<nop> hezekiah: enjoy your sheltered life ;) +<nop> while you can +<nop> cuz college is gonna be fun :) +<hezekiah> I'm enjoying it! I'm enjoying it! +* jrand0m enjoys the hookers and blow ;) +<nop> jrand0m: quick question +* w hugs luckypunk and nop +<jrand0m> si sr? +<nop> jrand0m: are you considering yourself a dev of IIP at some time soon? +<nop> since you are offering a merge ;) +<hifi> + http://www.guerrillanews.com/cgi-bin/wwwthreads/showflat.pl?Cat=&Board=gnn&Number=182767&page=0&view=collapsed&sb=5&o=0&part= +<hifi> sorry , opps again +<jrand0m> nop> a dev of invisiblenet, but I can't contribute to iip +<nop> understood +<nop> IIP == invisiblenet future projects +<hezekiah> jrand0m: Good working! +<hezekiah> jrand0m: Wording. +<nop> devs wanted for either +<nop> to make that clear +<nop> specifically cuz jrand0m could use a good team set +<Addic> I could take a look of the Windows code... +<jrand0m> si sr. once we get rolling into software design, there's going + to be more truckloads of work than one can imagine +<jrand0m> word Addic +<nop> awesome +<nop> ok +<nop> I will send this request on iip-dev line as well +<nop> anyone interested please don't hesitate to contact +<nop> was there a 6? +<nop> I believe so +<jrand0m> 6) comments suggestions and people who want to help +<jrand0m> suggestion: < 1.8 hours next time :) +<jrand0m> (not that any of the topics could have been condensed any more + than they were) +<nop> no comments? +* nop thinks everyone's asleep +<nop> hehe +<nop> we bored them +<jrand0m> w3wt +<Addic> heh, who has been working on the Windows' code this far? +<nop> ok +<hifi> zzzzzz... +<nop> UserX has made it so far portable +<Rain> What kind of talents are we looking for? +<Addic> ok +<nop> ok, let me re-iterate +<nop> Coders, Graphics dudes, Web devs, PR people, Web maintainers +<Rain> Ok, missed that. Sry. +<nop> and if you can write biz plans, that helps me too :) +<nop> you didn't miss +<nop> I didn't go in enough detail +<jrand0m> heh +<-- Ehud has quit (EOF From client) +<hifi> I am Born PR people +<Rain> Step one: Collect Underpants. +<Addic> translating to other languages at wiki? +<nop> yes +<nop> that would be great +<nop> translations +<Addic> ok, i could do that too +<nop> documentation +<nop> etc +<-- hezekiah has quit (Ping timeout) +<nop> even organization +<nop> anyone who wants to be actively involved in helping InvisibelNet/IIP +<hifi> I invite ppl to use IIP alll the time +<nop> thnx hifi +--> hezekiah (hezekiah@anon.iip) has joined #iip-dev +<Rain> What kind of org skills? +<nop> well, maybe help run the meetings, or maybe forcing us dev guys to get + more docs on the protocol +<nop> etc +<nop> possibly organize interviews and some type of press releases +<nop> some ideas for the future of promoting the use of IIP +<nop> etc +<nop> ok, please contact one of us if you want to help out +<Rain> Ok, org question, that I have mentioned before: IIP Signing key? (nag, nag) +--> Ehud (~hezekiah@anon.iip) has joined #iip-dev +<hifi> IIP notification service :) for ppl to knoe I /him is online LOL +<qriff> just as a question for the qurious... what defines the holder for "Trent"... +<qriff> and what about channel/nick expiration... +<qriff> registration that is... +<-- ChZEROHag has quit (Ping timeout) +<jrand0m> trent is a service, not a nick, so trent must have access to the + ircd (i think) +<nop> these questions are mids questions for trent, he's an abstract piece +<nop> yes jrand0m +<jrand0m> iip notification would be cool. how does anonymail do it? +<jrand0m> can clients send a /notify nick to the server and get a msg when + the nick joins? +<hifi> IIP SMS notification LOL +<nop> actually +<nop> we did have IIP SMS as the first version of anonymail +<nop> but it tended to flood +<hifi> oh +<nop> so now we do it as anonymail database delivery +<hifi> IIP invitation msg as signature to ordinary e-mails ... +<hifi> Kinda " Do yo Yahoo ? Get MSN free " stuff +<jrand0m> ooOOoo textAds +<jrand0m> but does iip need more users? +<hifi> oh +<jrand0m> or is getting more users just a "oh cool, lets service more people"? +<hifi> no +<hifi> dunno +<hifi> i just brainstorm +<-- Mira has quit (Ping timeout) +<hezekiah> More people ... more ideas ... more volunteers +<hifi> IIP as world standart will be cool +<hezekiah> More people ... more problems ... more strain on the network ... +<hezekiah> ... more floods of #anonymous ... +<hezekiah> It's a two sided question. +<hifi> more channels lol +--> Mira (~Mira@anon.iip) has joined #iip-dev +<hifi> IIP Eugenics Program LOL Less Population Less Problems +--> ChZEROHag (~hag@anon.iip) has joined #iip-dev +<Addic> hmm... going back to the notification question... is it so the /notify + nick does not work here? Or am I not understanding the question... +<lonelynerd> Addic: sure it works +<Addic> well what's the problem then? +<hifi> ? +<-- Delly has quit (EOF From client) +<lonelynerd> wasn't much following the conversation, but they talked about + having a /notify that wouldn't require the client to poll +<Addic> ok +<-- ChZEROHag has quit (Ping timeout) +<-- w has quit (Ping timeout) +<-- Rain has quit (I Quit) +--> w (~w@anon.iip) has joined #iip-dev +<hezekiah> Hmmm ... +<hezekiah> I think it's about time we adjurne this meeting. +<hezekiah> What do you say, nop? +* jrand0m thinks he fell asleep too +<nop> yeah +<nop> ok +<nop> later +<-- jrand0m (jrandom@anon.iip) has left #iip-dev (jrand0m) +<hezekiah> Meeting adjurned! :) +<hezekiah> *BAF*! +<-- Addic (anon@anon.iip) has left #iip-dev (Addic) +<-- LeerokLacerta (~leerok@anon.iip) has left #iip-dev (Client Exiting) +<-- hezekiah has quit (Client exiting) +<-- Ehud has quit (Client exiting) +\ No newline at end of file diff --git a/pages/meeting48.html b/pages/meeting48.html new file mode 100644 index 00000000..1490756f --- /dev/null +++ b/pages/meeting48.html @@ -0,0 +1,743 @@ +
+--- Log opened Tue Jul 15 17:46:47 2003
+17:46 < gott> yo.
+17:46 <@nop> just a heads up on my silence
+17:46 <@hezekiah> Tue Jul 15 21:46:49 UTC 2003
+17:47 <@hezekiah> OK. The iip-dev meeting has started.
+17:47 <@hezekiah> Is it the 48th or 49th?
+17:47 < jrand0m> nop> this is why its critical that we get the router
+ architecture pounded out asap. I understand that different people have
+ different rates of speed, and we must segment so different components can
+ proceed accordingly
+17:47 < mihi> 49th
+17:47 <@hezekiah> OK! Welcome to the 49th iip-dev meeting!
+17:47 < jrand0m> I have three more days at my job, after which 90+ hours /
+ week will be dedicated to getting this going
+17:48 < jrand0m> I know and don't expect everyone to be able to do that,
+ which is why we need to segment
+17:48 < jrand0m> hi hezekiah :)
+17:48 <@hezekiah> lol
+17:48 <@nop> to rebutt on that
+17:48 <@hezekiah> I'll wait a minute. Then we can do the agenda. :)
+17:48 <@nop> the security of the router architecture is dependant that you
+ do not rush as well
+17:49 <@nop> if we do
+17:49 <@nop> we overlook
+17:49 <@nop> which could leave us cleaning up a big mess later
+17:49 -!- Rain [Rain@anon.iip] has quit [I Quit]
+17:49 < jrand0m> nop> disagree. we can still build app layer and APIs
+ without implementing the router (or even knowing how the network will operate)
+17:49 <@nop> I agree with that
+17:50 <@nop> I'm specifically talking about the underlying network
+17:50 < jrand0m> if we can agree to the API I sent out, then thats the
+ segmentation we need
+17:50 < jrand0m> right, router impl and network design still isn't done
+17:50 <@nop> ok
+17:50 <@nop> oh, I can definitely agree with your api so far
+17:51 <@hezekiah> jrand0m: One problem.
+17:51 < jrand0m> shoot hezekiah
+17:51 <@hezekiah> It will look different if you implement it in C.
+17:51 < jrand0m> not too different
+17:51 < gott> oh dear
+17:51 < jrand0m> less capital letters, and replace the objects with structs
+17:51 < gott> what languages are people considering implementing it in?
+17:51 < jrand0m> (for the api)
+17:51 <@hezekiah> Uh, jrand0m? There is no 'byte[]' in C.
+17:51 < jrand0m> gott> read the mail archives for some example answers to that
+17:52 <@hezekiah> You will be using void*'s with an integer to specifiy the
+ length most likely.
+17:52 < jrand0m> hezekiah> then unsigned int[]
+17:52 < gott> jrand0m: for once, a religious war that I'm not a part of
+17:52 <@hezekiah> If I remember correctly (help me out here nop), you can't
+ just return an unsigned int[] from a function.
+17:53 <@hezekiah> gott: It's not a religious war. I'm just saying that the
+ API as a concept might be fine, but in C it would look seriously different.
+17:53 < gott> hezekiah: as opposed to what? pseudocode?
+17:53 < jrand0m> right, syntactic changes. but yes, if there are real
+ differences, we need to get them worked out ASAP. (like, today) Perhaps
+ now would be a good tiem to look at the email I sent entitled "high level
+ router architecture and API" and review?
+17:54 <@hezekiah> nop? UserX? Are you game for that?
+17:54 < jrand0m> not too different, but different none the less, yes.
+ which is why I said Java API on todays email :)
+17:54 -!- WinBear [WinBear@anon.iip] has joined #iip-dev
+17:55 <@nop> wait
+17:55 <@nop> reading above
+17:55 -!- mihi_2 [~none@anon.iip] has joined #iip-dev
+17:55 -!- mihi is now known as nickthief60234
+17:55 -!- mihi_2 is now known as mihi
+17:55 < jrand0m> wb mihi
+17:55 < gott> btw, is this being live logged?
+17:55 -!- nickthief60234 [~none@anon.iip] has quit [EOF From client]
+17:55 <@hezekiah> gott: Yes.
+17:55 < mihi> redundancy rules ;)
+17:55 < gott> I'll just read it later on then.
+17:55 -!- gott [~gott@anon.iip] has left #iip-dev [gott]
+17:56 <@nop> ok
+17:56 <@nop> yes
+17:56 < WinBear> jrand0m: hi
+17:56 <@nop> definitely differences
+17:56 <@nop> what we need
+17:56 < jrand0m> heya WinBear
+17:56 <@nop> is a team of certain developers to write the main api level
+ controls for these languages
+17:56 <@nop> we know that jrand0m can handle java
+17:56 <@nop> and probably could team up with thecrypto as well
+17:56 <@nop> and hezekiah and the gang can do C
+17:56 <@nop> and jeremiah if he's willing
+17:56 <@nop> can do python
+17:56 <@hezekiah> I can do C++ too! ;-)
+17:56 <@nop> ok
+17:56 <@nop> C++ as well
+17:57 <@hezekiah> lol
+17:57 <@nop> C++ will probably work
+17:57 <@nop> with C
+17:57 <@nop> if you don't template the crap out of it
+17:57 < jrand0m> heh
+17:57 <@hezekiah> lol
+17:57 <@hezekiah> Actually, while MSVC can link C and C++ object files,
+ gcc doesn't seem to like that.
+17:57 <@nop> aka, stick to structs that are compatible with C, or is that
+ not viable
+17:57 < jrand0m> first question, prior to that, is what applications will use
+ these APIs? I know of apps that will want to use java, will iproxy be in C?
+17:58 <@hezekiah> nop: I don't think C and C++ are object compatible.
+17:58 <@nop> ok
+17:58 <@hezekiah> nop: C++ won't get along with C much better than Java.
+17:58 <@nop> well maybe USerX could do C
+17:58 <@nop> and you could pull C++
+17:58 <@hezekiah> We don
+17:58 <@nop> ?
+17:58 <@hezekiah> don't even need to _do_ C++ if you don't want to. It's
+ just that I prefer it.
+17:59 <@nop> well, the thing is
+17:59 <@nop> there are a lot of C++ developers
+17:59 <@nop> especially in the microsoft world
+17:59 <@hezekiah> Even in the Linux world. (see: KDE and Qt.)
+17:59 < jrand0m> C and C++ are binary compatible if you just make .so or .a
+17:59 < jrand0m> (btw)
+18:00 <@nop> can C be a good placement for C++, aka C++ developers would be
+ able to handle a c api easier than a C++ api with a c developer?
+18:00 <@hezekiah> jrand0m: Yeah. You can probably have libraries ... but if
+ you can
+18:00 <@hezekiah> jrand0m: can't even use classes, it sorta defeats the
+ purpose.
+18:00 <@nop> right
+18:00 <@nop> let's stick with C
+18:01 <@nop> because C++ coders can still call a C library rather easily
+18:01 <@hezekiah> If one module needs to call anothers functions, then they
+ had best both be the same language.
+18:01 <@hezekiah> nop: C++ coders will know C well enough ... though it
+ might take some work if they never /learned/ C.
+18:02 <@hezekiah> However, C coders wouldn't know C++ since C is just a
+ subset of C++.
+18:02 -!- logger_ [~logger@anon.iip] has joined #iip-dev
+18:02 -!- Topic for #iip-dev: logfiles will be online after the meeting:
+ http://wiki.invisiblenet.net/?Meetings
+18:02 [Users #iip-dev]
+18:02 [@hezekiah] [+Ehud ] [ leenookx] [ moltar] [ tek ]
+18:02 [@nop ] [ jeremiah] [ logger_ ] [ Neo ] [ WinBear]
+18:02 [@UserX ] [ jrand0m ] [ mihi ] [ ptsc ]
+18:02 -!- Irssi: #iip-dev: Total of 14 nicks [3 ops, 0 halfops, 1 voices,
+10 normal]
+18:02 < jrand0m> right
+18:02 -!- Irssi: Join to #iip-dev was synced in 9 secs
+18:02 < jrand0m> (with JMS :)
+18:02 <@nop> yep
+18:03 -!- You're now known as logger
+18:03 < jrand0m> ok, can we review the overall architecture to see whether
+ the APIs are even relevent first?
+18:03 <@nop> fine 18:04 < jrand0m> :)
+18:04 < jrand0m> ok, see the email I sent w/ the routerArchitecture.png.
+ any thoughts on that seperation?
+18:04 -!- tek [~tek@anon.iip] has quit []
+18:05 < WinBear> jrand0m: is that on the wiki?
+18:05 < jrand0m> WinBear> no, on the mailing list, though the archives
+ are down. lemmie add it to the wikki
+18:06 <@hezekiah> Correct me if I'm wrong ...
+18:07 <@hezekiah> ... but it looks like we're going to have 3 seperate API's
+ that are as similar as possible.
+18:07 <@hezekiah> Right?
+18:07 < jrand0m> yes hezekiah
+18:07 <@hezekiah> So since each API is in a different language, are they
+ going all each have seperate implementations?
+18:07 < jrand0m> yes
+18:07 <@hezekiah> Or is there a way for Java or Python to access a C library?
+18:08 < jrand0m> yes, but we don't want to go that route
+18:08 < mihi> for java: JNI
+18:08 <@hezekiah> So this talk about Java, C, C++, Python, etc. working
+ together is mute since they never will?
+18:08 < jrand0m> how do I attach an image to the wiki?
+18:08 <@hezekiah> Each API has its own backend written in that language.
+18:08 < jrand0m> no hezekiah, look at the diagram
+18:09 <@hezekiah> Oh, duh!
+18:09 <@hezekiah> The API's don't link to a backend.
+18:10 <@hezekiah> They talk via sockets.
+18:10 < jrand0m> si sr
+18:10 <@hezekiah> This is still a little confusing though.
+18:10 <@hezekiah> Give me a sec here. :)
+18:11 <@hezekiah> OK. What is the thing labeled 'transport'?
+18:11 < jrand0m> for example, bidirectional HTTP transport, SMTP transport,
+ plain socket transport, polling HTTP socket, etc
+18:11 < jrand0m> the thing that moves bytes between routers
+18:12 <@hezekiah> OK.
+18:12 <@hezekiah> So the diagram I'm looking at shows one person's computer.
+18:12 <@hezekiah> He has a router that talks to other people's computers
+ via the transports.
+18:12 < jrand0m> correct
+18:12 <@hezekiah> Person 1 (Alice) has 2 applications running.
+18:12 <@hezekiah> One is in C, the other in Java.
+18:13 <@hezekiah> Both are linked to a library (that's the API).
+18:13 < jrand0m> both are "linked" to seperate libraries (the APIs)
+18:13 <@nop> simple concept
+18:13 <@nop> yes
+18:13 <@hezekiah> Those libraries, take input from the program encrypt it,
+ and send it via sockets (unix or TCP) to the router ... which is another
+ program Alice is running.
+18:13 < jrand0m> correct
+18:14 <@hezekiah> OK. So it's kinda like isproxy being split in two.
+18:14 < jrand0m> bingo :)
+18:14 <@hezekiah> One part is low end and written in C, and the other is
+ high end and written in whatever.
+18:14 < jrand0m> exactly
+18:14 <@hezekiah> OK. I get it. :)
+18:14 < jrand0m> w00t
+18:14 <@hezekiah> So no language needs to play nice with any other language.
+18:14 < jrand0m> WinBear> sorry, I can't toss it on the wiki as it only
+ takes text :/
+18:15 <@hezekiah> Since they all comunicate with the router via sockets,
+ you could write an API in PASCAL for all the design cares.
+18:15 <@nop> yes
+18:15 <@nop> arbitrary
+18:15 < jrand0m> right
+18:15 <@nop> it handles arbitrary sockets
+18:15 < jrand0m> though some things need to be standardized (like the data
+ structures for Destination, Lease, etc)
+18:15 < WinBear> jrand0m: i get a vague idea based on what hezekiah is saying
+18:15 < jrand0m> word
+18:16 <@hezekiah> jrand0m: Right. The structure and order of the bytes that
+ go across that socket is set in a design somewhre
+18:16 <@hezekiah> somewhere.
+18:17 <@hezekiah> But you can still implement how those bytes are send and
+ received any joly way you please.
+18:17 <@nop> WinBear: it's the same exact way that the irc client works
+ with isproxy
+18:17 < jrand0m> exactly
+18:17 <@hezekiah> Good.
+18:17 <@hezekiah> I understand now. :)
+18:17 -!- moltar [~me@anon.iip] has left #iip-dev [moltar]
+18:17 <@nop> well
+18:17 <@nop> not exactly
+18:17 <@hezekiah> Uh oh.
+18:17 <@nop> but imagine how that works
+18:17 <@nop> and you can understand arbitrary sockets
+18:17 <@nop> isproxy just routes
+18:17 <@nop> and delivers
+18:18 <@nop> now jrand0m
+18:18 <@nop> quick question
+18:18 < jrand0m> si sr?
+18:18 <@nop> is this api designed for only new applications that are designed
+ to work on this network
+18:18 -!- mode/#iip-dev [+v logger] by hezekiah
+18:18 < WinBear> nop: with the highlevel replacing the irc client?
+18:18 < jrand0m> nop> yes. though a SOCKS5 proxy could use this API as well
+18:18 <@nop> or can it be able to have a middle man that can allow already
+ standard clients
+18:18 <@nop> for instance
+18:19 <@nop> so all we would have to do is write the middleman -> api
+18:19 < jrand0m> (but note that there's no 'lookup' service available -
+ no DNS for this network)
+18:19 < jrand0m> correct
+18:19 <@nop> so that we can support say Mozilla etc
+18:19 <@nop> so they can just code plugins
+18:19 < jrand0m> nop> yes
+18:19 <@nop> ok
+18:19 <@nop> or transports :)
+18:20 < jrand0m> (e.g. the SOCKS5 has the HTTP outproxies hardcoded to
+ destination1, destination2, and destination3)
+18:20 <@nop> ok
+18:20 < WinBear> i think i get it
+18:21 < jrand0m> w00t
+18:21 < jrand0m> ok, one of the things I had to think about in this design
+ was keeping the private keys in the app's memory space - the router never
+ gets a hold of destination private keys.
+18:21 <@hezekiah> So the application can send raw data over the I2P network
+ by sending it to the API, and it doesn't need to worry about the rest.
+18:22 <@hezekiah> Right?
+18:22 < jrand0m> that means the APIs need to implement the end to end part
+ of the crypto
+18:22 < jrand0m> exactly hezekiah
+18:22 <@hezekiah> OK.
+18:22 <@nop> yes
+18:22 <@nop> that's the idea
+18:22 <@nop> it does it for you
+18:22 <@nop> you just call the hook
+18:23 <@hezekiah> One quick question:
+18:23 <@hezekiah> This 'router' obviously needs to speak a certain protocol
+ over it's transports.
+18:23 < jrand0m> correct
+18:23 <@hezekiah> So it is possible to provide multiple implementations of
+ the router ...
+18:23 < jrand0m> yes
+18:24 <@hezekiah> ... as long as they both speak the same protocol.
+18:24 < jrand0m> (which is why the spec has placeholders for bitbuckets)
+18:24 < jrand0m> right
+18:24 <@hezekiah> So you have a router in Java, and one in C, and one
+ in PASCAL.
+18:24 * jrand0m cringes
+18:24 < jrand0m> but yeah
+18:24 <@hezekiah> And they all can talk together since they're talking over
+ TCP/IP using the same protocol.
+18:24 * WinBear jumps
+18:24 <@hezekiah> jrand0m: And yes. I don't remember my PASCAL days overly
+ fondly either.
+18:25 < jrand0m> well, Pascal can talk to the C one through the TCP transport,
+ and the C one can talk to the Java one over the HTTP transport, for example
+18:25 <@hezekiah> Right.
+18:25 < jrand0m> (transports talk to other like transports, routers manage
+ the messages delivered between them but don't deal with how they're delivered)
+18:26 <@hezekiah> The point I was looking to make was that the protocol is the
+ same, so it doesn't matter what language someone's router is implemented in.
+18:26 < jrand0m> right
+18:26 <@hezekiah> Cool.
+18:26 < jrand0m> now you understand why I said "who cares" to all the C vs
+ Java vs etc debates? :)
+18:26 <@hezekiah> Yup.
+18:26 <@hezekiah> lol
+18:27 <@hezekiah> I've got to hand it to you jrand0m. This will make it very
+ kind for develoeprs to write programs for this network.
+18:27 < jrand0m> heh, well, the API ain't quite original. this is how
+ Message Oriented Middleware (MOM) works
+18:27 <@hezekiah> And you could even make routers that specialize in certain
+ platform specific features (like 64-bit CPU's).
+18:28 < jrand0m> absolutely
+18:28 <@hezekiah> jrand0m: Humble too! ;-)
+18:28 <@hezekiah> Well, it looks good to me.
+18:28 < jrand0m> ok, UserX, nop, does this seperation make sense?
+18:28 <@nop> of course
+18:28 <@nop> is userx still here
+18:29 <@hezekiah> He's been idle for 1:26.
+18:29 < jrand0m> 'k. so then we have two tasks: design the network, and
+ design how the API works.
+18:29 <@nop> right
+18:29 <@hezekiah> Quick simple question: The API's do end to end crypto. Do
+ the routers to node to node crypto ?
+18:29 <@nop> yes
+18:30 < jrand0m> yes
+18:30 < jrand0m> (transport level)
+18:30 <@hezekiah> Good. :)
+18:30 <@nop> hezekiah: it's very similar to what we have so far
+18:30 <@nop> in that aspect
+18:31 < jrand0m> ok.. er, shit, thecrypto aint around for comments on the
+ performance model.
+18:31 < Neo> and for the paranoid, the apps can do the pgp encryption before
+ it hits the API ;)
+18:31 < jrand0m> absolutely neo
+18:31 < jrand0m> I was even tempted to leave the end to end crypto out of
+ the API and leave it up to the apps...
+18:31 <@hezekiah> jrand0m: That would be cruel.
+18:31 < jrand0m> heheh
+18:32 <@hezekiah> BTW, the API's and the router communicate via sockets.
+18:32 <@hezekiah> On UNIX will they be using UNIX sockets or local TCP/IP
+ sockets?
+18:32 < jrand0m> prolly just local tcp/ip for simplicity
+18:32 <@nop> hold
+18:32 <@hezekiah> (I suppose you could make a router that accepts both.)
+18:33 * hezekiah is really liking this interchangable parts setup
+18:33 <@nop> if you hold on a sec
+18:34 <@hezekiah> Holding ... :)
+18:34 <@nop> I'll call thecrypto at his house
+18:34 <@nop> see if he can get on
+18:34 < jrand0m> hehe word
+18:34 <@hezekiah> lol
+18:34 * hezekiah dons a thick Itallian accent
+18:34 <@hezekiah> Nop ha' got ... CONNECTIONS!
+18:34 < jeremiah> lo
+18:34 <@nop> hey jeremiah
+18:35 < jrand0m> heya jeremiah
+18:35 <@nop> would you be willing at the api level to assist with a python api
+18:35 < jeremiah> sure
+18:35 * jeremiah reads backlog
+18:35 < jrand0m> heh word
+18:35 * nop is calling
+18:36 <@nop> he's not home
+18:36 <@nop> he'll be back in an hour
+18:36 < jrand0m> 'k, has anyone else read the .xls and/or have comments on
+ the model?
+18:37 <@hezekiah> I read the .xls ... but I don't know much about p2p so
+ most of it was over my head.
+18:37 <@hezekiah> UserX is good at that stuff.
+18:37 <@nop> I have to read it still
+18:37 < jrand0m> (btw, morphmix had some insane numbers... they were saying
+ they could expect random hosts on the net to have average 20-150ms ping times,
+ rather than the 3-500 I was expecting)
+18:37 < jrand0m> coo'
+18:37 <@nop> it's staroffice or openoffice?
+18:37 < jrand0m> openoffice, but I exported it to .xls
+18:37 <@nop> which is excell?
+18:37 < jrand0m> correct
+18:38 <@hezekiah> BTW, concerning the API ...
+18:38 < jrand0m> si sr?
+18:38 <@hezekiah> ... in C the boolean would be int.
+18:38 <@nop> which email
+18:38 <@nop> hezekiah: yes
+18:38 <@hezekiah> The classes would be sent as structure pointers.
+18:38 <@nop> unless you typedef boolean
+18:39 <@hezekiah> And the functions that use byte[] would use a void* with
+ an additional parameter that specefies the length of the buffer.
+18:39 <@nop> hezekiah: you're being picky :)
+18:39 < jrand0m> nop> I cant access the archives so I'm not sure what the
+ subject line was, but it was last week...
+18:39 <@nop> save it for a later time
+18:39 <@hezekiah> nop: Picky?
+18:39 < jrand0m> heh, yeah, y'all working on the C api can work that detail out
+18:39 * jeremiah is done reading backlog
+18:39 <@nop> what's the file called
+18:39 <@hezekiah> nop: I'm just trying to find all the stuff that is different,
+ so we can hammer it out like jrand0m asked.
+18:40 <@hezekiah> I'm trying to be helpful. :)
+18:40 <@nop> hezekiah: yes, probably off meeting time
+18:40 < jrand0m> nop> simple_latency.xls
+18:40 <@hezekiah> boolean sendMessage(Destination dest, byte[] payload);
+18:40 <@hezekiah> would be
+18:40 <@hezekiah> int sendMessage(Destination dest, void* payload, int length);
+18:40 <@hezekiah> .
+18:40 <@hezekiah> byte[] recieveMessage(int msgId);
+18:40 <@hezekiah> that could either be:
+18:41 <@hezekiah> void* recieveMessage(int msgId, int* length);
+18:41 <@hezekiah> or
+18:41 <@nop> jrand0m: got it
+18:41 <@hezekiah> void recieveMessage(int msgId, void* buf, int* length);
+18:41 <@hezekiah> or
+18:41 < jrand0m> hezekia: why not typedef struct { int length; void* data;
+ } Payload;
+18:41 <@hezekiah> DataBlock* recieveMessage(int msgId)l
+18:41 <@hezekiah> DataBlock* recieveMessage(int msgId);
+18:41 < jeremiah> where's this xls?
+18:41 <@nop> oh iip-dev
+18:41 <@hezekiah> jrand0m: The struct you just mentioned is basically what
+ DataBlock is.
+18:42 < jrand0m> word hezekiah
+18:42 <@nop> subject more models
+18:42 <@hezekiah> Chances are the C version would have DataBlocks.
+18:43 <@hezekiah> Beyond that the only other thing to note is that each
+ 'interface' would just be a set of functions.
+18:43 <@hezekiah> nop: Did I find all the differences that would exist in
+ a C API?
+18:43 < jrand0m> right. perhaps #include "i2psession.h" or something
+18:43 < jeremiah> is there a mockup python api?
+18:44 < jrand0m> no jeremiah, I don't really know python :/
+18:44 <@nop> I would have to re-review the java api, but I would say that
+ you're right on target
+18:44 < jrand0m> but it would probably be similar to the java, as python is OO
+18:44 < jeremiah> cool, i can derive one from the C one
+18:44 * nop is not a java head
+18:44 < jrand0m> cool jeremiah
+18:44 < jeremiah> is the c api in the thing you sent out a few days ago?
+18:44 <@hezekiah> Yeah. Python should be able to handle the Java api.
+18:44 < jrand0m> jeremiah> that was the Java one
+18:45 < jrand0m> oh, the Java one was today
+18:45 < jrand0m> the older one was language independent
+18:45 <@hezekiah> Hmm
+18:45 <@nop> UserX says he should be able to assist with C api
+18:45 < jrand0m> word
+18:45 <@nop> he's busy at work at the moment
+18:46 < jrand0m> coo'
+18:46 <@hezekiah> One last note: With the C api, each function would probably
+ take a structure* to the structure that it is an 'interface' of in Java.
+18:46 <@nop> hezekiah: loos good
+18:46 <@nop> looks good
+18:46 <@hezekiah> I2PSession createSession(String keyFileToLoadFrom,
+ Properties options);
+18:46 <@hezekiah> would be:
+18:46 <@nop> java and their non-native data types
+18:46 <@hezekiah> I2PSession* createSession(I2PClient* client, char*
+ keyFileToLoadFrom, Properties* options);
+18:46 <@nop> ;)
+18:46 < jrand0m> hehe
+18:46 < jrand0m> right hezekiah
+18:47 < jeremiah> are we addressing unicode?
+18:47 <@hezekiah> Anyway, if you can live with those differences, the C and
+ Java API's should be identical beyond that.
+18:47 <@hezekiah> nop? Unicode? :)
+18:47 < jrand0m> UTF8 if not UTF16
+18:48 <@hezekiah> Perhaps Unicode should be dealt with on the application
+ level.
+18:48 < jrand0m> right, charset is all the content of the message
+18:48 <@hezekiah> Oh.
+18:48 < jeremiah> ok
+18:48 <@hezekiah> Java String's are done in Unicode, aren't they jrand0m?
+18:48 < jrand0m> the bitbuckets'll all be bit defined
+18:48 < jrand0m> yes hezekiah
+18:48 < jrand0m> (unless you explicitly instruct them to change charsets)
+18:49 <@hezekiah> So the string sent to the Java API would be different than
+ the one sent to the C API unless the C API implements strings using Unicode.
+18:49 < jrand0m> not relevent
+18:49 <@hezekiah> OK.
+18:49 < jrand0m> (app->API != API->router. we only define API->router)
+18:49 <@hezekiah> What I'm saying is this, jrand0m:
+18:50 <@hezekiah> If I set my password with the Java API, it goes to the
+ router out someplace else.
+18:50 < jrand0m> password? you mean you create a Destination?
+18:50 <@hezekiah> Then it find another router, which sends it to another API
+ (?) which is implemented in C.
+18:50 <@hezekiah> void setPassphrase(String old, String new);
+18:50 <@hezekiah> That function.
+18:51 < jrand0m> hezekiah> thats the administrative password to access the
+ administrative methods of the router
+18:51 <@hezekiah> Ah
+18:51 <@hezekiah> Do any functions in the API which use Java String's end
+ up with that String being sent to another API?
+18:51 < jrand0m> 99.9% of apps will only use I2PSession, not I2PAdminSession
+18:51 <@nop> also, anything carried with the router gets converted for
+ network travel correct?
+18:51 <@hezekiah> If so, we should probably use Unicode.
+18:51 <@nop> unicode wouldn't be releavant
+18:52 < jrand0m> hezekiah> no. all inter-router info will be defined by
+ bit buckets
+18:52 <@hezekiah> OK.
+18:52 < jrand0m> correct nop, at the transport level
+18:52 <@hezekiah> (I'm assuming a bit bucket is just a binary buffer, right?)
+18:53 < jrand0m> a bit bucket is a statement that the first bit means X,
+ the second bit means Y, bits 3-42 mean Z, etc
+18:53 < jrand0m> (e.g. we may want to use X.509 for the certificates bitbucket)
+
+18:53 <@hezekiah> I've never dealt with that before.
+18:54 <@hezekiah> I'll worry about it when I get there. :)
+18:54 < jrand0m> heh word
+18:55 < jrand0m> ok, the four things I wanted us to hit today: *router
+ architecture, *performance model, *attack analysis, *psyc. We've done
+ the first, thecrypto is offline so perhaps we delay this (unless you have
+ thoughts on the model nop?)
+18:57 <@hezekiah> Um ... jrand0m. I have yet another question.
+18:57 < jeremiah> jrand0m: where's the latest version of the network spec? is
+ it what you sent out on the 13th?
+18:57 < jrand0m> si sr?
+18:57 <@hezekiah> Well the router architecture has the API's handle keys
+ /sent to them by the Application/.
+18:57 < jrand0m> jeremiah> yes
+18:57 <@nop> I don't at this time
+18:58 <@hezekiah> Now ... the only way I see that the API gets the key is
+ from createSession.
+18:58 < jrand0m> hezekiah> the router gets public keys and signatures,
+ not private keys
+18:58 < jrand0m> right
+18:58 <@hezekiah> But that requires a file.
+18:58 < jrand0m> the keys are stored in a file or in the API's memory
+18:58 < jrand0m> yes
+18:58 <@hezekiah> Now if the application generates a key, why can't it just
+ send it to the API via a buffer?
+18:59 <@hezekiah> Must it really store it in a file, and then provide the
+ file name?
+18:59 < jrand0m> no, it can be in memory if you'd like
+18:59 <@hezekiah> There is not function to all that in the API though.
+18:59 <@hezekiah> It's just a thought.
+19:00 <@hezekiah> If the key is supposed to be generated only once and used
+ many, many times (like GPG keys), then a file makes sense.
+19:00 -!- mihi [none@anon.iip] has quit [bye all, it's getting late...]
+19:00 <@hezekiah> But if it will be generated more often, then perhaps some
+ way to directly send it to the API via a structure or buffer of some sort
+ might be nice
+19:00 <@hezekiah> .
+19:01 < jrand0m> yes, its generated once and only once (unless you're wearing
+ a tinfoil hat)
+19:02 < jrand0m> though the createDestination(keyFileToSaveTo) lets you
+ create that key
+19:02 <@hezekiah> OK.
+19:02 <@hezekiah> So there's really no need for transfer directly from the
+ App to the API. A file will suffice.
+19:03 <@hezekiah> So where were we before I so rudely interupted? :)
+19:06 < jeremiah> so right now we're just working on the router API, not
+ the client one, right?
+19:06 < jrand0m> well, we're skipping on performance analysis for now
+ (hopefully we can get some chatter re: it on the mailing list before next
+ week?). and probably the same wrt attack analysis (unless anyone read the
+ new spec and has comments)
+19:07 <@hezekiah> So we're since we're skipping that, what are we supposed
+ to be talking about now?
+19:07 <@hezekiah> Psyc?
+19:07 < jrand0m> unless anyone else has other comments to bring up...?
+19:08 <@hezekiah> Well, for once, my comment hole (also notoriously known
+ as my mouth) is empty.
+19:08 < jrand0m> hehe
+19:09 < jrand0m> ok, anyone have any thoughts on how the IRC side of things
+ will work, and whether psyc may be relevent or useful?
+19:09 < jeremiah> sidenote (that pissed me off): wired's "Wired, Tired,
+ Expired" list had Waste as 'wired'
+19:09 < jrand0m> heh
+19:09 < jrand0m> do you realize how much we're going to blow everyone away?
+19:09 < jeremiah> yep
+19:09 <@hezekiah> jrand0m: That assumes we get this to work.
+19:10 < jrand0m> I guarantee it will work.
+19:10 <@hezekiah> There are a lot of other failed efforts out there.
+19:10 < jrand0m> I quit my job to work on this.
+19:10 <@hezekiah> Then we're going to blow everyone away. :)
+19:10 <@hezekiah> Yeah. How is bread getting on the table when you do that?
+19:10 <@hezekiah> GPL code doesn't pay well. ;-)
+19:10 < jrand0m> heh
+19:11 <@hezekiah> As for psyc ... let me put it this way:
+19:11 <@hezekiah> The first time I heard of it was when you emailed us
+ about it.
+19:11 < jrand0m> shit, I wasn't the one who found it :)
+19:11 <@hezekiah> However, IRC is probably one of the most (if not /the/
+ most) prolific chat protocols around.
+19:11 <@hezekiah> People will want IRC apps LONG before they even /know/
+ what psyc is.
+19:11 <@hezekiah> jrand0m: Oops. Sorry. I forgot that detail. :)
+19:12 < jrand0m> not according to psyc. their history goes back to 86 I think
+19:12 <@hezekiah> The point is that the supperiority of the protocol, isn't
+ really as relevant as to who uses it.
+19:12 <@hezekiah> Their _history_ may go back that far.
+19:12 <@hezekiah> But how many people _use_ Psyc?
+19:12 < jeremiah> yeah if they've been around since a year after I was born
+ (ahem) and they aren't that big yet
+19:12 <@hezekiah> My point is that even if it's a better protocol, most
+ people _use_ IRC.
+19:13 <@hezekiah> We can make the best I2P network on the planet ...
+19:13 -!- Ehud [logger@anon.iip] has quit [Ping timeout]
+19:14 < jeremiah> can someone explain briefly why we care? I thought IRC
+ would only be one possible application but that the network is flexible to
+ support psyc as well if it wanted to
+19:14 <@hezekiah> Right.
+19:14 <@hezekiah> Psyc can be made ...
+19:14 <@hezekiah> ... but I'm saying we should do IRC first because more
+ people use it.
+
+19:14 <@hezekiah> jrand0m, we can make a great I2P network, but people won't
+ use it unless it has something they want.
+19:14 < jrand0m> jeremiah> the reason psyc is interesting is that we may
+ want to implement IRC in the same vein that psyc works
+19:15 <@hezekiah> Hence we should provide them with a 'killer-app'.
+19:15 < jeremiah> ok
+19:15 < jrand0m> right, IIP is invisible IRC project, and will allow people
+ to run IRC
+19:16 < jrand0m> with no central server (or any server at all, actually),
+ theres a lot of thinking to be done to figure out how IRC will work.
+ psyc has a possible answer to that
+19:16 < jrand0m> though there are others
+19:17 <@hezekiah> As I said, psyc might do better, but people want to use IRC,
+ not psyc.
+19:17 < jrand0m> and they will
+19:17 < jrand0m> they'll use irc
+19:17 <@hezekiah> It's all about marketing, baby! ;-)
+19:17 < jeremiah> I'll try to read the spec and some stuff on psyc tonight
+19:17 < jrand0m> word
+19:17 <@hezekiah> lol
+19:17 < jeremiah> planning to meet at 5:00 UTC tommorow?
+19:17 <@hezekiah> No?
+19:18 < jeremiah> or whenever
+19:18 < jrand0m> I'm on iip 24x7 :)
+19:18 < jeremiah> yeah but i eat
+19:18 <@hezekiah> jrand0m: I noticed.
+19:18 < jrand0m> 05:00 utc or 17:00 utc?
+19:18 <@hezekiah> jeremiah: LOL!
+19:18 <@hezekiah> Well the iip-dev meeting officially starts at 21:00 UTC.
+19:18 -!- Ehud [~logger@anon.iip] has joined #iip-dev
+19:19 < jeremiah> ok, i just said 05:00 UTC because I was talking out of my ass
+19:19 < jeremiah> where's mids?
+19:19 <@hezekiah> mids, left the project for a while.
+19:19 <@hezekiah> Weren't you there a few meetings back?
+19:19 < jeremiah> ok
+19:19 < jeremiah> guess not
+19:19 <@hezekiah> We had a goodbye party of sorts as part of the agenda.
+19:19 < jeremiah> oh
+19:20 <@hezekiah> OK ...
+19:20 <@hezekiah> Is there anything still on the agenda?
+19:20 * jrand0m doesn't have any left on mine
+19:20 < jeremiah> about psyc:
+19:20 < jeremiah> if this is a psyc feature, I know you mentioned it a
+ while ago
+19:20 * hezekiah never had an agenda in the first placve
+19:21 <@hezekiah> pace
+19:21 <@hezekiah> place
+19:21 < jeremiah> I don't think having each user send a message to every
+ other use in the room is s smart idea
+19:21 <@hezekiah> There!
+19:21 < jrand0m> jeremiah> so you'd have redundant nominated pseudoservers
+ redistribute the messages?
+19:21 < jrand0m> (pseudoservers = peers in the channel who have the list
+ of users)
+19:21 < jeremiah> I don't think 'broadcasting' is that smart either, but it
+
+ seems like it'll require a _lot_ of bandwith for a given user who may be on
+ a modem, and with the lag from sending say... 20 messages separately would
+ screw up conversation
+19:21 < jeremiah> I don't know the best solution, maybe that would be one
+19:22 < jeremiah> I think direct messaging would be good if you wanted it,
+ but there are cases where it's probalby not that important
+19:22 <@hezekiah> The message would need to be signed by the authors private
+ key to garuntee authenticity.
+19:22 <@hezekiah> Though this issue won't matter for a long time still,
+ I think jeremiah has a point
+19:22 < jrand0m> hezekiah> that requires users wanting provable comm :)
+19:23 < jrand0m> definitely.
+19:23 <@hezekiah> If I had to send a message to 100 users in a channel ...
+19:23 < jeremiah> although my average message is only a few hundred bytes,
+ so sending it to hundreds of users might not be so hard
+19:23 <@hezekiah> ... well, my conversation would be /very/ slow.
+19:23 < jeremiah> especially if you didn't wait for a response
+19:23 <@hezekiah> 20K to send one message.
+19:23 <@hezekiah> I don't think so. :)
+19:23 < jrand0m> well, if there are 100 users in a channel, *someone* has
+ to send out 100 messages
+19:23 < jeremiah> it's 20k?
+19:23 < jeremiah> oh, right
+19:23 <@hezekiah> 200 users
+19:24 < jeremiah> hmm
+19:24 < jeremiah> wouldn't the routers be good at that?
+19:24 < jeremiah> we can somewhat safely assume they have decent bandwith,
+ right?
+19:24 <@hezekiah> I thought each person had a 'router implementation'
+19:24 < jrand0m> not really. if there are relays, the nomination mechanism
+ needs to take that into consideration
+19:24 < jrand0m> yes hezekiah
+19:24 < jeremiah> i haven't read the spec
+19:25 < jrand0m> a router is your local router
+19:25 <@hezekiah> Ugh!
+19:25 <@hezekiah> I'm still mixing your nicks up!
+19:25 <@hezekiah> lol
+19:25 < jrand0m> hehe
+19:25 <@hezekiah> Um ... where'd nop go?
+19:25 <@hezekiah> Oh.
+19:26 <@hezekiah> He's still here.
+19:26 <@hezekiah> I thought he was gone for a moment,
+19:26 < jrand0m> but jeremiah is right, psyc has some ideas we may want to
+ consider, though we may want to reject them
+19:26 <@hezekiah> Let's just get the network running first.
+19:26 * jrand0m drinks to that
+19:26 <@hezekiah> If you strech your vision to the finish line, you'll trip
+ over the rock 3 inches in front of you.
+19:27 * jeremiah feels inspired
+19:27 <@hezekiah> lol
+19:27 < jrand0m> I think what would be really great if we could aim to review
+ the network spec by next week, sending out emails to iip-dev whenever anyone
+ has thoughts or comments. am I out of my mind?
+19:27 <@hezekiah> nop? Do you have anything else to add to the agenda,
+ or do we adjurn?
+19:27 <@hezekiah> jrand0m: Well, I don't know if I could read all that by
+ next week, but I can try. :)
+19:27 < jrand0m> heh
+19:28 < jrand0m> its a grueling 15 pages ;)
+19:28 <@hezekiah> 15 pages?
+19:28 <@hezekiah> It looked more like 120!
+19:29 < jrand0m> heh, well, depends on your resolution I suppose ;)
+19:29 < jeremiah> he has a lot of anchors in there, makes it look like
+ it's huge
+19:29 < jrand0m> hehe
+19:29 <@hezekiah> The left side has a LOT more than 15 links, budy!
+19:29 <@hezekiah> 'Fess up!
+19:29 <@hezekiah> It's more than 15. :)
+19:29 <@hezekiah> Oh!
+19:29 <@hezekiah> Those aren't pages! They're just anchors!
+19:29 <@hezekiah> I'm saved!
+19:30 * hezekiah feels like a seaman just rescued from drowning
+19:30 < jeremiah> class turn to volume 4 chapter 2 Message Byte Structure
+19:30 < jrand0m> lol
+19:30 <@hezekiah> lol
+19:30 <@nop> adjourn
+19:30 <@hezekiah> *baf*!
+19:30 <@hezekiah> Next week, 21:00 UTC, same place.
+19:30 <@hezekiah> See y'all there. :)
+19:30 < jeremiah> seeya
+--- Log closed Tue Jul 15 19:30:51 2003
+
\ No newline at end of file
diff --git a/pages/meeting49.html b/pages/meeting49.html
new file mode 100644
index 00000000..1490756f
--- /dev/null
+++ b/pages/meeting49.html
@@ -0,0 +1,743 @@
+
+--- Log opened Tue Jul 15 17:46:47 2003
+17:46 < gott> yo.
+17:46 <@nop> just a heads up on my silence
+17:46 <@hezekiah> Tue Jul 15 21:46:49 UTC 2003
+17:47 <@hezekiah> OK. The iip-dev meeting has started.
+17:47 <@hezekiah> Is it the 48th or 49th?
+17:47 < jrand0m> nop> this is why its critical that we get the router
+ architecture pounded out asap. I understand that different people have
+ different rates of speed, and we must segment so different components can
+ proceed accordingly
+17:47 < mihi> 49th
+17:47 <@hezekiah> OK! Welcome to the 49th iip-dev meeting!
+17:47 < jrand0m> I have three more days at my job, after which 90+ hours /
+ week will be dedicated to getting this going
+17:48 < jrand0m> I know and don't expect everyone to be able to do that,
+ which is why we need to segment
+17:48 < jrand0m> hi hezekiah :)
+17:48 <@hezekiah> lol
+17:48 <@nop> to rebutt on that
+17:48 <@hezekiah> I'll wait a minute. Then we can do the agenda. :)
+17:48 <@nop> the security of the router architecture is dependant that you
+ do not rush as well
+17:49 <@nop> if we do
+17:49 <@nop> we overlook
+17:49 <@nop> which could leave us cleaning up a big mess later
+17:49 -!- Rain [Rain@anon.iip] has quit [I Quit]
+17:49 < jrand0m> nop> disagree. we can still build app layer and APIs
+ without implementing the router (or even knowing how the network will operate)
+17:49 <@nop> I agree with that
+17:50 <@nop> I'm specifically talking about the underlying network
+17:50 < jrand0m> if we can agree to the API I sent out, then thats the
+ segmentation we need
+17:50 < jrand0m> right, router impl and network design still isn't done
+17:50 <@nop> ok
+17:50 <@nop> oh, I can definitely agree with your api so far
+17:51 <@hezekiah> jrand0m: One problem.
+17:51 < jrand0m> shoot hezekiah
+17:51 <@hezekiah> It will look different if you implement it in C.
+17:51 < jrand0m> not too different
+17:51 < gott> oh dear
+17:51 < jrand0m> less capital letters, and replace the objects with structs
+17:51 < gott> what languages are people considering implementing it in?
+17:51 < jrand0m> (for the api)
+17:51 <@hezekiah> Uh, jrand0m? There is no 'byte[]' in C.
+17:51 < jrand0m> gott> read the mail archives for some example answers to that
+17:52 <@hezekiah> You will be using void*'s with an integer to specifiy the
+ length most likely.
+17:52 < jrand0m> hezekiah> then unsigned int[]
+17:52 < gott> jrand0m: for once, a religious war that I'm not a part of
+17:52 <@hezekiah> If I remember correctly (help me out here nop), you can't
+ just return an unsigned int[] from a function.
+17:53 <@hezekiah> gott: It's not a religious war. I'm just saying that the
+ API as a concept might be fine, but in C it would look seriously different.
+17:53 < gott> hezekiah: as opposed to what? pseudocode?
+17:53 < jrand0m> right, syntactic changes. but yes, if there are real
+ differences, we need to get them worked out ASAP. (like, today) Perhaps
+ now would be a good tiem to look at the email I sent entitled "high level
+ router architecture and API" and review?
+17:54 <@hezekiah> nop? UserX? Are you game for that?
+17:54 < jrand0m> not too different, but different none the less, yes.
+ which is why I said Java API on todays email :)
+17:54 -!- WinBear [WinBear@anon.iip] has joined #iip-dev
+17:55 <@nop> wait
+17:55 <@nop> reading above
+17:55 -!- mihi_2 [~none@anon.iip] has joined #iip-dev
+17:55 -!- mihi is now known as nickthief60234
+17:55 -!- mihi_2 is now known as mihi
+17:55 < jrand0m> wb mihi
+17:55 < gott> btw, is this being live logged?
+17:55 -!- nickthief60234 [~none@anon.iip] has quit [EOF From client]
+17:55 <@hezekiah> gott: Yes.
+17:55 < mihi> redundancy rules ;)
+17:55 < gott> I'll just read it later on then.
+17:55 -!- gott [~gott@anon.iip] has left #iip-dev [gott]
+17:56 <@nop> ok
+17:56 <@nop> yes
+17:56 < WinBear> jrand0m: hi
+17:56 <@nop> definitely differences
+17:56 <@nop> what we need
+17:56 < jrand0m> heya WinBear
+17:56 <@nop> is a team of certain developers to write the main api level
+ controls for these languages
+17:56 <@nop> we know that jrand0m can handle java
+17:56 <@nop> and probably could team up with thecrypto as well
+17:56 <@nop> and hezekiah and the gang can do C
+17:56 <@nop> and jeremiah if he's willing
+17:56 <@nop> can do python
+17:56 <@hezekiah> I can do C++ too! ;-)
+17:56 <@nop> ok
+17:56 <@nop> C++ as well
+17:57 <@hezekiah> lol
+17:57 <@nop> C++ will probably work
+17:57 <@nop> with C
+17:57 <@nop> if you don't template the crap out of it
+17:57 < jrand0m> heh
+17:57 <@hezekiah> lol
+17:57 <@hezekiah> Actually, while MSVC can link C and C++ object files,
+ gcc doesn't seem to like that.
+17:57 <@nop> aka, stick to structs that are compatible with C, or is that
+ not viable
+17:57 < jrand0m> first question, prior to that, is what applications will use
+ these APIs? I know of apps that will want to use java, will iproxy be in C?
+17:58 <@hezekiah> nop: I don't think C and C++ are object compatible.
+17:58 <@nop> ok
+17:58 <@hezekiah> nop: C++ won't get along with C much better than Java.
+17:58 <@nop> well maybe USerX could do C
+17:58 <@nop> and you could pull C++
+17:58 <@hezekiah> We don
+17:58 <@nop> ?
+17:58 <@hezekiah> don't even need to _do_ C++ if you don't want to. It's
+ just that I prefer it.
+17:59 <@nop> well, the thing is
+17:59 <@nop> there are a lot of C++ developers
+17:59 <@nop> especially in the microsoft world
+17:59 <@hezekiah> Even in the Linux world. (see: KDE and Qt.)
+17:59 < jrand0m> C and C++ are binary compatible if you just make .so or .a
+17:59 < jrand0m> (btw)
+18:00 <@nop> can C be a good placement for C++, aka C++ developers would be
+ able to handle a c api easier than a C++ api with a c developer?
+18:00 <@hezekiah> jrand0m: Yeah. You can probably have libraries ... but if
+ you can
+18:00 <@hezekiah> jrand0m: can't even use classes, it sorta defeats the
+ purpose.
+18:00 <@nop> right
+18:00 <@nop> let's stick with C
+18:01 <@nop> because C++ coders can still call a C library rather easily
+18:01 <@hezekiah> If one module needs to call anothers functions, then they
+ had best both be the same language.
+18:01 <@hezekiah> nop: C++ coders will know C well enough ... though it
+ might take some work if they never /learned/ C.
+18:02 <@hezekiah> However, C coders wouldn't know C++ since C is just a
+ subset of C++.
+18:02 -!- logger_ [~logger@anon.iip] has joined #iip-dev
+18:02 -!- Topic for #iip-dev: logfiles will be online after the meeting:
+ http://wiki.invisiblenet.net/?Meetings
+18:02 [Users #iip-dev]
+18:02 [@hezekiah] [+Ehud ] [ leenookx] [ moltar] [ tek ]
+18:02 [@nop ] [ jeremiah] [ logger_ ] [ Neo ] [ WinBear]
+18:02 [@UserX ] [ jrand0m ] [ mihi ] [ ptsc ]
+18:02 -!- Irssi: #iip-dev: Total of 14 nicks [3 ops, 0 halfops, 1 voices,
+10 normal]
+18:02 < jrand0m> right
+18:02 -!- Irssi: Join to #iip-dev was synced in 9 secs
+18:02 < jrand0m> (with JMS :)
+18:02 <@nop> yep
+18:03 -!- You're now known as logger
+18:03 < jrand0m> ok, can we review the overall architecture to see whether
+ the APIs are even relevent first?
+18:03 <@nop> fine 18:04 < jrand0m> :)
+18:04 < jrand0m> ok, see the email I sent w/ the routerArchitecture.png.
+ any thoughts on that seperation?
+18:04 -!- tek [~tek@anon.iip] has quit []
+18:05 < WinBear> jrand0m: is that on the wiki?
+18:05 < jrand0m> WinBear> no, on the mailing list, though the archives
+ are down. lemmie add it to the wikki
+18:06 <@hezekiah> Correct me if I'm wrong ...
+18:07 <@hezekiah> ... but it looks like we're going to have 3 seperate API's
+ that are as similar as possible.
+18:07 <@hezekiah> Right?
+18:07 < jrand0m> yes hezekiah
+18:07 <@hezekiah> So since each API is in a different language, are they
+ going all each have seperate implementations?
+18:07 < jrand0m> yes
+18:07 <@hezekiah> Or is there a way for Java or Python to access a C library?
+18:08 < jrand0m> yes, but we don't want to go that route
+18:08 < mihi> for java: JNI
+18:08 <@hezekiah> So this talk about Java, C, C++, Python, etc. working
+ together is mute since they never will?
+18:08 < jrand0m> how do I attach an image to the wiki?
+18:08 <@hezekiah> Each API has its own backend written in that language.
+18:08 < jrand0m> no hezekiah, look at the diagram
+18:09 <@hezekiah> Oh, duh!
+18:09 <@hezekiah> The API's don't link to a backend.
+18:10 <@hezekiah> They talk via sockets.
+18:10 < jrand0m> si sr
+18:10 <@hezekiah> This is still a little confusing though.
+18:10 <@hezekiah> Give me a sec here. :)
+18:11 <@hezekiah> OK. What is the thing labeled 'transport'?
+18:11 < jrand0m> for example, bidirectional HTTP transport, SMTP transport,
+ plain socket transport, polling HTTP socket, etc
+18:11 < jrand0m> the thing that moves bytes between routers
+18:12 <@hezekiah> OK.
+18:12 <@hezekiah> So the diagram I'm looking at shows one person's computer.
+18:12 <@hezekiah> He has a router that talks to other people's computers
+ via the transports.
+18:12 < jrand0m> correct
+18:12 <@hezekiah> Person 1 (Alice) has 2 applications running.
+18:12 <@hezekiah> One is in C, the other in Java.
+18:13 <@hezekiah> Both are linked to a library (that's the API).
+18:13 < jrand0m> both are "linked" to seperate libraries (the APIs)
+18:13 <@nop> simple concept
+18:13 <@nop> yes
+18:13 <@hezekiah> Those libraries, take input from the program encrypt it,
+ and send it via sockets (unix or TCP) to the router ... which is another
+ program Alice is running.
+18:13 < jrand0m> correct
+18:14 <@hezekiah> OK. So it's kinda like isproxy being split in two.
+18:14 < jrand0m> bingo :)
+18:14 <@hezekiah> One part is low end and written in C, and the other is
+ high end and written in whatever.
+18:14 < jrand0m> exactly
+18:14 <@hezekiah> OK. I get it. :)
+18:14 < jrand0m> w00t
+18:14 <@hezekiah> So no language needs to play nice with any other language.
+18:14 < jrand0m> WinBear> sorry, I can't toss it on the wiki as it only
+ takes text :/
+18:15 <@hezekiah> Since they all comunicate with the router via sockets,
+ you could write an API in PASCAL for all the design cares.
+18:15 <@nop> yes
+18:15 <@nop> arbitrary
+18:15 < jrand0m> right
+18:15 <@nop> it handles arbitrary sockets
+18:15 < jrand0m> though some things need to be standardized (like the data
+ structures for Destination, Lease, etc)
+18:15 < WinBear> jrand0m: i get a vague idea based on what hezekiah is saying
+18:15 < jrand0m> word
+18:16 <@hezekiah> jrand0m: Right. The structure and order of the bytes that
+ go across that socket is set in a design somewhre
+18:16 <@hezekiah> somewhere.
+18:17 <@hezekiah> But you can still implement how those bytes are send and
+ received any joly way you please.
+18:17 <@nop> WinBear: it's the same exact way that the irc client works
+ with isproxy
+18:17 < jrand0m> exactly
+18:17 <@hezekiah> Good.
+18:17 <@hezekiah> I understand now. :)
+18:17 -!- moltar [~me@anon.iip] has left #iip-dev [moltar]
+18:17 <@nop> well
+18:17 <@nop> not exactly
+18:17 <@hezekiah> Uh oh.
+18:17 <@nop> but imagine how that works
+18:17 <@nop> and you can understand arbitrary sockets
+18:17 <@nop> isproxy just routes
+18:17 <@nop> and delivers
+18:18 <@nop> now jrand0m
+18:18 <@nop> quick question
+18:18 < jrand0m> si sr?
+18:18 <@nop> is this api designed for only new applications that are designed
+ to work on this network
+18:18 -!- mode/#iip-dev [+v logger] by hezekiah
+18:18 < WinBear> nop: with the highlevel replacing the irc client?
+18:18 < jrand0m> nop> yes. though a SOCKS5 proxy could use this API as well
+18:18 <@nop> or can it be able to have a middle man that can allow already
+ standard clients
+18:18 <@nop> for instance
+18:19 <@nop> so all we would have to do is write the middleman -> api
+18:19 < jrand0m> (but note that there's no 'lookup' service available -
+ no DNS for this network)
+18:19 < jrand0m> correct
+18:19 <@nop> so that we can support say Mozilla etc
+18:19 <@nop> so they can just code plugins
+18:19 < jrand0m> nop> yes
+18:19 <@nop> ok
+18:19 <@nop> or transports :)
+18:20 < jrand0m> (e.g. the SOCKS5 has the HTTP outproxies hardcoded to
+ destination1, destination2, and destination3)
+18:20 <@nop> ok
+18:20 < WinBear> i think i get it
+18:21 < jrand0m> w00t
+18:21 < jrand0m> ok, one of the things I had to think about in this design
+ was keeping the private keys in the app's memory space - the router never
+ gets a hold of destination private keys.
+18:21 <@hezekiah> So the application can send raw data over the I2P network
+ by sending it to the API, and it doesn't need to worry about the rest.
+18:22 <@hezekiah> Right?
+18:22 < jrand0m> that means the APIs need to implement the end to end part
+ of the crypto
+18:22 < jrand0m> exactly hezekiah
+18:22 <@hezekiah> OK.
+18:22 <@nop> yes
+18:22 <@nop> that's the idea
+18:22 <@nop> it does it for you
+18:22 <@nop> you just call the hook
+18:23 <@hezekiah> One quick question:
+18:23 <@hezekiah> This 'router' obviously needs to speak a certain protocol
+ over it's transports.
+18:23 < jrand0m> correct
+18:23 <@hezekiah> So it is possible to provide multiple implementations of
+ the router ...
+18:23 < jrand0m> yes
+18:24 <@hezekiah> ... as long as they both speak the same protocol.
+18:24 < jrand0m> (which is why the spec has placeholders for bitbuckets)
+18:24 < jrand0m> right
+18:24 <@hezekiah> So you have a router in Java, and one in C, and one
+ in PASCAL.
+18:24 * jrand0m cringes
+18:24 < jrand0m> but yeah
+18:24 <@hezekiah> And they all can talk together since they're talking over
+ TCP/IP using the same protocol.
+18:24 * WinBear jumps
+18:24 <@hezekiah> jrand0m: And yes. I don't remember my PASCAL days overly
+ fondly either.
+18:25 < jrand0m> well, Pascal can talk to the C one through the TCP transport,
+ and the C one can talk to the Java one over the HTTP transport, for example
+18:25 <@hezekiah> Right.
+18:25 < jrand0m> (transports talk to other like transports, routers manage
+ the messages delivered between them but don't deal with how they're delivered)
+18:26 <@hezekiah> The point I was looking to make was that the protocol is the
+ same, so it doesn't matter what language someone's router is implemented in.
+18:26 < jrand0m> right
+18:26 <@hezekiah> Cool.
+18:26 < jrand0m> now you understand why I said "who cares" to all the C vs
+ Java vs etc debates? :)
+18:26 <@hezekiah> Yup.
+18:26 <@hezekiah> lol
+18:27 <@hezekiah> I've got to hand it to you jrand0m. This will make it very
+ kind for develoeprs to write programs for this network.
+18:27 < jrand0m> heh, well, the API ain't quite original. this is how
+ Message Oriented Middleware (MOM) works
+18:27 <@hezekiah> And you could even make routers that specialize in certain
+ platform specific features (like 64-bit CPU's).
+18:28 < jrand0m> absolutely
+18:28 <@hezekiah> jrand0m: Humble too! ;-)
+18:28 <@hezekiah> Well, it looks good to me.
+18:28 < jrand0m> ok, UserX, nop, does this seperation make sense?
+18:28 <@nop> of course
+18:28 <@nop> is userx still here
+18:29 <@hezekiah> He's been idle for 1:26.
+18:29 < jrand0m> 'k. so then we have two tasks: design the network, and
+ design how the API works.
+18:29 <@nop> right
+18:29 <@hezekiah> Quick simple question: The API's do end to end crypto. Do
+ the routers to node to node crypto ?
+18:29 <@nop> yes
+18:30 < jrand0m> yes
+18:30 < jrand0m> (transport level)
+18:30 <@hezekiah> Good. :)
+18:30 <@nop> hezekiah: it's very similar to what we have so far
+18:30 <@nop> in that aspect
+18:31 < jrand0m> ok.. er, shit, thecrypto aint around for comments on the
+ performance model.
+18:31 < Neo> and for the paranoid, the apps can do the pgp encryption before
+ it hits the API ;)
+18:31 < jrand0m> absolutely neo
+18:31 < jrand0m> I was even tempted to leave the end to end crypto out of
+ the API and leave it up to the apps...
+18:31 <@hezekiah> jrand0m: That would be cruel.
+18:31 < jrand0m> heheh
+18:32 <@hezekiah> BTW, the API's and the router communicate via sockets.
+18:32 <@hezekiah> On UNIX will they be using UNIX sockets or local TCP/IP
+ sockets?
+18:32 < jrand0m> prolly just local tcp/ip for simplicity
+18:32 <@nop> hold
+18:32 <@hezekiah> (I suppose you could make a router that accepts both.)
+18:33 * hezekiah is really liking this interchangable parts setup
+18:33 <@nop> if you hold on a sec
+18:34 <@hezekiah> Holding ... :)
+18:34 <@nop> I'll call thecrypto at his house
+18:34 <@nop> see if he can get on
+18:34 < jrand0m> hehe word
+18:34 <@hezekiah> lol
+18:34 * hezekiah dons a thick Itallian accent
+18:34 <@hezekiah> Nop ha' got ... CONNECTIONS!
+18:34 < jeremiah> lo
+18:34 <@nop> hey jeremiah
+18:35 < jrand0m> heya jeremiah
+18:35 <@nop> would you be willing at the api level to assist with a python api
+18:35 < jeremiah> sure
+18:35 * jeremiah reads backlog
+18:35 < jrand0m> heh word
+18:35 * nop is calling
+18:36 <@nop> he's not home
+18:36 <@nop> he'll be back in an hour
+18:36 < jrand0m> 'k, has anyone else read the .xls and/or have comments on
+ the model?
+18:37 <@hezekiah> I read the .xls ... but I don't know much about p2p so
+ most of it was over my head.
+18:37 <@hezekiah> UserX is good at that stuff.
+18:37 <@nop> I have to read it still
+18:37 < jrand0m> (btw, morphmix had some insane numbers... they were saying
+ they could expect random hosts on the net to have average 20-150ms ping times,
+ rather than the 3-500 I was expecting)
+18:37 < jrand0m> coo'
+18:37 <@nop> it's staroffice or openoffice?
+18:37 < jrand0m> openoffice, but I exported it to .xls
+18:37 <@nop> which is excell?
+18:37 < jrand0m> correct
+18:38 <@hezekiah> BTW, concerning the API ...
+18:38 < jrand0m> si sr?
+18:38 <@hezekiah> ... in C the boolean would be int.
+18:38 <@nop> which email
+18:38 <@nop> hezekiah: yes
+18:38 <@hezekiah> The classes would be sent as structure pointers.
+18:38 <@nop> unless you typedef boolean
+18:39 <@hezekiah> And the functions that use byte[] would use a void* with
+ an additional parameter that specefies the length of the buffer.
+18:39 <@nop> hezekiah: you're being picky :)
+18:39 < jrand0m> nop> I cant access the archives so I'm not sure what the
+ subject line was, but it was last week...
+18:39 <@nop> save it for a later time
+18:39 <@hezekiah> nop: Picky?
+18:39 < jrand0m> heh, yeah, y'all working on the C api can work that detail out
+18:39 * jeremiah is done reading backlog
+18:39 <@nop> what's the file called
+18:39 <@hezekiah> nop: I'm just trying to find all the stuff that is different,
+ so we can hammer it out like jrand0m asked.
+18:40 <@hezekiah> I'm trying to be helpful. :)
+18:40 <@nop> hezekiah: yes, probably off meeting time
+18:40 < jrand0m> nop> simple_latency.xls
+18:40 <@hezekiah> boolean sendMessage(Destination dest, byte[] payload);
+18:40 <@hezekiah> would be
+18:40 <@hezekiah> int sendMessage(Destination dest, void* payload, int length);
+18:40 <@hezekiah> .
+18:40 <@hezekiah> byte[] recieveMessage(int msgId);
+18:40 <@hezekiah> that could either be:
+18:41 <@hezekiah> void* recieveMessage(int msgId, int* length);
+18:41 <@hezekiah> or
+18:41 <@nop> jrand0m: got it
+18:41 <@hezekiah> void recieveMessage(int msgId, void* buf, int* length);
+18:41 <@hezekiah> or
+18:41 < jrand0m> hezekia: why not typedef struct { int length; void* data;
+ } Payload;
+18:41 <@hezekiah> DataBlock* recieveMessage(int msgId)l
+18:41 <@hezekiah> DataBlock* recieveMessage(int msgId);
+18:41 < jeremiah> where's this xls?
+18:41 <@nop> oh iip-dev
+18:41 <@hezekiah> jrand0m: The struct you just mentioned is basically what
+ DataBlock is.
+18:42 < jrand0m> word hezekiah
+18:42 <@nop> subject more models
+18:42 <@hezekiah> Chances are the C version would have DataBlocks.
+18:43 <@hezekiah> Beyond that the only other thing to note is that each
+ 'interface' would just be a set of functions.
+18:43 <@hezekiah> nop: Did I find all the differences that would exist in
+ a C API?
+18:43 < jrand0m> right. perhaps #include "i2psession.h" or something
+18:43 < jeremiah> is there a mockup python api?
+18:44 < jrand0m> no jeremiah, I don't really know python :/
+18:44 <@nop> I would have to re-review the java api, but I would say that
+ you're right on target
+18:44 < jrand0m> but it would probably be similar to the java, as python is OO
+18:44 < jeremiah> cool, i can derive one from the C one
+18:44 * nop is not a java head
+18:44 < jrand0m> cool jeremiah
+18:44 < jeremiah> is the c api in the thing you sent out a few days ago?
+18:44 <@hezekiah> Yeah. Python should be able to handle the Java api.
+18:44 < jrand0m> jeremiah> that was the Java one
+18:45 < jrand0m> oh, the Java one was today
+18:45 < jrand0m> the older one was language independent
+18:45 <@hezekiah> Hmm
+18:45 <@nop> UserX says he should be able to assist with C api
+18:45 < jrand0m> word
+18:45 <@nop> he's busy at work at the moment
+18:46 < jrand0m> coo'
+18:46 <@hezekiah> One last note: With the C api, each function would probably
+ take a structure* to the structure that it is an 'interface' of in Java.
+18:46 <@nop> hezekiah: loos good
+18:46 <@nop> looks good
+18:46 <@hezekiah> I2PSession createSession(String keyFileToLoadFrom,
+ Properties options);
+18:46 <@hezekiah> would be:
+18:46 <@nop> java and their non-native data types
+18:46 <@hezekiah> I2PSession* createSession(I2PClient* client, char*
+ keyFileToLoadFrom, Properties* options);
+18:46 <@nop> ;)
+18:46 < jrand0m> hehe
+18:46 < jrand0m> right hezekiah
+18:47 < jeremiah> are we addressing unicode?
+18:47 <@hezekiah> Anyway, if you can live with those differences, the C and
+ Java API's should be identical beyond that.
+18:47 <@hezekiah> nop? Unicode? :)
+18:47 < jrand0m> UTF8 if not UTF16
+18:48 <@hezekiah> Perhaps Unicode should be dealt with on the application
+ level.
+18:48 < jrand0m> right, charset is all the content of the message
+18:48 <@hezekiah> Oh.
+18:48 < jeremiah> ok
+18:48 <@hezekiah> Java String's are done in Unicode, aren't they jrand0m?
+18:48 < jrand0m> the bitbuckets'll all be bit defined
+18:48 < jrand0m> yes hezekiah
+18:48 < jrand0m> (unless you explicitly instruct them to change charsets)
+18:49 <@hezekiah> So the string sent to the Java API would be different than
+ the one sent to the C API unless the C API implements strings using Unicode.
+18:49 < jrand0m> not relevent
+18:49 <@hezekiah> OK.
+18:49 < jrand0m> (app->API != API->router. we only define API->router)
+18:49 <@hezekiah> What I'm saying is this, jrand0m:
+18:50 <@hezekiah> If I set my password with the Java API, it goes to the
+ router out someplace else.
+18:50 < jrand0m> password? you mean you create a Destination?
+18:50 <@hezekiah> Then it find another router, which sends it to another API
+ (?) which is implemented in C.
+18:50 <@hezekiah> void setPassphrase(String old, String new);
+18:50 <@hezekiah> That function.
+18:51 < jrand0m> hezekiah> thats the administrative password to access the
+ administrative methods of the router
+18:51 <@hezekiah> Ah
+18:51 <@hezekiah> Do any functions in the API which use Java String's end
+ up with that String being sent to another API?
+18:51 < jrand0m> 99.9% of apps will only use I2PSession, not I2PAdminSession
+18:51 <@nop> also, anything carried with the router gets converted for
+ network travel correct?
+18:51 <@hezekiah> If so, we should probably use Unicode.
+18:51 <@nop> unicode wouldn't be releavant
+18:52 < jrand0m> hezekiah> no. all inter-router info will be defined by
+ bit buckets
+18:52 <@hezekiah> OK.
+18:52 < jrand0m> correct nop, at the transport level
+18:52 <@hezekiah> (I'm assuming a bit bucket is just a binary buffer, right?)
+18:53 < jrand0m> a bit bucket is a statement that the first bit means X,
+ the second bit means Y, bits 3-42 mean Z, etc
+18:53 < jrand0m> (e.g. we may want to use X.509 for the certificates bitbucket)
+
+18:53 <@hezekiah> I've never dealt with that before.
+18:54 <@hezekiah> I'll worry about it when I get there. :)
+18:54 < jrand0m> heh word
+18:55 < jrand0m> ok, the four things I wanted us to hit today: *router
+ architecture, *performance model, *attack analysis, *psyc. We've done
+ the first, thecrypto is offline so perhaps we delay this (unless you have
+ thoughts on the model nop?)
+18:57 <@hezekiah> Um ... jrand0m. I have yet another question.
+18:57 < jeremiah> jrand0m: where's the latest version of the network spec? is
+ it what you sent out on the 13th?
+18:57 < jrand0m> si sr?
+18:57 <@hezekiah> Well the router architecture has the API's handle keys
+ /sent to them by the Application/.
+18:57 < jrand0m> jeremiah> yes
+18:57 <@nop> I don't at this time
+18:58 <@hezekiah> Now ... the only way I see that the API gets the key is
+ from createSession.
+18:58 < jrand0m> hezekiah> the router gets public keys and signatures,
+ not private keys
+18:58 < jrand0m> right
+18:58 <@hezekiah> But that requires a file.
+18:58 < jrand0m> the keys are stored in a file or in the API's memory
+18:58 < jrand0m> yes
+18:58 <@hezekiah> Now if the application generates a key, why can't it just
+ send it to the API via a buffer?
+18:59 <@hezekiah> Must it really store it in a file, and then provide the
+ file name?
+18:59 < jrand0m> no, it can be in memory if you'd like
+18:59 <@hezekiah> There is not function to all that in the API though.
+18:59 <@hezekiah> It's just a thought.
+19:00 <@hezekiah> If the key is supposed to be generated only once and used
+ many, many times (like GPG keys), then a file makes sense.
+19:00 -!- mihi [none@anon.iip] has quit [bye all, it's getting late...]
+19:00 <@hezekiah> But if it will be generated more often, then perhaps some
+ way to directly send it to the API via a structure or buffer of some sort
+ might be nice
+19:00 <@hezekiah> .
+19:01 < jrand0m> yes, its generated once and only once (unless you're wearing
+ a tinfoil hat)
+19:02 < jrand0m> though the createDestination(keyFileToSaveTo) lets you
+ create that key
+19:02 <@hezekiah> OK.
+19:02 <@hezekiah> So there's really no need for transfer directly from the
+ App to the API. A file will suffice.
+19:03 <@hezekiah> So where were we before I so rudely interupted? :)
+19:06 < jeremiah> so right now we're just working on the router API, not
+ the client one, right?
+19:06 < jrand0m> well, we're skipping on performance analysis for now
+ (hopefully we can get some chatter re: it on the mailing list before next
+ week?). and probably the same wrt attack analysis (unless anyone read the
+ new spec and has comments)
+19:07 <@hezekiah> So we're since we're skipping that, what are we supposed
+ to be talking about now?
+19:07 <@hezekiah> Psyc?
+19:07 < jrand0m> unless anyone else has other comments to bring up...?
+19:08 <@hezekiah> Well, for once, my comment hole (also notoriously known
+ as my mouth) is empty.
+19:08 < jrand0m> hehe
+19:09 < jrand0m> ok, anyone have any thoughts on how the IRC side of things
+ will work, and whether psyc may be relevent or useful?
+19:09 < jeremiah> sidenote (that pissed me off): wired's "Wired, Tired,
+ Expired" list had Waste as 'wired'
+19:09 < jrand0m> heh
+19:09 < jrand0m> do you realize how much we're going to blow everyone away?
+19:09 < jeremiah> yep
+19:09 <@hezekiah> jrand0m: That assumes we get this to work.
+19:10 < jrand0m> I guarantee it will work.
+19:10 <@hezekiah> There are a lot of other failed efforts out there.
+19:10 < jrand0m> I quit my job to work on this.
+19:10 <@hezekiah> Then we're going to blow everyone away. :)
+19:10 <@hezekiah> Yeah. How is bread getting on the table when you do that?
+19:10 <@hezekiah> GPL code doesn't pay well. ;-)
+19:10 < jrand0m> heh
+19:11 <@hezekiah> As for psyc ... let me put it this way:
+19:11 <@hezekiah> The first time I heard of it was when you emailed us
+ about it.
+19:11 < jrand0m> shit, I wasn't the one who found it :)
+19:11 <@hezekiah> However, IRC is probably one of the most (if not /the/
+ most) prolific chat protocols around.
+19:11 <@hezekiah> People will want IRC apps LONG before they even /know/
+ what psyc is.
+19:11 <@hezekiah> jrand0m: Oops. Sorry. I forgot that detail. :)
+19:12 < jrand0m> not according to psyc. their history goes back to 86 I think
+19:12 <@hezekiah> The point is that the supperiority of the protocol, isn't
+ really as relevant as to who uses it.
+19:12 <@hezekiah> Their _history_ may go back that far.
+19:12 <@hezekiah> But how many people _use_ Psyc?
+19:12 < jeremiah> yeah if they've been around since a year after I was born
+ (ahem) and they aren't that big yet
+19:12 <@hezekiah> My point is that even if it's a better protocol, most
+ people _use_ IRC.
+19:13 <@hezekiah> We can make the best I2P network on the planet ...
+19:13 -!- Ehud [logger@anon.iip] has quit [Ping timeout]
+19:14 < jeremiah> can someone explain briefly why we care? I thought IRC
+ would only be one possible application but that the network is flexible to
+ support psyc as well if it wanted to
+19:14 <@hezekiah> Right.
+19:14 <@hezekiah> Psyc can be made ...
+19:14 <@hezekiah> ... but I'm saying we should do IRC first because more
+ people use it.
+
+19:14 <@hezekiah> jrand0m, we can make a great I2P network, but people won't
+ use it unless it has something they want.
+19:14 < jrand0m> jeremiah> the reason psyc is interesting is that we may
+ want to implement IRC in the same vein that psyc works
+19:15 <@hezekiah> Hence we should provide them with a 'killer-app'.
+19:15 < jeremiah> ok
+19:15 < jrand0m> right, IIP is invisible IRC project, and will allow people
+ to run IRC
+19:16 < jrand0m> with no central server (or any server at all, actually),
+ theres a lot of thinking to be done to figure out how IRC will work.
+ psyc has a possible answer to that
+19:16 < jrand0m> though there are others
+19:17 <@hezekiah> As I said, psyc might do better, but people want to use IRC,
+ not psyc.
+19:17 < jrand0m> and they will
+19:17 < jrand0m> they'll use irc
+19:17 <@hezekiah> It's all about marketing, baby! ;-)
+19:17 < jeremiah> I'll try to read the spec and some stuff on psyc tonight
+19:17 < jrand0m> word
+19:17 <@hezekiah> lol
+19:17 < jeremiah> planning to meet at 5:00 UTC tommorow?
+19:17 <@hezekiah> No?
+19:18 < jeremiah> or whenever
+19:18 < jrand0m> I'm on iip 24x7 :)
+19:18 < jeremiah> yeah but i eat
+19:18 <@hezekiah> jrand0m: I noticed.
+19:18 < jrand0m> 05:00 utc or 17:00 utc?
+19:18 <@hezekiah> jeremiah: LOL!
+19:18 <@hezekiah> Well the iip-dev meeting officially starts at 21:00 UTC.
+19:18 -!- Ehud [~logger@anon.iip] has joined #iip-dev
+19:19 < jeremiah> ok, i just said 05:00 UTC because I was talking out of my ass
+19:19 < jeremiah> where's mids?
+19:19 <@hezekiah> mids, left the project for a while.
+19:19 <@hezekiah> Weren't you there a few meetings back?
+19:19 < jeremiah> ok
+19:19 < jeremiah> guess not
+19:19 <@hezekiah> We had a goodbye party of sorts as part of the agenda.
+19:19 < jeremiah> oh
+19:20 <@hezekiah> OK ...
+19:20 <@hezekiah> Is there anything still on the agenda?
+19:20 * jrand0m doesn't have any left on mine
+19:20 < jeremiah> about psyc:
+19:20 < jeremiah> if this is a psyc feature, I know you mentioned it a
+ while ago
+19:20 * hezekiah never had an agenda in the first placve
+19:21 <@hezekiah> pace
+19:21 <@hezekiah> place
+19:21 < jeremiah> I don't think having each user send a message to every
+ other use in the room is s smart idea
+19:21 <@hezekiah> There!
+19:21 < jrand0m> jeremiah> so you'd have redundant nominated pseudoservers
+ redistribute the messages?
+19:21 < jrand0m> (pseudoservers = peers in the channel who have the list
+ of users)
+19:21 < jeremiah> I don't think 'broadcasting' is that smart either, but it
+
+ seems like it'll require a _lot_ of bandwith for a given user who may be on
+ a modem, and with the lag from sending say... 20 messages separately would
+ screw up conversation
+19:21 < jeremiah> I don't know the best solution, maybe that would be one
+19:22 < jeremiah> I think direct messaging would be good if you wanted it,
+ but there are cases where it's probalby not that important
+19:22 <@hezekiah> The message would need to be signed by the authors private
+ key to garuntee authenticity.
+19:22 <@hezekiah> Though this issue won't matter for a long time still,
+ I think jeremiah has a point
+19:22 < jrand0m> hezekiah> that requires users wanting provable comm :)
+19:23 < jrand0m> definitely.
+19:23 <@hezekiah> If I had to send a message to 100 users in a channel ...
+19:23 < jeremiah> although my average message is only a few hundred bytes,
+ so sending it to hundreds of users might not be so hard
+19:23 <@hezekiah> ... well, my conversation would be /very/ slow.
+19:23 < jeremiah> especially if you didn't wait for a response
+19:23 <@hezekiah> 20K to send one message.
+19:23 <@hezekiah> I don't think so. :)
+19:23 < jrand0m> well, if there are 100 users in a channel, *someone* has
+ to send out 100 messages
+19:23 < jeremiah> it's 20k?
+19:23 < jeremiah> oh, right
+19:23 <@hezekiah> 200 users
+19:24 < jeremiah> hmm
+19:24 < jeremiah> wouldn't the routers be good at that?
+19:24 < jeremiah> we can somewhat safely assume they have decent bandwith,
+ right?
+19:24 <@hezekiah> I thought each person had a 'router implementation'
+19:24 < jrand0m> not really. if there are relays, the nomination mechanism
+ needs to take that into consideration
+19:24 < jrand0m> yes hezekiah
+19:24 < jeremiah> i haven't read the spec
+19:25 < jrand0m> a router is your local router
+19:25 <@hezekiah> Ugh!
+19:25 <@hezekiah> I'm still mixing your nicks up!
+19:25 <@hezekiah> lol
+19:25 < jrand0m> hehe
+19:25 <@hezekiah> Um ... where'd nop go?
+19:25 <@hezekiah> Oh.
+19:26 <@hezekiah> He's still here.
+19:26 <@hezekiah> I thought he was gone for a moment,
+19:26 < jrand0m> but jeremiah is right, psyc has some ideas we may want to
+ consider, though we may want to reject them
+19:26 <@hezekiah> Let's just get the network running first.
+19:26 * jrand0m drinks to that
+19:26 <@hezekiah> If you strech your vision to the finish line, you'll trip
+ over the rock 3 inches in front of you.
+19:27 * jeremiah feels inspired
+19:27 <@hezekiah> lol
+19:27 < jrand0m> I think what would be really great if we could aim to review
+ the network spec by next week, sending out emails to iip-dev whenever anyone
+ has thoughts or comments. am I out of my mind?
+19:27 <@hezekiah> nop? Do you have anything else to add to the agenda,
+ or do we adjurn?
+19:27 <@hezekiah> jrand0m: Well, I don't know if I could read all that by
+ next week, but I can try. :)
+19:27 < jrand0m> heh
+19:28 < jrand0m> its a grueling 15 pages ;)
+19:28 <@hezekiah> 15 pages?
+19:28 <@hezekiah> It looked more like 120!
+19:29 < jrand0m> heh, well, depends on your resolution I suppose ;)
+19:29 < jeremiah> he has a lot of anchors in there, makes it look like
+ it's huge
+19:29 < jrand0m> hehe
+19:29 <@hezekiah> The left side has a LOT more than 15 links, budy!
+19:29 <@hezekiah> 'Fess up!
+19:29 <@hezekiah> It's more than 15. :)
+19:29 <@hezekiah> Oh!
+19:29 <@hezekiah> Those aren't pages! They're just anchors!
+19:29 <@hezekiah> I'm saved!
+19:30 * hezekiah feels like a seaman just rescued from drowning
+19:30 < jeremiah> class turn to volume 4 chapter 2 Message Byte Structure
+19:30 < jrand0m> lol
+19:30 <@hezekiah> lol
+19:30 <@nop> adjourn
+19:30 <@hezekiah> *baf*!
+19:30 <@hezekiah> Next week, 21:00 UTC, same place.
+19:30 <@hezekiah> See y'all there. :)
+19:30 < jeremiah> seeya
+--- Log closed Tue Jul 15 19:30:51 2003
+
\ No newline at end of file
diff --git a/pages/meeting50.html b/pages/meeting50.html
new file mode 100644
index 00000000..0425fe68
--- /dev/null
+++ b/pages/meeting50.html
@@ -0,0 +1,594 @@
+--- Log opened Tue Jul 22 15:56:06 2003 +15:56 <@hezekiah> jrand0m: Righto! +15:56 -!- mode/#iip-dev [+o jrand0m] by hezekiah +15:56 <@cohesion> log enabled +15:56 <@jrand0m> w00t +15:56 <@nop> we need to add cohesion and remove mids on dev list +15:56 <@hezekiah> Excelent. :) +15:56 <@hezekiah> What dev list? +15:56 <@cohesion> nop: i tried CVS and it wouldn't accept my user/pass +15:56 <@nop> ok, I'll add you +15:56 <@nop> hold +15:56 <@nop> what is your sf id +15:56 <@cohesion> cohesion +15:56 <@nop> pmsg me if you need +15:56 <@nop> ok +15:57 <@cohesion> i think +15:57 -!- thecrypto [thecrypto@anon.iip] has joined #iip-dev +15:57 <@hezekiah> BTW, everyone I will be leaving around 22:15. +15:57 <@hezekiah> UTC +15:57 <@cohesion> yea +15:57 <@cohesion> hezekiah: okay +15:58 <@nop> cohesion: you're in +15:58 <@nop> we need to update website +15:58 <@cohesion> nop: okay +15:58 <@cohesion> nop: i'll try it now +15:58 <@nop> and we need to start modelling the IIP with an I2P +15:58 < thecrypto> hey +15:58 < thecrypto> i made it +15:58 <@nop> ok +15:58 <@nop> werd +15:58 <@nop> ;) +16:00 <@hezekiah> jrand0m? I just looked at your revision to the +development schedual. +16:00 <@jrand0m> si sr? +16:00 <@hezekiah> The graph with the bars and lines gets chopped off at +the right hand side; I can't see the rest of it. +16:01 <@jrand0m> yeah, ganttproject isn't quite perfect, but its better +than doing it by hand. +16:01 <@jrand0m> the things at the far right are the last tasks - +nothing is after them +16:01 <@hezekiah> But I can +16:01 <@jrand0m> the tasks there are listed, in order, on the +index-tasks.html +16:01 <@hezekiah> can't even see what the tasks are. +16:02 <@hezekiah> OK. :) I'll just have to settle for text. +16:02 <@hezekiah> nop: Are we going to start soon? I'm going to have to +leave at 22:15 UTC, but I'd like to catch as much of the meeting as +possible. +16:02 <@jrand0m> let me see if I can make a big task to fix that... +16:02 <@hezekiah> jrand0m: Thanks. :) +16:03 <@nop> yes +16:03 <@nop> alright +16:03 <@nop> agenda +16:03 <@nop> 1) +16:03 <@nop> welcome +16:03 <@nop> 2) +16:03 <@nop> Website future +16:03 <@nop> 3) +16:03 <@nop> bug fixes with 1.1 +16:03 <@nop> 4) +16:03 <@nop> I2P +16:03 <@nop> 5) +16:03 <@nop> Suggestions and comments +16:03 <@nop> welcome all +16:04 <@nop> moving to 2 +16:04 <@nop> website +16:04 <@nop> cohesion, are your maintanance website skills up to par? +16:04 <@cohesion> aye +16:04 <@cohesion> XHTML and CSS are my specialties +16:04 <@nop> ok, we are assuming you can do website stuff, changes etc +16:04 <@nop> ok +16:04 <@cohesion> yep +16:05 <@cohesion> granted that i can get CVS to cooperate :) +16:05 <@nop> easy +16:05 <@nop> export CVS_RSH=ssh +16:05 <@nop> and don't use pserver +16:05 <@nop> use d:ext +16:05 <@cohesion> i'm using gruntspud to CVS interfacing +16:05 <@nop> ok +16:05 <@cohesion> it's part of my text editor +16:05 <@cohesion> it should work +16:05 <@cohesion> we can talk about that later though +16:05 <@cohesion> i'm trying it now +16:05 -!- thecrypto [thecrypto@anon.iip] has quit [Ping timeout] +16:05 <@nop> if you have issues let me know right away if you can, so I +can assist this because I have a bunch of tasks +16:06 <@nop> also +16:06 <@nop> we need to look at making an I2P section +16:06 <@nop> since it's going to be the next big project +16:06 <@nop> I'll talk to ellison to see if he's contribute a bit of his +web design skills to add to that for a template +16:06 <@hezekiah> Should I2P be a section of invisiblenet.net or +invisiblenet.net/iip? (I vote for the former.) +16:06 <@nop> and we can get that hashed out +16:06 <@cohesion> ok +16:06 <@nop> former as well +16:06 <@jrand0m> former +16:06 <@nop> it would be under projects +16:07 -!- thecrypto [~thecrypto@anon.iip] has joined #iip-dev +16:07 <@nop> iip is one project +16:07 <@nop> i2p is another +16:07 <@hezekiah> So, invisiblenet.net/i2p +16:07 <@nop> yes +16:07 <@hezekiah> Right. That's the way I see it too. :) +16:07 <@nop> anyone here good at making a logo? +16:07 <@nop> volunteers are welcome +16:07 <@nop> just submit to iip-dev list +16:07 <@nop> ok moving on +16:07 <@nop> bug fixes in 1.1 +16:07 <@jrand0m> h/o +16:07 * hezekiah would like to point out that his skills at the GIMP are +to be avoided like WMD. +16:08 <@jrand0m> would it be possible to keep the i2p stuff off the web +until we're ready for beta? +16:08 <@cohesion> i suggest we use the wiki for collaborating on the i2p +documents +16:08 <@nop> yes +16:08 <@cohesion> i can set up a restricted area +16:08 <@nop> that's possible +16:08 <@hezekiah> jrand0m: Are you thinking of a big smash announcement +on /. or something once we have it in good order? +16:08 <@nop> cohesion: I concur +16:08 <@jrand0m> yes hezekiah +16:08 <@jrand0m> word cohesion +16:09 <@nop> ok +16:09 <@nop> let's look at 1.1 for a sec +16:09 <@nop> hezekiah you made a discovery, that has not to do with +focus? +16:09 <@nop> or what? +16:10 <@hezekiah> The code is fine. +16:10 <@hezekiah> The problem is communication, not code. +16:10 <@hezekiah> The user has to move the mouse aroung _inside_ the +dialog box. +16:10 < mihi> the dialog lacks a progress bar to give feedback if the +user does it correctly +16:10 <@nop> yes that's true +16:10 <@hezekiah> He can move the mouse around _outside_ the dialog box +until he's blue in the face, but it won't gather entropy. (Which is what +these users are doing.) +16:10 <@nop> it does lack a dialog box +16:11 <@hezekiah> A progress bar would be a plus. +16:11 <@hezekiah> And should be somewhat easy to implement ... if I +could understand the tangle that UI code in IIP is. +16:11 <@cohesion> or even some feedback +16:11 <@hezekiah> Anyway, I posted my suggestions to the mailing list. +16:12 <@nop> it's in win32 api +16:12 <@nop> ;) +16:12 <@hezekiah> Either capture the mouse (I couldn't get M$ to +cooperate to do that), or make the dialog box message explain to the +user he needs to move the mouse around _inside_ the dialog box. +16:12 <@hezekiah> nop: I know. +16:12 <@nop> fine hezekiah be that way :) +16:12 <@hezekiah> What? +16:12 <@hezekiah> What did I do? +16:12 * hezekiah is confused +16:12 < thecrypto> how about just maximize the dialog box? +16:12 <@nop> hezekiah: I'm just messin' with ya +16:13 <@hezekiah> nop: OK. :) +16:13 <@hezekiah> Where's UserX? He knows more about the IIP UI code +than I do. +16:14 <@hezekiah> thecrypto: As for maximizing, well, the user might not +like a rabid dialog box consuming his entire screen. +16:14 <@hezekiah> Mouse capture is ideal, but as I said, I couldn't get +M$ to do it. +16:14 <@jrand0m> many other apps don't capture the mouse +16:14 <@jrand0m> a status bar plus explaination seems typical +16:15 <@hezekiah> Anyway, that's the 'bug'. +16:15 <@hezekiah> How do you want it fixed nop? +16:15 <@nop> well +16:15 <@nop> I would think if possible we could have a meter that shows +the entropy gathering for sure +16:16 <@hezekiah> OK. +16:16 <@nop> and definitely fixes the language. Have you exhausted the +research on capturing the mouse movements? +16:16 <@hezekiah> To the point of my patience. +16:16 <@hezekiah> Seriously, what I did _should_ work. +16:16 <@nop> I assume that's a lot? +16:16 <@hezekiah> Well, I didn't get much sleep last night. +16:17 <@nop> hmm +16:17 <@nop> let's try to get a meter bar and the language fixed +16:17 <@nop> that will give us an idea +16:17 <@hezekiah> Because it isn't working, I'm assuming the M$ docs are +lieing to me (very possible) or something 'unknown' is happening in the +IIP UI code. +16:17 <@nop> right +16:17 <@hezekiah> Righto. :) +16:17 * hezekiah now gets down on his knees and prays that UserX wrote +UI code for a progress bar. +16:19 <@nop> haha +16:19 <@nop> if not go to planet-source-code.com +16:19 <@nop> there's a lot of samples there +16:19 <@hezekiah> The win32 API I can manage (though I detest it.) +16:19 <@nop> I hate it as well +16:19 <@hezekiah> But UserX/whoever-originally-wrote-this made a wrapper +around it. +16:19 <@hezekiah> It's the wrapper I'm worried about. +16:19 * nop is coding in it right now for work +16:19 <@hezekiah> I'm looking into it now. +16:20 <@hezekiah> Let's move on to the next agenda item. +16:20 -!- jeremiah-gym is now known as jeremiah +16:20 <@nop> ok +16:20 <@nop> next item is i2p +16:20 < jeremiah> hi +16:20 <@nop> hi +16:20 <@nop> jrand0m you start +16:20 <@hezekiah> jeremiah: Just in time! +16:20 < jeremiah> hezekiah: nop and I are oddly time synced, as you'll +learn +16:20 <@jrand0m> 'k, has everyone had a chance to check out the roadmap? +16:21 <@hezekiah> Yeah. +16:21 <@jrand0m> its obviously draft, and things after the 1.0 milestone +are largely up in the air, but its something to start from +16:21 <@jrand0m> I've updated it beyond whats on the list to include +hezekiah jumping on the C api (w00t!) +16:22 -!- jeet [~miteymous@anon.iip] has joined #iip-dev +16:22 <@jrand0m> basically, after this coming friday, we'll have the API +protocol spec'ed out, which will mean we can parallelize a lot +16:22 < jeet> hello ;) +16:22 <@jrand0m> 'lo jeet +16:23 < jeet> hey if i make a server is it possible to change anon.iip +to whatever i want +16:23 <@jrand0m> rough gut question: how insane does the r2 roadmap +sound? are schedules insane, are there things missing, are things in the +wrong order or dependencies not represented? +16:23 <@nop> yes +16:23 < jeet> kewl +16:24 <@hezekiah> jrand0m: I would concur the entire thing is insane. +However, I think (until I get to college) it should be doable. +16:24 <@jrand0m> heh +16:24 < jeet> this is a very cool thing you guys have done ;X +16:24 <@hezekiah> Though I'm not sure nop and UserX can design that IRC +protocol even in 21 days. +16:24 <@hezekiah> nop: ;-) +16:24 <@nop> no +16:24 <@jrand0m> ok, you're off to uni in late august? mid august? when +should we pencil you in for less activity? +16:24 <@hezekiah> Around August 20th I'm of. +16:24 <@hezekiah> off. +16:25 <@jrand0m> 'k +16:25 <@hezekiah> Until then I'm a rabid nermal! :) +16:25 < jeremiah> I'm off about the same time +16:25 < jeremiah> (to univ) +16:26 <@nop> ok +16:26 <@jrand0m> so we'll have to get more resources on the 'implement +IRC' task or just drop the task from the 1.0 release +16:26 <@hezekiah> I wouldn +16:26 <@hezekiah> wouldn't make the 1.0 release dependant on IRC. +16:26 <@nop> I believe that we will need to delay the task +16:26 < jeet> [17:23] -anon.iip- CTCP (except ACTION) and DCC are +disabled <- how can i stop this from poppiing up every 3 minutes? +16:26 <@hezekiah> Do the IRC, but let i2p 1.0 come out when it's ready. +16:27 < thecrypto> wow, i'm half way through college as two others just +start :) +16:27 <@jrand0m> lol +16:28 <@jrand0m> I concur hezekiah +16:28 <@hezekiah> Cool. I still think i2p will be it's own killer app. +:) +16:28 <@jrand0m> so that basically means all I2P 1.0 requires after +august is a month of debugging and documentation to go from alpha to +beta to 1.0 +16:29 <@jrand0m> hezekiah> definitely. we need to get a demo app out on +it first - does the instant messenger app + file transfer sound good to +people for that? +16:29 -!- jeet [~miteymous@anon.iip] has quit [ircN 7.27 + 7.0 for mIRC +(2002/01/10 00.00)] +16:29 <@hezekiah> Well, you said it best: 'demo'. From my view, it +doesn't need to be special. It just needs to prove the network is worth +developing on. +16:30 <@hezekiah> So the IM client would be a good demo, in my opinion. +16:30 < Zwolly> file transfer is one thing i really would like to see so +gimme a demo +16:30 <@hezekiah> Zwolly: lol +16:30 <@nop> yes +16:30 < Zwolly> and see me as an "normal" user +16:31 <@hezekiah> Zwolly: You can be our guniea pig! ;-) +16:31 * hezekiah starts mixing poisinous code in his lab. ;-) +16:31 < Zwolly> hmmm yummie +16:32 <@jrand0m> ok, one last thing on i2p +16:32 <@nop> sure +16:33 <@jrand0m> nop> any chance we can get a non sourceforge trusted +cvs server? +16:34 <@jrand0m> sourceforge has more problems than these college +student's exams +16:34 <@nop> yes +16:34 <@nop> I will arrange that and have it up by next week +16:34 <@jrand0m> awesome. thanks +16:34 <@nop> also +16:34 <@nop> I may be able to get a compile farm +16:34 <@nop> that is not sf +16:34 <@nop> with vpn access to it +16:35 <@hezekiah> Compile farm!? +16:35 <@jrand0m> compile farm? bah, we can just run ant :) +16:35 <@hezekiah> jrand0m: All code is not Java. +16:35 <@hezekiah> I personally love compile farms. +16:35 <@hezekiah> :) +16:35 <@jrand0m> ant == make. it can run gcc / etc +16:35 <@nop> hezekiah: send me a list of viable platforms we'll need to +test on +16:35 <@jrand0m> 'k, if we really need the cpu power of a compile farm, +thats great +16:36 < wilde> what license are you planning to use? +16:36 <@nop> GPL +16:36 <@jrand0m> GPL cool with everyone for this? +16:36 < wilde> k nice +16:36 <@hezekiah> I'm very pro GPL. +16:36 <@hezekiah> But one warning +16:36 <@hezekiah> For the API's we will probably need LGPL. Otherwise +all programs made for this network MUST be GPL +16:36 <@jrand0m> we may want to go LGPL down the line +16:37 <@jrand0m> yeah +16:37 <@jrand0m> we MUST not require all apps using I2P to be GPL'ed +16:37 <@hezekiah> So the router should be GPL, but the API's will +probably need to be LGPL at some time. +16:37 <@hezekiah> jrand0m: Then we'll need an LGPL API. +16:37 <@hezekiah> The only problem that poses is getting a good crypto +kit for C that is compatible with LGPL. +16:38 <@hezekiah> I don't think Cryptlib's Sleepycat license is. +16:38 <@hezekiah> I could email the author and ask for an exception or +something if I need to when the time comes. +16:38 <@jrand0m> hezekiah> not need, want. the API comm layer will be an +open spec, so anyone can write their own and not link to any of our +libraries +16:38 <@hezekiah> Right. +16:38 <@nop> right +16:38 <@hezekiah> So for now we can even make GPL API's if we need to. +16:39 <@hezekiah> OK, one question for jrand0m: +16:39 < jeremiah> but we should try to have non-viral ones asap +16:39 <@hezekiah> I agree. +16:39 < wilde> http://www.virtualunlimited.com/products/beecrypt/ +16:40 < wilde> Bee Crypt is LGPL, i've used once +16:40 <@hezekiah> wilde: Beecrypt is far beneath what is required +unfortunately. +16:40 <@nop> yes +16:40 <@nop> I don't think we should use a crypto lib like Beecrypt +16:40 <@jrand0m> word wilde +16:40 <@cohesion> hezekiah: there's tons of crypto code in +GnuPrivacyGuard that's all GPL'd +16:40 <@cohesion> you might check and see where it came from +16:40 <@hezekiah> cohesion: The problem is we'll need an LGPL C API that +uses Crypto. +16:41 <@hezekiah> I'll work it out when I get to it. +16:41 <@hezekiah> For now, I have two questions for jrand0m: (It's gone +up one!) :) +16:41 <@jrand0m> we have lots of options. we'll figure it out +16:41 <@jrand0m> heh fire away +16:42 <@hezekiah> 1.) When the client API spec is done on the 25th will +it detail the byte-by-byte structure of the messages sent over the +network, and will it detail the specifics on how the crypto is +implemented? +16:42 -!- ion [ion@anon.iip] has joined #iip-dev +16:42 <@jrand0m> yes +16:42 <@hezekiah> 2.) Will be we using Twofish? ;-) +16:43 <@jrand0m> no, prolly aes, unless someone has a really good reason +16:43 <@hezekiah> jrand0m: Was that yes to both questions, or just +question 1? +16:43 -!- nemesis [nemesis@anon.iip] has joined #iip-dev +16:43 <@hezekiah> OK. +16:43 <@jrand0m> hezekiah> yes to both +16:43 <@nop> well +16:43 < nemesis> uuuh, since when there are here ops? :) +16:43 <@hezekiah> I really like twofish, but unfortunately AES is easier +to find a good lib for. +16:44 <@nop> hold +16:44 <@hezekiah> nemesis: The English structure of that sentence was +too garbled for me to decipher? Whould you like to restate your +question? +16:44 <@jrand0m> whats special about twofish? why not go with the +advanced encryption Standard? +16:44 <@hezekiah> nop: Holding ... :) +16:44 * jrand0m holds +16:44 <@nop> I prefer that we have a suite of encryption options +16:44 <@nop> not just aes +16:44 <@nop> there are opinions about AES that some people do not feel +comfortable using +16:44 <@nop> and would rather go with Twofish etc +16:44 <@nop> so maybe we can have it be a selection +16:44 < wilde> do both :) +16:44 <@nop> yes +16:44 <@nop> wilde: exactly +16:45 <@jrand0m> nop> suites would mean not everyone can send messages +to everyone +16:45 < jeremiah> but then wouldn't each router have to support both? +that seems painful +16:45 <@jrand0m> doing both is definitely the case for transport layer, +where things can be negotiated +16:45 <@nop> not really +16:45 <@nop> I would not agree with AES then +16:45 <@nop> as if you are paranoid +16:45 <@hezekiah> Right. But let's try to too enclude things that are +weakening like 3DES. +16:45 <@hezekiah> A chain is only as strong as its weakest link. +16:45 <@nop> then you'll realize why +16:45 <@nop> with the US gov't approvals +16:46 <@jrand0m> I don't support AES because it has govt approval, I +support AES because it has cryptographers, scientists, and +mathematicians approvals. +16:46 <@jrand0m> if there is a better one, we can go with that. +16:46 <@jrand0m> but I don't want to go with something because its +different +16:46 <@nop> but the approval of twofish is strong as well amongst +cryptographers +16:46 <@hezekiah> Well, the last three AES candidates were Rijndael, +Twofish, and Serpent. +16:46 <@nop> exactly +16:47 <@hezekiah> Rijndael was the fastest. +16:47 <@hezekiah> Personally, I have more faith in Twofish than +Rijndael. +16:47 <@jrand0m> nop I think I heard you say there were problems with +serpent? +16:47 < wilde> use multiple layers of encryption if you have CPU for it +16:48 <@jrand0m> wilde> there will be, but thats on a different aspect +of things. +16:48 <@nop> all I'm saying is that we could have both supported +16:48 <@nop> doesn't hurt +16:48 <@jrand0m> actually it does hurt +16:48 <@jrand0m> segmentation attack +16:48 < wilde> ok twofish wrapped in AES could be overkill +16:48 <@nop> haha +16:48 <@nop> not twofish wrapped in AES +16:49 < jeremiah> should we standardize each transport as having one +specific set of characteristics (network setup, encryption)? +16:49 <@nop> alright for the sake of argument +16:49 <@nop> let's do rijndael for this part +16:49 < jeremiah> and then we could have one TCP transport supporting +AES, one with Twofish, but not one that has to juggle both? +16:49 <@jrand0m> jeremiah> yes, particular transports will have +particular characteristics, but we're covering the end to end message +crypto done in the api atm +16:49 <@nop> let's do end to end AES +16:49 < jeremiah> jrand0m: ah +16:49 <@nop> then node to node twofish option +16:50 <@nop> and if you can, do AES-counter mode +16:50 <@jrand0m> 'k, sounds good. we can always change later on before +release (during peer review, etc) +16:50 < wilde> but all crypto algorithms have failed in the past, using +double encryption would at least buy time in case of a crypto +breakthrough +16:50 < jeremiah> not really +16:50 <@jrand0m> wilde> the truly paranoid can encrypt with their own +system prior to sending messages over the I2P network +16:50 <@hezekiah> wilde: If one algorithm is found to be weak, we'll +replace it. +16:51 <@jrand0m> I2P will just transparently encrypt +16:51 < wilde> jrand0m: yes, you're right, there should be a limit to +paranoia +16:52 <@nop> yes +16:52 <@nop> we could go on all day +16:52 <@nop> arguing about it +16:52 <@nop> AES end to end +16:52 <@jrand0m> ok, I don't have anything else on I2P stuff +16:52 <@nop> Twofish and others node to node +16:52 <@jrand0m> coo' +16:53 <@jrand0m> any other I2P stuff, or are we on the next agenda item? +16:54 <@hezekiah> I'm done. :) +16:54 < wilde> what about A2A, anonymous 2 anonymous? +16:54 <@hezekiah> I +16:55 <@hezekiah> I've never heard of that. What are you talking about, +wilde? +16:55 <@jrand0m> I2P is anonymous to anonymous communication +16:55 <@jrand0m> I2P = "Invisible Internet Project" +16:55 < nemesis> jrand0m: can you send the roadmap as an attechment, and +not as inline? +16:55 <@jrand0m> (dont make us say I^2P) +16:55 <@nop> hushmail has an encrypted messenger +16:55 <@nop> neat +16:56 <@jrand0m> nemesis> hmm, I tried to - hushmail said it was +attached :/ +16:56 <@hezekiah> nemesis: I got it as attached. +16:56 <@jrand0m> nemesis> you can d/l from +http://article.gmane.org/gmane.comp.security.invisiblenet.iip.devel/290 +16:56 < nemesis> i'm sorry, i can't copy&paste it +16:56 <@hezekiah> nemesis: Perhaps your mail reader is the problem? (He +sent it as a zip file.) +16:56 < nemesis> its inline +16:56 < nemesis> theres a zip file... +16:56 -!- UserX [~User@anon.iip] has joined #iip-dev +16:57 <@jrand0m> 'lo userx +16:57 < nemesis> -Hush_boundarfy-31fda3d62329b +16:57 <@nop> did anyone log this +16:57 < nemesis> Content-Transfer-Encoding: base64 +16:57 <@hezekiah> cohesion was supposed to. +16:57 <@jrand0m> I log all IRC +16:57 <@cohesion> i have it all +16:57 < thecrypto> yes +16:57 <@jrand0m> word +16:58 < Zwolly> my ISP also logs all the IRC chatting so what is new +16:58 <@jrand0m> lol Zwolly +16:58 < Zwolly> hehe +16:59 <@hezekiah> Zwolly: Your ISP won't have logs of this. :) +16:59 < Zwolly> i hope not if so you guys do a louzy job +16:59 <@hezekiah> lol +17:00 <@hezekiah> So, I'm assuming we move on to the next agenda item +now since we've stopped talking about i2p for a while. +17:00 <@nop> yes +17:00 <@nop> comments +17:00 <@nop> suggestions +17:01 <@jrand0m> we, should, like, do some drugs, man +17:01 <@hezekiah> jrand0m: Sorry. I refuse to ruin a good mind with such +substances. +17:01 < wilde> question: isn't the release plan a bit optimistic= +17:01 < wilde> ? +17:02 <@hezekiah> wilde: lol. Well, my term would be 'insane'. But I +think it might be feasible. +17:02 <@jrand0m> wilde> good question. it should be plausible, and if +any devs on there want to adjust tasks they are working on, we will. +17:03 < thecrypto> we can do it! +17:04 <@jrand0m> go TEAM! +17:04 < wilde> aim high that's good, but it should be realistic +17:04 < wilde> do you guys have time enough for the actual programming? +17:04 * jrand0m quit his job to work on this, and a few people have +summer break coming up +17:05 < wilde> i mean september-october that's like 60-90 days +17:05 < wilde> ok that's sounds good +17:05 <@jrand0m> but don't believe us. we'll release when its ready. +17:05 <@hezekiah> jrand0m: BTW, since you quit your job, how are you +going to eat while you code this? +17:05 < jeremiah> wilde: we're going to be implementing lots of it in +high-level languages and then re-coding in C later +17:05 <@jrand0m> hezekiah> I eat code +17:05 <@hezekiah> I was afraid you'd say something like that. +17:06 <@jrand0m> ;) +17:06 <@hezekiah> I just hope you've got a good nest egg to live on. +17:06 < jeremiah> jrand0m: my code eats random numbers +17:06 < jeremiah> that might make a bad loop +17:06 <@hezekiah> ROTFL! +17:07 < wilde> drinking java, eating python, roasted ant, could go +17:07 <@jrand0m> but bugs have lots of protien +17:07 * jrand0m !thwaps self +17:07 <@jrand0m> ok, do we have other questions / comments / +suggestions? +17:07 <@hezekiah> Well, I've got to go now. +17:07 <@hezekiah> Bye everyone. :) +17:07 <@jrand0m> or are we actually finishing up in under an hour? +17:07 -!- hezekiah [hezekiah@anon.iip] has quit [Client exiting] +17:07 <@jrand0m> lol wilde +17:08 <@jrand0m> nop> got anything or we done? +17:10 -!- UserX [~User@anon.iip] has quit [Ping timeout] +17:10 -!- wilde [anon@anon.iip] has quit [] +17:10 <@cohesion> ok, i'm ending the meeting +17:11 < nemesis> STOP! +17:11 <@cohesion> nop: i'll get with you about CVS tomarrow +17:11 * jrand0m stops +17:11 < nemesis> ganttproject-1.9.7.jar +17:11 <@cohesion> GO! +17:11 < nemesis> how it works? +17:11 <@nop> ok +17:11 <@nop> also +17:11 <@nop> aes +17:11 <@jrand0m> nemesis> just double click on it with java 1.4.2 +installed +17:11 <@nop> we should use 256 bit as a norm +17:11 < nemesis> i have java 1.4.2... +17:11 <@jrand0m> nemesis> I'll email out the xml with the project info +17:12 <@jrand0m> word nop, definitely +17:13 < nemesis> Could not find the main class. Program will exit! +17:13 < nemesis> hm.. i think my java are broken.... Title of the +Window: Java Virtual Machine Launcher... +17:14 <@jrand0m> weird nemesis, works for me... make sure its loading it +with the 1.4.2 jvm and not the windows jvm +17:14 <@jrand0m> ah, try running from the cmd.exe command line +17:14 < nemesis> eh? +17:14 < nemesis> k +17:14 < nemesis> then i write a .bat for it, like for columba :) +17:14 <@cohesion> ok, i'm closing the logs +17:14 <@jrand0m> (and type java -version first to make sure it uses the +right one) +17:14 <@jrand0m> heh word +17:14 <@cohesion> everyone say "cheese" +17:14 <@jrand0m> queso +17:14 < thecrypto> cheese +17:15 < Zwolly> chesse +17:15 < Zwolly> cheese +17:15 < nemesis> E:\Sytemprogramme\server\Projektverwaltung>java +ganttproject-1.9.7.jar +17:15 < nemesis> Exception in thread "main" +java.lang.NoClassDefFoundError: ganttproject-1/9/7/ja +17:15 < nemesis> r +17:16 <@jrand0m> java -jar ganttproject-1.9.7.jar +17:16 < nemesis> java version "1.4.2-beta" +17:16 < nemesis> Java(TM) 2 Runtime Environment, Standard Edition (build +1.4.2-beta-b19) +17:16 < nemesis> Java HotSpot(TM) Client VM (build 1.4.2-beta-b19, mixed +mode) +17:16 < nemesis> hm... why with -jar? +17:16 < nemesis> now it works... +17:17 -!- ion [ion@anon.iip] has quit [Ping timeout] +17:17 < nemesis> thx jrand0m +17:17 <@jrand0m> without -jar asks it to load the class +ganttproject-1/9/7/jar +17:17 <@jrand0m> np +17:17 < jeremiah> is cvs working? +17:17 < jeremiah> i checked out earlier today, but it's weird now +17:17 <@jrand0m> sourceforge is being a pain atm +--- Log closed Tue Jul 22 17:18:14 2003\ No newline at end of file diff --git a/pages/meeting51.html b/pages/meeting51.html new file mode 100644 index 00000000..6b1129e4 --- /dev/null +++ b/pages/meeting51.html @@ -0,0 +1,883 @@ +
+--- Log opened Tue Jul 29 16:54:31 2003 +17:11 <@hezekiah> Tue Jul 29 21:11:18 UTC 2003 +17:11 <@hezekiah> The 51th (I think) iip-dev meeting. +17:11 <@hezekiah> Agenda: +17:11 <@hezekiah> 1.) Welcome +17:11 <@hezekiah> 2.) jrand0m's stuff +17:11 <@hezekiah> 3.) Any of the other developer's stuff +17:11 <@hezekiah> 4.) Anything nop adds when/if he gets here +17:12 <@hezekiah> 5.) Questions and Comments from the ever eager unwashed + masses. ;-) +17:12 <@hezekiah> OK! +17:12 <@hezekiah> Welcome everyone to the 51th (I think) iip-dev meeting +17:12 <@hezekiah> Item number 2! +17:12 <@hezekiah> jrand0m's stuff +17:12 -!- thetower [none@anon.iip] has joined #iip-dev +17:12 * hezekiah hands the mike to jrand0m +17:12 <@jrand0m> sub-agenda: +17:12 <@jrand0m> 2.1) I2CP spec & dev status +17:12 < co> Where are the logs for meeting 50? +17:12 <@jrand0m> 2.2) SDK plans +17:12 <@jrand0m> 2.3) crypto +17:12 <@jrand0m> 2.4) roadmap / network proto status +17:13 <@hezekiah> co: cohesion is working on getting them up +17:13 <@jrand0m> (btw, its "mic", for microphone) +17:13 <@hezekiah> jrand0m: Sorry. :) +17:13 <@hezekiah> jrand0m: (And this mistake from a sound tech guy!) +17:13 -!- luckypunk [~yetalohe@anon.iip] has joined #iip-dev +17:13 -!- odargur [odargur@anon.iip] has joined #iip-dev +17:13 <@jrand0m> 2.1) I2CP: the spec is committed to CVS with a slight mod + to one of the messages (MessageStatusMessage) +17:14 <@jrand0m> Comments are always welcome on I2CP, but the sooner the + better. +17:14 <@hezekiah> jrand0m: Where's the spec in CVS? ... and is it on the SF + CVS too? +17:14 <@jrand0m> The reason for sooner the better is that we'll have a + working Java client implementation by friday. +17:14 -!- some_random_guy [~dan@anon.iip] has joined #iip-dev +17:14 * thecrypto crosses fingers on that one +17:14 <@jrand0m> Plus a local only router by the end of the weekend, I'm hoping +17:15 <@jrand0m> no hez, only on the cathedral +17:15 <@jrand0m> good point thecrypto. +17:15 <@jrand0m> Caveat: +17:15 <@hezekiah> Ugh. I still can't get CVS to work with cathedral. +17:15 <@jrand0m> some crypto isn't 100%, but its all stub'ed to let us plug + in more complete or other implementations later +17:15 <@jrand0m> hezekiah> we'll get you up after the meeting. +17:15 <@hezekiah> jrand0m: Thanks. :) +17:16 <@jrand0m> the spec is in the + i2p/doc/specs/data_structure_spec/datastructures.html +17:16 <@jrand0m> thecrypto> do you have anything to add re: java impl? +17:16 -!- ArdVark [simple1@anon.iip] has joined #iip-dev +17:16 <@jeremiah> the local-only router you mentioned was the python one, + right? or is there a java one too? +17:17 <@jrand0m> that all depends :) +17:17 <@jrand0m> jeremiah/hezekiah> how goes the python client and local-only + router? +17:17 <@thecrypto> not really, except for the crypto issue i think we'll + talk about in a bit +17:17 <@jrand0m> word thecrypto. +17:17 <@hezekiah> jrand0m: It's coming. I finally got the TCP transport + stuff working yesterday. +17:17 <@jeremiah> it seems ok, i think most of it will be dependent on + hezekiah's dev speed more than mine +17:17 <@hezekiah> jrand0m: Jeremiah has some nice stuff going with the + message strcutures. +17:18 <@hezekiah> hezekiah: I'm hoping that we can make the deadline. +17:18 <@jrand0m> cool. +17:18 <@jeremiah> also... friday is my birthday, so I plan on not being + around the computer then +17:18 <@hezekiah> jeremiah: Understandable. :) +17:18 <@hezekiah> jeremiah: And happy birthday in advance. :) +17:18 <@jeremiah> thanks +17:18 <@jrand0m> jumping slightly to agenda 2.4> when would we expect to be + able to have the python local only router? realistically? +17:19 <@jrand0m> word, if you code on friday I'll kick your ass +17:19 <@jrand0m> virtually, at least +17:19 <@hezekiah> jrand0m: I thought that's what I'm coding. The Python + local only router. +17:19 <@jrand0m> si, that you are +17:19 <@hezekiah> Well the deadline is August 1st. +17:19 <@jeremiah> right now we're working on message to-from binary format + stuff +17:19 <@hezekiah> That's not that hard. +17:19 <@jeremiah> right +17:19 <@hezekiah> I'm hoping to have that done in a day or two. +17:20 <@jrand0m> thats friday :) +17:20 <@jrand0m> awesome +17:20 <@hezekiah> I hope it will be done by August 1st. Realistically it + might be a few days late, but I hope not. +17:20 <@jrand0m> 'k, I'll hold off on touching any java local only stuff + then and work on the network spec after the java client api is set. +17:20 <@hezekiah> Yes. Specs are good. +17:21 <@hezekiah> They make my job a LOT easier! :) +17:21 <@jrand0m> word. +17:21 <@jrand0m> I'll write up a quick 2 paragraph run through of the java + I2CP test harness too +17:21 <@jrand0m> I'll get that out tonight +17:22 <@hezekiah> jrand0m: I love how you get these specs written so fast. +17:22 <@hezekiah> This is fun. :) +17:22 <@jrand0m> Ok, hez/jeremiah/thecrypto> anything else on I2CP? +17:22 <@jrand0m> lol +17:22 -!- dm [~hifi@anon.iip] has joined #iip-dev +17:22 <@hezekiah> Um ... +17:22 <@hezekiah> I want the crypto spec! +17:22 < dm> welcome +17:22 * hezekiah pouts like a baby +17:22 <@hezekiah> ;-) +17:23 <@hezekiah> Seriously, ... I can't think of anything. +17:23 <@jrand0m> thats agenda item 2.3 +17:23 <@thecrypto> still waiting for 2.3 to come up +17:23 <@hezekiah> If I do, I'll just come online and pester you with questions, + jrand0m. :) +17:23 <@jrand0m> word. +17:23 <@jrand0m> ok. 2.2) SDK plans +17:23 <@hezekiah> What agenda point did we just finish? +17:23 <@hezekiah> 2.4? +17:23 <@hezekiah> And have we finished 2.1 yet? +17:23 <@jrand0m> 2.1 +17:24 <@jrand0m> now 2.2> the SDK +17:24 <@hezekiah> OK. +17:24 < dm> agenda has decimal point in it now? I see progress already. +17:24 <@hezekiah> I'm found now (as opposed to lost). +17:24 <@thecrypto> we might have 2 decimal points :) +17:25 <@jeremiah> what makes up the SDK apart from the various APIs? +17:25 <@jrand0m> the SDK is: the client API (as many as we have available), the + local only router, a trivial sample app, and some docs on how to use the APIs. +17:25 <@hezekiah> jrand0m: Would I be correct in assuming that you're writing + the docs? :) +17:26 <@jrand0m> I'd like to have the SDK released asap, so that 3rd (or + even 2nd or 1st) party developers can write and test applications that will + run over I2P, so once the network is operational, we'll hit the ground running. +17:26 <@jrand0m> hezekiah> I'd actually prefer not to. +17:26 <@jrand0m> hezekiah> and I say that not because I don't want to document, + but because I'm too close to it. +17:26 <@hezekiah> jrand0m: OK. +17:26 <@jrand0m> we should have somone who *doesn't* actually implement the + code write that doc, so it can be understandable to people who didn't write + the I2CP spec +17:26 <@hezekiah> jrand0m: We'll cross that bridge when we get there. +17:26 <@jrand0m> but if need be, I'll jump on it. +17:26 <@jrand0m> word. +17:27 < dm> what incentive do people have to write apps without an operational + network, and how would they even test their app. +17:27 <@hezekiah> jrand0m: Or why don't someone who designed the protocol + write it, and then have someone who never worked with it go over it until + it makes sense? +17:27 <@jrand0m> Ok, there has been some discussion of a simple 'talk' + style app. +17:27 <@jrand0m> dm> people will be able to test with the SDK. +17:27 <@thecrypto> actully, i was wondering what would be the use of that + if it's local only +17:28 <@jeremiah> dm: the idea is to implement a simple network that isn't + fully functional but can pass messages +17:28 <@thecrypto> you'd only be able to talk to yourself +17:28 <@jeremiah> it's not actually local-only, but it only includes + client-router, not router-router code +17:28 <@jrand0m> thecrypto> you can talk to other Destinations. I2P is + location independent - local is the same as remote. +17:29 <@thecrypto> okay +17:29 < dm> nice and all, I just don't see anyone (besides you 3-4) writing + anything if you can only test locally. But anyway, doesn't matter. +17:29 <@jrand0m> so a talk app can open up two instances of the application + and talk to oneself, etc +17:30 <@thecrypto> but when we add the remote stuff, the app should just work +17:30 <@jrand0m> dm> right, this is just a prereq for having other people + write apps. +17:30 <@jrand0m> exactly. +17:30 <@jrand0m> the app will work with absolutely NO changes +17:30 < co> dm: This is a test application. Once the router-router code is + written, you will be able to talk to others. +17:30 <@jeremiah> having local-only just lets us develop in parallel +17:30 < dm> yes, but if the app assumes 10 ms latency, and it ends being 12 + seconds, it won't work too well :) +17:31 <@jrand0m> agreed dm +17:31 < dm> any estimates on latency btw? :) +17:31 <@jrand0m> if we have 12 second latency, we have work to do. +17:31 <@jrand0m> we won't have that though. +17:31 <@jrand0m> estimates are .6-2.7sec +17:31 <@jrand0m> for a 5,000,000 router network. +17:31 <@hezekiah> BTW, that reminds me. We need to talk about ElGamal. +17:31 <@thecrypto> the longest time is setup +17:31 <@jrand0m> (see iip-dev archives for the rudimentary models) +17:31 < dm> lower or higher for smaller networks? +17:32 <@jrand0m> hezekiah> 2.3: crypto. +17:32 <@thecrypto> after that the time the drops dramatically +17:32 <@jrand0m> dm> lower. +17:32 <@thecrypto> hezekiah: you prolly have the same question as i +17:32 <@jrand0m> thecrypto> exactly, setup time is offline for message + delivery though [aka set up tunnels prior to sending messages] +17:32 < dm> ok, just checking you ;) +17:32 <@jrand0m> heh +17:33 <@jrand0m> ok. last part of the SDK - the app +17:33 <@jrand0m> co/thecrypto: thoughts on a java talk impl? workable? + time? plans? interest? +17:34 <@thecrypto> once the API is up, we can prolly have a talk done in + about a week or so, 2 tops, co agrre? +17:34 <@jeremiah> chat could be built in as a jabber router, right? +17:34 < co> That should be fairly easy to do. +17:34 < co> thecrypto: I agree. +17:34 <@jrand0m> jeremiah> I don't know jabber, but if jabber can run over + the api, cool +17:35 <@jrand0m> word co & thecrypto +17:35 <@jrand0m> jeremiah> note that this is just a trivial app to do proof + of concept with, not a Kickass Anonymous IM System :) +17:35 <@jeremiah> not yet ;) +17:35 <@thecrypto> we can add that functionallity later +17:35 <@jeremiah> k +17:36 <@jrand0m> heh +17:36 <@thecrypto> let's start small +17:36 * jrand0m puts in the schedule "add feature: be kickass" +17:36 < some_random_guy> heh +17:36 < some_random_guy> nice feature :) +17:36 -!- dm2 [~hifi@anon.iip] has joined #iip-dev +17:37 <@jeremiah> jrand0m: I think I missed this in 2.1, but any thoughts + on kademlia as a DHT? it requires less upkeep than Chord +17:37 -!- nop [nop@anon.iip] has joined #iip-dev +17:37 < nop> sorry +17:37 <@jrand0m> plus one of these days we need to get someone on the IIP + redesign to run over this. +17:37 -!- dm [~hifi@anon.iip] has quit [Ping timeout] +17:37 < nop> what? +17:37 < nop> who +17:37 < nop> where +17:37 < nop> when +17:37 < nop> ? +17:37 -!- dm2 is now known as dm +17:37 <@jrand0m> hey, speakin of the devil +17:37 < WinBear> why? +17:37 < WinBear> nm +17:37 < nop> I'm an angel actually +17:37 <@hezekiah> lol +17:38 <@thecrypto> someone hand nop a log +17:38 < WinBear> azrel +17:38 <@jrand0m> jeremiah> kademila is a good DHT, and we will definitely + review that plus the chord/tapestry crew, along with sloppy dhts in the + network spec. +17:38 <@jeremiah> jrand0m: cool +17:38 <@hezekiah> thecrypto: I'm working on it. :) +17:38 < nop> I was hearing of one that kicks but +17:38 < nop> called chord/middle +17:38 -!- hif [~hifi@anon.iip] has joined #iip-dev +17:39 < nop> but you know who is good to talk to his brandon wiley +17:39 * jrand0m !thwaps nop +17:39 < nop> I knew that would hurt +17:39 <@hezekiah> lol +17:39 <@hezekiah> Who's Brandon Wiley? +17:39 < nop> someone I'm sure jrand0m has been in numerous discussions with +17:39 < nop> :) +17:39 < nop> someone email me a log +17:39 < dm> Brandon is jrandom's real name, busted! +17:39 <@hezekiah> I'm working on it. +17:40 <@hezekiah> Hold you horses, nop. :) +17:40 < nop> haha +17:40 < dm> Brandon Wiley is the first Freenet programmer, having +17:40 < dm> co-founded the development effort with the system's inventor, + Ian Clarke +17:40 < nop> is userx here or there +17:40 < WinBear> you can talk to my brandon wiley +17:40 <@hezekiah> OK. It's on the way ... if my mail client will cooperate + and send a 15K attachement. +17:41 <@thecrypto> we've talked alot :) +17:41 <@hezekiah> nop: UserX is niether hither or thither. +17:41 <@hezekiah> OK! +17:41 <@hezekiah> The log is sent nop! Go read. :) +17:41 <@thecrypto> and now we wait +17:41 <@jrand0m> ok, anyone have any SDK thoughts while we give nop a min + to catch up? ;) +17:41 <@hezekiah> jrand0m: Now that I've gotten that log business done + ... what's kademlia? +17:42 <@jrand0m> Yet Another Academic DHT :) +17:42 <@hezekiah> And where I can get a link to kademlia's webpage? +17:42 -!- Erazerhead [JohnDoe@anon.iip] has joined #iip-dev +17:42 <@jeremiah> http://kademlia.scs.cs.nyu.edu/ +17:42 <@hezekiah> Thanks. :) +17:42 <@thecrypto> YAADHT? +17:42 <@hezekiah> lol +17:42 <@hezekiah> Names these days ... I tell ya'! +17:43 <@jrand0m> and if there's ever any CS stuff mentioned that you don't + understand, go to citeseer.nj.nec.com/cs +17:43 < WinBear> klamidia? +17:43 <@hezekiah> OK. +17:43 < nop> jrand0m: I was just about to say citeseer +17:43 < dm> what's the ETA on the SDK? +17:44 * jrand0m avoids injecting the clap into I2P +17:44 * jrand0m hopes the SDK will be out next week. perhaps next friday? +17:44 * thecrypto crosses another pair of fingers +17:45 <@jrand0m> ok. moving on to 2.3) Crypto. +17:45 * hezekiah imagines thecrypto with about 13 sets of fingers crossed + ... and then realized that he must have run out by now. +17:45 <@hezekiah> Yay! +17:45 * jrand0m pokes nop to make sure he's here +17:45 <@hezekiah> Crypto! +17:45 <@hezekiah> I have something to start us off with. :) +17:46 <@thecrypto> i have something too +17:46 <@thecrypto> Dibs! :) +17:46 * jrand0m doesn.t so you two fight it out +17:46 <@hezekiah> thecrypto can go first. :) +17:46 <@jrand0m> thecrypto> speak +17:46 <@jrand0m> :) +17:46 <@thecrypto> Ok, on Elgamal +17:47 <@thecrypto> We have to figure out whether or not we have common p + and alpha +17:47 -!- some_random_guy [~dan@anon.iip] has quit [BitchX: the original + point-and-click interface.] +17:47 <@thecrypto> the problem with a common p and alpha is that we'd have + to find someway to change everyone's keys at the same time +17:48 <@jrand0m> aka: really bad. +17:48 < co> thecrypto: Sorry, what are p and alpha? +17:48 <@thecrypto> the advantage is that we can pick specially optimized + ones and the amount of data transmitted for a public key is very small +17:48 * jrand0m sees no good reason to use common p and alpha, beyond saving + a few bits +17:48 <@thecrypto> co: for all intensive purposes, special big numbers +17:49 <@jrand0m> thecrypto> we can still optimize for commonly encrypted to + destination's p and alpha +17:49 <@thecrypto> or should i go into an explaination of how elgamal workds +17:49 <@thecrypto> jrand0m: yes +17:49 < co> thecrypto: OK. +17:49 <@thecrypto> we can also have everyone have a different p and alpha +17:50 <@jeremiah> for those who are interested: + http://www.wikipedia.org/wiki/ElGamal_discrete_log_cryptosystem +17:50 <@thecrypto> this means that the amount of data transmitted is much + larger and we have to figure out how to pack it in +17:50 <@jrand0m> word, thanks jeremiah +17:50 <@jrand0m> much larger? +17:50 <@jrand0m> I thought with varying p and alpha we can use smaller p + and alpha? +17:51 <@thecrypto> instead of 160 bit numbers we are now talking 2 1024 bit + and 1 160 +17:51 <@thecrypto> or overall 2308 +17:51 <@hezekiah> 288 bytes +17:51 <@hezekiah> Big deal. +17:52 <@jrand0m> ok, thats not too bad. we've planned on 256bytes +17:52 <@hezekiah> These keys aren't transfered all that often, are they? +17:52 <@jrand0m> another 32 doesn't hurt +17:52 <@jrand0m> hezekiah> they're inserted into the DHT +17:52 <@hezekiah> Ah! +17:52 <@hezekiah> That's why we wanted it small. +17:53 <@thecrypto> also, another problem about elgamal we might also have + to worry about +17:53 <@jrand0m> well, it doesn't really hurt if the RouterInfo structure + is about 10K or so +17:53 -!- mrflibble [mrflibble@anon.iip] has joined #iip-dev +17:53 <@jrand0m> 'k, s'up thecrypto? +17:53 <@thecrypto> message expansion is 2, the size of an encryption or a + signature is twice the size of the message +17:54 <@jrand0m> ElG encryption is only of the AES key +17:54 <@jrand0m> ElG signature is only of the SHA256 hashes +17:55 <@thecrypto> okay, it's just something to bring up as well +17:55 <@hezekiah> jrand0m: Which makes me _really_ puzzled. +17:55 <@thecrypto> now back to the original issue, do we want to have a + shared p and alpha or do we want everyone to have different p and alphas? +17:55 <@jrand0m> hezekiah> hmm? you read the data structure spec for + #Payload ? +17:55 <@jrand0m> any thoughts/questions on that hezekiah? +17:55 * dm now understands how DHTs work. +17:55 <@jrand0m> nop> thoughts? +17:55 <@jrand0m> awesome dm +17:55 <@hezekiah> If a signature is twice the size of the data signed, + then why does the IC2P spec say a signature is 128 bytes? +17:56 < nop> no +17:56 < nop> shared p +17:56 <@hezekiah> Shouldn't it bee 512? +17:56 <@thecrypto> the hash of the bytes +17:56 < nop> and alphas +17:56 < dm> seems like a lot of work is required when joining a DHT, but I + guess it works. +17:56 < nop> shared base, shared p +17:56 <@jrand0m> hezekiah> bits / bytes. +17:56 < nop> this will eliminate a lot of risk +17:56 <@thecrypto> then how big do we want it? +17:56 <@hezekiah> Hmm +17:56 <@jrand0m> nop> in 3 years, will we want to have everyone change their + p and alpha at the same time? +17:56 < nop> and hold our protocol to standards +17:57 <@thecrypto> since it does open up that p and alpha huge attacks +17:57 < nop> jrand0m: there is such a thing called cooked primes, at this + time, and this is the time I'm looking at +17:57 <@thecrypto> which if completed bring the entire network down +17:57 < nop> I believe we can modify with the times +17:57 < nop> but a static oakley approved prime is advised +17:57 < nop> as they have been reviewed thoroughly as secure +17:58 < nop> and that is a better basis than any of our assumptions about + primes being generated (probable at that) +17:58 <@thecrypto> if it's not prime, encryption or signatures won't work + so we just throw it our +17:59 <@jrand0m> agreed, they have better primes. so when one of those + primes are factored, everyone using them is exposed, correct? +17:59 < dm> hmmm, I gotta go. This is logged right? +17:59 < nop> jrand0m: yes +17:59 <@thecrypto> yup +17:59 < nop> jrand0m: when that happens we'll all know +17:59 < nop> I don't want to risk prime generation +17:59 -!- dm [~hifi@anon.iip] has quit [it better be] +17:59 <@thecrypto> how will we know? +17:59 < nop> plus it adds to our calculation time +17:59 -!- hif [~hifi@anon.iip] has quit [] +17:59 < nop> thecrypto: if you use a standard defined Oakley prime set, + you will know when it's been cracked +18:00 <@thecrypto> how? +18:00 < nop> as it will be very public news +18:00 <@jrand0m> nop> we'll know unless the NSA cracks it. +18:00 < co> nop: How many of those primes are there? If not many, using them + is a risk. +18:00 <@thecrypto> yeah, passive evesdropping is still a threat +18:00 <@thecrypto> and i can make a program to generate ps and alphas and + test them in about an hour +18:00 <@jrand0m> nop> it would be very public news unless it was a threat + to national security. +18:00 < co> Wait... no, that's a stupid question. Never mind. +18:01 < nop> this is true, but I believe from numerous contacts in the + cryptography community that if it's solved it will be solved before the NSA + does it +18:01 < nop> our prime generation will not secure that either way +18:01 < nop> if they solve those primes +18:01 < nop> you may as well figure out a new algo to use +18:01 <@jrand0m> 'k. +18:02 < nop> please use static, it will relieve problems with cryptanalysis, + and reduce the risks of mistake in our crypto +18:02 <@jrand0m> I was on the fence, and I'm fine with going with shared + known good primes. +18:02 <@thecrypto> okay, then let's pick a prime then +18:02 <@jrand0m> nop> we've still got you penciled in the ganttchart for + crypto spec +18:02 <@thecrypto> and do they have generators for these primes? +18:02 < nop> yes +18:02 < nop> yes I do +18:03 < nop> 2 +18:03 < nop> that is a primitive root of the primes I will have +18:03 < nop> what size primes do you guys want? +18:03 <@thecrypto> i'm thinking somewhere between 2048-4096 +18:03 <@hezekiah> We're using a 2048 key, right? +18:03 < nop> yes, so use a 4096 or higher prime +18:04 <@thecrypto> because the sharedness means we're out in the open +18:04 <@thecrypto> and if this takes off, it would be a very valuble prime + to break +18:04 * cohesion missed the meeting +18:04 < co> You are using this prime within ElGamal, though, right? +18:04 <@hezekiah> So the keys will be 4096 bits? +18:04 <@cohesion> did someone log? +18:04 < nop> co yes +18:04 < nop> no hezekiah +18:04 < nop> the keys will be 2048 +18:04 <@cohesion> ok +18:04 < nop> the prime will be higher than 4096 +18:04 * cohesion goes back to his work +18:04 <@hezekiah> OK. Please forgive my horribe understanding here. :) +18:04 < nop> brb +18:05 <@thecrypto> p and alpha can be fixed, alpha will be 2 and p will be + the prime we pick +18:05 < nop> ok, let me email the prime candidates +18:05 < nop> give me a couple of hours I have some work to do +18:05 * jeremiah wanders to dinner, will read logs later +18:05 <@thecrypto> the serect key is a, a number between 0 and p - 2 +18:05 <@thecrypto> the public key is 2^a mod p +18:06 < nop> can we move to next topic and come back so I can be here for + that, I'll be right back, at work and have to do a task real quick +18:06 <@hezekiah> OK, so you call my 'x' as 'a' +18:06 <@hezekiah> ... and my 'g' as 'alpha'. +18:06 < nop> please move the algo talk explanations to a private message +18:06 <@hezekiah> thecrypto: Right? +18:06 <@thecrypto> yes +18:06 <@jrand0m> ok. so thecrypto, nop, and hezekiah will work out the + details of the algo later. +18:06 < nop> ok +18:06 < nop> for sure +18:06 <@hezekiah> OK ... so thecrypto, are you done with your question? +18:06 <@thecrypto> so let's move on +18:06 < nop> I'll email our primes +18:06 <@thecrypto> ye +18:06 <@thecrypto> s +18:06 <@hezekiah> OK. My turn! :) +18:07 <@hezekiah> Why on earth are we using ElGamal for signing? +18:07 <@jrand0m> ok. 2.4) roadmap / network proto status +18:07 <@jrand0m> not yet hez :) +18:07 <@jrand0m> oh hez +18:07 <@hezekiah> When do I get to ask it? +18:07 -!- dm [~hifi@anon.iip] has joined #iip-dev +18:07 <@jrand0m> what would you recommend, when we have ElG public keys? +18:07 <@thecrypto> when nop gets back +18:07 <@jrand0m> no, you're right, I'm wrong. now is the right time. +18:07 < co> Next topic, please. +18:07 <@hezekiah> jrand0m: Well, the problem is this: +18:07 <@hezekiah> speed +18:08 <@hezekiah> I was playing around with the crypto stuff today, and got + a nasty shock. +18:08 <@hezekiah> ElGamal was _astronomically_ slower at verifying a signature + than DSA or RSA. +18:08 <@jrand0m> hezekiah> is that a library implementation problem or + the algorithm? +18:08 <@hezekiah> I don't know. +18:09 <@hezekiah> But I checked Applied Crypto and saw that at least _part_ + of the problem is with ElGamal. +18:09 <@hezekiah> AC has tables of the amount of time it takes for signing + and verification for DSA, RSA, and ElGamal. +18:09 <@jrand0m> so are you suggesting we go to RSA for encryption, decryption, + and signing? +18:09 <@hezekiah> I +18:09 <@hezekiah> I'm not really suggesting much that's definate. +18:09 <@jrand0m> ...though we *could* add a second signing public key to + the RouterInfo structure +18:10 <@hezekiah> I'm just saying, that AC lists ElGamal verification at +9.30 seconds. +18:10 <@hezekiah> RSA is 0.08 seconds +18:10 <@thecrypto> for 1024 bits +18:10 <@jrand0m> damn. +18:10 <@hezekiah> DSA is 1.27 seconds +18:10 <@hezekiah> Now you see my problem. +18:10 <@hezekiah> ElGamal is dirt slow ... +18:10 <@jrand0m> we need sub <100ms verification. +18:10 <@jrand0m> if not sub <10ms +18:10 <@hezekiah> ... and my CPU is 333MHz. +18:11 <@hezekiah> BTW, these calculations were done on a SPARC II +18:11 <@hezekiah> I've got an AMD K6-2 333MHz. +18:11 <@jrand0m> a sparc 2 is a 40Mhz machine. +18:11 <@hezekiah> Verifying an ElGamal sig with my Python module (which uses + a C backend but smells a little fishy). +18:11 < luckypunk> god +18:11 < luckypunk> well +18:11 <@hezekiah> jrand0m: OK. I have no clue about SPARC's. +18:11 <@hezekiah> Anyway, it took about 20 seconds. +18:12 <@hezekiah> If not a little more. +18:12 < luckypunk> anyone with a 1 ghz -2 ghz proc doesn't need to worry. +18:12 < co> hezekiah: On modern computers, then, the verification should be + acceptably fast. +18:12 <@hezekiah> DSA and RSA were nearly instantainious. +18:12 <@jrand0m> hezekiah> I do. sparc 2 was fast in '92 +18:12 <@hezekiah> Anyway, that's why I bring all this up. +18:12 <@hezekiah> We could add a DSA key, but that would meen 2 keys +18:12 <@thecrypto> we should still wonder about people who don't have the + uber fast machines +18:12 <@hezekiah> Or we could go with RSA. +18:12 <@jrand0m> my memory of our rationale for ElG as opposed to RSA was + the preference was not very strong. +18:13 <@hezekiah> Or we can live with the long verification time and use ElG. +18:13 <@jrand0m> thecrypto> absolutely. +18:13 <@thecrypto> nop was the one to say, let's use elgamal +18:13 <@hezekiah> thecrypto: Precisely. Mom and Pop will eventually be + transparently using I2P. +18:13 <@jrand0m> we're going to want bootable distros for 386s, as well as + in-applet implementations. +18:13 <@hezekiah> Mom and Pop won't have state of the art hardware. +18:13 < luckypunk> oh god +18:14 < luckypunk> everyone who would want this has at least a p100 or so. +18:14 < co> Let's not compromise security by choosing a weaker algorithm + that is faster. +18:14 <@hezekiah> co: I'm not suggesting we do. +18:14 <@thecrypto> elgamal and DSA are equivilent +18:14 <@jrand0m> ok. so we're going to revisit the RSA/ElG choice. the code + changes shouldn't be a problem. +18:14 < luckypunk> they can suffer. +18:14 <@hezekiah> co: RSA and DSA are just as reputable as ElGamal. +18:14 < luckypunk> lol +18:14 < luckypunk> if you're concerned about anonyminity +18:14 <@hezekiah> thecrypto: And nothing could be farther from the truth. +18:14 < luckypunk> you won't care about speed too much. +18:14 <@thecrypto> hezekiah: they are both implementations of the same + general algorithim +18:14 < dm> the obvious step here is for someone to figure out for certain + what the CPU usages for the two are :) +18:14 <@jrand0m> luckypunk> you listen to the complaints wrt freenet much? +18:15 <@hezekiah> thecrypto: DSA can't encrypt. It's only a sig algo, and + it's a lot faster than ElG. +18:15 <@thecrypto> hezekiah: it just happens that the signing and verification + equations for DSA are faster +18:15 <@jrand0m> dm> if Applied Crypto benchmarked RSA verification at +1/100th ElG, thats enough for me. +18:15 <@thecrypto> we can use ElG for encryption/decryption and DSA for + signing/verification +18:15 <@jrand0m> the options are go to RSA or add a DSA key (~256bytes more) + to the RouterInfo structure +18:15 <@hezekiah> Right. But now the DHT has 2 public keys in it. +18:16 <@jrand0m> so? +18:16 < co> Let's have one public key. That will be less confusing. +18:16 <@hezekiah> co: It would only be 'confusing' for developers ... and + we need to know what we're doing. :) +18:16 <@thecrypto> i think it's time to wait for nop on this one too +18:16 <@hezekiah> Right. +18:16 <@jrand0m> but if its 100times a slow... +18:16 <@jrand0m> anyway, we'll continue the crypto design discussion offline. +18:17 <@hezekiah> jrand0m: Email the mailing list, will ya'? +18:17 < luckypunk> jrand0m: god, i don't mind, if you cant wait 40 sseconds + for your page to load, fuck off. +18:17 <@thecrypto> or after the main part of the meeting +18:17 <@jrand0m> shit, I email the list daily :) +18:17 <@jrand0m> heh lucky +18:17 -!- hif [~hifi@anon.iip] has joined #iip-dev +18:17 <@jrand0m> right. +18:17 <@jrand0m> ok> 2.4) roadmap / network proto status +18:17 -!- hif is now known as dm2 +18:18 <@jrand0m> I have done very little wrt the network proto beyond + responding to co's messages, as I've been working on the java and I2CP. +18:18 <@jrand0m> roadmap still seems on target. +18:18 <@jrand0m> any changes to the roadmap? +18:19 <@jrand0m> ok. if there are, whenever there are, just mail the list. +18:19 <@hezekiah> Right. +18:19 -!- dm [~hifi@anon.iip] has quit [Ping timeout] +18:19 <@jrand0m> the roadmap.xml is now in the i2p cvs module + i2p/doc/projectPlan +18:19 -!- dm2 is now known as dm +18:20 <@hezekiah> jrand0m: Let me guess ... that's on cathedral too? +18:20 < nop> back +18:20 < nop> sorry bout that +18:20 <@jrand0m> ok, thats it for that (though we can come back to network + protocol questions in the questions section). +18:20 <@jrand0m> I have no more subitems +18:20 <@jrand0m> hezekiah> I don't use sf +18:20 <@thecrypto> well, now that nop is back we can go back to the speed + issue quickly +18:20 <@hezekiah> Right. +18:21 < nop> which speed issue +18:21 <@thecrypto> Elgamal is slow to verify +18:21 < nop> that's true +18:21 < nop> but so is rsa +18:21 <@jrand0m> nop> Applied Crypto benchmarked RSA verification at 1/100th + ElG for signing. +18:21 < nop> hmm +18:22 <@hezekiah> RSA and DSA are instantanious for me. +18:22 <@hezekiah> ElG takes 20 seconds. +18:22 < nop> DSA is el gamal +18:22 <@jrand0m> So we can either jump to RSA or add a DSA key to the + RouterInfo structure +18:22 < nop> DSA +18:22 < nop> I have anything with R's in it +18:22 < nop> ;) +18:22 * jrand0m doesn't remember a really strong reason for ElG as opposed + to RSA +18:22 * jrand0m resents that +18:22 <@hezekiah> nop: Will you enlighten us? Why don't we use RSA? +18:23 <@hezekiah> In all the gory detials. :) +18:23 < nop> for the reasons of this, and it's debatable, but +18:23 < dm> someone msg me the URL to the iip-dev again when you get a chance. +18:23 < nop> factoring primes is how to solve RSA +18:23 < dm> iip-dev list that is. +18:23 < luckypunk> RSA has been cracked. +18:23 < luckypunk> practically. +18:23 < nop> yes, 512 bit RSA has been cracked +18:23 < luckypunk> or was it DES? +18:23 < luckypunk> bah. +18:23 <@hezekiah> DES has been cracked. +18:23 < nop> it was DES I think you're talking about +18:23 < co> luckypunk: Keys of certain size have been cracked. +18:23 <@hezekiah> RSA is not quite there yet. +18:24 < nop> anyway +18:24 < luckypunk> but it might. +18:24 < nop> back to my point +18:24 <@hezekiah> But the question is: is a 2048 or 4096 RSA key secure today? +18:24 <@thecrypto> hold one second +18:24 < nop> 512 bit RSA keys have been cracked with office computers +18:24 <@jrand0m> we're looking at 2048bit RSA or ElG +18:24 < nop> hezekiah: it would be, but here's the fun part +18:24 < nop> if you can factor primes +18:24 < nop> you can crack RSA +18:24 < nop> if you can compute discrete logarithms you can solve RSA and + EL gamal +18:24 < nop> we're closer to factoring +18:24 < nop> than we are with computing discrete logs +18:24 < nop> at this time +18:24 < luckypunk> isn't discrete logs a bit harder? +18:25 <@hezekiah> If you can factor primes _quickly_ you can crack RSA. +18:25 <@hezekiah> luckypunk: That's what nop's saying. +18:25 < luckypunk> quantum computers. +18:25 < luckypunk> are damned near to functional. +18:25 <@hezekiah> lol +18:25 < nop> and the ratio of bit sizes for pub keys for discrete logs is + stronger than RSA's keys +18:25 < nop> for instance 768 bit key is not advised by diffie-hellman + variants, but it has not been provably cracked +18:25 <@hezekiah> So, the end of it is that we add a DSA key. +18:25 <@thecrypto> nop, don't do a bill gates, it's factor large n where n = pq +18:25 < nop> as 512 bit RSA keys have +18:25 <@thecrypto> since factoring prime numbers is easy +18:25 < nop> thnx +18:25 < nop> sorry +18:25 <@jrand0m> hezekiah> thats what its looking like. +18:26 < nop> I was trying to let everyone understand +18:26 < nop> sorry +18:26 <@thecrypto> just a bit of a clarification +18:26 <@jrand0m> word nop, thats cool, gracias +18:26 <@hezekiah> OK. +18:26 < nop> so DSA +18:26 < nop> then +18:26 <@hezekiah> So we're adding a DSA key? +18:26 < nop> which is a diffie-hellman variant as well +18:26 <@jrand0m> ok, given that, we'll continue crypto details offline. +18:26 < nop> I'm in favor of logs over factors +18:27 < nop> ;) +18:27 <@hezekiah> BTW, what do we still need to continue? +18:27 < co> dm: That URL is + http://news.gmane.org/thread.php?group=gmane.comp.security.invisiblenet.iip.devel +18:27 <@thecrypto> hezekiah: picking the magic prime +18:27 <@hezekiah> Oh, right! +18:27 < dm> thanks co, I found jrand0m's specs. Now all I need is a printer + with lots of toner. +18:27 < nop> I'll send that out +18:27 <@jrand0m> hezekiah> update the data structure spec, add info wrt the + DSA, specify key size for dsa, etc. +18:27 < nop> let's do that offline +18:27 <@jrand0m> lol dm. +18:28 <@hezekiah> OK, so do you have anything left, jrand0m? +18:28 <@jrand0m> ok, I'm done with my stuff. hezekiah> you had # 3? +18:28 <@hezekiah> Yeah. +18:28 < dm> hmmm. pictures are not showing up. +18:28 <@hezekiah> 3.) Whatever nop wants to add to the agenda. + +18:28 < dm> jrand0m: is there a place to get the 'I2P Network Spec Draft +2003.07.23' with pictures included? +18:29 < co> dm: Yes, I have had that problem, too. +18:29 <@jrand0m> dm/co> get the first rev of the network spec (two weeks + prior in the zip), which includes the png. +18:30 <@jrand0m> (its in cvs too, but thats not anon/public yet) +18:30 < arj> when will it be? :) +18:30 <@hezekiah> Wow! +18:30 <@hezekiah> CVS is fast now! +18:31 <@jrand0m> arj> we're doing our best to avoid hype, so once its ready + we're going to put things public, but keep it largely quiet until. +18:31 < nop> hezekiah: what the cathedral one? +18:31 <@jrand0m> arj> however, everything we're doing is GPL, at least so far. +18:31 <@hezekiah> nop: Yeah +18:31 <@hezekiah> ! +18:31 < dm> two weeks prior in which zip? +18:31 <@jrand0m> oh word, you got it working hezekiah? +18:31 < arj> jrand0m: just wanted to read the latest specs +18:31 <@jrand0m> dm> network_spec_*.zip iirc +18:31 <@hezekiah> jrand0m: Yup! :) +18:31 < dm> same here, with pictures! +18:31 <@thecrypto> iip-dev has most of it +18:32 <@jrand0m> arj> + http://article.gmane.org/gmane.comp.security.invisiblenet.iip.devel/292 has + all but one tiny change. +18:32 <@jrand0m> (well, except for the Client Access Layer, which is in a + different spec now) +18:33 < arj> ok thanx +18:33 <@jrand0m> the client access layer spec is + http://article.gmane.org/gmane.comp.security.invisiblenet.iip.devel/298 +18:33 < dm> ok, and the link to the zip with the pictures? +18:33 <@jrand0m> ok. nop you have anything, or we "5) opening up to + questions/thoughts from the masses"? +18:34 -!- mihi [none@anon.iip] has quit [Ping timeout] +18:34 * jeremiah is back and has read the backlog +18:34 <@jrand0m> dm> h/o, pulling it up +18:34 <@jrand0m> + http://article.gmane.org/gmane.comp.security.invisiblenet.iip.devel/269 +18:35 < dm> ty +18:35 <@jrand0m> ok, any questions / thoughts? +18:35 -!- arj [anders@anon.iip] has quit [EOF From client] +18:35 < co> yes. +18:35 <@jrand0m> np +18:35 < co> Are we on item 5 now? +18:35 * jrand0m knew you'd have some co :) +18:35 < co> Currently, communication between client and router (outgoing) + is not encrypted. +18:35 <@jrand0m> yes, since nop is slow :) +18:35 <@jrand0m> (damn people with jobs and stuff) +18:36 <@hezekiah> lol +18:36 < co> Suppose I have a trusted friend and want to use his router for + outgoing messages. +18:36 <@hezekiah> jrand0m: Well, you know. Not everyone can aford not having + a life. +18:36 <@jrand0m> co> largely correct. message payloads are encrypted, + but the rest of I2CP isn't +18:36 < co> Wouldn't that put me at risk of having my messages captured. +18:37 <@hezekiah> Yeah. They would be transfered in the clear over the wire. +18:37 <@hezekiah> Unless you ssh tunnel to his router or something. +18:37 <@jrand0m> if you have a trusted friend and connect to their router, + they can know that you sent or recieved a message, but they can't know what + you sent. +18:37 <@jeremiah> wouldn't the messages still go under public key encryption? +18:37 <@hezekiah> Oops. +18:37 <@hezekiah> My bad. +18:37 < dm> I'm gonna use I2P as a way to learn new stuff to prevent 9to5 + (windows admin, VB tools) job from turning me into a zombie. +18:37 <@jrand0m> I'm fine with adding SSL listener support, as opposed to + just TCP listener. +18:37 <@hezekiah> I forgot that clients to end to end encryption. +18:37 < co> Your assumption is that I run a local trusted router, but as + stated above, I might not want to do that so that messages would not be + connected to me. +18:37 <@jrand0m> yes jeremiah, but thats only for the payload +18:37 <@jrand0m> heh word dm +18:37 -!- mihi [none@anon.iip] has joined #iip-dev +18:38 <@jrand0m> hmm. +18:38 <@hezekiah> jrand0m: Why not add support later on for client-to-router + comm to be encrypted? +18:38 <@jrand0m> you really always should have a local trusted router. + you can have it connect to another known non-local trusted router too. +18:39 < co> True, but I would like to second hezekiah's suggestion. +18:39 <@jrand0m> hezekiah> I'm fine with adding it later (where later: + t=0...releaseDate ;) +18:40 <@jrand0m> I have absolutely no qualms with even adding support for + DH+AES for I2CP +18:40 < nop> good +18:40 <@jrand0m> actually, those features can be added on per-router basis + as well +18:41 < nop> jrand0m: also I believe the polymorphic key rotation will be + needed as well as chaffe traffic +18:41 < nop> I'm sure we're looking at that at a later meeting +18:41 < nop> just my side comment +18:41 < nop> using key sets +18:41 <@jrand0m> yes, when we touch the router-router comm. +18:41 <@jrand0m> (1-2 weeks off) +18:41 < co> nop: Currently, I don't see chaffe traffic in the spec, but it + would be good to add. +18:42 <@jrand0m> there is chaffe, in the sense that routers and tunnel + participants test themselves and their peers. +18:42 -!- arj [~anders@anon.iip] has joined #iip-dev +18:42 <@jrand0m> plus DHT requests are chaffe wrt payload messages +18:42 < nop> jrand0m: well I'll dive into some research on evading some + traffic analysis and giving away any known plaintext +18:42 <@jrand0m> *and* individual transports will have hteir own chaffe styles + (e.g. http transport will query google for "cute puppy dogs" periodically, + or whatever) +18:43 < nop> well, that chaffe is nice, but I also mean encrypted chaffe +18:43 < nop> this helps rotate the session keys +18:43 < nop> and keep your node busy even when inactive +18:43 < dm> maybe change that to hard child porn for more realistic chaffe +18:43 <@jrand0m> word. +18:43 < dm> just kidding! +18:43 <@hezekiah> dm: Good. Otherwise I'd have to !thwack you. +18:43 <@hezekiah> :) +18:44 <@jrand0m> DHT (link encrypted) and test messages (free route mix, + ala onion/garlic) won't have known plaintext problems +18:44 < nop> since newer nodes will have less traffic when starting out +18:44 <@jrand0m> plus we'll have support for constant bitrate transports +18:44 < nop> garlic rocks +18:44 < nop> :) +18:44 < nop> jrand0m: DC net style :) +18:44 * jrand0m is making some pasta w/ lots of garlic after this meeting + is over +18:45 < nop> jrand0m: I meant garlic routing +18:45 <@hezekiah> lol! +18:45 <@jrand0m> i know ;) +18:45 < nop> jrand0m: anyway, constant bitrate could be forced with the + block encryption since AES generates 128 bit blocks +18:45 < nop> ;) +18:45 < nop> so we could just pad all data to be 16 bytes per message +18:45 <@jrand0m> co> did my answers to your email make sense? +18:47 <@jrand0m> *ping* +18:47 <@hezekiah> *pong* +18:47 <@thecrypto> *pong +18:47 <@thecrypto> * +18:47 <@jrand0m> any other questions from anyone, or has my iproxy + disconnected? +18:47 <@jrand0m> heh word +18:47 <@hezekiah> thecrypto: Fragmented packet! +18:47 <@hezekiah> lol +18:48 <@thecrypto> lost that tail end there +18:48 <@thecrypto> smaller MTU here :) +18:48 <@hezekiah> jrand0m: Well, I have no questions. +18:48 < co> jrand0m: Yes, the answers made sense. +18:48 < co> I have no more questions. +18:48 < dm> I shall create questions when I read the specs tomorrow. +18:49 <@jrand0m> well, I hope you have more later :) +18:49 <@jrand0m> awesome dm +18:49 < dm> awesome initially maybe. +18:49 < dm> well, i'm off. good luck people! +18:49 -!- dm [~hifi@anon.iip] has quit [] +18:50 <@jrand0m> we *do* still have the big 2 week peer review period in + the schedule, but review before then is appreciated (even though all the + details haven't yet been put in) +18:51 <@jrand0m> ok. any other questions, or are we going to wrap up #52 + as a 102 minute meeting? +18:52 <@thecrypto> #51 +18:52 <@hezekiah> Uh, I read 1:57 minutes. +18:52 <@hezekiah> Duh. +18:52 <@hezekiah> I'm stupid +18:52 <@hezekiah> Never mind me. +18:52 <@hezekiah> I have no questions ... +18:52 <@hezekiah> Questions! +18:52 * jrand0m could never add... +18:52 <@hezekiah> Speak now or hold you peace until next Tuesday! +18:52 <@hezekiah> Going once! +18:53 <@hezekiah> ... Going twice! +18:53 <@thecrypto> Sold to the guy in a button down shirt +18:53 <@hezekiah> Gone! +18:53 * jrand0m goes to the kitchen to make some long overdue dinner +18:53 <@jrand0m> gracias srs y srtas +18:53 <@hezekiah> Goodbye everyone! +18:53 <@jeremiah> I should checkout the source before I wander off +18:53 <@hezekiah> See you next Tuesday! +--- Log closed Tue Jul 29 18:53:55 2003 +\ No newline at end of file diff --git a/pages/meeting52.html b/pages/meeting52.html new file mode 100644 index 00000000..b2b88d76 --- /dev/null +++ b/pages/meeting52.html @@ -0,0 +1,378 @@ +
+<nop> ok, meeting started +<nop> what's on the agenda +--> logger (logger@anon.iip) has joined #iip-dev +--> Anon02 (~anon@anon.iip) has joined #iip-dev +<hezekiah> Tue Aug 5 21:03:10 UTC 2003 +<hezekiah> Welcome to the Nth iip-dev meeting. +<hezekiah> What's on the agenda? +<thecrypto> Tue Aug 5 21:02:44 UTC 2003 +<thecrypto> synced to a NTP stratum 2 :) +<hezekiah> Tue Aug 5 21:03:13 UTC 2003 +--> ptm (~ptm@anon.iip) has joined #iip-dev +<hezekiah> Just synced to NIST. :) +<mihi> this sync does not help w/ iip delays ;) +<jrand0m> nop: things I want to see covered: java dev status, java crypto + status, python dev status, sdk status, naming service +<hezekiah> (We're going into the naming service _already_?) +<jrand0m> not design you wanker, thats co's schpeel. just talk about stuff + if there's stuff to talk about. +<hezekiah> Ah +* jrand0m puts LART away +<jrand0m> anything else on the agenda? +<jrand0m> or shall we dig in? +<hezekiah> Well, I can't think of anything else to add. +<hezekiah> Ah! +<hezekiah> Oh! +<jrand0m> ok. java dev status: +<hezekiah> Good. +<-- mrflibble has quit (Ping timeout) +<nop> ok +<nop> agenda +<nop> 1) Welcome +<jrand0m> as of today, there is a java client API with a stub java router + that can talk to each other. in addition, there is an application called ATalk + allowing anonymous IM + file transfer. +<nop> 2) IIP 1.1 blackouts +<nop> 3) I2P +<nop> 4) The End with comments and stuff +* jrand0m goes back to corner +<nop> sorry + joeyo jrand0m Aug 05 17:08:24 * hezekiah gives jrand0m a dunce hat to wear in + the corner. ;-) +<nop> sorry about that +<nop> didn't see you started there +<nop> maybe I should go in corner +<hezekiah> lol +<jrand0m> no worry. item 1) +* hezekiah hands nop a dunce hat too. :) +<nop> ok welcome everybuddy +<nop> blah blah +<nop> 2) IIP 1.1 blackouts +--> mrflibble (mrflibble@anon.iip) has joined #iip-dev +<hezekiah> 52nd iip-dev meeting and all that good rot! +<nop> the server recently had some issues with the hard drive sectors and has + been replaced +<nop> I plan to be moving the darn server into a more stable environment with + redundancy +<nop> and possibly lend out control of multiple ircd servers +<nop> dunno +<nop> that's something to be discussed +<-- Anon02 has quit (EOF From client) +<nop> hopefully our servers should stay up now since the harddrive was replaced +<nop> sorry about the inconvenience folks +<nop> 3) I2P - Jrand0m take it away +<nop> come out of the corner jrand0m +* hezekiah goes over to the corner, pulls jrand0m off his chair, drags him + to the podium, takes away his dunce hat, and hands him the mic. +* nop goes into that corner to fill his place +<hezekiah> lol! +<jrand0m> sorry, back +* nop grabs dunce hat from hezekiah +* nop puts it on his head +* nop applauds for jrand0m +* jrand0m just watches the show +<jrand0m> er... um ok +<hezekiah> jrand0m: i2p, java status, etc. Talk man! +<jrand0m> so, as of today, there is a java client API with a stub java + router that can talk to each other. in addition, there is an application called + ATalk allowing anonymous IM + file transfer. +<hezekiah> File transfer already!? +<jrand0m> si sr +<hezekiah> Wow. +<hezekiah> I'm sure behind the times. +<jrand0m> but not the most graceful +<hezekiah> lol +<jrand0m> it takes a file and tosses it in a message +<hezekiah> Ouch. +<nop> how long did 1.8 mb local transfer take? +<jrand0m> I've tested with a 4K file and a 1.8Mb file +<jrand0m> a few seconds +<nop> nice +<nop> :) +<hezekiah> Does the java stuff do real encryption yet, or does it still + fake that? +<nop> fake +<nop> even I know that +<nop> :) +<jrand0m> I warmed it up by talking to myself first [e.g. one window to + another, saying hi] so it didn't deal with the overhead of the first elg +<jrand0m> right, its faked largely +<thecrypto> most of the encryption is fake +<thecrypto> that's being worked on though +<hezekiah> Of course. :) +<jrand0m> definitely. +<jrand0m> on that front, wanna give us an update thecrypto? +<thecrypto> well, right now i'm done with ElGamal and SHA256 +<thecrypto> right now I'm working on generating primes for DSA +<thecrypto> I'll send out 5 and then we can just pick one +<hezekiah> nop: Didn't you have prime(s) coming for use with DSA? +<thecrypto> We also have some benchmarks on ElGamal and SHA256 +<thecrypto> And they are all fast +<jrand0m> latest benchmarks w/ elg: +<jrand0m> Key Generation Time Average: 4437 total: 443759 min: + 872 max: 21110 Keygen/second: 0 +<jrand0m> Encryption Time Average : 356 total: 35657 min: + 431 max: 611 Encryption Bps: 179 +<jrand0m> Decryption Time Average : 983 total: 98347 min: + 881 max: 2143 Decryption Bps: 65 + +<hezekiah> min and max: are they in seconds? +<jrand0m> note that the Bps isn't really useful, as we only encrypt/decrypt + 64 bytes +<thecrypto> ms +<jrand0m> no, sorry, those are all milliseconds +<hezekiah> Cool. :) +<hezekiah> And this is done in java? +<thecrypto> yes +<thecrypto> pure java +<hezekiah> OK. I am officiall impressed. :) +<jrand0m> 100%. P4 1.8 +<thecrypto> they are about the same on my 800 Mhz +<hezekiah> How can I do the same tests? +<jrand0m> sha256 benchmark: +<jrand0m> Short Message Time Average : 0 total: 0 min: 0 max: + 0 Bps: NaN +<jrand0m> Medium Message Time Average : 1 total: 130 min: 0 max: + 10 Bps: 7876923 +<jrand0m> Long Message Time Average : 146 total: 14641 min: + 130 max: 270 Bps: 83037 +<thecrypto> run the ElGamalBench program +<hezekiah> OK. +<hezekiah> I'll go find it. +<jrand0m> (short size: ~10 bytes, medium ~10KB, long ~ 1MB) +<jrand0m> java -cp i2p.jar ElGamalBench +<jrand0m> (after running "ant all") +<hezekiah> jrand0m: Thanks. :) +<jrand0m> np +<thecrypto> The NaN thing means it's so fast that we end up dividing by 0 + it's so fast :) +<hezekiah> What's the sha bench? +<jrand0m> java -cp i2p.jar SHA256Bench +--> Neo (anon@anon.iip) has joined #iip-dev +<hezekiah> OK. +<jrand0m> we'll probably want to move those to be main() methods of the + associated engines, but they're good where they are atm +<hezekiah> Let's see how fast all this is on an AMD K6-2 333MHz (which is + a chip not well know for its integer math.) +<jrand0m> heh +<jrand0m> ok so we have DSA and AES left, right? +<jrand0m> this is all wikked thecrypto. nice work. +<thecrypto> yup +<jrand0m> can I nag you for an ETA on the other two? ;) +<hezekiah> If this is anywhere near as fast on my box as it is on yours, + you have to show me how you do that. ;-) +<thecrypto> DSA should be done almost as soon as i have primes ready +<nop> hezekiah have you tried the sslcrypto for python +<thecrypto> copying some code around from the prime generator and things like + that and it's done +<nop> the one off that link +<hezekiah> nop: sslcrypto won't do us any good. +<hezekiah> nop: It doesn't implment ElGamal _or_ AES _or_ sha256. +<thecrypto> AES is mostly done except that there is some error somewhere that + i'm still trying to pick out and destroy, once i have that, it'll be done +<jrand0m> thecrypto> so by friday, DSA keygen, sign, verify, and AES encrypt, + decrypt for arbitrary size inputs? +<nop> the one on McNab's site does not? +<thecrypto> yeah +<nop> darn +<thecrypto> should be friday +<thecrypto> most likey thursday +<jrand0m> thecrypto> does that include the UnsignedBigInteger stuff? +<thecrypto> i'll be missing next weeks meeting because of summer camp, and + i'll be back after that +<thecrypto> jrand0m: prolly not +<jrand0m> ok. +<jrand0m> so for the time being, interoperability between java and python + is b0rked. +<jrand0m> for crypto, that is. +--- Notify: jeremiah is online (anon.iip). +--> jeremiah (~chatzilla@anon.iip) has joined #iip-dev +<jrand0m> (aka for signatures, keys, encryption, and decryption) + +<nop> hmm maybe we should focus more on C/C++ +<thecrypto> well, once we get it working completely we can then make sure + both java and python can speak to each other +<jrand0m> while you're out I'll look into the unsigned stuff. +<jeremiah> can someone email me a backlog? jeremiah@kingprimate.com +<hezekiah> jeremiah: Give me a minute. :) +<jrand0m> nop> do we have devs for C/C++? +<nop> I have one guy yes +<nop> and Hezekiah we know could do it +<jrand0m> or perhaps we can get a python dev status update from hezekiah + + jeremiah to see when we'll have more people for the c/c++ dev +<jrand0m> right, of course. but hez+jeremiah are working on python atm + (right?) +<hezekiah> Yeah. +<-- mrflibble has quit (Ping timeout) +<hezekiah> I'm sort of giving poor jeremiah lots of trouble. +<nop> I was just saying if python won't be fast speeds +<hezekiah> Python is mainly for me to understand this network. +<nop> ahh +<hezekiah> Once, I get it to basically follow the complete spec, I intend + to hand it off to jeremiah to do with as he sees fit. +<hezekiah> It's not meant to be a killer implementation of the spec. +<hezekiah> (If I wanted that, I'd use C++.) +<jeremiah> well there aren't any really processor intensive parts of the app, + iirc, aside from crypto, and ideally that will be handled in C anyways, right? +<jrand0m> sure jeremiah. all depends on the app +--> mrflibble (mrflibble@anon.iip) has joined #iip-dev +<hezekiah> jeremiah: In theory. +<jrand0m> so where are we on the python side? client api, local only + router, etc? +<jeremiah> the python implementation will also let us know what optimizations + we could make from the start... I'd like to keep it up to date or, possibly, + ahead of the C implementation as I can +<hezekiah> jrand0m: OK. Here's what I've got. +<hezekiah> In _theory_ the router should be able to handle all non-admin + messages from a client. +<hezekiah> However, I don't have client yet, so I haven't been able to debug + it (i.e. there are still bugs.) +<hezekiah> I'm working on the client right now. +<jrand0m> 'k. if you can disable signature verification, we should be able + to run the java client against it now +<hezekiah> I'm hoping to have that done except for admin messages in a day + or two. +<jrand0m> we can test that out after the meeting +<hezekiah> jrand0m: OK. +<jeremiah> I've been dealing with real-world stuff mostly since the last + meeting, I can work on the client API, just been trying to sync my thinking + with hezekiah's +<jrand0m> cool +<hezekiah> jeremiah: You know what, just wait. +<hezekiah> jeremiah: I'm probably throwing in too much new stuff for you to + deal with right now. +<jeremiah> hezekiah: right, what I was going to say is that you should + probably just go ahead and implement the base stuff +<hezekiah> jeremiah: In a little while, it will be stabalized and you can + start refining it. (There are lots of TODO comments that need help.) +<jeremiah> and then I can extend it later once I get the picture +<hezekiah> Exactly. +<hezekiah> You get to maintain all this code. :) +<jrand0m> cool. so eta 1-2 weeks for a working python router + client api? +<hezekiah> I'm going on vacation next week so probably. +<hezekiah> Are we going to have more details on router to router soon? +<jrand0m> no. +<jrand0m> well, yes. +<jrand0m> but no. +<hezekiah> lol +<jeremiah> hezekiah: how long is the vacation? +<hezekiah> 1 week. +<jeremiah> ok +<jrand0m> (aka as soon as the SDK goes out, 100% of my time goes into I2NP) +<hezekiah> I'm hoping to have all non-admin functionality written before I + go on vacation +<hezekiah> . +<jrand0m> but then soon after you get back you're off to college, right? +<hezekiah> I2NP? +<hezekiah> Right. +<jrand0m> network proto +<hezekiah> I have about 1 week after vacation. +<hezekiah> Then I'm gone. +<hezekiah> And my free time drops like a stone. +<jrand0m> so that 1 week should only be debugging +<jeremiah> I can work on the code while hez is gone though +<jrand0m> word +<jrand0m> whats your summer look like jeremiah? +<hezekiah> jeremiah: Perhaps you can get those admin functions working? + +<thecrypto> i'll still have a month after i come back from my vaction to work + on things +<jrand0m> having a life, or being like the rest of us l00sers? :) +<jeremiah> maybe +<hezekiah> 100sers? +<hezekiah> What's a 100ser? +<jeremiah> i leave for college on the 22nd, other than that I can dev +<mihi> hezekiah: a loser +<jeremiah> and the last week before I leave all my friends will be gone... so + I can go into hyperdev mode +<hezekiah> mihi: Ah! +<jrand0m> hehe +<hezekiah> OK. So where were we on the agenda? +<hezekiah> i.e. What's next? +<jrand0m> sdk status +<jrand0m> sdk == one client impl, a local only router impl, an app, and docs. +<jrand0m> I'd like to have that out by next tuesday. +<hezekiah> jeremiah: That backlog is on the way. Sorry I forgot you there. :) +<jeremiah> thanks +<jrand0m> ok, co isn't around, so the naming service stuff is prolly a bit + off base +<jrand0m> we can discuss the naming service after he puts out specs or + he's around +<jrand0m> ok, thats it for I2P stuff +<jrand0m> anyone else have I2P stuff, or we on to: <nop> 4) The End with + comments and stuff +<hezekiah> I can't think of anything. +<jrand0m> I assume everyone's seen + http://www.cnn.com/2003/TECH/internet/08/05/anarchist.prison.ap/index.html ? +<thecrypto> not here +<jrand0m> (nop posted it here earlier) +<hezekiah> The thing about the guy who got arrested for linking to a bomb + building site? +<jrand0m> yes +<jrand0m> relevence to the need to get I2P up ASAP should be aparent ;) +<hezekiah> OK! jeremiah, those logs are now sent. +<jeremiah> thanks +<jrand0m> anyone have any questions / comments / thoughts / frisbees, + or are we having a record breaking short meeting? +* thecrypto tosses a frisbee +<-- logger has quit (Ping timeout) +<jrand0m> damn y'all are quiet today ;) +<mihi> question: +<mihi> where can non devs get yout java code? +<jrand0m> si sr? +<thecrypto> not yet +<mihi> 404 +<jrand0m> that'll be made available once we're release ready. aka the + source will go out with the SDK +<jrand0m> heh +<jrand0m> yeah, we don't use SF +<hezekiah> nop: Is it possible that we can get anonymous cvs working some tiem? +<hezekiah> time? +<-- mrflibble has quit (Ping timeout) +<nop> well, I would open up a non-standard port +<jrand0m> hezekiah> we'll have that once the code has the GPL license on there +<nop> but I am working on viewcvs +<jrand0m> aka not now since the gpl doc hasn't been added to the code yet +<hezekiah> jrand0m: It's in all the python code directories and all python + source files speceify licensing under GPL-2. +<jrand0m> hezekiah> is that on the cathedral? +<hezekiah> Yes. +<jrand0m> ah word. i2p/core/code/python ? or a different module? +* jrand0m hasn't seen it in there +<hezekiah> Each python code directory has a COPYING file in it with the + GPL-2 and each source file has the license set a GPL-2 +<hezekiah> It's i2p/router/python and i2p/api/python +<jrand0m> 'k +<jrand0m> so, yeah, by next tuesday we'll have the SDK + public source access. +<hezekiah> Cool. +<hezekiah> Or as you like to say, wikked. ;-) +<jrand0m> heh +<jrand0m> nada mas? +<hezekiah> nada mas? What's that mean!? +<jeremiah> nothing more +* jrand0m suggests you learn a lil espanol en universidad +--> mrflibble (mrflibble@anon.iip) has joined #iip-dev +<hezekiah> Questions anyone? +<hezekiah> Going once! +<-- ptm (~ptm@anon.iip) has left #iip-dev (ptm) +<hezekiah> Going twice! +<-- mrflibble has quit (mr. flibble says "game over boys") +<hezekiah> Speak now .. or wait until you feel like speaking later! +<thecrypto> okay, i'm going to be optimizing the elgamal even more, so expect + even faster elgamal benches in the future +<jrand0m> please focus on DSA and AES before tuning... puhleeeease :) +<thecrypto> i will +<hezekiah> The reason he's doing that is 'cause I'm causing trouble for + people again. ;-) +<thecrypto> i'm making DSA primes +--> mrflibble (mrflibble@anon.iip) has joined #iip-dev +<thecrypto> well, at least making the program to make DSA primes right now +<hezekiah> ElGamal in Java doesn't like an AMD K-6 II 333MHz. +<hezekiah> OK. +<hezekiah> Question round is over! +<jrand0m> ok hez, we're done. you wanna powow on getting the java client + and the python router work? +<hezekiah> See you all next week citizens! +* hezekiah smashes down the *baf*er +\ No newline at end of file diff --git a/pages/meeting53.html b/pages/meeting53.html new file mode 100644 index 00000000..e1e87f3f --- /dev/null +++ b/pages/meeting53.html @@ -0,0 +1,110 @@ +
+[21:09] <jrand0m> ok. 21:00 UTC esta ahora +[21:09] <jrand0m> welcome to the um meeting +[21:09] <jrand0m> we have a lot of people out today (nop, hezekiah, thecrypto, and userx), so we'll keep it brief +[21:10] <jrand0m> agenda: 1) hi 2) sdk 3) status 4) questions +[21:10] <jrand0m> 1) hi +[21:10] <jrand0m> hello. +[21:10] <jrand0m> 2) sdk +[21:11] <jrand0m> the I2P SDK 0.1 is ready for quiet release. +[21:11] <mihi> quiet release? +[21:11] <jrand0m> basically we're not publicizing it except for people in the know, and those trusted by people in the know +[21:12] <jrand0m> it is however fully ready to do application design, development, and testing with +[21:12] <jrand0m> If you're on #iip-dev, you're in the know +[21:13] <jrand0m> so anyone who wants to check it out can either pull it from CVS or retrieve source, docs, and build from CHK@GZ-A-C~SH03AwBuKf~AE3E347IcKAwI,4K38eh3m06zAygRzUnw4tQ/i2p_sdk.zip +[21:13] * UserX has joined #iip-dev +[21:13] <jrand0m> hey, its UserX +[21:14] <jrand0m> The 0.1 of the SDK contains the working java client API, as well as both a python and java router implementation and a simple command line chat application +[21:15] <jrand0m> The point of having the SDK is so that people can get a head start on development so their applications will be up and running once the network goes operational and public in september. +[21:16] <mihi> september that never ended? ;) +[21:16] <jrand0m> (rather than having the network up and running with no applications) +[21:16] <jrand0m> heh +[21:16] <jrand0m> no, we're actually beating the schedule I posted to iip-dev a few weeks back in the ganttproject document +[21:16] <jrand0m> not by much (5 days), but beating it none the less. +[21:17] <jrand0m> I'm quite confident that we'll be 1.0alpha in september. +[21:17] <jrand0m> Also, for status, I suspect that there will be a new I2NP (network proto) draft out by the end of the week. +[21:18] <jrand0m> Then, hopefully next week we can have some internal review and revisions, after which we can go into peer review. +[21:18] * shardy_ is now known as shardy +[21:18] <jrand0m> 'lo shardy +[21:18] <shardy> hiya. +[21:18] <shardy> how goes? +[21:19] <jrand0m> wikked. +[21:19] <jrand0m> I hear rumors we might be able to get some of your time for some .net client lib stuff? +[21:19] * jrand0m may be misinformed +[21:20] * ion has quit IRC (Ping timeout) +[21:21] <shardy> .net? nope, that's not me... +[21:21] <jrand0m> ah 'k, my bad +[21:21] <jrand0m> soy muy tonto +[21:21] <jrand0m> well, hi anyway :) +[21:21] <jrand0m> I also got some feedback from co wrt the naming service application +[21:22] * ion has joined #iip-dev +[21:22] <jrand0m> "On August 8th the first version of the specification for the naming service was posted. It was discovered that the specification has flaws, and I am revising it. It should be done within a week or so. After that, I will be start implementing the system. In the end, there will be four components of this software: +[21:22] <jrand0m> 1. Client program to interact with naming service. +[21:22] <jrand0m> 2. Program for the naming service itself. +[21:22] <jrand0m> 3. Administrative utilities for the naming service. +[21:22] <jrand0m> 4. A Certificate Authority (CA) component." +[21:23] <jrand0m> That's co's status report +[21:23] <jrand0m> I think that may be it for status, unless someone has something to add. +[21:24] <shardy> neat. +[21:24] <jrand0m> definitely neat +[21:24] <shardy> as soon as I get time I'm going to start looking over the specs and get familiar with the way you guys do things. +[21:25] <jrand0m> cool. the I2CP spec in the SDK is pretty much operational, but the I2P network spec posted yesterday is a few weeks behind the times. +[21:25] <jrand0m> I'll be posting a new version probably on friday. +[21:25] <jrand0m> (and as this project only began in earnest maybe a month ago, we're open for variations in how we work) +[21:26] <jrand0m> oh wait, now I remember, you're the ecc guy :) +[21:26] <shardy> yep, that's me. although I haven't really done much with ecc in a while... I'm now the prng guy. +[21:27] <jrand0m> oh nice. we're currently using generic prngs, and will want a better way to deal with random data +[21:27] <jrand0m> ok +[21:27] <shardy> generic ones? nop mentioned using yarrow, which seems pretty good. +[21:28] <shardy> I'm doing implementation work on a new prng now. trying to reduce the theory and practice gap somewhat. :) +[21:28] <jrand0m> right. we have a GPL'ed version of yarrow we can pull from freenet into the java implementations, but for the time being we're using java's built in one (java.security.SecureRandom) +[21:28] <jrand0m> heh +[21:29] <mihi> be careful w/ yarrow from freenet, it does heisenbugs ;) +[21:29] <jrand0m> lol +[21:29] <jrand0m> well, thats fixed now that its synchronized +[21:29] * jrand0m opens the floor to any questions +[21:30] * mihi gets DNF for the key mentioned above :( +[21:30] <jrand0m> shite. I inserted it a dozen times at htl 25 +[21:30] <jrand0m> I'll reinsert it yet again +[21:32] <jrand0m> anyone have any questions, other than "why won't freenet find the SDK's key?" +[21:33] * mihi did not ask that ;) and does not have any other questions until he looks @ it ;) +[21:33] <jrand0m> heh +[21:33] <mihi> who puts the log onto the wiki this time? /me has it completely this time. +[21:33] <jrand0m> awesome, go for it +[21:34] <jrand0m> I believe we're out of questions for the meeting, though please everyone feel free to post up further thoughts ot the mailing list. +[21:34] * jrand0m really likes active discussion on iip-dev, even if its everyone saying how my docs suck +[21:34] <mihi> your java sux, jrandom ;) (HHOK) +[21:35] <jrand0m> thats more like it +[21:35] <jrand0m> I'm reinserting the .zip from freenet's CLI, so it'll probably have a different CHK +[21:36] <jrand0m> I'll msg people with it after I reinsert it a few times +[21:36] <jrand0m> mihi wants it. anyone else I should msg? +[21:36] <jrand0m> (or anyone can ask at another time, as well) +[21:36] <mihi> you could mail it to me... +[21:36] <jrand0m> 1.1Mb +[21:37] <mihi> if it is not *too* large. +[21:37] <mihi> erm, okay then not. +[21:37] * mihi is not kind on fetching splitfiles anyway +[21:37] <mihi> s/kind/keen/ +[21:37] <jrand0m> heh, are you going to suggest I insert it without FEC? +[21:38] <mihi> i guess it won't have any chance in current freenet. +[21:38] <jrand0m> ok, I'll see about getting it web accessible with a private URL +[21:39] * jrand0m feels kind of weird with this quiet release thing, but I think its for the best +[21:40] <mihi> just put it on some webspace and put some gpg conventional encryption around it - and tell the passphrase here. +[21:40] <mihi> or use the key mentioned above as passphrase +[21:40] <mihi> btw - shall i strip that one from the log? +[21:41] <jrand0m> no need to. I'm paranoid enough to believe if its said here, its available to those who want to see it ;) +[21:41] <jrand0m> I'll have nop toss it up on some webspace when he gets back later this evening and anonymail people with the appropriate info (url & password / technology / etc) +[21:43] <mihi> thx. "this evening" regarding which time zone? (me will go to bea in about 1 hour) +[21:43] <mihi> s/bea/bed +[21:46] <jrand0m> heh, evening for nop, which is california +[21:46] <jrand0m> ok, I've got to jet. +[21:46] * jrand0m !thwaps meeting to an end +[21:46] <jrand0m> gracias srs y srtas +[21:46] * mihi hands jrandom the *baf*er +[21:47] * jrand0m *baf*s mihi on the head +[21:47] * shardy has quit IRC (EOF From client) +[21:48] <ion> 2 blocks downloading above url +[21:48] <jrand0m> nice +[21:48] * shardy has joined #iip-dev +[21:48] * mihi drops dead. +\ No newline at end of file diff --git a/pages/meeting54.html b/pages/meeting54.html new file mode 100644 index 00000000..57a625ce --- /dev/null +++ b/pages/meeting54.html @@ -0,0 +1,438 @@ +
+--- Log opened Tue Aug 19 16:56:12 2003 +17:00 -!- logger [logger@anon.iip] has joined #iip-dev +17:00 -!- Topic for #iip-dev: Weekly IIP development meetings, and other + conversations among developers are held here. +17:00 [Users #iip-dev] +17:00 [ cohesion] [ leenookx ] [ mihi] [ shardy_ ] [ UserXClone] +17:00 [ Ehud ] [ logger ] [ nop ] [ thecrypto] [ velour ] +17:00 [ hezekiah] [ lonelynerd] [ Rain] [ UserX ] [ WinBear ] +17:00 -!- Irssi: #iip-dev: Total of 15 nicks [0 ops, 0 halfops, 0 voices, +15 normal] +17:00 -!- Irssi: Join to #iip-dev was synced in 7 secs +17:00 < hezekiah> Alright! :) +17:00 < hezekiah> Both loggers are in place. :) +17:01 < thecrypto> yah! +17:03 < hezekiah> Hmmm ... +17:03 < hezekiah> This meeting was supposed to start 3 minutes ago. +17:03 < hezekiah> I wonder what's up. +17:04 < thecrypto> well, whose idle +17:04 < hezekiah> jrand0m's not even online. +17:04 < hezekiah> nop's been idle 15 minutes. +17:05 < nop> hi +17:05 < nop> sorry +17:05 < nop> I'm super busy at work +17:05 < mihi> [22:36] * jrand0m is off to dinner but i'll be back within + the half hour for the meeting +17:05 -!- jrand0m [~jrandom@anon.iip] has joined #iip-dev +17:05 < hezekiah> Hi, jrand0m. +17:05 < nop> hi +17:05 < nop> ok, here's the thing +17:05 < nop> I can't be seen on IIP at work right now +17:05 < nop> so I'll check in with yall later +17:05 < nop> got slack about it yesterday +17:05 < nop> so +17:05 < hezekiah> Bye, nop. +17:05 < thecrypto> bye +17:06 < nop> I'll hang in the channel +17:06 < nop> just won't be obvious :) +17:06 < hezekiah> jrand0m? Since you do the most talking these days, is + there anything you want on the agenda for this meeting? +17:07 < jrand0m> back +17:08 < jrand0m> ok, the pesto pasta was good. +17:08 < jrand0m> lemmie pull up the agenda-ish stuff +17:09 -!- Lookaround [~chatzilla@anon.iip] has joined #iip-dev +17:09 < jrand0m> x.1) i2cp sdk mods x.2) i2np review x.3) polling http + transport x.4) dev status x.5) todo x.6) plan for next two weeks +17:09 < jrand0m> (place x at whatever # in the agenda it fits) +17:10 < thecrypto> you are the agencda +17:10 < hezekiah> jrand0m: I don't have anything to say, and nop can +17:10 < hezekiah> can't talk. +17:10 < jrand0m> lol +17:10 < hezekiah> UserX most likely won't be adding anything (he usually + doesn't), so as far as I'm concerned it's all yours. :0 +17:10 < hezekiah> :) +17:10 < jrand0m> 'k. we logging? +17:10 < jrand0m> heh +17:10 < hezekiah> I'm logging everything. +17:10 < jrand0m> cool. ok. 0.1) welcome. +17:10 < jrand0m> hi. +17:11 < jrand0m> 0.2) mailing list +17:11 < jrand0m> the list is down atm, back asap. you'll know when it is :) +17:11 < jrand0m> for the meantime, wiki or use iip to convo. +17:11 < jrand0m> 1.1) i2cp sdk mods +17:12 < jrand0m> the SDK has been updated with some bugfixes, plus some new + things in the spec have been introduced. +17:12 < jrand0m> I posted to the list yesterday with the info. +17:13 < jrand0m> hezekiah/thecrypto/jeremiah> any questions on what I posted, + or thoughts on a plan to implement the changes? (or other alternatives I + haven't considered?) +17:13 < hezekiah> I've been running around like the chicken with my head + cut off getting ready for college. +17:13 < jrand0m> word, understood. +17:13 < hezekiah> I had a cursory look at what you wrote, but haven't actually + looked at the changes to the spec. +17:13 < jrand0m> we barely have any more of your time left, do we... +17:13 < hezekiah> Not until I get to college. +17:14 < hezekiah> Once I do, then I will probably be unheard from for at + least a week while I adjust. +17:14 < jrand0m> and once you get there you'll have a lot of settling in to do + (iirc from when i went to school ;) +17:14 < jrand0m> heh word. +17:14 < hezekiah> Then by then, I should be a bit more efficient and have + more time so I can code. +17:14 < jrand0m> cool +17:14 < thecrypto> i'm just doing crypto, so the data structures are my real + worry, once i have the CTS mode done, i'll go work on that prolly +17:14 < hezekiah> Anyway, that's my guess. +17:14 < jrand0m> awesome thecrypto +17:15 < jrand0m> ok, the good thing is the SDK works perfectly fine (with + the bugs mihi found being fixed [yay mihi!]) without the update to the spec. +17:15 -!- arsenic [~none@anon.iip] has joined #iip-dev +17:16 < jrand0m> ok, on to 1.2) i2np review +17:16 < jrand0m> anyone read the doc? +17:16 < jrand0m> ;) +17:16 < hezekiah> Not I, yet. +17:16 < hezekiah> As I said, I'm currently a chicken with its head cut off. +17:17 < hezekiah> BTW jrand0m, it appears you like sending PDF's. +17:17 < jrand0m> can everyone read openoffice .swx? +17:17 < hezekiah> I can. +17:17 < jrand0m> [if so, I'll send swx] +17:17 -!- abesimpson [~k@anon.iip] has joined #iip-dev +17:17 < thecrypto> i can +17:17 < hezekiah> I can't search for text in a PDF with KGhostView. +17:17 < hezekiah> So that really hurts. +17:17 < jrand0m> that sucks hezekiah +17:17 -!- mrflibble [mrflibble@anon.iip] has joined #iip-dev +17:17 < hezekiah> The linux version of Adobe Acrobat isn't very friendly eiter. +17:18 < jrand0m> ok, openoffice format it is instead of pdf. +17:18 < hezekiah> Cool. +17:18 < jrand0m> um, ok. i2np has a few minor changes to the LeaseSet + structure (reflecting the i2cp change posted earlier), but other than that, + largely in place. +17:19 < hezekiah> jrand0m: Are all these docs in cathedral's CVS? +17:19 < nop> oh +17:19 < nop> can I interject +17:19 < hezekiah> i.e. copies of the PDF files you've been sending to the + list, etc. +17:19 < hezekiah> nop: Go ahead. +17:19 < nop> this is offtopic but important +17:19 -!- ChZEROHag [hag@anon.iip] has joined #iip-dev +17:19 < nop> IIP-dev and the mail are kind of screwy right now +17:19 < hezekiah> I noticed. +17:19 < nop> so bear with us for a bit +17:20 < nop> we're trying to get it up and going +17:20 < nop> but it has spam assassin built in +17:20 < nop> which is the good news +17:20 < nop> :) +17:20 < nop> and a lot of other features +17:20 < jrand0m> any eta nop for the list? +17:20 * ChZEROHag pokes his nose in +17:20 < jrand0m> (i know you're busy, not nagging, just wondering) +17:20 < nop> hopefully by tomorrow +17:20 < jrand0m> cool +17:20 < nop> the mail admin is working on it +17:21 * hezekiah notes that jrand0m _really_ likes the iip-dev list. ;-) +17:21 < nop> haha +17:21 < hezekiah> Go delta407! +17:21 < nop> anyway +17:21 < jrand0m> its best to document decisions publicly hezekiah ;) +17:21 < nop> back to our regularly scheduled meeting +17:21 < jrand0m> heh +17:21 -!- nop is now known as nop_afk +17:21 < hezekiah> jrand0m: So where were we? +17:21 < jrand0m> ok, to your equestion hezekiah> some are, but the latest + aren't. I'll switch to placing in the openoffice format. +17:21 < jrand0m> rather than the pdfs +17:22 < hezekiah> OK. +17:22 < hezekiah> It'd be really cool if all the docs were in CVS. +17:22 < jrand0m> definitely, and they will be +17:22 < hezekiah> Then I can just update, and I know I have the latest edition. +17:22 < jrand0m> (there are the three drafts that aren't so far) +17:22 < hezekiah> (BTW, a little off topic, but is anonymous access to + cathedral up yet?) +17:23 < jrand0m> not yet. +17:23 < jrand0m> ok, by friday, I hope to have another draft of I2NP in + full form [aka no more ... for the kademlia explanation sections, and sample + implementation details] +17:24 < jrand0m> there are no significant changes. just more filling + clarifying things. +17:24 < hezekiah> Sweet. +17:24 < hezekiah> Will there be byte layout for data structures avalible in it? +17:24 < jrand0m> 1.3) I2P Polling HTTP Transport spec. +17:24 < jrand0m> no, byte layouts go in the data structures spec, which + should be converted to the standard format instead of html +17:25 < jrand0m> (though I2NP already has all the necessary byte layouts) +17:25 < jrand0m> ((if you read it *cough* ;) +17:25 < hezekiah> Good. +17:25 < hezekiah> lol +17:25 < hezekiah> Sorry about that. +17:25 < hezekiah> As I said, I've been really busy. +17:25 < jrand0m> heh no worry, you're heading off to college shortly, you're + supposed to be partying :) +17:25 < hezekiah> Partying? +17:25 < jrand0m> ok, 1.3) I2NP Polling HTTP Transport spec +17:25 < hezekiah> Hmmm ... I guess I'm just odd. +17:25 < jrand0m> heh +17:26 < jrand0m> ok, I tried sending this out earlier, but I'll commit + it shortly. its a quick and dirty transport protocol fitting in with I2NP + to allow routers to send data back and forth without direct connections + (e.g. firewalls, proxies, etc) +17:27 < jrand0m> I'm *hoping* someone can see how this works and build + similar transports (e.g. bidirectional TCP, UDP, direct HTTP, etc) +17:27 -!- mihi [none@anon.iip] has quit [Ping timeout] +17:27 < hezekiah> Hmmm, well I don +17:27 < jrand0m> before putting I2NP out for review, we need to include + sample transports so people can see the full picture +17:27 < hezekiah> don't think _I'll_ be building any transports soon. ;-) +17:27 -!- WinBear_ [~WinBear@anon.iip] has joined #iip-dev +17:27 < hezekiah> TCP is working for Java and Python. +17:27 < hezekiah> (At least client-to-router is.) +17:27 < jrand0m> no worry, I'm just putting it out there as a todo for people + who want to contribute +17:28 < hezekiah> Right. +17:28 < jrand0m> right, client-router has different requirements than the + router-router. +17:28 < jrand0m> ok, anyway, 1.4) dev status +17:28 < jrand0m> how we doing with CBC thecrypto? +17:28 < thecrypto> CBC is committed +17:28 < jrand0m> w00000t +17:28 < thecrypto> CTS is almost done +17:28 < hezekiah> thecrypto: What's CTS? +17:29 < thecrypto> i just have to figure out how to implement i nicely +17:29 < jrand0m> cts being cyphertext stealing :) +17:29 < hezekiah> Ah! +17:29 < thecrypto> CipherText Stealing +17:29 -!- WinBear [WinBear@anon.iip] has quit [EOF From client] +17:29 < jrand0m> did you pull nop's reference on that? +17:29 < hezekiah> OK. We're using CBC with CTS instead of padding. +17:29 < hezekiah> Hmm. +17:29 < thecrypto> basically, it makes the message exaclty right length +17:29 < jrand0m> is that workable for the python side hezekiah? +17:29 < hezekiah> I might need to slap the Python crypto lib I'm using upside + the head to make it us CTS properly. +17:30 < hezekiah> I've always prefered CTS over padding, but I don't know + what PyCrypt does. +17:30 < jrand0m> what can python do out of the box to allow exact message + size recovery? +17:30 < thecrypto> all you need to do is change how you process the last + two blocks +17:30 < hezekiah> I have a feeling that library is going to get some serious + rewritting. +17:30 < hezekiah> jrand0m: The CBC stuff in python is transparent. You just + send the buffer to the AES objects encrypt function. +17:31 < hezekiah> It spits out cipher text. + +17:31 < hezekiah> End of story. +17:31 < jrand0m> does D(E(data,key),key) == data, byte for byte, exact + same size? +17:31 < hezekiah> So if it has the wacky idea of using padding instead of CTS, + then I might need to get in its guts and fix it. +17:31 < jrand0m> (regardless of input size?) +17:31 -!- mihi [~none@anon.iip] has joined #iip-dev +17:31 < hezekiah> jrand0m: Yes. It should. +17:31 < jrand0m> hezekiah> if you could look into exactly what algorithm it + uses to do the padding, that'd be great +17:32 < hezekiah> Right. +17:32 * jrand0m is hesitant at requiring a mod to a python crypto lib if + the lib already uses a standard and useful mechanism +17:32 < hezekiah> One way or another, CBC with CTS sounds good. +17:32 < hezekiah> jrand0m: This python crypto lib stinks. +17:32 < jrand0m> heh 'k +17:33 < thecrypto> i just have to calculate how to mess with the two blocks +17:33 < hezekiah> jrand0m: ElGamal will need to be completely rewritten in + C just to make it fast enough to use. +17:33 < jrand0m> hezekiah> whats the benchmark for python elg of 256bytes? + its only done once per dest-dest comm... +17:34 < jrand0m> (if you know offhand, that is) +17:34 < hezekiah> I'd have to test it. +17:34 < hezekiah> Encryption is only a second or two I think +17:34 < jrand0m> < 5 sec, < 2 sec, > 10 sec, > 30 sec? +17:34 < thecrypto> i'll prolly do some work with it +17:34 < hezekiah> Decrypton might be some place between 5 or 10 seconds. +17:34 < jrand0m> cool. +17:35 < jrand0m> hezekiah> have you spoken with jeremiah or do you have any + news about the status of the python client api? +17:35 < hezekiah> thecrypto: All you should need to do is write a C module + that works with Python. +17:35 < hezekiah> I have no clue what he's been up to. +17:35 < hezekiah> I haven't spoken to him since I got back. +17:35 < jrand0m> 'k +17:35 < jrand0m> any other dev status thoughts? +17:36 < hezekiah> Um, not really from me. +17:36 < hezekiah> I've already explained my current free time status. +17:36 < jrand0m> word. understood +17:36 < hezekiah> My only plans are to get the C API up and the python router + back up to spec. +17:37 < jrand0m> 'k +17:37 < hezekiah> Oh my goodness! +17:37 < jrand0m> 1.4) todo +17:37 < jrand0m> si sr? +17:37 < hezekiah> The Python crypto lib doesn't implement CTS or padding! +17:37 < hezekiah> I'll have to do that manually. +17:37 < jrand0m> hmm? it requires data to be mod 16 bytes? +17:37 < hezekiah> Yup. +17:38 < jrand0m> heh +17:38 < jrand0m> oh well. +17:38 < hezekiah> Currently the Python router uses padding. +17:38 < jrand0m> ok. here are some oustanding items that need to get done. +17:38 < hezekiah> I remember that now. +17:38 < hezekiah> Well, let +17:38 < hezekiah> let's be frank about one thing. +17:38 < hezekiah> The Python router is never really meant to be used. +17:39 < hezekiah> It's primarily meant for me to be very familiar with the + spec and it also accomplishes something else: +17:39 < hezekiah> It forces the Java router to comply _exactly_ with the spec. +17:39 < jrand0m> both very important goals. +17:39 < hezekiah> Sometimes the Java router doesn't quite comply, and then + the Python router screams bloody murder. +17:39 < hezekiah> So it doesn't really need to be fast or stable. +17:39 < jrand0m> plus I'm not sure it won't ever be used in the sdk +17:39 < jrand0m> right. exactly. +17:39 < jrand0m> the python client api is a different thing though +17:39 < hezekiah> The Python client API on the other hand needs to be decent. +17:40 < jrand0m> exactly. +17:40 < hezekiah> But that's jeremiah's problem. :) +17:40 < hezekiah> I've left that to him. +17:40 < jrand0m> the SDK local only routers are client dev use only +17:40 < jrand0m> lol +17:40 < jrand0m> ok, as I was saying... ;) +17:40 < hezekiah> ;-) +17:41 < jrand0m> - we need someone to start working on a small web page + for i2p that will be used for putting out the various I2P related specs for + peer review. +17:41 < jrand0m> I'd like this to be ready before 9/1. +17:41 < hezekiah> OK. I am stating right now that you don't want me to do that. +17:41 < hezekiah> I'm not a good webpage designer. :) +17:41 < jrand0m> nor I, if anyone here has seen my flog ;) +17:41 < jrand0m> cohesion? ;) +17:41 < hezekiah> lol +17:42 < hezekiah> Poor cohesion, always stuck with the dirty work. :-) +17:42 * cohesion reads the back log +17:42 < hezekiah> ;) +17:42 < jrand0m> heh +17:42 < cohesion> jrand0m: I will do it +17:42 < cohesion> me@jasonclinton.com +17:42 < cohesion> send me the specs +17:42 < jrand0m> 'k, gracias. +17:42 < jrand0m> the specs aren't all done yet. +17:43 < jrand0m> but the contents that will need to be there are: +17:43 < cohesion> well, what you have an what you would like to have put up +17:43 < jrand0m> -I2CP spec, I2NP spec, Polling HTTP Transport spec, TCP + Transport spec, Security analysis, Performance analysis, Data structure spec, + and a readme/intro +17:44 < jrand0m> (those 7 documents will be in pdf and/or text format) +17:44 < cohesion> k +17:44 < jrand0m> barring the readme/intro +17:45 < jrand0m> I'm hoping that all of those docs will be ready by next week + (8/26). will that give you enough time to get together a small page for a +9/1 release? +17:46 < jrand0m> ok. another thing that will need to come down the pipe is + an I2P network simulator. +17:46 < jrand0m> do we have anyone looking for a CS project? ;) +17:46 < hezekiah> lol +17:46 < cohesion> jrand0m: yea, that's doable +17:47 < hezekiah> I'm not for another few years. ;-) +17:47 < jrand0m> cool cohesion +17:47 < thecrypto> not for a year +17:47 * cohesion goes back to work +17:47 < jrand0m> tnx cohesion +17:48 < jrand0m> ok, 1.6) next two weeks. on my plate is getting these specs, + docs, and analysis up. I'll post & commit as soon as I can. +17:48 < jrand0m> PLEASE READ THE SPECS AND COMMENT +17:48 < jrand0m> :) +17:48 < hezekiah> jrand0m: Right. Once I get time, I will start reading. :) +17:48 < jrand0m> I'd prefer people to post comments to the list, but if + people want to be anon, send me comments privately and I'll post replies to + the list anonymously. +17:49 < hezekiah> (What do you think the eta for OpenOffice files for the + docs being on CVS is?) +17:49 < jrand0m> I can commit the latest revs within 10 minutes of this + meeting being over. +17:49 < hezekiah> Awesome. :) +17:50 < jrand0m> ok, thats it for 1.*. +17:50 < jrand0m> 2.x) comments/questions/concerns/rants? +17:50 < jrand0m> how's the sdk mod working out mihi? +17:51 < jrand0m> or anyone else? :) +17:51 < hezekiah> jrand0m: What is this sdk mod you're talking about? +17:52 < jrand0m> hezekiah> two bugfixes to the sdk, commited (& posted) + the other day +17:52 < hezekiah> Ah +17:52 < hezekiah> Neato. +17:52 < jrand0m> (rotate the message IDs, synchronize writes) +17:52 < hezekiah> Just the java side, or the python side too? +17:52 < jrand0m> yo no hablo python. +17:53 < hezekiah> lol +17:53 < jrand0m> not sure if the bugs exist there. do you rotate message + ids every 255 messages, and synchronize your writes? +17:54 < hezekiah> I think the Python router does both +17:54 < jrand0m> cool. +17:54 < jrand0m> we'll let you know if it doesn't ;) +17:54 < hezekiah> What exactly do you mean by "synchronize your writes"? +17:55 < jrand0m> aka make sure multiple messages aren't written to a client + at the same time if there are multiple clients trying to send messages to + it at the same time. +17:55 < hezekiah> All the data sent over the TCP connection gets sent in + the order it originated. +17:56 < hezekiah> So you won't be 1/2 of message A and then 1/3 of message B. +17:56 < jrand0m> 'k +17:56 < hezekiah> You'll get message A and then message B. +17:56 < hezekiah> OK ... if no one else is going to talk, I suggest we + adjurne the meeting. +17:56 < mihi> my simple TCP/IP over I2p seems to work... +17:56 < jrand0m> niiiiice!! +17:56 * mihi was idling a bit sorry +17:57 < hezekiah> Anyone else have anything to say? +17:57 < jrand0m> mihi> so we'll be able to run pserver over that? +17:57 < mihi> as long as you do not try to create lotas connections at once. +17:57 < mihi> jrand0m: i guess so - i could ge tgoogle through it +17:57 < jrand0m> niiiice +17:57 < jrand0m> mihi++ +17:57 < mihi> jrand0m-ava +17:57 < jrand0m> so you have an outproxy and an inproxy? +17:58 < mihi> exactly. +17:58 < jrand0m> cool +17:58 < mihi> the destination needs keys, the source generates them on demand +17:58 * hezekiah hands jrand0m the *baf*er. Smash the thing when you're + done, man. +17:58 < jrand0m> right. hopefully co's naming service could help with that + once its ready. +17:59 < jrand0m> ok cool. mihi, let me or anyone else know if there's + anything we can do to help :) +17:59 < mihi> fix that thing with the 128 msgids or build a better GUARANTEED + support +17:59 * jrand0m *baf*s nop_afk over the head for having a real job +18:00 < mihi> jrand0m: baf abuse costs 20 yodels +18:00 < jrand0m> lol +18:00 < jrand0m> better guaranteed support? +18:00 < jrand0m> (aka better performance than the one described? we'll fix + that in impl) +18:00 < mihi> did you test my test case with start_thread=end_thread=300? +18:01 < mihi> it generates lots of messages in one direction, and that causes + all msgids to be eaten... +18:01 < jrand0m> hmm, no, hadn't seen that message +18:01 < hezekiah> jrand0m: Would it be reasonable to make msgid 2 bytes? +18:01 * jrand0m tried the 200 / 201, but thats fixed with the latest +18:01 -!- cohesion [cohesion@anon.iip] has quit [off to the lug meeting] +18:01 < mihi> which latest? +18:01 < hezekiah> Then they would have 65535 msgids (if you don't could + msgid 0) +18:01 < hezekiah> . +18:02 < jrand0m> 2 byte message ids wouldn't hurt. I'm comfortable with + that change. +18:02 < jrand0m> mihi> the one I mailed you +18:02 < mihi> if you have a more latest than the one you sent me, send it + (or give me cvs access) +18:03 < mihi> hmm, that one fails for me with 200/201 (as well as with 300) +18:03 < jrand0m> hmm. I'll do some more testing and debugging and mail you + what I come up with. +18:03 < mihi> thx. +18:04 < jrand0m> ok. +18:04 * jrand0m declares the meeting +18:04 < jrand0m> *baf*'ed +18:04 * hezekiah hangs the *baf*er reverantly on its special rack. +18:05 * hezekiah then spins around walks out the door, slamming it behind + him. The baffer falls off the rack. +18:05 < hezekiah> ;-) +--- Log closed Tue Aug 19 18:05:36 2003 +\ No newline at end of file diff --git a/pages/meeting55.html b/pages/meeting55.html new file mode 100644 index 00000000..7f136281 --- /dev/null +++ b/pages/meeting55.html @@ -0,0 +1,211 @@ +
+[23:00] <jrand0m> ok, topics> x.0: welcome x.1: spec questions x.2: elg issues x.3: sdk status x.4: release plan x.5: apps
+[23:00] <jrand0m> is x == 0 or 1 or 2?
+[23:00] <jeremiah> 22/7
+[23:01] <thecrypto> i think it's 0
+[23:01] * jrand0m always logs, so wtf, why not.
+[23:01] <jrand0m> 0.0: welcome.
+[23:01] <jrand0m> hi.
+[23:01] <jrand0m> 0.1: spec questions
+[23:01] <jrand0m> anyone read the specs? :)
+[23:02] * mihi did. at least tried to
+[23:02] <jrand0m> w0ah word
+[23:02] <jeremiah> nope
+[23:02] <jeremiah> what are the new ones?
+[23:02] <thecrypto> occasionally
+[23:02] <jrand0m> mihi> tried to, hard to read, bad language, incomprehensible organization, or just boring as fuck?
+[23:03] <mihi> i'm just not familiar enough with crypto. the first part was very interesting.
+[23:03] <jrand0m> jeremiah> specs are in cvs, and I post to iip-dev when they come out. current ones are: i2cp, i2np, i2p data structures, polling http transport proto
+[23:03] <mihi> but when it got into detaily, you could have described how to brew an irish stew and i would not hav noticed ;)
+[23:04] <jeremiah> sweet
+[23:04] <jrand0m> lol mihi
+[23:05] <mihi> although the format had its problems as well -don't have open office here, just ol' staroffice 5.2
+[23:05] <jrand0m> does star office 5.2 not read it? would you prefer .pdf or kludged html?
+[23:05] <jrand0m> (or .txt? though txt wouldn't have pics or real formatting)
+[23:05] <mihi> i'd prefer "old" .sdw format.
+[23:05] <jeremiah> pdf if at all possible
+[23:05] <mihi> or pdf
+[23:06] <jrand0m> pdf is a one click solution.
+[23:06] * jrand0m edits in open office, reads in pdf
+[23:06] <jeremiah> or appleworks
+[23:06] <jeremiah> ;)
+[23:06] <mihi> sxw is supported only in staroffice 6.0 and above
+[23:06] <jrand0m> ah ok mihi
+[23:06] * jrand0m put out .sxw because last time people complained and wanted .sxw. when we publish we'll put out .sxw, .sdw, and .pdf
+[23:07] <jrand0m> (or maybe .doc if i'm feeling dirty)
+[23:07] <mihi> i would not mind .sdw.zip or .sdw.gz or .sdw.bzw either...
+[23:07] <mihi> s/bzw/bz2/
+[23:07] <jrand0m> heh, zipped up, for sure.
+[23:08] <jrand0m> the data structures spec may require a mod, and the network proto requires some fixed urls before release.
+[23:08] <jrand0m> anyone have any questions on any of the four specs?
+[23:09] <thecrypto> not at the momemet
+[23:10] <jrand0m> ok. 0.2: elg issues
+[23:10] <jrand0m> we're having some probs w/ elgamal encryption as specified on p13 of the data structures spec.
+[23:11] <jrand0m> it may be key related, algorithm related, or implementation related. probably not implementation related, as this has been tested against two implementations.
+[23:11] <jrand0m> if its algorithm related, we're going to want to update the spec prior to spec release to reflect whatever we need to change to make it work.
+[23:12] <jrand0m> if its implementation or key generation related, we can publish the spec and fix the sdk when resolved.
+[23:13] <jrand0m> thecrypto> any thoughts on whats up, or we waiting for nop to reply to the list (or here, if he's around and available to talk)
+[23:14] <thecrypto> i'm trying to figure it out at the moment
+[23:15] *** Signoff: mihi (Ping timeout)
+[23:15] *** mihi_ (~none@anon.iip) has joined channel #iip-dev
+[23:15] <jrand0m> 'k
+[23:15] *** mihi_ is now known as mihi
+[23:15] <thecrypto> i have to run some math and through some other implementation and figure it out
+[23:15] <thecrypto> i never had a problem with elgamal
+[23:15] <thecrypto> last time i tested
+[23:16] *** Signoff: mihi ((null))
+[23:17] <thecrypto> with that benchmark
+[23:17] <jrand0m> right, but the benchmark only tried one key
+[23:17] <thecrypto> ahh
+[23:17] <jrand0m> i can quite repeatedly get the error without any mods to the elg impl
+[23:17] <thecrypto> didn't we have a wrong key message that came up?
+[23:18] <jrand0m> yes, those still come up
+[23:18] *** mihi_ (~none@anon.iip) has joined channel #iip-dev
+[23:18] <jrand0m> periodically (usually 2-4 times per keygen)
+[23:18] *** mihi (~none@anon.iip) has joined channel #iip-dev
+[23:18] *** mihi is now known as mihi_backup
+[23:18] *** mihi_ is now known as mihi
+[23:18] <thecrypto> and we still get bad keys?
+[23:19] <jrand0m> or something.
+[23:19] <jrand0m> all that wrong size tests is "if ( (k0.length == PublicKey.KEYSIZE_BYTES) && (k1.length == PrivateKey.KEYSIZE_BYTES) ) {"
+[23:19] <jrand0m> no value evaluation, etc.
+[23:20] <thecrypto> one second
+[23:23] <thecrypto> can you check if x the private key is < p
+[23:23] <jrand0m> if (m.compareTo(CryptoConstants.elgp) >= 0)
+[23:23] <jrand0m> already done.
+[23:23] <jrand0m> (throw new IllegalArgumentException("ARGH. Data cannot be larger than the ElGamal prime. FIXME");) that exception is never thrown.
+[23:23] <jrand0m> er x? hmm.
+[23:24] <jrand0m> 'k. perhaps we may want to steal bouncycastle's or another impl's elg key gen algo
+[23:25] <jrand0m> ok. 0.3> sdk issues
+[23:26] <jrand0m> elg is pending, but other than that the sdk is very close to 0.8 (aka release matching specs)
+[23:26] <jrand0m> (only the elg issue plus the LeaseSet modification is left)
+[23:26] <jrand0m> I'd like to have the SDK 0.8 ready to go with the spec release, but I don't think we should commit to that.
+[23:27] <jrand0m> or even whether we need to include SDK 0.1 with the spec release.
+[23:27] <thecrypto> gah! annoying
+[23:28] <thecrypto> miracl which nop pointed me too does the exact same thing we do
+[23:28] <thecrypto> and they have no checks
+[23:28] <jrand0m> unsigned though.
+[23:28] <jrand0m> (since miracl is in c)
+[23:28] * jrand0m assumes
+[23:28] <thecrypto> yes
+[23:29] <thecrypto> but still, i make sure we never have a signed biginteger
+[23:30] <jrand0m> biginteger.toByteArray() returns a signed byte array
+[23:30] <thecrypto> sorry, continue
+[23:30] <jrand0m> 'k
+[23:30] <jrand0m> any movement on the python front jeremiah?
+[23:31] <jeremiah> hey
+[23:31] <jeremiah> sorry I was reading the backlog
+[23:31] <jrand0m> heh hi
+[23:31] <jeremiah> nope, I'm still getting used to classes
+[23:31] <jrand0m> coo'
+[23:31] <jrand0m> no prob
+[23:31] <jeremiah> I think I'm gonna sleep for a bit actually
+[23:31] <jrand0m> 'k
+[23:32] <jrand0m> 0.4: release plan
+[23:32] <jrand0m> we need the sdk issues resolved in the next day or so, one way or another.
+[23:32] <jrand0m> we need to get working on wiki-fiying the security model
+[23:32] <jrand0m> (wiki, where art thou)
+[23:33] <jrand0m> we need to get the performance model up (not a prob, ill have it in a day or so)
+[23:33] <jrand0m> we need to update the specs to include any elg mods, plus real URLs to other specs.
+[23:33] <nop> miracl
+[23:33] <nop> has a port
+[23:33] <nop> to java
+[23:33] <jrand0m> perhaps we need to host the specs && / || sdk outside the US for export regulations [not that i care]
+[23:34] <jrand0m> right, but miracl's java port doesnt have elg encryption last i checked.
+[23:34] <jrand0m> i'll check again.
+[23:34] <nop> jrand0m, we don't care, but we'll worry about that later
+[23:34] <nop> jrand0m if it has bigdig() and modexp()
+[23:34] <nop> you're fine
+[23:34] *** yodel (~yodel@anon.iip) has joined channel #iip-dev
+[23:34] <thecrypto> one second
+[23:34] <thecrypto> i think i found our problem
+[23:35] <jrand0m> word, whats up thecrypto?
+[23:35] <nop> can you check jrand0m
+[23:35] <thecrypto> our k isn't being checked for relitive prime
+[23:36] <jrand0m> will that cause the problems described thecrypto? i thought that would just render the encryption insecure (a problem, nonetheless)
+[23:36] <thecrypto> but that would mean only some messages with the key would fail
+[23:36] <thecrypto> it's something in keygen
+[23:36] <jrand0m> nop> we'll find something to solve it. but i outlined some specific questions in my email that are implementation independent
+[23:36] <jrand0m> ok thecrypto, we'll work through that after the meeting
+[23:37] <nop> the double ciphertext question?
+[23:37] <thecrypto> okay
+[23:37] <jrand0m> nop> thats one of the questions
+[23:37] * nop goes to read
+[23:39] <jrand0m> nop> any ideas on when the wiki will be up? if its just dns, whats the IP so I can mod my hosts file so I can start editing?
+[23:40] <thecrypto> quick q jrand0m: where does it fail, the benchmark runs perfectly and it makes a new keypair every time?
+[23:41] <nop> let me get it up, hold
+[23:41] <mihi> wiki.invisiblenet.net == jasonclinton.com [64.91.236.103]
+[23:41] <jrand0m> gracias mihi
+[23:42] <jrand0m> thecrypto> it makes a new keypair each time. it fails on a two line test case that I built when debugging the ElGamalAESEngine
+[23:42] <thecrypto> can i see this ElGamalAESEngine?
+[23:42] <thecrypto> just commit it to CVS and i'll see what the problem is
+[23:43] <nop> ok wiki is cname'd
+[23:43] <nop> should propagate in a bit
+[23:43] * jrand0m doesnt commit things that don't work, but I'll email you
+[23:43] <jrand0m> thanks nop
+[23:43] <nop> it's up
+[23:43] <nop> ;)
+[23:43] <nop> (Link: http://wiki.invisiblenet.net)http://wiki.invisiblenet.net
+[23:43] <jrand0m> not on my box it aint
+[23:43] <jrand0m> ;)
+[23:44] <nop> what are we wiki'ing
+[23:44] <nop> ?
+[23:44] <jrand0m> the security doc, plus a place to distro the specs.
+[23:44] <jrand0m> perhaps even the i2p website prior to 1.0 release, but at least the security doc.
+[23:45] *** Signoff: sirk ((null))
+[23:45] *** Signoff: shardy_ (Ping timeout)
+[23:46] <jrand0m> ok. given the above 5 points on the release plan, I'd like to have the specs out friday, saturday, or sunday, at the latest.
+[23:46] *** shardy_ (~shardy@anon.iip) has joined channel #iip-dev
+[23:46] <nop> I have a grphx guy working on the website
+[23:47] <nop> for i2p
+[23:47] <jrand0m> any problems with that for a deadline? [friday deadline, fallback only if Bad Things Happen]
+[23:47] <nop> sure
+[23:47] <thecrypto> jrand0m: sent?
+[23:47] <jrand0m> 'k, so just the security docs and the i2p spec distro location
+[23:47] <jrand0m> no thecrypto, there are half a dozen files. i'll send after the meeting.
+[23:47] <thecrypto> okay
+[23:48] <thecrypto> i'd like them sooner because we're moving tables around today so i need to move computers soon
+[23:48] <nop> jrand0m, I'll need to look at your email and I'll respond shortly
+[23:48] <nop> multi-tasking
+[23:49] <jrand0m> 'k.
+[23:49] <jrand0m> 0.5> apps
+[23:49] <jrand0m> the name service is awol, as co aint around ;) [but i think he just went off to school too, so thats to be expected for the short term]
+[23:49] <jrand0m> mihi has an awesome awesome i2ptunnel app
+[23:50] *** Signoff: WinBear_ (EOF From client)
+[23:50] <mihi> strip one or two `awesome's ;)
+[23:50] <jrand0m> heh
+[23:51] <jrand0m> well, its very impressive. there's still stuff to add, but as is its a working port forwarder with reasonable performance. a really good proof of concept
+[23:51] <mihi> it relies on too many things i cannot see from the spec (e.g. that GUARANTEED packets are delivered in order)
+[23:52] <jrand0m> guaranteed packets are not delivered in order, but the java impl blocks on send of guaranteed, so if you use the java impl w/ guaranteed and don't have multiple sending threads, its guaranteed in order.
+[23:52] <jrand0m> ideally, it'd be cool if it FEC'ed or had built in ordering & reconstruction or something
+[23:52] <jrand0m> (so that it didn't block on send and didn't require GUARANTEED)
+[23:53] <mihi> that's a bot too many ifs i think...
+[23:53] <mihi> s/bot/bit/
+[23:55] <mihi> but perhaps i'll have some time to add reordering/resending to it...
+[23:55] <jrand0m> well, thats how the java client impl is implemented ;) guaranteed is not recommended for low latency synchronous use, as it requires an ack (which in turn is a full message delivery, though without the client side end to end crypto, just i2np crypto)
+[23:55] <jrand0m> word
+[23:56] <jrand0m> any other apps on the horizon? should we have a page on the wiki w/ apps & app ideas for devs to get involved with?
+[23:57] * jrand0m thinks we probably aren't too far off until yodel's xml rpc can operate via the i2p sdk (either through mihis tunnel or natively)
+[23:57] <nop> hmm
+[23:57] <thecrypto> test
+[23:57] <jrand0m> tset
+[23:57] <thecrypto> still connected?
+[23:57] <jrand0m> si sr
+[23:58] <thecrypto> we're unplugging phonelines right now
+[23:58] <nop> IIP, it defies phone lines
+[23:58] <jrand0m> heh
+[23:58] <nop> :)
+[23:58] <thecrypto> i can get back on the IM front and file transfer
+[23:58] <jrand0m> wikked
+[00:00] <jrand0m> ok. thats all i have for agenda items.
+[00:00] <jrand0m> any comments/questions/concerns/frisbees?
+[00:00] * thecrypto throws a frisbee
+[00:00] * jrand0m gets a frisbee in the face
+[00:01] <thecrypto> i just want to get this crypto stuff done so i can go back and optimize elg
+[00:01] <thecrypto> and do the same for python hopefully
+[00:01] <jrand0m> word. I'll get you the code in the next 5
+[00:02] <thecrypto> that would be good
+[00:03] * jrand0m readies the *baf*er
+[00:03] * jrand0m winds up
+[00:03] * jrand0m *baf*s the meeting to a close.
+
\ No newline at end of file
diff --git a/pages/meeting56.html b/pages/meeting56.html
new file mode 100644
index 00000000..71d88505
--- /dev/null
+++ b/pages/meeting56.html
@@ -0,0 +1,212 @@
++[22:53] <jrand0m> ok, wtf, why not. agenda: +[22:53] <jrand0m> 0) welcome +[22:53] <jrand0m> 1) spec & sdk release +[22:53] <jrand0m> 2) spec & sdk questions +[22:53] <jrand0m> 3) dev status 3.1) co's NS 3.2) SDK 1.0 criteria 3.3) network simulator 3.4) other apps [IM, tunnel, etc] 3.5) more transports 3.6) java router implementation +[22:53] <jrand0m> 4) meeting time change? +[22:53] <jrand0m> 5) cvs administravia +[22:54] <jrand0m> 6) shardy's stuff +[22:54] <jrand0m> 7) peanut gallery +[22:54] <jrand0m> thazzit. +[22:54] <jrand0m> 0) welcome +[22:54] <w0rmus> hihi +[22:54] <thecrypto> so welcome everyone to meeting number 55 +[22:54] <thecrypto> 56 +[22:55] <thecrypto> 56 is correct +[22:55] *** Signoff: mihi (EOF From client) +[22:55] <jrand0m> hi. welcome to meeting 56 +[22:55] <jrand0m> yea +[22:55] <jrand0m> 1) spec & sdk release +[22:55] <w0rmus> haha +[22:55] *** mihi (~none@anon.iip) has joined channel #iip-dev +[22:55] <jrand0m> the specs are out and the sdk 0.2 is out as well. +[22:56] <jrand0m> currently, they're only available on freenet [http://localhost:8888/CHK@p1VU1U67UgXYJ7v7cS4Xqn~p4ssLAwI,RvdwV4jZyZYcJgYabpVPOQ/I2P_SDK.zip] +[22:56] <jrand0m> but nop told me he'd have them on the normal web today, as well as an email to a few of the traditional lists to round up some reviewers +[22:57] <jrand0m> 2) any new questions on the specs or the sdk? +[22:58] *** nixonite (~nixonite@anon.iip) has joined channel #iip-dev +[22:58] *** terrific (terrific@anon.iip) has joined channel #iip-dev +[22:58] <jrand0m> well, first question in there is, how goes the progress /reading/ the specs? :) +[22:58] <w0rmus> needa do that :) +[22:58] <thecrypto> slowlyu +[22:58] <w0rmus> therefore I have no questions +[22:58] <jrand0m> heh word +[22:59] <w0rmus> I'll start now then +[22:59] <jrand0m> suggested order of reading the PDFs is> I2POverview.pdf, then I2NP, then datastructures, then I2CP, then polling HTTP transport +[22:59] <w0rmus> ok I'll do it in that order then +[23:00] <jrand0m> ok. on to # 3 then, unless there are any q's on the specs +[23:00] <jrand0m> 3.1) co's naming service proposal +[23:00] <jrand0m> he posted rev 1.1 of his spec up to the mailing list this morning and it seems to deal with a lot of the issues brought up before +[23:01] <jrand0m> does anyone have any comments/questions on the spec that they want to say here? or should we just do that part on the list, since co isn't here atm? +[23:01] <mihi> how can one get the address of a name server? ;) +[23:02] <jrand0m> OOB, but good point. he should toss in a "bootstrapping" section +[23:03] <thecrypto> OOB? +[23:03] <jrand0m> out of band. e.g. from a web site or built into the software +[23:03] <thecrypto> ahh +[23:03] *** naphtala (asdf@anon.iip) has joined channel #iip-dev +[23:04] <jrand0m> (co may actually have different ideas, I'm just assuming thats what he meant. definitely something to mention on the list) +[23:04] <mihi> is there any general way to make a text representation of Destinations (e.g. ascii armor)? +[23:05] <jrand0m> no, we haven't needed to spec that yet, though offhand I'd probably suggest alt-base64 the Destination object per that rfc that was just released +[23:06] <jrand0m> perhaps that should be added to the I2P data structures spec. good idea. +[23:06] <jrand0m> does anyone have any qualms with base64? +[23:07] <jrand0m> ok. at least for now that'll get added in. +[23:08] <jrand0m> 3.2) SDK 1.0 criteria +[23:08] <jrand0m> SDK 0.2 does full end to end crypto for java, but there's still a lot to be done before the SDK is 1.0 ready. +[23:09] <jrand0m> the criteria I have jotted down for the sdk 1.0: all APIs and local only routers up to spec [there are two small mods left]. full Java, C, and Python client API implementations. +[23:09] <jrand0m> optionally, we may want to include a streaming API as well +[23:10] <jrand0m> does anyone else have any 1.0 criteria they'd like to see in the SDK? +[23:11] *** jnk (jnk@anon.iip) has joined channel #iip-dev +[23:11] <jrand0m> ok. post to the list if you think of anything +[23:11] <jrand0m> 3.3) network simulator +[23:12] <jrand0m> sometime when someone has spare time, there should be efforts made on simulating the i2p net per i2np. the performance models used so far are limited in that they do not take into consideration resource contention among different users +[23:13] <jrand0m> there are good tools out there, and i've got some sketches down already of how to run this, but I'm just mentioning this now in case anyone is looking for a project ;) +[23:14] * jrand0m utterly fails to keep a straight face wrt the likelyhood of someone jumping up and writing a simulator +[23:14] <jrand0m> ok. 3.4) other apps +[23:14] <w0rmus> haha +[23:14] *** Signoff: mihi_backup (Ping timeout) +[23:14] * thecrypto jumps up...and writes something else +[23:14] <jrand0m> heh +[23:15] <jrand0m> mihi> any mods/updates/plans for the i2ptunnel? +[23:17] <mihi> nope. +[23:17] <jrand0m> cool, just checkin' in :) +[23:17] <mihi> if someone writes a TCP layer for I2P, i might use it, but I wont write it. +[23:18] <jrand0m> ah word. yeah, thats the streaming api thing. no worry, using GUARANTEED works and is a perfect use for local only routers +[23:18] *** Trifixion (~lame-o@anon.iip) has joined channel #iip-dev +[23:19] <jrand0m> and in a production environ waiting for an ACK before sending the next message is only a ~.4s delay +[23:19] <jrand0m> <insert caveat on latency models here> +[23:19] <jrand0m> ok. next "other apps" +[23:20] <jrand0m> thecrypto> IM? +[23:20] <thecrypto> well, i'm working on a UI prototype right now +[23:20] <thecrypto> as soon as we have some way of communicating with other people, i can just put in the networking stuff +[23:20] <jrand0m> we /have/ some way of communicating with other people +[23:21] <jrand0m> (not that I'm against doing it in pieces anyway) +[23:21] <thecrypto> i'm going to start with just UI +[23:21] <jrand0m> wikked. +[23:21] <w0rmus> I do wish to help thecrypto with the IM but I've some reading to do +[23:21] <thecrypto> once all the UI is done, whoever is working on this will just have to plug in the networking stuff and we'll be done' +[23:22] <jrand0m> nice +[23:22] <thecrypto> and i thought we only had local only unless you want to tunnel? +[23:22] <jrand0m> will the UI have an address book feature for storing destinations of friends? +[23:22] <thecrypto> buddy list +[23:23] <thecrypto> we'll have to poll the name server somehow to check when people are online +[23:23] <jrand0m> right, local only, but you can still run multiple instances and talk to itself through the SDK. same way normal network dev goes against localhost +[23:23] <jrand0m> hmm, the IM app will depend on the name server? +[23:23] <jrand0m> or will the IM have a central "presence" server? +[23:23] <thecrypto> it'll need someway to keep track of everyone +[23:23] <thecrypto> i'm trying to avoid central anything +[23:24] <thecrypto> but some sort of distributed presense would have to be thought up and it looks like the NS will do that +[23:24] <jrand0m> I don't think the NS has presence. it only says what the Destinations are +[23:24] <jrand0m> (for each service for each nym) +[23:25] <thecrypto> but doesn't it have an online offline state? +[23:25] <jrand0m> no, the NS is just like DNS. it doesn't tell you if the host is reachable. +[23:25] <thecrypto> at least i thought it do +[23:25] *** mihi_backup (~none@anon.iip) has joined channel #iip-dev +[23:25] <thecrypto> so you have to try it to find out +[23:26] <thecrypto> then i'll have to come up with my own spec to work out that part +[23:26] <jrand0m> coo'. perhaps start without one, and maybe add a rudimentary periodic ping, and then a fully distributed whatever ;) +[23:27] <thecrypto> well step 1 is UI +[23:27] <jrand0m> anyway, you know best, whatever works for ya. if there's anything anyone can do to help, just say the word +[23:27] <jrand0m> right +[23:27] <jrand0m> ok. I don't have any other apps to discuss in the "other apps" section. anyone else have app related ideas / discussion? +[23:28] <thecrypto> well what apps do we have planned already other than IM and NS and Tunnel? +[23:29] <w0rmus> will file transfer be implemented along with IM or separately? +[23:29] <w0rmus> separately I imagine +[23:29] <thecrypto> you will be allowed to file transfer IM, but other people can come up with file transfer only protocols like FTP +[23:29] <w0rmus> ok so what you're working on will have file transfer as well +[23:29] <jrand0m> thecrypto> I'd like to see an http proxy (perhaps ripping the code from JAP), as well as a plugin for a web server to allow I2P web publishing and browsing +[23:30] <thecrypto> IE replace freenet :) +[23:30] <jrand0m> a multiplexing "outdial" tcp tunnel would be cool too +[23:30] <jrand0m> naw, freenet is a CDN, this would require having a server to store space on +[23:31] <thecrypto> okay +[23:31] <jrand0m> (the outdial would probably require SOCKS integration though) +[23:32] <jrand0m> that it for the top of my head though. with mihi's tunnel we can already ssh and cvs over i2p +[23:32] <jrand0m> ok. 3.5) more transports +[23:33] <jrand0m> we need more transports (TCP, UDP, Email). realistically, this will probably be spec'ed and implemented in line with the router reference implementation. +[23:33] <jrand0m> but if someone wants to look at the polling HTTP transport and define some other transport, that'd be fantastic +[23:33] <thecrypto> transports kinda like the jabber transports +[23:33] <thecrypto> translating one to another? +[23:34] <jrand0m> hmm? transports are the actual means of sending bytes from one router to another. +[23:34] <thecrypto> ahh okay +[23:34] *** jnk has left #iip-dev +[23:34] <thecrypto> so instead of just one method of getting the bits from one router to another there are many? +[23:34] <jrand0m> exactly. +[23:34] <jrand0m> I2NP does /not/ specify a particular transport +[23:35] <thecrypto> so if one is firewalled/blocked/slow/... you use another +[23:35] <jrand0m> exactly +[23:35] <thecrypto> sweee +[23:35] <w0rmus> yah that sweet :) +[23:35] <jrand0m> ok, 3.6) java router reference implementation +[23:36] <jrand0m> I'll probably have an architecture doc and some rapid prototypes ready this week. nothing whatsoever will work, but it'll show how things will fit together. +[23:36] <jrand0m> then individual subsystems can be stub'ed and implemented in turn (or in parallel). +[23:37] *** Signoff: mihi (EOF From client) +[23:37] <jrand0m> so probably by end of week or perhaps next weeks meeting I'll be making a call out for java devs to jump in and get coding :) +[23:37] <thecrypto> can do +[23:38] <jrand0m> w3wt +[23:38] <w0rmus> hopefully can do :) +[23:38] <jrand0m> word +[23:38] <jrand0m> ok. any other dev status questions / thoughts / comments? +[23:39] <w0rmus> thecrypto: is anyone else working on the IM with you as of now? +[23:39] <thecrypto> co should be +[23:39] <w0rmus> is co cohesion? +[23:39] <thecrypto> but right now i'm just getting the UI started +[23:39] * jrand0m thinks co will havea /LOT/ of work with the naming service +[23:39] <thecrypto> no co == whit +[23:39] <jrand0m> no, co is wiht, cohesion is a different person :) +[23:39] <w0rmus> ok thanks +[23:40] *** mihi (~none@anon.iip) has joined channel #iip-dev +[23:40] <thecrypto> if it was cohesion then we would use tab compleletion +[23:40] <jrand0m> heh +[23:40] <w0rmus> some people are too lazy for even that +[23:41] <jrand0m> ok. agenda item 4) meeting time change +[23:41] <jrand0m> is anyone here further east than GMT+2? +[23:41] <jrand0m> you don't need to answer that... +[23:41] <jrand0m> er, is anyone here already pushed to their limit of lateness with 9PM GMT meeting time? +[23:41] * mihi_backup is gmt+2 +[23:42] <jrand0m> ah cool. would later work for you mihi, or is 9p best? +[23:42] * jrand0m doesn't go to bed until after the sun rises in gmt+2 +[23:42] <mihi_backup> not much later. 8p or 7p would be better +[23:42] <jrand0m> ah 'k +[23:42] <mihi_backup> but if i can't come; i'll read the log. +[23:43] *** Signoff: cohesion (class) +[23:43] <jrand0m> well, we have no hard reason to make it later and its good to have you here ;) +[23:43] <thecrypto> i say it's perfect where it is +[23:44] <jrand0m> cool. I just wanted to bring it up to possibly help out the left coast 'mericans who have jobs :) +[23:44] <jrand0m> but 9P GMT it is and 9P GMT it stays +[23:44] <jrand0m> ok. item 5) cvs administravia +[23:45] <jrand0m> well, none of the python people are here, and thecrypto and I have already spoken re: cvs module conventions :) +[23:45] <jrand0m> we still are working on getting anon cvs +[23:45] <jrand0m> or at the very least nightly snapshots of the cvs on the web. +[23:45] <jrand0m> that'll be announced once its ready. +[23:46] <thecrypto> most of the reason for limiting access to to make sure not too many people start getting at it +[23:46] <thecrypto> before it's ready +[23:46] <jrand0m> right, but the SDK has the full source of everything in the tree atm anyway ;) +[23:47] <jrand0m> but thats a good point. perhaps we can change perms on the dirs for the router ref impl as it progresses until its ready +[23:47] <jrand0m> dunno though. we'll cross that bridge when it comes +[23:47] *** Trifixion has left #iip-dev +[23:48] <jrand0m> item 6) shardy's stuff +[23:48] * jrand0m waves to shardy +[23:48] <shardy> hiya +[23:48] <shardy> um, I don't really have much of anything to say +[23:48] <shardy> just thought I'd say hi and all +[23:48] <shardy> seeing as how I've got myself involved in the project latey :) +[23:48] <shardy> lately. +[23:48] <w0rmus> hihi +[23:49] <shardy> I don't have a ton of time until thesis/toorcon are both done, but I'll help out with what I can do until then +[23:49] <shardy> like if you need random code debugged, or crypto implemented, or optimized +[23:49] <shardy> the next thing I'm probably going to look at is optimizing the hell out of the crypto engine... I have a lot of experience doing that kind of stuff +[23:49] <jrand0m> cool. we'll probably want to pick your brain as the crypto gets implemented for the routers and we pull in yarrow or another prng +[23:49] <jrand0m> nice +[23:50] <shardy> I'll be hanging around, so grab me for whatever if you need anything. +[23:50] <thecrypto> yah +[23:50] <jrand0m> wikked. +[23:50] <jrand0m> ok. 7) peanut gallery +[23:50] <jrand0m> any i2p thoughts / comments / questions / concerns? +[23:52] <jrand0m> ok then :) +[23:52] *** naphtala has left #iip-dev +[23:52] <w0rmus> i2p is neat +[23:52] <jrand0m> heh +[23:52] <w0rmus> ;0 +[23:52] * jrand0m pulls the *baf* off the wall... +[23:53] <jrand0m> ... the wind-up +[23:53] <jrand0m> and the *baf* +\ No newline at end of file diff --git a/pages/meeting57.html b/pages/meeting57.html new file mode 100644 index 00000000..c0e1c324 --- /dev/null +++ b/pages/meeting57.html @@ -0,0 +1,167 @@ +
+[22:57] <jrand0m> ok, buenos noches srs y srtas +[22:57] <jrand0m> agenda: +[22:57] <jrand0m> 0) welcome +[22:57] <jrand0m> 1) cvs +[22:57] <jrand0m> 4) naming service +[22:58] <co> You forgot 5) questions. +[22:58] <jrand0m> 3) dev status +[22:58] <jrand0m> 2) spec questions? +[22:58] <jrand0m> 5) other questions? +[22:58] <jrand0m> oh, shit, I forgot to reorder those. ok. they're numbered incorrectly :) 0 == 0, 1 == 1, 4 ==2, 3 == 3, 2 == 4, 5 == 5 +[22:59] <jrand0m> lets see if I can keep that straight as we go... +[22:59] <jrand0m> ok, 0) welcome +[22:59] <shardy> yay for permutation groups! +[22:59] <jrand0m> welcome to meeting 57 +[22:59] <jrand0m> yeah, they're all just symbols anyway +[22:59] <w0rmus> sweet whatup ;0 +[23:00] <w0rmus> I'll help comprise peanut gallery +[23:00] <jrand0m> 1) cvs is still down, after 10+ days. we're finding a new host. +[23:00] <jrand0m> sf.net sucks, and I have no reason to believe gnu's nongnu is better. +[23:00] <co> jrand0m: Why not make that host have the alias "cvs.invisiblenet.net"? +[23:00] <jrand0m> nop is leading the charge on finding the new host. +[23:01] <jrand0m> sure co, once we get the server +[23:01] <shardy> what do you need for a host? +[23:01] <jrand0m> shardy> reliable net connection, ssh/cvs access. and some disk space +[23:01] <shardy> do you have something lined up? +[23:01] <shardy> because if not. I may be able to assist. +[23:02] <jrand0m> awesome! I don't know what nop has lined up, but I'll have him check in with you (unless he's here now?) +[23:02] * w0rmus taps nop +[23:03] <shardy> I've got 1.1 business sdsl. I'd need to find a machine. but as long as you're not using uber amounts of bandwidth I could probably host the server. +[23:03] <shardy> how much disk space would you need? +[23:03] <jrand0m> the repository currently comprises ~ 6Mb. so probably 50M would handle growth for a good while +[23:04] <shardy> oh. pfft. that's nothing. +[23:04] <shardy> and the machine wouldn't need to be super fast? +[23:04] <shardy> you wouldn't be doing big compile jobs on it? +[23:04] <jrand0m> naw, a 286 would probably do it. +[23:04] <jrand0m> no, strictly cvs checking / checkout +[23:04] <jrand0m> (well, and diff, and log, etc ;) +[23:05] <jrand0m> "we're java, we don't need compile farms" </fark> +[23:05] *** Signoff: cohesion (class) +[23:05] <w0rmus> do people concerned with anonymity access CVS using something like JAP? I've never used CVS +[23:05] <jrand0m> w0rmus> I use cvs through a private series of ssh proxies +[23:05] <co> jrand0m: Keep in mind that a C or C++ implementation may be likely in the future. +[23:06] <mihi> jap does not allow cvs access AFAIK :( +[23:06] <w0rmus> ssh tunnelling +[23:06] <shardy> let me see what I can do. someone said they were going to give me another drive... if I can get a disk I have a machine I can toss up. +[23:06] <jrand0m> oh, of course co. I just don't expect we can require a cvs repository to necessarily be a compile farm as well. +[23:07] <jrand0m> awesome shardy. there's anything we can do, just say the word. +[23:07] <co> jrand0m: You are right. They should be separate. +[23:07] <shardy> will do. let me scrounge for a drive, I should be able to get one, and if I do I'd be happy to host the cvs for everyone. +[23:07] <jrand0m> shardy++ +[23:07] <w0rmus> yay ;0 +[23:07] <jrand0m> ok, 4) naming service +[23:08] <jrand0m> co, how goes? +[23:08] <co> I am still writing, but would like to say a few words about it. +[23:08] <co> First, to address a question from thecrypto during the last meeting, the NS does not provide notification of someone's being online. +[23:09] <co> It merely says that a person can be contacted via certain methods, such as AIM. +[23:09] <co> Second, the client side. +[23:09] <co> There will be an API which programs can use to make queries to naming servers. +[23:10] <co> The underlying mechanism will read a configuration file of which servers to query, will use the I2P network to obtain the results, and will pass the results back to the caller. +[23:11] <co> The underlying mechanism will also read the destination mechanism for the local router to contact from a file. +[23:11] <jrand0m> the destination mechanism? +[23:11] <co> I'm sorry, the destination address. +[23:11] <jrand0m> ah 'k +[23:12] <co> That is all at this time. +[23:12] <jrand0m> cool +[23:12] <w0rmus> I agree +[23:12] <w0rmus> ;) +[23:12] <jrand0m> any ballpark ideas on timelines for various milestones? +[23:13] <jrand0m> obviously nothing anyone could hold you to, of course, just wondering +[23:13] <co> Let's say end of the week for finishing the specification and publishing it and the API. +[23:14] * mariesofie arrives late +[23:14] <jrand0m> ah nice co +[23:14] <co> Then, I will start implementing it. I am not certain how long that will take, though. +[23:14] <jrand0m> understandable +[23:15] <jrand0m> anyone else have any naming service questions/thoughts? +[23:15] <jrand0m> ok, 3) dev status +[23:16] <jrand0m> dev goes well. +[23:16] <jrand0m> the java side is up to spec and implements all I2CP and I2NP messages and structures +[23:17] <jrand0m> the java architecture itself is functional and I'm going to continue stubbing out the various subsystems +[23:17] <co> Have you tested it? +[23:17] <jrand0m> the messages & structures? yes via the TestData harness in net.invisiblenet.i2p.data.test +[23:17] <co> I mean connecting two different computers with I2P. +[23:18] <jrand0m> oh, no, thats requires the full implementation of the communication subsystem +[23:18] <co> I see. +[23:18] <jrand0m> first I'm building the various subsystems to operate in test mode, then implementing the various subsystems so they can operate in isolation +[23:19] <jrand0m> we're probably 2 weeks off from a client sending a message to a client on a different router +[23:19] * mariesofie cheers +[23:20] <jrand0m> there's still a lot of work to be done after that before the alpha, but thats progress +[23:21] <jrand0m> the datastrucutres and i2np specs need about a dozen small modifications that I've been accumulating during the implementation to address things overlooked. e.g. "datastructures p11, TunnelSigningPublic/PrivateKey should contain SIGNING Public/Private keys" and "i2np p15, TunnelCreateStatus - add hash of the replying RouterIdentity" +[23:21] <shardy> man. i really need to read up on the specs. +[23:22] <jrand0m> well, they'll soon be hosted on your machine so it'll be easy :) +[23:22] <w0rmus> haha +[23:22] <w0rmus> I have not finished specs either +[23:23] <mariesofie> i printed the specs, read them so many times it got worn out and i had to print out another copy +[23:23] <jrand0m> from discussions I've had with various people, I've found the specs aren't that great at conveying how the thing actually works. they cover the fuzzy stuff and the nitty gritty, but not why the nitty gritty meets the why +[23:23] <w0rmus> heh +[23:23] <jrand0m> rofl mariesofie +[23:23] <jrand0m> ok, thats it for 3) dev status +[23:24] <jrand0m> now for 2) spec questions +[23:24] <w0rmus> I suppose I'll read them instead of stupid calculus +[23:24] <co> I am thinking a little bit into the future. +[23:24] <co> The python and C or C++ implementations will need to have message data readable by the Java implementation. +[23:24] *** Signoff: mihi (EOF From client) +[23:25] <jrand0m> correct co +[23:25] <co> How will you accomplish that? +[23:25] <jrand0m> the datastructures spec specifically defines the byte layouts +[23:25] <jrand0m> and everything is big endian and all numbers are unsigned +[23:25] <mariesofie> what level of technical knowledge are you targetting the specs for? anyone with decent comp. knowledge? college level CS engineer students? +[23:25] <co> Oh, all right. +[23:25] *** mihi_ (~none@anon.iip) has joined channel #iip-dev +[23:26] <mariesofie> i.e. who is the target audience? +[23:26] *** mihi_ is now known as mihi +[23:26] <jrand0m> mariesofie> well, those specs were really targeted haphazardly. i2p_philosophy was the "ok, wtf is this all about", but the rest of the specs were targeted towards people interested in actually implementing the system +[23:26] <jrand0m> we really really need some docs that go in the middle +[23:27] <mariesofie> i see +[23:27] <mariesofie> I found the API docs are very easy to understand and useful, but ironically I still get mixed up when reading the I2NP specs trying to understand the core architecture +[23:28] <mariesofie> maybe thats reflective on me more than the documentation :) +[23:28] <jrand0m> heh geek :) +[23:29] <jrand0m> ok, any other questions on the specs? lets move on to 5) other questions +[23:29] <jrand0m> anyone have any other questions? this is our last bullet point on the meeting agenda +[23:30] <w0rmus> I wonder where thecrypto is with achat +[23:30] <jrand0m> ah, thecrypto is offline for the next three weeks or so +[23:30] <mihi> what happens with peer review? +[23:30] <w0rmus> or atalk +[23:30] <w0rmus> wow +[23:30] <mihi> is anyone reviewing it? +[23:30] <mariesofie> i thought thecrypto has 2hrs per day +[23:31] <w0rmus> and I can't even see the codes he has :( +[23:31] <jrand0m> mihi> reviews have been sent to various people for review and as feedback comes it will be addressed. +[23:31] <jrand0m> w0rmus> do you have any questions on ATalk? +[23:32] <shardy> I will be reviewing it as soon as I have time :) +[23:32] <mihi> i meant, did any feedback come till nowß +[23:32] <w0rmus> I suppose not +[23:32] <mihi> s/nowß/now?/ +[23:32] <jrand0m> mihi> largely in the form of discussions and clarifications +[23:32] <jrand0m> awesome shardy :) +[23:33] <Brownspider> hapy birthday google +[23:33] <jrand0m> mariesofie> right, but thats not even enough time for him to d/l the java lang docs to continue dev :/ +[23:33] <w0rmus> ahaha wtf +[23:35] <jrand0m> ok, any other questions / thoughts? +[23:35] <w0rmus> I guess I should mention that I've never coded outside of school +[23:35] <w0rmus> but I gotta start somewhere anyways +[23:35] <jrand0m> now's a good time to start :) +[23:35] <jrand0m> word +[23:35] <w0rmus> ;0 +[23:35] <mariesofie> i have questions on the api, but not yet, in a day or two when i can try it out some more +[23:35] <w0rmus> I've taken 2 years of java or so +[23:36] <jrand0m> ok cool mariesofie, just bounce a msg to the list or bounce me a message here whenever +[23:37] <co> mariesofie: Have you read the discussion on the iip-dev mailing list? +[23:37] <w0rmus> where is it archived? +[23:37] <jrand0m> http://news.gmane.org/thread.php?group=gmane.comp.security.invisiblenet.iip.devel +[23:37] <jrand0m> (fairly low traffic atm) +[23:38] <Brownspider> jrand0m wants you code something that can not logicly exist, to tear the world usunder, to end the reign of god. +[23:38] <shardy> my services are still offered if you need any crypto cores or such written or debugged. +[23:39] *** M123456789 (~no@anon.iip) has joined channel #iip-dev +[23:39] <co> Brownspider: huh? +[23:39] <Brownspider> co, it was on his freesite, nevermind +[23:40] <jrand0m> great shardy, I have a feeling we're going to need some once the routers get up and running, and especially when we get the C/Python APIs back up to spec +[23:40] <mariesofie> co> i've only read back to about issue #52 or so +[23:42] <jrand0m> ok. any last words (as I eye the *baf*er...) +[23:43] *** mihi_backup_ (~none@anon.iip) has joined channel #iip-dev +[23:43] *** Signoff: mihi_backup (EOF From client) +[23:43] *** mihi_backup_ is now known as mihi_backup +[23:43] <jrand0m> ok great. next week, same bat time, same bat place. +[23:44] * jrand0m *baf*s the meeting to an end +\ No newline at end of file diff --git a/pages/meeting58.html b/pages/meeting58.html new file mode 100644 index 00000000..ad39c25c --- /dev/null +++ b/pages/meeting58.html @@ -0,0 +1,311 @@ +
+[22:53] <jrand0m> 0) welcome +[22:54] <jrand0m> 1) apps: +[22:54] <jrand0m> 1.1) IM +[22:54] <jrand0m> 1.2) NS +[22:54] <jrand0m> 2) dev status: +[22:54] <jrand0m> 2.1) subsystems +[22:54] <jrand0m> 2.2) encryption key persistence +[22:54] <jrand0m> 2.3) todo +[22:54] <jrand0m> 3) spec stuff +[22:54] <jrand0m> 3.1) mods +[22:54] <jrand0m> 4) administravia: +[22:54] <jrand0m> 4.1) anon cvs +[22:54] <jrand0m> 5) ? +[22:55] <jrand0m> ok, 0) welcome +[22:55] <jrand0m> welcome to meeting 58 +[22:55] <thecrypto> that all +[22:55] <jrand0m> si sr, unless anyone else has things to add? +[22:55] * nop notices jrand0m is object oriented with his numbering :) +[22:56] <nop> 3.1.2.2.4.5.8() ;) +[22:56] <jrand0m> hey, they could be structs ;) +[22:56] <nop> haha +[22:56] <nop> that is definitely true +[22:56] <jrand0m> ok, 1.1) IM. thecrypto? +[22:56] <nop> although +[22:56] <nop> 2 has inheritance +[22:57] <nop> ;) +[22:57] <jrand0m> heh +[22:57] <nop> nevermind me +[22:57] <nop> ok +[22:57] <nop> sorry +[22:57] <nop> continue +[22:57] *** mihi_ (~none@anon.iip) has joined channel #iip-dev +[22:57] <thecrypto> okay, right now i'm uploading some basic specs for IM +[22:58] <thecrypto> (Link: http://www.thecrypto.org/i2pim.sxw)http://www.thecrypto.org/i2pim.sxw for oowriter +[22:58] <thecrypto> and i'm working on uploading the pdf +[22:58] <nop> if you want I can put on i2p site +[22:59] <thecrypto> give me a second +[22:59] <thecrypto> sure +[22:59] *** mrflibble (mrflibble@anon.iip) has joined channel #iip-dev +[22:59] <jrand0m> do you want to put that into i2p/apps/IM/doc/ ? +[22:59] *** mihi_ is now known as mihi_backup +[23:00] <nop> I can +[23:00] <nop> yes +[23:00] <jrand0m> I meant in cvs :) +[23:00] <thecrypto> i can do that too +[23:00] <jrand0m> (but on the web is good too) +[23:00] <nop> oh +[23:00] <nop> haha +[23:00] <thecrypto> (Link: http://www.thecrypto.org/i2pim.pdf)http://www.thecrypto.org/i2pim.pdf +[23:01] <MrEcho> "the file is damaged and could not be repaired" AR error +[23:01] <thecrypto> try again +[23:01] * jrand0m loaded it fine +[23:01] <co> MrEcho: The PDF file? +[23:01] <jrand0m> (the sxw) +[23:01] <thecrypto> only partially uploaded at that time +[23:01] <MrEcho> now it works +[23:01] <MrEcho> hehe +[23:02] <thecrypto> basicall i just put in the presence stuff, online offline messages, and a message message +[23:02] <thecrypto> i shameless ripped some sections from the I2NP documenty +[23:02] <thecrypto> :) +[23:02] <jrand0m> heh I thought some of it looked familiar :) +[23:02] <thecrypto> i'm also working on uploading the UI i +[23:02] <thecrypto> i've been working on +[23:03] <thecrypto> jrand0m: do i need to create the dirs apps/IM/doc +[23:03] <jrand0m> yes, and cvs add them individually +[23:03] <thecrypto> -kb? +[23:03] <jrand0m> yes +[23:03] <co> thecrypto: I believe apps/ is there now. +[23:04] <jrand0m> whats a presence? +[23:05] <thecrypto> let me run update +[23:05] <thecrypto> but it's getting in there +[23:05] *** Signoff: shardy (Ping timeout) +[23:05] <thecrypto> i'm just saying rip apart the specs +[23:05] <thecrypto> and the UI will be in there soon as well +[23:05] <thecrypto> and if you have anything that needs to be clarified then anonymail, e-mail, anything me and i'll fix it +[23:05] <mrflibble> did i miss the meeting? +[23:05] *** shardy (~shardy@anon.iip) has joined channel #iip-dev +[23:05] <co> thecrypto: You might want to announce it on the e-mail list, as well, with a link to the documents. +[23:05] <thecrypto> i thought i put that in there? +[23:05] <jrand0m> nope still on the first item point mrflibble +[23:05] <co> mrflibble: Meeting is in progress. +[23:05] <mrflibble> oh sorry, just couldnt see "logger" +[23:06] <jrand0m> thecrypto> you state that its a destination, but is that the destination at which to send messages? how do offline messages work? +[23:06] <mihi> no mids here, so no logger ;) +[23:06] <mrflibble> k +[23:06] * mrflibble goes back to lurking +[23:06] <jrand0m> oh wait, these are just presence notifications, sorry +[23:06] <mihi> how can one subscribe to a presence? +[23:06] <thecrypto> jrand0m: no offline messages +[23:07] <thecrypto> basically +[23:07] <thecrypto> the presence just wraps a destination and a name together +[23:07] <thecrypto> to make things easy +[23:08] <thecrypto> so if we want to move onto NS we can do that, and we can come back to this later? +[23:09] <jrand0m> 'k cool +[23:09] <thecrypto> and you can still message me questions +[23:09] <jrand0m> actually, one quick question +[23:09] <thecrypto> shoot +[23:09] <jrand0m> so the IM is strictly text only? +[23:10] <thecrypto> with this basic one yes, but i will be adding file support in +[23:10] <jrand0m> coo' +[23:10] <thecrypto> i just want the beginnings of the system taken care of and build on it +[23:10] <jrand0m> (iterative and incremental)++ +[23:11] <jrand0m> ok great. I'll go through this further and other people should too... for now, moving on to 1.2) NS. co? +[23:11] <co> Version 1.1 (final) of the naming service specification was released earlier today. +[23:12] <jrand0m> (and there was much rejoicing) +[23:12] <co> Basically, I finished the sections on the data structures and network messages that the program needs. +[23:12] <co> I will be releasing the client API on Thursday. +[23:12] <co> And will begin implementing the NS application. +[23:12] <jrand0m> great +[23:13] <co> One idea that has changed is what the CA does when entities register with it. +[23:13] <thecrypto> co: how will you be implementing it? +[23:13] <thecrypto> co: the name server or the client? +[23:14] <co> thecrypto: Well, first I will implement the data structures necessary. +[23:14] <co> Then, the client, then the server and CA components. +[23:14] <thecrypto> okay +[23:15] <co> As I was saying, I now would like the CA to issue a certificate to newly registered entities. +[23:15] <co> They will present this certificate to naming servers when modifying their records. +[23:15] <co> I have not specified what the certificate contains in this version; that will go into the next version of the specification. +[23:16] <co> Does this strike anyone as a bad idea? +[23:16] <jrand0m> hmm. wouldn't it be simpler / safer to just have the client use a public key / private key? +[23:16] <jrand0m> aka during register, provide a public key for updates and sign the registration, and whenever you want to update again, sign an update +[23:16] <jrand0m> (so that hte CA never gets the private key) +[23:17] <thecrypto> Sidenote: all the I2PIM stuff is now committed to the cvs respository +[23:17] <jrand0m> great +[23:17] <co> It may be simpler to do just that. I will re-think this issue. Thank you for the comment. +[23:17] <co> That is all I have to discuss for the naming service at this time, if you have no other questions. +[23:18] <jrand0m> its lookin good, I haven't gone through the 1.1 yet but I'll email if I come across something +[23:19] <co> OK. Next topic? +[23:19] <jrand0m> ok, 2.1) dev status for subsystems. +[23:19] *** w0rmus (o0o@anon.iip) has joined channel #iip-dev +[23:20] <jrand0m> transport subsystem is good 'nuff to move forward. peer management subsystem is stubbed with stupid algorithms but functional. network db, tunnel management, and stats management subsystems are still pending. client subsystem will be trivial (just reusing the SDK local only router) +[23:21] <co> What do you mean by stupid algorithms? +[23:21] <w0rmus> not fast? +[23:21] <jrand0m> eh, the peer management subsystem isn't keeping track of peer performance, its just returning random peers. +[23:22] <jrand0m> the algorithm will be updated and tuned as things progress to more adequately provide peer selection +[23:22] <jrand0m> current task on my plate is building and handling garlic messages, which is a PITA. +[23:23] <jrand0m> but workable, just annoying +[23:23] <jrand0m> that actually leads into 2.2) encryption key persistence. +[23:24] <jrand0m> garlic messages use ElG+AES encryption to wrap the layers of the cloves +[23:24] <jrand0m> and private keys are used in other places (transport, client management) +[23:25] *** Signoff: thecrypto (Ping timeout) +[23:25] <jrand0m> keeping private and session keys always in memory and never on disk is ideal, but sucks for times when the router goes down (either intentionally or by fault) +[23:26] <jrand0m> does anyone have any thoughts for whether we should 1) never write the keys to disk and risk excessive unnecessary message loss (since they won't be decryptable) 2) encrypt them before writing to disk or 3) just write them to disk plain? +[23:26] <co> Option 2. +[23:27] <nop> jrand0m option 2, or do what we said before +[23:27] <nop> we must trust localhost +[23:27] *** Signoff: cohesion (class) +[23:27] <nop> we assume localhost is not compromised +[23:27] <jrand0m> the kooky thing about option 2 is that it either the user will have to enter a pass phrase to start the router, or the session key will be knowable +[23:27] <jrand0m> good point nop. +[23:28] <nop> again we are a transport, we can't worry about that as much, that can be modified on client end, or we could give them options +[23:28] <nop> depending on paranoia level +[23:28] <nop> security vs convenience measure +[23:29] <co> Then I propose having 3 by default, and giving the user the option to use 2. +[23:29] <nop> exactly +[23:29] <jrand0m> right. ok, the good thing is that people can (and should!) take the router code and modify it for that tradeoff - a "tinfoil I2P router" and a "jane sixpack I2P router" +[23:29] <jrand0m> ok, cool, I'll just go with the simple 3) for now then +[23:30] <jrand0m> ok 2.3) todo +[23:30] * co would like to revisit the NS topic at the end of the meeting. +[23:30] * nop needs to finish reading the NS email +[23:30] <jrand0m> 'k, you're item #5 now +[23:30] <co> I can wait until the end. +[23:31] <jrand0m> mihi put together some tests to point out some bugs in the SDK impl. some fixed already, some not. fixing them is on the todo :) +[23:32] <jrand0m> also, there have been about a dozen changes to various specs. once I get time I'll update the docs and push 'em out, though I may just put up an errata page on the wiki in the meantime +[23:33] <nop> word +[23:34] <jrand0m> other todo's... um, I fixed the "Wrong Size generating key" thing this morning plus a few random bugs +[23:34] <jrand0m> ok, thats it for dev status. 3) spec stuff +[23:35] <jrand0m> 3.1) see todo re: mods. there have been mostly typographical changes, I came across a slightly larger one today when implementing the garlics. still no prob, just requires moving around some data structures and doing some fancy footwork with the encryption. I'll get that in the errata. +[23:35] <jrand0m> 3.2) [I know, this one wasn't on the agenda, but here it is anyway] spec questions +[23:35] <shardy> (brb, I'm still lurking if you need me) +[23:35] <jrand0m> anyone have any questions on any of the specs? +[23:35] <jrand0m> cool shardy +[23:36] <co> jrand0m: Please tell us again which spec is in which document. +[23:37] <jrand0m> (Link: http://wiki.invisiblenet.net/iip-wiki?I2PProtocolSpecs)http://wiki.invisiblenet.net/iip-wiki?I2PProtocolSpecs has 'em mapped out +[23:37] <co> I will look at it. +[23:38] <jrand0m> (looking at that it reminds me I need to document the secure reliable UDP transport. yet another todo...) +[23:39] <jrand0m> there have been some questions from various people wrt what specs to look at - basically, unless you want to know how the routers work (or you want to help implement them), you won't need to read the I2NP spec. I2CP and the I2CP section of the data structures is good enough +[23:40] <nop> jrand0m +[23:40] <jrand0m> si sr? +[23:41] <nop> do you mean actual UDP as in UDP packets +[23:41] <nop> or UDP as in a general UDP protocol +[23:41] <jrand0m> yes, UDP as in UDP packets +[23:41] <nop> for I2P +[23:41] *** thecrypt1 (~thecrypto@anon.iip) has joined channel #iip-dev +[23:41] *** thecrypt1 is now known as thecrypto +[23:41] <jrand0m> i2p/code/router/java/src/net/invisiblenet/i2p/router/transport/udp for the implementation +[23:42] <thecrypto> back +[23:42] <jrand0m> wb +[23:42] <thecrypto> anyone want to send me what happened while i was gone? +[23:43] <jrand0m> the UDP impl is a pretty simple one - it does a DH exchange and messages are split into 1K packets and AES256 encrypted with the generated key +[23:43] <jrand0m> rekeying is supported though not automatic atm +[23:43] <jrand0m> ACKs are sent back in bundles (aka "I received all packets for message 42 up through packet 18 but not 3 or 7") +[23:44] <jrand0m> (and the practical reason why I went with the UDP impl before the TCP impl is UDP gives 'free' asynchronous IO with nearly 0 overhead) +[23:45] <nop> of course +[23:45] <jrand0m> there are two things left to do in that udp impl - station to station it for MITMs and add a packet for "oh shit, I forgot the session key" +[23:45] <nop> good +[23:46] <jrand0m> after the UDP transport the next one I want to implement is the polling HTTP - so we will have support for both the common user (UDP) and the firewalled / nat'ed / proxied user (polling http) +[23:47] <jrand0m> ok, so, yeah, that needs to get doc'ed up into a spec :) +[23:48] * jrand0m !thwaps self for coding before specing +[23:48] <thecrypto> coding before specing helps me +[23:48] <jrand0m> yeah, it works best iteratively +[23:48] <jrand0m> (as we're finding problems with the specs by implementing them, etc) +[23:49] <jrand0m> ok, thats 3) specs. 4) administravia +[23:49] <jrand0m> 4.1) anon cvs. thecrypto? :) +[23:49] <thecrypto> just in the nick of time +[23:49] <thecrypto> well, i'm looking into it, i think 2401 is currently blocked +[23:49] <jrand0m> can you cvs -d :pserver: locally? +[23:49] <thecrypto> and there might be some inetd stuff to do as well thanks jrandom +[23:50] <jrand0m> ah coo' +[23:50] <thecrypto> let me test that i forgot you cood do that :) +[23:51] <thecrypto> would it just be cvs -d :pserver: ? +[23:51] <jrand0m> cvs -d :pserver:anonymous@localhost:/home/cvsgroup/cvsroot/ co i2p +[23:52] <jrand0m> also, it'd be great if we could get a bugzilla on there too +[23:52] <thecrypto> acvs [checkout aborted]: connect to localhost(127.0.0.1):2401 failed: Connection refused +[23:52] <jrand0m> 'k, after adding the inetd.conf line and kill -HUP identd? +[23:52] <thecrypto> let me try that inet line and i'll get back to you +[23:52] <jrand0m> er, inetd :) +[23:52] <jrand0m> 'k cool +[23:53] <thecrypto> does the pserver go on the same line? +[23:53] <jrand0m> yes, thats all on one line +[23:55] <jrand0m> ok, thats it for administravia, at least that I can think of +[23:55] <jrand0m> 5a) co, you're up +[23:56] <co> When two people want to register the same entity name, the second is refused. +[23:56] <co> But if we use a signature-based approach, +[23:56] <co> the person who was refused could send a message to the naming server +[23:56] <co> anyway, telling it to modify the record. +[23:56] <co> There are two possibilities: +[23:57] <co> 1) CA sends the naming server a copy of the public key for the entity that was approved. +[23:57] <co> 2) CA sends the person who is registering a name a certificate, signed by its private key. The naming server will have the CA's public key to verify it. +[23:58] <co> If a malicious user tells the naming server to modify a certain record, the lack of a certificate would prevent the modification. +[23:58] <co> That is what I was thinking. +[23:59] <jrand0m> but in that case the CA knows the key - asym crypto would mean the CA only ever knows the public key, plus the CA would never want to or need to give that public key out to anyone - its just for the authentic updater to sign against when requesting an update +[00:00] <jrand0m> what you're describing sounds more like symmetric crypto - just using a passphrase, eseentially +[00:00] <thecrypto> cvs is screwing with me! +[00:00] <jrand0m> (where the certificate is the shared secret between CAs and the authentic owner of the nym) +[00:00] *** mrsc (~efgsdf@anon.iip) has joined channel #iip-dev +[00:01] <jrand0m> whats up thecrypto? +[00:01] <thecrypto> i added the user anonymous with blank password added them to readers and into the cvsgroup and i get cvs login: authorization failed: server localhost rejected access to /home/cvsgroup/cvsroot for user anonymous +[00:01] <co> jrand0m: Good point. Let's say that this part of the specification is not finalized, and I will think about it some more. +[00:01] <jrand0m> coo' +[00:01] *** LeerokLacerta (~leerok@anon.iip) has joined channel #iip-dev +[00:02] <LeerokLacerta> Konnichiwa. +[00:02] <jrand0m> hmm thecrypto, I don't think you want an anonymous OS user +[00:02] <jrand0m> heya LeerokLacerta +[00:02] <LeerokLacerta> Hello, jrand0m. +[00:02] <thecrypto> well i stuck on a password and it works now +[00:03] <co> jrand0m: And if you have any more suggestions after reading the spec, send them to me. +[00:03] <jrand0m> shall do co +[00:03] <jrand0m> cool thecrypto.. is /bin/false their shell? +[00:03] <thecrypto> now i just have to find that section in the cvs manual about how to make a user +-> *thecrypto* whats the pw? +[00:04] <thecrypto> now it is +[00:05] <jrand0m> ok, we can work through this after the meeting. +[00:05] <jrand0m> ok, last point on the agenda: 5b) ? +[00:05] <jrand0m> any questions / thoughts / concerns? +[00:05] <thecrypto> just check out the IM app +[00:06] <thecrypto> right now all it does is make a tree but it shows you what it's starting to look like +[00:06] <LeerokLacerta> No SOCKS? +[00:06] <thecrypto> ohh yeah that's what i forgot +[00:06] <jrand0m> ah cool thecrypto +[00:06] <jrand0m> SOCKS? as in, the proxy protocol? +[00:06] <thecrypto> anyone here good at making icons? +[00:06] <LeerokLacerta> Yup. +[00:06] <LeerokLacerta> The answer for all the times I've asked as been "No". +[00:07] <jrand0m> ah. yes, we're definitely going to want a socks proxy, but no one is working on it atm. +[00:07] <LeerokLacerta> Hmm. +[00:07] <jrand0m> thats going to be one of the apps we'll want by 1.0 public, so that people can browse i2p based sites, as well as so that people can browse the normal web anonymously +[00:07] <mihi> there are enough socks proxies available for free, i'd say ;) +[00:08] <jrand0m> exactly, we just need to integrate 'em +[00:08] <mihi> but i don't know any in java. +[00:08] <jrand0m> the JAP client app might work well, I don't know if its GPL though +[00:08] <mihi> the jap client does not contain a proxy. +[00:08] <thecrypto> well I need some icons for the I2PIM project +[00:09] <thecrypto> Something to represent online offline and a group of people +[00:09] <mihi> the only proxy is a http/ftp proxy and that is in the last mix. +[00:10] <mihi> like with iip - isproxy does not know any IRC protocol. +[00:10] <jrand0m> well, thats the outbounds side - for i2p based web sites, we'll need something to accept proxy requests from local browsers, do the lookup of the dest, and send the messages to the appropriate dest +[00:10] <thecrypto> anyone interested? +[00:11] <co> thecrypto: Could you take the icons from the GPL'd gaim project? +[00:11] * jrand0m makes horrificly boring graphics in ms paint +[00:11] <co> Since it's under GPL, and so is this, unless I am mistaken. +[00:11] <thecrypto> yeah, i could +[00:11] <jrand0m> if I2PIM uses the sdk's client libs, I2PIM is definitely GPL :) +[00:12] <thecrypto> ahh the wonderful GPL +[00:12] <jrand0m> LeerokLacerta> any particular reason you ask, or just wanting to prod us to do it? ;) +[00:13] <thecrypto> the problem with the gaim ones is they are from the IM apps they are using +[00:14] <thecrypto> so if someone could make the I2PIM icon that would just be great +[00:15] * jrand0m thinks we'll have lots of scribbled paint-based images for the time being... +[00:16] <jrand0m> ok, anyone have any other thoughts / questions / commnets? +[00:16] <nop> I have commnets +[00:16] <jrand0m> (other than "wtf is a commnet") +[00:16] <jrand0m> is that contagious? +[00:16] *** nixonite (~nixonite@anon.iip) has joined channel #iip-dev +[00:16] <mrflibble> lol +[00:17] <jrand0m> 'k, well, if not, that about wraps up the meetin', no more agenda items left +[00:17] <nixonite> did i miss the meeting? +[00:17] <jrand0m> yup, 9p GMT +[00:17] <jrand0m> well, technically you made it for the end :) +[00:17] <nixonite> oh +[00:18] <co> nop: Let's hear them. +[00:18] <thecrypto> so what are the comments +[00:18] * jrand0m thought nop was just making fun of my typo, but if he has comments, let 'er rip bro +[00:20] <thecrypto> anon cvs is still not liking me, more work tommorow +[00:20] <jrand0m> gimmie root and I'll get 'er up +[00:21] <thecrypto> talk to nop about that one +[00:21] <jrand0m> heh 'k +[00:22] <jrand0m> ok, as nop seems to have been dragged back into work... +[00:22] <jrand0m> nop, and anyone else, really> if you have any comments /questions / concerns, either let us know or post on the mailing list (or even into the wiki) +[00:23] * jrand0m loads up and *baf*s the meeting to an end. +\ No newline at end of file diff --git a/pages/meeting59.html b/pages/meeting59.html new file mode 100644 index 00000000..4c2fb464 --- /dev/null +++ b/pages/meeting59.html @@ -0,0 +1,732 @@ +
+[22:56] <jrand0m> ok ok
+[22:56] <jrand0m> agenda
+[22:56] <jrand0m> 0.0) welcome
+[22:56] <jrand0m> 1.0) dev status
+[22:56] <jrand0m> 1.1) router
+[22:56] *** Myself248 (~ident@anon.iip) has joined channel #iip-dev
+[22:56] <jrand0m> 1.2) DH precalc
+[22:56] <jrand0m> 2.0) microroadmap
+[22:56] <jrand0m> 3.0) apps / usage
+[22:56] <jrand0m> 4.0) ns
+[22:56] <jrand0m> 5.0) IM
+[22:56] <jrand0m> 6.0) administravia (cvs, bugzilla, cvs list, cvs web)
+[22:56] <jrand0m> 7.0) questions
+[22:57] <jrand0m> (yes, 7 points today. w00t)
+[22:57] <jrand0m> 0.0) welcome
+[22:57] <jrand0m> hi.
+[22:57] <dm> hey
+[22:57] <jrand0m> 17 users today. neat
+[22:57] *** Ryan_Singer (chatzilla@anon.iip) has joined channel #iip-dev
+[22:57] <jrand0m> and counting
+[22:57] <jrand0m> ok
+[22:57] <thecrypto> 1~hi
+[22:57] <jrand0m> 1.1) dev status for router
+[22:58] <jrand0m> the java reference impl router is doing very well
+[22:58] *** ChZEROHag (hag@anon.iip) has joined channel #iip-dev
+[22:58] <jrand0m> we can now run applications on different routers and send messages ot each other
+[22:59] <ChZEROHag> Sorry to interrupt, but hopefully it'll just be once
+[22:59] <jrand0m> taking an iterative and incremental approach, the current state is secure, not anonymous, not scalable, and harvestable
+[22:59] <ChZEROHag> Is anyone else working on a C api?
+[22:59] <jrand0m> 'lo ChZEROHag, whats shakin?
+[22:59] <ChZEROHag> Because I am, but very slowly
+[22:59] *** dcat (dirtycat@anon.iip) has joined channel #iip-dev
+[22:59] <jrand0m> oh cool
+[22:59] <jrand0m> shardy will be working on one after toorcon is finished
+[22:59] <jrand0m> perhaps you two could work together on that?
+[23:00] <co> jrand0m: Can you input a destination to send messages to by hand?
+[23:00] <co> Better said, is there an ASCII representation of a destination?
+[23:00] <jrand0m> yes co, to both
+[23:00] <co> Excellent.
+[23:00] <jrand0m> destinations, and all I2P structures, are loadable and serializable in (an alternate alphabet) base 64
+[23:01] <thecrypto> so it won't be easy to remember, but it will be ascii?
+[23:01] <jrand0m> (e.g. in the netDb for one of my routers, I have leaseSet-enD4jtE-orMwFD0QGog9GAyC5MvLvnPzhVD8cDYvSI8.dat which contains the lease set for destination enD4jtE-orMwFD0QGog9GAyC5MvLvnPzhVD8cDYvSI8)
+[23:02] <jrand0m> [though that is H(destination).toBase64()
+[23:03] <jrand0m> ChZEROHag> if there's anything we can do to help you with that, just say the word
+[23:03] <jrand0m> ok thats 1.1. 1.2) DH precalc
+[23:03] <ChZEROHag> You could do it for me? :-)
+[23:04] <jrand0m> last night I wrote up a precalc optimization for DH exchanges to save ~1s off 1.5s session negotiations. I'd love if someone who knows crypto could make sure I'm not nuts ;)
+[23:04] <jrand0m> lol ChZEROHag
+[23:04] <ChZEROHag> aah I know what I needed
+[23:04] <ChZEROHag> A netdb implementation
+[23:04] <thecrypto> is it in cvs?
+[23:04] <thecrypto> the dh
+[23:04] <jrand0m> yes thecrypto
+[23:05] <jrand0m> C:\dev\i2p\code\core\java\src\net\invisiblenet\i2p\crypto\DHSessionKeyBuilder.java
+[23:05] <ChZEROHag> Well I'm going to be up for a good 3/4 hours yet, maybe it'll give me something to do
+[23:05] <jrand0m> er, s/C:\\dev/g; s/\\/\//g
+[23:05] *** wax_off (~nomail@anon.iip) has joined channel #iip-dev
+[23:06] <jrand0m> word. what do you need a netdb impl for?
+[23:06] <ChZEROHag> I don't remember
+[23:06] <jrand0m> we currently have a non-scalable netdb in cvs
+[23:06] <jrand0m> heh
+[23:06] <ChZEROHag> Haven't touched it in at least a week
+[23:06] <jrand0m> you're working on a C I2CP api, right? not I2NP?
+[23:07] <ChZEROHag> I was just going to do everything
+[23:07] *** wax_off has left #iip-dev
+[23:07] <jrand0m> I2NP is really, really, really significantly more work than I2CP
+[23:07] <ChZEROHag> Once I actually get properly started, it'll just roll out
+[23:07] <jrand0m> but if you impl an I2NP in C that'd rule
+[23:07] <dm> is there a I2NP in anything right now?
+[23:07] <jrand0m> (I2CP:I2NP::FCP:FNP)
+[23:07] <jrand0m> yes dm
+[23:08] * ChZEROHag deminimizes emacs
+[23:08] <jrand0m> the java impl i'm working on has I2NP functioning
+[23:08] <dm> alrighty...
+[23:08] <ChZEROHag> jrand0m: url? I could do with a reference, even if it's in a horrible language.
+[23:08] <jrand0m> heh
+[23:08] <jrand0m> erm, actually thats 6.0 administravia: aka where the fuck is our anon cvs access ;)
+[23:09] <thecrypto> i'm getting the DH stuff
+[23:09] <jrand0m> coo'
+[23:09] <ChZEROHag> Oh right
+[23:09] <Ryan_Singer> jrand0m, back to schedule, the microroadmap?
+[23:09] * thecrypto hides his face
+[23:09] <ChZEROHag> well I'll wait :)
+[23:09] <jrand0m> heh 'k
+[23:09] <jrand0m> microroadmap
+[23:09] <jrand0m> I have 0.1 through 0.5 mapped out
+[23:09] <dm> followed freenet's roadmap then?
+[23:10] *** mrflibble (mrflibble@anon.iip) has joined channel #iip-dev
+[23:10] <jrand0m> 0.1) functional, secure, not anonymous, not scalable, harvestable
+[23:10] <dm> development slows down and freezes during 0.5...
+[23:10] <jrand0m> we are now at 0.1.
+[23:10] <jrand0m> heh I noticed that dm, flinks hosed off at 0.5.2 as well ;)
+[23:10] <co> What are you calling the whole package?
+[23:10] <jrand0m> (strange coincidence)
+[23:10] <co> i.e. version 0.1 of?
+[23:10] <jrand0m> the whole package? i2p router reference implementation
+[23:10] <ChZEROHag> co: Wonga
+[23:10] * beefbroth joins the meeting
+[23:11] <jrand0m> buenos noches beefbroth
+[23:11] <co> All right. That explains it.
+[23:11] <ChZEROHag> Actually maybe I will call it that. Certainly sounds more interesting than 'i2pd'
+[23:11] <jrand0m> 0.1 has bugs. thats a given. and it has no optimizations of note (though the DH precalc helps).
+[23:11] <jrand0m> heh
+[23:11] <Ryan_Singer> jrand0m, what's 0.2) then?
+[23:11] <jrand0m> invisible internet police department
+[23:11] <jrand0m> ok, 0.2
+[23:12] <jrand0m> 0.2 is functional, secure, anonymous, not scalable, harvestable
+[23:12] <jrand0m> 0.2 adds support for non-zero-length tunnels
+[23:12] <jrand0m> I actually implemented most of that last night, but not thoroughly tested
+[23:12] <jrand0m> I think 0.2 will be ready by end of week
+[23:12] <Ryan_Singer> how far away are we from that from a dev perspective?
+[23:13] <Ryan_Singer> great
+[23:13] <jrand0m> 0.3) is functional, secure, anonymous, scalable, harvestable
+[23:13] * thecrypto gets bochs so he can simulate a network to help with this
+[23:13] <jrand0m> 0.3 adds a kademliaDatabaseManager
+[23:13] <jrand0m> right now we use a BroadcastDatabaseManager
+[23:13] <jrand0m> (aka gnunet ;)
+[23:14] <jrand0m> trivial to implement and functional for small networks, but we need the kademlia to scale
+[23:14] <jrand0m> 0.4) is functional, secure, anonymous, scalable, non-harvestable
+[23:14] <jrand0m> that adds trusted links
+[23:14] <Ryan_Singer> jrand0m, and how much of a dev challenge is it to implement kademlia?
+[23:14] <jrand0m> I have two ideas for trusted links.. one is more easily implementable and usable
+[23:15] <jrand0m> kademlia will probably take a full week
+[23:15] <jrand0m> (to get right)
+[23:15] <jrand0m> note that all of this has lots of room for refactoring and tuning. I'm aiming functional first, then we tune.
+[23:16] <co> Are you certain you will be able to develop and test that quickly?
+[23:16] <jrand0m> I am certain of nothing
+[23:16] <jrand0m> thats just my estimate
+[23:16] <Ryan_Singer> co, hegets functional, we test
+[23:16] <ChZEROHag> Are you sure?
+[23:16] <ChZEROHag> (sorry)
+[23:16] <co> Ryan_Singer: I see.
+[23:17] * jrand0m <3 people who test :)
+[23:17] <Myself248> When you say "we" test. Is there any place for non-coders to help with the testing?
+[23:17] <jrand0m> Myself248> probably not until 0.4
+[23:17] <dm> lets just hope it never gets to the point where it's functional, but nobody knows what the fuck is going on inside the network to make it work well (i.e. freenet)
+[23:18] <jrand0m> once 0.4 is ready, thats pre-alpha. once its 0.4 I'll tune and refactor and fill in the blanks to get ready for 0.5 (alpha)
+[23:18] <Myself248> Document, document, document.
+[23:18] <dm> is there any though being put into active monitoring of network internals, or is it straightforward?
+[23:18] <jrand0m> yes dm, absolutely
+[23:18] <jrand0m> one of the key pieces of i2np is the inclusion of stats in the routerInfo strutures published
+[23:18] <mihi> jrand0m: do a s/0./0.0./ ;)
+[23:18] <jrand0m> the initial revs will publish real stats so we can tune
+[23:19] <jrand0m> later revs will either not publish any stats or publish fake ones
+[23:19] * jrand0m does not do 0.0
+[23:19] <shardy> ok, I'm here
+[23:19] <jrand0m> wb shardy
+[23:19] <shardy> sorry for being late, forgot about this window being open, heh
+[23:19] <dm> cool.
+[23:19] <Ryan_Singer> is there a higher level document describing the archetecture for the network under .4?
+[23:19] <jrand0m> off with your head
+[23:20] <jrand0m> Ryan_Singer> hmm, I had some overview docs a few months back that mids and nop mirrored, and there's the i2p overview doc
+[23:20] <jrand0m> 0.4 is full i2np as described in the spec, just not optimally implemented
+[23:20] <shardy> oh and jrand0m, I'll check out the DH optimization for you
+[23:20] <jrand0m> word, gracias
+[23:20] <Ryan_Singer> can I get those docs?
+[23:21] <jrand0m> the overview is at (Link: http://www.invisiblenet.net/i2p/i2p_philosophy.pdf)http://www.invisiblenet.net/i2p/i2p_philosophy.pdf
+[23:21] <beefbroth> they're on the wiki I think?
+[23:21] <jrand0m> hte old overview docs... hmm
+[23:21] <jrand0m> (i2p specs are at (Link: http://wiki.invisiblenet.net/iip-wiki?I2PProtocolSpecs)http://wiki.invisiblenet.net/iip-wiki?I2PProtocolSpecs)
+[23:21] <co> They are on (Link: www.invisiblenet.net/i2p/.)www.invisiblenet.net/i2p/.
+[23:21] <jrand0m> right beefbroth
+[23:22] <jrand0m> though there are old docs in html format w/ ugly ms paint pictures from before showing how tunnels work...
+[23:22] <beefbroth> I should know, I've read them enough
+[23:22] <jrand0m> hehe
+[23:22] <co> Unless those are older versions or mirrors.
+[23:22] <jrand0m> those files on the wiki are 0.9 (0.9.1 is out for I2NP and datastructures, but they only include minor changes)
+[23:23] <thecrypto> jrand0m: the precalc looks good
+[23:23] <jrand0m> cool
+[23:24] *** pitu (~pitu@anon.iip) has joined channel #iip-dev
+[23:24] * jrand0m runs the router w/ java -Dcrypto.dh.precalc.min=3 -Dcrypto.dh.precalc.max=10 -Dcrypto.dh.precalc.delay=5000 -jar C:\dev\i2p\code\router\java\src\router.jar
+[23:25] <jrand0m> ok, thats the microroadmap
+[23:25] <jrand0m> as you can see, I'm accepting that alpha won't be ready for end of month. 0.4 will probably be first week of october
+[23:26] <dm> that's okay, even that would be the fastest ever implementation of a network of this type ;)
+[23:26] <Ryan_Singer> lol
+[23:26] <beefbroth> when reading jrand0m's time estimates here, please remember that he has been drinking whiskey for the last 4 hours :-P
+[23:26] <jrand0m> heh
+[23:26] <Ryan_Singer> ok...apps/usage?
+[23:26] <jrand0m> good whiskey at that ;)
+[23:26] <jrand0m> ok, apps/usage
+[23:27] <dm> 0.7 in 4 seconds....3...2...1..!!
+[23:27] <jrand0m> I'm aiming for low hanging fruit here - these are things that we can do with 0 or minimal new code.
+[23:27] <ChZEROHag> How are you supposed to code properly if you're stone sober?
+[23:27] <jrand0m> all of these make significant use of mihi's kickass i2ptunnel
+[23:27] <co> ChZEROHag: Easily.
+[23:27] *** mihi has changed the topic on channel #iip-dev to <dm> 0.7 in 4 seconds....3...2...1..!!
+[23:28] <jrand0m> using the i2ptunnel, we can do the following without writing any new code:
+[23:28] <jrand0m> public ww proxy (using i2ptunnel + squid)
+[23:28] * dm tips his hat to mihi.
+[23:28] <jrand0m> JAP (using i2ptunnel + JAP)
+[23:28] <mihi> you cannot kick asses though i2p (not through a tunnel either...)
+[23:28] <jrand0m> browse www anon (i2ptunnel + web browser)
+[23:28] <jrand0m> run an i2p web server (i2ptunnel + httpd)
+[23:29] <co> Very nice. Bravo, mihi.
+[23:29] <jrand0m> cvs outproxy (i2ptunnel) [e.g. cvs outproxy to sourceforge for anon freenet dev]
+[23:29] <jrand0m> cvs client, cvs server
+[23:29] <jrand0m> IM app, pop3 server, imap server, opennap
+[23:29] <jrand0m> those are all really low hanging fruit
+[23:29] <dm> okay, now all we need is i2p :)
+[23:30] <jrand0m> right ;)
+[23:30] <Myself248> wouldn't i2p webserver kinda supplant freenet? :)
+[23:30] * jrand0m thinks that qualifies as a faq I should answer
+[23:30] <Ryan_Singer> jrand0m, but they are also very valuable
+[23:30] <ChZEROHag> From that list, I'd consider cvs more important/useful
+[23:30] <ChZEROHag> Partly because I wish to remain anonymous, but also because if anonymous www is provided you'll get lusers
+[23:30] <jrand0m> i2p + web doesn't supplant freenet - freenet adds significant value on top of an anon comm framework - content distribution
+[23:31] <ChZEROHag> And at the moment the idea of anonymous email is scary :)
+[23:31] * dm writes down: "no lusers"
+[23:31] <jrand0m> cvs definitely is in the top 3
+[23:31] <beefbroth> i think if i2p webserving works well, you have to consider merging the DHT/storage parts of freenet on top of i2p and then you have the best of both worlds.
+[23:31] <Ryan_Singer> ChZEROHag, if it's scalable thats a goodthing
+[23:31] <ChZEROHag> dm: lusers are only a problem during the early stages, but they tend not to use cvs
+[23:31] <Myself248> okay, add lots of hashcash to any anon email thing.
+[23:31] <ChZEROHag> Or, for that matter, even know what (or that) it is
+[23:31] <co> I think one of the tests that needs to be done is a test attack on the network.
+[23:31] <jrand0m> yes beefbroth, once i2p does what we aim at, freenet will most likely adjust to make use of it
+[23:32] <co> Sorry if that is offtopic.
+[23:32] <mihi> Myself248: just add a redirector to an anon remailer.
+[23:32] <jrand0m> no, thats definitely on topic co - attacking this network is key
+[23:32] <ChZEROHag> Myself248: hashcash is primarily to stop flooding while we're forced to use the ancient protocol that is 'irc'
+[23:32] <ChZEROHag> Not to stop what could be termed 'abuse'
+[23:32] <jrand0m> right mihi. though perhaps mixminion run over i2p would be useful
+[23:33] <jrand0m> right, hashcash is even built into i2p itself to keep messages from being delivered a single hop unless they "pay up"
+[23:33] <Ryan_Singer> jrand0m, we could run imap over this easily?
+[23:33] <jrand0m> absolutely
+[23:33] <Ryan_Singer> impressive
+[23:33] <jrand0m> imapd with an i2ptunnel pointing at it, with i2ptunnel on the client pointing at that tunnel's destination
+[23:34] <Myself248> and freenet search engines :)
+[23:34] <mihi> ftp or several non-jabber instant messengers will make problems...
+[23:34] <jrand0m> right, things that require two connections are more complex
+[23:34] <ChZEROHag> jrand0m: hashcash in i2p?
+[23:34] <ChZEROHag> I shall bug you about that when this is over.
+[23:34] <shardy> hashcash in i2p? nice.
+[23:34] <dm> we're getting ahead of ourselves! oh alright, who cares.. QUAKE + IIP!!!!!!
+[23:34] <dm> sorry, I2p :)
+[23:34] <jrand0m> lol dm
+[23:35] <Myself248> Those of us with little CPUs get nervous when someone says hashcash, but as an anti-spamming measure I understand it.
+[23:35] <co> dm: That is *reallY* getting ahead of ourselves.
+[23:35] * mihi is jabber:schierlm@a-message.de ;)
+[23:35] <jrand0m> yes ChZEROHag - Destination == public signing key (DSA) + public encryption key (ElGamal) + certificate (either null or hashcash(keys))
+[23:35] <beefbroth> is the i2p tunnel static or dynamic on the client end?
+[23:35] <mihi> beefbroth: atm it is all static. but you could use a socks proxy as dest. ;)
+[23:35] <jrand0m> Myself248> I'm getting a bitching sun ultra1 in the mail in a few weeks. if a 160Mhz box can do it, everyone can
+[23:35] <shardy> well. hashcash shouldn't be something that is terrible even to small cpus. only if you want to do something eleventy billion times, should you notice it.
+[23:36] <co> beefbroth: It can be dynamic.
+[23:36] <Ryan_Singer> the potential applications of the "low-hanging fruit" here are very impressive
+[23:36] <jrand0m> right mihi
+[23:36] <jrand0m> "eleventy". heh
+[23:36] <ChZEROHag> the low hanging fruit is essentially 'normal' internet apps, but anonymously
+[23:36] <ChZEROHag> right?
+[23:36] <jrand0m> right
+[23:36] <Ryan_Singer> yes
+[23:36] <dm> (quake)
+[23:37] <jrand0m> 0.1 runs them securely, 0.2 runs them anonymously, 0.3 runs them scalably, 0.4 runs them non-harvestably
+[23:37] <jrand0m> (we're @ 0.1 now)
+[23:37] <shardy> what do you mean by non-harvestably?
+[23:37] <co> Sorry, what is harvestable again?
+[23:37] <ChZEROHag> dm: Unfortunately we've ben held back enough that realtime is after more than 30 years still not 'normal'
+[23:37] <Myself248> Phew. I was hoping someone would ask that. ;)
+[23:37] <Ryan_Singer> loggable
+[23:37] <jrand0m> harvesting means an active attacker can run a router, find out about lots of other routers ("harvest" them), and send the goons to kick in their doors
+[23:38] <Myself248> oh, like you can do with gnutella. :)
+[23:38] <Ryan_Singer> secret-servicy like goons
+[23:38] <jrand0m> right
+[23:39] <shardy> ah, gotcha.
+[23:39] <jrand0m> ok, but yeah, thats the microroadmap.
+[23:40] <jrand0m> now, am I being stupid calling these 0.x instead of 0.0.x? should 1.0 be "perfect" or should 1.0 be functional and safe?
+[23:40] <Ryan_Singer> jrand0m, and we will see .4 when?
+[23:40] <jrand0m> 0.4 is probably 2 weeks out
+[23:40] * jrand0m is taking a week off (ish) in mid october as I have people coming to visit
+[23:40] *** Signoff: dm (EOF From client)
+[23:40] <mihi> 1.0 should be stable.
+[23:40] <co> Let 1.0 be functional and safe.
+[23:40] <thecrypto> dittos co
+[23:41] <Ryan_Singer> 1.0 should be functional, stable and safe
+[23:41] <ChZEROHag> jrand0m: My philosophy, regarding version numbers, is if in doubt, copy Linux
+[23:41] <Myself248> 5.0 can be "perfect". Free software people are overly afraid of version number bloat.
+[23:41] <jrand0m> word
+[23:41] <mrflibble> jrand0m, v1 of things are never perfect :)
+[23:41] *** dm (~gj@anon.iip) has joined channel #iip-dev
+[23:41] <mrflibble> people dont expect them to be perfect either
+[23:41] <dm> did I miss 1.0?
+[23:41] <ChZEROHag> mrflibble: People don't expect any software to be perfect. People use windows.
+[23:41] <Ryan_Singer> this software will beGPL orLGPL?
+[23:41] <jrand0m> cool, I've already gotten flack for 1.0 being not-perfect yet
+[23:41] <ChZEROHag> That doesn't mean it shouldn't be.
+[23:41] <mrflibble> good point ChZEROHag
+[23:42] <dm> ah shit, I did didn't i..
+[23:42] <mihi> dm: stop kidding
+[23:42] <mrflibble> yup, u did
+[23:42] <jrand0m> the router is GPL. the java client library is currently GPL, but I'm open. thecrypto and I are full owners of all but one section (the Cryptix AES impl, which is MIT)
+[23:42] <dm> alright alright I'm sorry :(
+[23:42] <jrand0m> actually, I take that back
+[23:42] <jrand0m> I used the Base64.java from freenet too
+[23:43] <beefbroth> are we still on agenda item 0.3 Apps ?
+[23:43] <jrand0m> so base64 is GPL :)
+[23:43] <thecrypto> and the IM client will be GPL
+[23:43] <jrand0m> oh yeah, we're on 0.3 aren't we
+[23:43] <thecrypto> as soon as i get around to putting comments in the code
+[23:43] *** UserX_ (~User@anon.iip) has joined channel #iip-dev
+[23:43] <jrand0m> heh thecrypto
+[23:43] <ChZEROHag> GPL sounds good to me
+[23:43] <jrand0m> w0ah, 23 users
+[23:43] <Myself248> we're on agenda item 6.02E23, random crap. :)
+[23:43] <Ryan_Singer> jrand0m, if you get time, I want to talk to you about liscencing and potential consulting gigs
+[23:43] <jrand0m> cool Ryan_Singer
+[23:43] <ChZEROHag> Though as someone (Fillament?) pointed out - if someone breaks the license how is an anonymous person going to do anything about it?
+[23:43] <mihi> jrand0m: 22 ;)
+[23:43] <jrand0m> ChZEROHag> read my license on flinks ;)
+[23:43] <Myself248> we need an anonymous court system.
+[23:44] * mihi is here twice
+[23:44] <jrand0m> Myself248> its called yodel ;)
+[23:44] <Myself248> "The court now hears docket number 34534, J. Doe v. J. Doe"
+[23:44] <Ryan_Singer> ChZEROHag, the reason I ask is for corporations to make use of this software for security against industrialespionage
+[23:44] <co> Naming server will be licensed under GPL as well.
+[23:44] <CCD> lol
+[23:44] <Myself248> "Baliff, aren't those the same parties as the last 34533 cases we've heard?"
+[23:44] <shardy> well
+[23:45] <shardy> there's always the idea that if you want people to *really* use your protocol, and you're not worried about money, just make it completely open. not even restricted by gpl.
+[23:45] <co> shardy: You mean public domain?
+[23:45] <beefbroth> i think that was co's lead in to 0.4 agenda item :-P
+[23:45] <jrand0m> shardy> the specs are public and open. I have not asserted copyright on the specs.
+[23:45] <Ryan_Singer> shardy, no, we would like work on the protocol to stay available
+[23:45] <shardy> public domain, bsd license, "do whatever you want just give us credit please" license, etc
+[23:45] <jrand0m> the code is GPL for the router. one client api implementation in java is GPL
+[23:46] <Ryan_Singer> check out the liberty protocol.... (Link: http://projectliberty.org)http://projectliberty.org
+[23:46] <shardy> jrand0m: ok cool. gotcha.
+[23:46] * jrand0m has thought about "no government use" licenses ;)
+[23:46] <jrand0m> ok, the reason I tossed 3.0) apps into the list of issues is this
+[23:46] <jrand0m> we need help.
+[23:46] <Ryan_Singer> help with what?
+[23:46] <jrand0m> i2ptunnel is good code. i2p's router will be good code.
+[23:47] <jrand0m> what we need is for people to start figuring out the nuts and bolts of release engineering
+[23:47] <dm> why do you need apps if you can just use i2ptunner?
+[23:47] <ChZEROHag> jrand0m: come again?
+[23:47] <jrand0m> aka, how to actually package something up that joe sixpack can download and browse the web
+[23:47] <ChZEROHag> dm: Why do you need apps if you can just use telnet?
+[23:47] <dm> what?
+[23:47] * dm scratches his head.
+[23:47] <CCD> err, there is something besides telnet?
+[23:48] * jrand0m thinks thats ChZEROHag's point dm ;)
+[23:48] *** Myself248 is now known as myself248
+[23:48] *** Signoff: thecrypto (Ping timeout)
+[23:48] <ChZEROHag> dm: To use i2ptunnel would be like having a working car and then dragging it around on a handcart
+[23:48] <jrand0m> ok, thats just that. I just wanted to mention in case people had spare time :)
+[23:48] <jrand0m> ok, 4.0)
+[23:48] <jrand0m> naming service
+[23:48] <dm> I can see he's trying to make a point.
+[23:48] <jrand0m> hi co, hows it going? :)
+[23:48] <co> The naming server must be GPL, since at least the Java implementation uses code from the client library to contact routers.
+[23:49] <dm> but we just spent 20 minutes going: I2Ptunnel + web server!, I2Ptunnel + quake! ;)
+[23:49] <ChZEROHag> Or, in computing terms, like doing all your internet stuff with telnet instead if directly on the ip stack
+[23:49] <co> I did not do much last week. I released the client API, which also needs work.
+[23:49] <ChZEROHag> i2ptunnel is an interrim solution
+[23:49] <co> I will have time this week, though, to begin implementing the naming server.
+[23:49] <jrand0m> cool
+[23:49] <jrand0m> where is the client api again?
+[23:50] <mihi> on the mailing list ;)
+[23:50] <co> One of its assumptions is that destinations can be encoded in base64, which is why I asked the question about that earlier.
+[23:50] <jrand0m> ChZEROHag> in some ways its interim
+[23:50] * jrand0m !thwaps self
+[23:50] *** thecrypto (~thecrypto@anon.iip) has joined channel #iip-dev
+[23:50] <dm> so is TCP!
+[23:50] *** yodel (yodel@anon.iip) has joined channel #iip-dev
+[23:50] <jrand0m> 'lo yodel
+[23:50] <beefbroth> what are the naming conventions going to look like? is it something that joe average will be able to relate to (i.e. (Link: www.somthing.com)www.somthing.com or (Link: www.something.i2p)www.something.i2p for http/web stuff)?
+[23:50] <co> I will put the naming service specification and client API into CVS.
+[23:50] <jrand0m> wb thecrypto
+[23:50] <ChZEROHag> These have probably been covered before, but how will the ns provide unique names fairly?
+[23:50] * mihi wants to have *.mihi.iip ;)
+[23:50] <jrand0m> beefbroth> with the naming service or without?
+[23:50] <jrand0m> heh mihi
+[23:50] <ChZEROHag> avoiding the squatting, etc. that has plagued DNS
+[23:50] <thecrypto> can someone send me what happened?
+[23:51] <beefbroth> jrand0m: with. i think without would be a long string of numbers.
+[23:51] <co> ChZEROHag: You will register with a group of naming servers, then will use the name of that group to identify yourself.
+[23:51] <co> As in IM.beefbroth.mygroup if you provide IM service.
+[23:51] <mihi> oops, s/iip/i2p
+[23:51] *** godmode0_ (~mode@anon.iip) has joined channel #iip-dev
+[23:51] *** Signoff: godmode0 (EOF From client)
+[23:51] <jrand0m> ChZEROHag> co's naming service has trusted groups, where each group manages a group name (tld). you select chose which groups run each tld
+[23:51] <co> Yes, it will be possible for someone to register the username beefbroth with group2.
+[23:51] <thecrypto> in the 4 minutes i was gone
+[23:52] <ChZEROHag> co: So the only issue is the .mygroup uniqueness?
+[23:52] <ChZEROHag> And who gets the group 'com'? :-)
+[23:52] <jrand0m> and that is selected by the client
+[23:52] <mihi> ChZEROHag: i2p is not COMmerical
+[23:52] <jrand0m> (e.g. you tell your ns client lib "group '.com' is group 0123ff33aefcbb34fe
+[23:52] <beefbroth> I hate to suggest it, but I almost think the groups should default to 3 letters to preserve the illusion that it is similar to the regular web
+[23:52] <co> ChZEROHag: I am not sure who gets the "com" group.
+[23:52] <co> Good question.
+[23:53] <shardy> beefbroth: except the "regular web" is no longer only 3 letter lds
+[23:53] <mihi> beefbroth: or add a .i2p to all addresses.
+[23:53] <ChZEROHag> beefbroth: That illusion is only present in america
+[23:53] <shardy> tlds.
+[23:53] <jrand0m> to start with, we may just want to initially have one group of naming servers, ".i2p"
+[23:53] <co> beefbroth: The naming server software permits you to have up to 32 letters.
+[23:53] <ChZEROHag> Elsewhere we use the 2-letter country codes given us
+[23:53] <shardy> .us is also in use in america.
+[23:53] <co> Actually, I wanted the first group to be "test".
+[23:53] <shardy> as are things like .info and .name
+[23:53] <jrand0m> heh 'k
+[23:54] <ChZEROHag> shardy: yeah, by about 5 people.
+[23:54] <ChZEROHag> But this is perhaps a rant for another time :)
+[23:54] <jrand0m> actually...
+[23:54] <shardy> there's even a .museum
+[23:54] <Ryan_Singer> jrand0m, using .12p sounds good
+[23:54] <jrand0m> I ran into a distributed DNS based of JXTA the other day
+[23:54] <co> ChZEROHag: But the point is that if you do not like the people running the "com" group, you can establish the "com2" group and run its servers (and register with it).
+[23:55] <ChZEROHag> YEs that bit makes perfect sense
+[23:55] <mihi> ChZEROHag: (Link: http://www.nic.us/press/audio/dotus-mayEM.wav)http://www.nic.us/press/audio/dotus-mayEM.wav ;)
+[23:55] <jrand0m> co> can't you just say "well, they 'think' they're .com, but I say .com is run by group2"?
+[23:55] <ChZEROHag> What I'm getting at, I suppose, is does it rely on first-come-first-served?
+[23:55] <co> You may configure your client to do anything.
+[23:56] <Ryan_Singer> how does the JXTA name system work?
+[23:56] <jrand0m> co> (Link: http://wiki.java.net/bin/view/Jxta/DisDNS)http://wiki.java.net/bin/view/Jxta/DisDNS is a distributed DNS wiki, though its very rough and doesn't address any real hard issues
+[23:56] <co> ChZEROHag: In registering your username with a group, yes.
+[23:56] <co> jrand0m: I will look at that after the meeting.
+[23:56] <jrand0m> jxta runs naming servers off rendevous points
+[23:56] <ChZEROHag> mihi: wassat?
+[23:56] <beefbroth> so it is possible someone tries to attack the NS system by mimicing the already existing i2p group of naming servers
+[23:57] *** Signoff: jeremiah (Ping timeout)
+[23:57] <co> beefbroth: I think not.
+[23:57] <mihi> ChZEROHag: listen to it. why xxx million americans prefer .us over .com
+[23:57] <mihi> 68 million
+[23:57] <co> As I envision it, people setting up groups will announce those groups.
+[23:57] <jrand0m> mimicing? they can't mimic as the servers in the group are authenticated by public key systems
+[23:58] <jrand0m> however, if groups allow non-trusted members to join the group, they can be taken over trivially.
+[23:58] <shardy> but how is the key exchange done?
+[23:58] <co> The later people will face the problem that the group is already established, and the client software configuration files contain the former group's destinations.
+[23:58] <ChZEROHag> mihi: Well I've always said it makes sense to prefer it, patriotism and whatnot, I've just never really seen it.
+[23:58] <beefbroth> what happens if two groups of naming servers both claim to resolve the .i2p group?
+[23:58] <co> Good question, though, and I will think over it again, carefully.
+[23:58] <ChZEROHag> Anyway, I shall have a listen
+[23:58] <jrand0m> shardy> no key exchange - key publishing
+[23:58] <beefbroth> i see, good point
+[23:58] <ChZEROHag> co: Yeah that's another thing I was trying to get at
+[23:58] <shardy> but keys can still be intercepted if they're published online
+[23:58] <jrand0m> beefbroth> no one claims anything. your client says "i2p == [dest1, dest2, dest]"
+[23:59] <shardy> what we need is a trust-based dns system :)
+[23:59] <shardy> so you can submit a query for the name and get back a list of responses... and then go with the trusted one
+[23:59] <co> Thank you for bringing this up.
+[23:59] <jrand0m> shardy> ah, I think I understand the confusion. I think the naming service will want to come with a set of destinations out of band (aka packaged with install)
+[23:59] <ChZEROHag> Yeah we have one - everyone trusts IANA (or whatever they call themselves) or else.
+[23:59] * shardy ducks
+[23:59] <ChZEROHag> :-D
+[23:59] <mrflibble> they're trying that with dnssec, but of course that's not anonymous
+[00:00] <jrand0m> what this naming service does is get away from root servers
+[00:00] <beefbroth> you could always have an i2p homepage that listed active naming groups and authorites?
+[00:00] <shardy> jrand0m: ok. just pointing out that it can still be intercepted no matter what you do, unless there's a physically secure channel to initially transmit those keys over...
+[00:00] <co> shardy: I think I covered key exchange in the spec. If not, tell me.
+[00:00] <shardy> but packaging it oob makes it better
+[00:00] <shardy> co: I'll check it out.
+[00:00] <jrand0m> shardy> oh, right. yes, people need to be able to trust the code they download
+[00:00] <co> beefbroth: Certainly.
+[00:01] <ChZEROHag> aah that reminds me
+[00:01] <jrand0m> beefbroth> yes, thats most certainly one of the first apps that will be implemented - an i2p webserver w/ bbs & wiki that people can access through i2p
+[00:01] <ChZEROHag> I should create a gpg key for my iipmail
+[00:01] *** yodel has left #iip-dev
+[00:01] * ChZEROHag does so while unexciting stuff happens
+[00:01] <jrand0m> heh ok
+[00:01] <co> Please understand that the naming server specification is still open to suggestions for improvement.
+[00:02] <shardy> I think I'm going to bring all the specs with me on the flight to toorcon... that'll give me a time to read them
+[00:02] <co> I do not claim it is perfect or finalized at this time.
+[00:02] <jrand0m> heh I hope its a long flight
+[00:02] <shardy> and it's more productive than playing fft advance the entire time, heh
+[00:02] * jrand0m has found that criticism will more freely come once there is code implementing specs
+[00:02] *** godmode0_ is now known as godmode0
+[00:02] <co> And I have to write the code.
+[00:02] <co> I think we can move on to the next topic now.
+[00:02] <jrand0m> 'k
+[00:02] <jrand0m> 5.0) IM
+[00:03] <jrand0m> hi thecrypto
+[00:03] <mihi> names should not be able to clash with base64 representations.
+[00:03] <thecrypto> hi
+[00:03] <thecrypto> okay
+[00:03] <mihi> and the namin server should transparently return bas64 addressas as is.
+[00:03] <co> mihi: Very well, I will try to avoid that problem.
+[00:03] <thecrypto> first since my e-mail isn't working again (damn spammers)
+[00:03] <jrand0m> (all classes that extend DataStructure have String .toBase64() and .fromBase64(InputStream) )
+[00:03] <thecrypto> i'll answer whit's questions about me system here
+[00:04] * jrand0m loads up co's email
+[00:04] <mihi> jrandom? why Inputstream and not Reader?
+[00:04] <thecrypto> network is the first thing that came to mind, you are making connections over the i2p network, it's very p2p so i called it a networkr
+[00:04] <jrand0m> if you want a Reader, just run an InputStreamReader, you brat
+[00:04] <mihi> base64 is characters, not bytes in my opinion.
+[00:04] <ChZEROHag> jrand0m: IM == Instant Messaging?
+[00:04] <jrand0m> yes ChZEROHag
+[00:04] <thecrypto> if people have a problem with that, give me a suggestion for what to call it about
+[00:05] <ChZEROHag> jabber?
+[00:05] <thecrypto> IM == my own distributed IM network
+[00:05] <shardy> you should call it "bob"
+[00:05] <jrand0m> i2p im is a network in the same way aim is a network, or kazaa is a network, all running over tcp/ip or udp/ip
+[00:05] <co> How about IM application?
+[00:05] <ChZEROHag> (anonabber)
+[00:05] <co> jrand0m: I see.
+[00:05] <thecrypto> jabber requires a centerized server
+[00:05] <jrand0m> terminology doesn't matter to me. I like shardy's idea
+[00:05] <ChZEROHag> thecrypto: Nothing *requires* a centralised server
+[00:05] <thecrypto> and i cannot spell today so bear with me
+[00:06] <ChZEROHag> That's just the way things are written
+[00:06] <jrand0m> (though I prefer Betty)
+[00:06] <thecrypto> so you want me to call it I2PIM bob?
+[00:06] <thecrypto> :)
+[00:06] <jrand0m> how about wilma?
+[00:06] <jrand0m> fred is taken thoug
+[00:06] <co> How about distributed IM?
+[00:06] <jrand0m> DIM, heh
+[00:06] <co> But then, distributed IM *application*?
+[00:06] <dm> AIM, anonymous Instant messaging!
+[00:06] <thecrypto> bad acronym :)
+[00:07] <dm> then we can take over AOL.
+[00:07] <thecrypto> ohh i can just wait for AOL to get wind of that
+[00:07] <ChZEROHag> dm: That would realy piss certain wankers off. I like it.
+[00:07] <jrand0m> heh do it
+[00:07] <Ryan_Singer> thecrypto, will webe able to implement IM in a decentralised way, or will it have to be centrallized?
+[00:07] <co> dm: Good idea. I would back that acronym.
+[00:07] <jrand0m> the way I've read thecrypto's docs, the IM is fully decentralized
+[00:07] <thecrypto> i am implementing a distributed IM, it's in the CVS
+[00:07] <beefbroth> I would vote against anything that is going to confuse people
+[00:08] <Ryan_Singer> AOL TimeWarner changed it's name to Time Warner
+[00:08] <ChZEROHag> beefbroth: I would too, but the vote to piss AOL off outweighs that.
+[00:08] <beefbroth> You want the system to be familiar enough that people won't be afraid to install it, but different enough to differentiate
+[00:08] <jrand0m> actually, thats a good point
+[00:08] <thecrypto> I2PIM is the name of the application
+[00:08] <jrand0m> being transparently anonymous isn't useful if people don't understand what anonymous is.
+[00:09] <ChZEROHag> Oh wait, I have something like this down on paper
+[00:09] <beefbroth> I like the crypto's idea
+[00:09] <thecrypto> what "network" I2PIM runs on is what I'm looking for
+[00:09] <jrand0m> teaching people how to protect themselves is a really important thing
+[00:09] <thecrypto> i was thinking Presence System?
+[00:09] <Ryan_Singer> hypethe security aspect of anon
+[00:09] <dm> I2M (instant 2 messaging)
+[00:09] <ChZEROHag> Although I only called it XIrc
+[00:10] <jrand0m> you're the man thecrypto, whatever works for ya ;)
+[00:10] <dm> and in the I2M logo, the 2 will be really small :)
+[00:10] <thecrypto> well I2P expands to Invisible ... jrand0m ?
+[00:10] <ChZEROHag> The main thing I liked about it was that everyone was called a Borg and they chatted in Collectives
+[00:10] <jrand0m> i2p = i^2p (invisible internet project)
+[00:10] <co> I thought the P stands for protocol.
+[00:10] <jrand0m> that too
+[00:10] <jrand0m> well, actually, no
+[00:11] <thecrypto> so it's Invisible Internet Project Instant Messaging
+[00:11] <jrand0m> i2np is the protocol
+[00:11] <jrand0m> i2p is the project
+[00:11] <beefbroth> I thought it stood for "poop"
+[00:11] <jrand0m> i2cp is the client proto
+[00:11] <co> thecrypto: You are right, the name does not matter too much.
+[00:11] <dm> i2m = i^2m = instant invisible messaging
+[00:11] <thecrypto> so next topic then
+[00:11] <Ryan_Singer> ok....so, we're drifting off agenda...are we done with IM?
+[00:11] <shardy> if "bob" isn't good enough, we can call it "jimbob"
+[00:11] <jrand0m> 0k, 6.0) administravia
+[00:11] <thecrypto> no, still more here
+[00:12] <thecrypto> sorry
+[00:12] <co> It's administrivia.
+[00:12] <thecrypto> no it's IM
+[00:12] <jrand0m> nop> give me root. I need to get anon cvs, bugzilla, and cvsweb installed.
+[00:12] <thecrypto> i wasn't finished
+[00:12] <thecrypto> :)
+[00:12] <thecrypto> rewind!
+[00:12] * jrand0m backs up
+[00:12] <jrand0m> 5.1) thecrypto v2
+[00:12] <Ryan_Singer> what else is there in IM, thecrypto?
+[00:13] <mihi> thecrypto: just talk on; /me idi it the same way as i missed the naming services
+[00:13] <thecrypto> okay, the thing about presences communicating is different
+[00:13] <thecrypto> not everyone knows everyone else
+[00:13] <thecrypto> there is practically no way to "stalk" someone
+[00:13] <thecrypto> you have to ask to be shown
+[00:14] <mihi> in anonymous networks, usually no one knows anyone else ;)
+[00:14] <jrand0m> (as long as people's Destination is random)
+[00:14] *** Signoff: pitu (Lost terminal)
+[00:14] <dm> what do you mean?
+[00:14] <thecrypto> Alice wants to talk to Bob
+[00:14] <jrand0m> mihi> though the naming service allows search by service
+[00:14] <jrand0m> (service being IM, www, etc)
+[00:14] <thecrypto> Alice finds Bobs IM destination some how, prolly by the naming service
+[00:15] <thecrypto> So Alice sends a message to Bobs IM destination
+[00:15] <dm> yes?
+[00:15] <thecrypto> he gets a little message saying "Alice tried to contact you" if he wants to talk to her, he can, or he can ignore it
+[00:16] <thecrypto> but there is no central presence server, Alice can also just see her message disappear and not get a response
+[00:16] <dm> ok, like MSN then?
+[00:16] <jrand0m> (though Alice can know that Bob ignored her)
+[00:16] <thecrypto> and Alice can't just put Bob on her buddy list and wait for him
+[00:16] <Ryan_Singer> thecrypto, ok...how is this different then properly configured Y!, MSN or AIM..apart from the nocentral server bit
+[00:16] <thecrypto> because Bob has to send a message to Alice to see her sign on
+[00:16] <Ryan_Singer> oh
+[00:16] <dm> ok, it doesn't change anything as far as the user is concerned, but I see what you mean.
+[00:17] <jrand0m> thecrypto> not quite true
+[00:17] <Ryan_Singer> got it..no buddylist functionality...
+[00:17] <jrand0m> oh, well, hmm, technically...
+[00:17] <thecrypto> Ryan_Singer: no there is still a buddy list
+[00:17] <dm> how does alice send bob a message if she can't see him?
+[00:17] <dm> you just have to try random contacts in case they are there?
+[00:17] <jrand0m> bob has to send a message to alice's router, which can happen without alice knowing it
+[00:17] <thecrypto> Alice can just randomly try
+[00:18] <dm> that's not very convenient? you go online and have to send everyone a message saying (you there?, you there?)
+[00:18] <beefbroth> thecrypto: can't a user "notify" all their buddies when they sign on by sending them a message? or is that what you were just saying
+[00:18] * co notes that there can be two Bobs registered with two different naming server groups.
+[00:18] <thecrypto> beefbroth: that was just want i'm saying
+[00:18] <dm> ok, so similar to current scheme but you are invisible by default.
+[00:18] <dm> gotcha.
+[00:19] <thecrypto> dm: no it's the other way around, when you sign on, you send a message to everyone saying "I'm on, I'm on" if you recieve a message saying "I'm on" you return it
+[00:19] <thecrypto> if you want to
+[00:19] <co> So the user controls who can see him/her/it.
+[00:19] <thecrypto> so Alice can put you on her buddy list and you'll get a message when she signs on saying "Alice has put you on her buddy list, would you like to notify her of your presece"
+[00:20] <Ryan_Singer> when you get off do you first send a msg that says "I'm getting off"?
+[00:20] <dm> ok, that's just a way to get around having a server, but the question is will the apps be setup by default to send a "I'm on" when someone logs on.
+[00:20] <Ryan_Singer> hopefully
+[00:20] <jrand0m> Ryan_Singer> or just have a periodic "I'm still on" ping
+[00:20] <jrand0m> (and missing ping == off)
+[00:21] <Ryan_Singer> keep-alive type deal?
+[00:21] <beefbroth> It might need to "ping" the other IM user every so often to make sure there wasn't an unintentional disconnect
+[00:21] <thecrypto> if Bob has Alice on his buddy list and Bob recives and Online message from Alice the return message is automatic
+[00:21] <beefbroth> heh
+[00:21] <thecrypto> If Bob doesn't have Alice on his buddy list and bob recives an online message from alice, the user is propmted
+[00:21] <dm> ok, so the IM experience is the same as it is now. Just wanted to confirm that.
+[00:22] <thecrypto> just you now have a confirm on buddy adds
+[00:22] <thecrypto> which i think only ICQ has
+[00:22] <jrand0m> will the IM app be a stand alone or will I be able to use trillian?
+[00:22] <dm> yeah, that's how MSN works.
+[00:22] <jrand0m> [etc]
+[00:22] <ChZEROHag> thecrypto: ICQ only pretends to require confirmation
+[00:22] <beefbroth> dm: wrong. you won't have to deal with MSN, Y! and AIM changing their protocols and locking people out every few months :)
+[00:23] <thecrypto> jrand0m: i'll make a spec, trillian can either give me a plugin interface or they can write thier own
+[00:23] <thecrypto> i will be writing a plugin for gaim at leasty
+[00:23] <thecrypto> along with a standalong client
+[00:23] <jrand0m> cool
+[00:23] <thecrypto> which is built to be used with the network
+[00:23] <jrand0m> does gaim support file xfer or will that be the benefit of the i2pim client?
+[00:23] <beefbroth> thecrypto: you might want to give a shout to the kopete developers just to let them know
+[00:23] * jrand0m shows his cluelessnesss
+[00:24] <thecrypto> i'll try to make the gaim plugin work as well as the standalong, but i don't know
+[00:24] <co> thecrypto: Let's have the standalone application first.
+[00:24] <thecrypto> gaim file transfer i think only works on AIM
+[00:24] <thecrypto> so it might take some wrangling to get it into a plugin
+[00:24] <Ryan_Singer> ok..I think we all understand this now...any more IM issues?
+[00:25] <thecrypto> and co's final thing
+[00:25] <beefbroth> gaim suffers problems with it's IM xfers for people using NAT
+[00:25] <thecrypto> more than one person can have the same name
+[00:25] <thecrypto> they will have unique destinations
+[00:25] *** Signoff: mihi (Ping timeout)
+[00:25] <co> All right.
+[00:25] * mihi_backup is still here...
+[00:25] <thecrypto> but someone can't masquerde
+[00:26] <jrand0m> heh nice1 mihi_backup
+[00:26] <co> If you use the naming server, it will be "Bob from group1" and "Bob from group2".
+[00:26] <co> With unique destinations.
+[00:26] <jrand0m> right thecrypto. names are arbitrary. kind of like dns ;)
+[00:26] *** mihi (~none@anon.iip) has joined channel #iip-dev
+[00:26] <thecrypto> also the IM client itself can optionally check "Hey, this IM you got was from someone called Bob, the destination of the Bob in your list is different, accept message?"
+[00:27] <dm> mihi: your backup talked while you were gone.
+[00:27] <thecrypto> if they person is trying to masquerde Bob, you'll know, otherwise, you can alias them out
+[00:27] <mihi> i know...
+[00:27] <jrand0m> "someone called bob"? says who? they call themself bob? or some group calls them bob? or you call their dest bob?
+[00:27] <thecrypto> there is a feild in the presence called name
+[00:27] <thecrypto> i'm looking at that
+[00:28] * jrand0m likes the way ICQ works with that problem - everyone is a number and you just alias numbers locally to names
+[00:28] <co> As an aside, should I make the NS entity names case insensitive?
+[00:28] <jrand0m> probably co
+[00:28] <mihi> base64 things must be case sensitive still ;)
+[00:28] * jrand0m doesn't want people spoofing Jrand0m
+[00:28] <co> mihi: Entity names, not destinations.
+[00:28] <jrand0m> right right mihi
+[00:29] <jrand0m> (well, people can spoof jrand0m all they want. I just want jrandom back)
+[00:29] <co> Go on, thecrypto.
+[00:29] *** Signoff: UserX_ (Ping timeout)
+[00:29] <thecrypto> that's all i have
+[00:29] <thecrypto> finally :)
+[00:29] <mihi> co: you should be able to place a destination wherever you can place an entity name.
+[00:29] <mihi> like it is with dns names and IPs
+[00:29] <co> mihi: Good point. I will add that to the specification.
+[00:29] <thecrypto> jrand0m: actully it's kinda like ICQ except you tell people what you'd like your alias to be
+[00:30] <thecrypto> which i think they do now
+[00:30] <co> The idea, though, is that it will be much shorter to type names than destinations.
+[00:30] <jrand0m> mihi> the naming service only turns names to destinations - if you ask the naming service for the destination of a destination, it should return really really quickly
+[00:30] <Ryan_Singer> ok guys...I have a meeting... jrand0m, anonymail me
+[00:30] <jrand0m> 'k adios
+[00:30] <mihi> jrand0m: yes, and it should return that dest itself, and not "not found"
+[00:31] <jrand0m> right
+[00:31] *** Signoff: Ryan_Singer ((null))
+[00:31] <jrand0m> ok. we're at 7.0)
+[00:31] <jrand0m> questions
+[00:31] <jrand0m> hi
+[00:31] <co> What about 6.0) Administrivia?
+[00:32] <co> Or were you done with that?
+[00:32] <jrand0m> 6.0 administravia was just me nagging nop to give me root to get y'all: anon cvs access, bugzilla, and a cvsweb interface :)
+[00:32] <beefbroth> are there going to be owners to work on packaging the alpha, beta and releases for Win/Mac/SuSE/RehHat/Debian to speed up adoption?
+[00:33] <jrand0m> you volunteering?
+[00:33] <jrand0m> (aka yeah, that'd be great)
+[00:33] <beefbroth> If I learn how to make a package for my distribution :)
+[00:33] <jrand0m> what distro do you use?
+[00:34] <co> As I recall, the IIP developers wanted to reimplement IIP over I2P. If I2P delivers on its promises of anonymity, will it not be simpler to just have IRC over I2P?
+[00:34] <beefbroth> But my point is, alot of people rely on those. It would make it easier for people to adopt. Freenet suffers from a lack of active maintainers.
+[00:34] <dm> jr makes for a good manager :)
+[00:34] <jrand0m> yes co, simpler, but not as scalable
+[00:34] *** UserX_ (~User@anon.iip) has joined channel #iip-dev
+[00:34] <thecrypto> yes, but some people don't want IRC
+[00:35] <jrand0m> beefbroth> you're absolutely right, there's a lot of work to do, and I need to sleep at least 4 hours a night
+[00:35] <co> thecrypto: Good point, though I2P will anonymize people's IP addresses.
+[00:35] <beefbroth> jrand0m: i can help package when things are ready. I think that's a great way some non-developers with a bit of technical expertise can contribute.
+[00:35] <jrand0m> awesome beefbroth
+[00:35] <thecrypto> if we have IM and IRC, more adoption
+[00:36] <mihi> co: the problem is that with irc there is something to shut down (servers).
+[00:36] *** jeremiah (~jeremiah@anon.iip) has joined channel #iip-dev
+[00:36] <jrand0m> thecrypto> instant adoption: opennap
+[00:36] <beefbroth> it's easier to learn to make packages than to learn i2p datastructures. it's an easy way for a few people to get involved
+[00:36] <dm> IRC is quite tough though isn't it?
+[00:36] <dm> distributed IRC that is...
+[00:36] <co> mihi: Of course. I forgot that. Thank you for reminding me. Objection withdrawn.
+[00:37] <jrand0m> dm> irc can have multiple irc servers (ala efnet, etc) that talk to each other through i2p
+[00:37] <shardy> do you mean an "irc lookalike" chat protocol?
+[00:37] <shardy> or adapting irc?
+[00:37] <jrand0m> with people talking to each other by tunneling to one of the irc servers via i2p
+[00:37] <dm> irc with servers behind i2p is fine, I'm saying without servers. Doesn't matter I guess.
+[00:38] <jrand0m> dm> right, it can be done much better without servers, and some thought has been put into it, but nothing really solid (to my knowledge)
+[00:39] <dm> anyway, it's off-topic.
+[00:39] <dm> carry on!
+[00:39] <jrand0m> any other questions?
+[00:39] <jrand0m> anyone read the specs yet? ;)
+[00:39] <jrand0m> (other than beefbroth, who has them memorized)
+[00:39] * dm looks at the ceiling.
+[00:40] <jrand0m> ok, 100 minute meeting it is then
+[00:40] <thecrypto> i'm reading the, when i need something :)
+[00:40] <ChZEROHag> specs!
+[00:40] <ChZEROHag> That's what I forgot!
+[00:40] <jrand0m> heh
+[00:41] *** dm has changed the topic on channel #iip-dev to topic1
+[00:41] * jrand0m loads up and...
+[00:41] * jrand0m *baf*s the meeting to an end
+
\ No newline at end of file
diff --git a/pages/meeting60.html b/pages/meeting60.html
new file mode 100644
index 00000000..17b7ead4
--- /dev/null
+++ b/pages/meeting60.html
@@ -0,0 +1,277 @@
+
+
+[22:53] <jrand0m> 0.x) welcome
+[22:53] <jrand0m> 1.x) todo before i2p 0.2:
+[22:53] <jrand0m> 1.1) bw limiting
+[22:54] <jrand0m> 1.2) AES the tcp transport
+[22:54] <jrand0m> 1.3) package up [distro, building, seeding, running]
+[22:54] <jrand0m> 1.4) ElG session ack discussion
+[22:54] * hezekiah is away: Is off eating to keep up is strength for his upcoming tests
+[22:54] <jrand0m> 2.x) apps
+[22:54] <jrand0m> 2.1) ns
+[22:54] <jrand0m> 2.2) i2pim
+[22:54] <jrand0m> 2.3) i2ptunnel
+[22:54] <jrand0m> 3.x) ???
+[22:54] <jrand0m> 0.x) welcome
+[22:54] <jrand0m> welcome to meeting 60
+[22:54] <dm> thanks
+[22:55] <mihi> oh. 60. whe have something to celebrate ;)
+[22:55] * jrand0m hands out some beers
+[22:55] *** wiht (anon@anon.iip) has joined channel #iip-dev
+[22:55] * mihi does not like alcohol
+[22:55] <thecrypto> hi
+[22:55] * jrand0m takes back the german beer
+[22:55] <thecrypto> i'm not awake
+[22:55] <mihi> but not asleep either ;)
+[22:55] <jrand0m> heh interesting
+[22:56] <jrand0m> ok, 1.{x,1}) todo before 0.2
+[22:56] <thecrypto> i just remembered the meeting it today
+[22:56] <thecrypto> i was just discussing wireless cards
+[22:56] <jrand0m> the router is in pretty good shape, and I think 0.2 will be ready for internal dist and testing
+[22:57] *** Signoff: mihi (EOF From client)
+[22:57] <jrand0m> there are three things that need to get implemented first though. bandwidth limiting, AES on the TCP, and ElG session ack
+[22:57] <jrand0m> the bandwidth limiting will be classless for the moment - just one big honking input limit and output limit.
+[22:58] *** mihi_backup (~mihi@anon.iip) has joined channel #iip-dev
+[22:58] <jrand0m> the code is committed to tie it in, but the limit is set at infinity atm
+[22:58] <jrand0m> for point 1.2, the TCP transport has key exchange and authentication, but needs encryption
+[22:59] <jrand0m> nop/semi-awake-thecrypto> thoughts on AES for streaming?
+[22:59] <thecrypto> carefully
+[22:59] <jrand0m> !thwap
+[22:59] <thecrypto> sorry
+[23:00] * CounterRev eats popcorn in the grand stands
+[23:00] <jrand0m> CBC using first 16 bytes of H(sessionKey) work, or should we do something else?
+[23:00] <dm> I can't remember where that originated, exclamation mark before an action.
+[23:00] <thecrypto> i realized when the agenda started being pasted today was tuesday
+[23:00] <jrand0m> dm> some eggdrops use them as command identifiers
+[23:01] <thecrypto> why not use more bits from the DH for that?
+[23:01] <jrand0m> hmm?
+[23:01] <thecrypto> i don't see any problem for that
+[23:01] <thecrypto> for the IV
+[23:01] <jrand0m> more bits of what? X, Y, x, y?
+[23:02] *** mihi (mihi@anon.iip) has joined channel #iip-dev
+[23:02] <thecrypto> K
+[23:02] <dm> !thwap thecrypto
+[23:02] <thecrypto> what?
+[23:02] <dm> he said X,Y,x or y
+[23:02] <jrand0m> AES 256 only has a 16 byte K
+[23:02] <jrand0m> er, IV
+[23:03] <jrand0m> the session key is 32 bytes
+[23:03] <thecrypto> but you generate many more
+[23:03] <jrand0m> (originally I was stupid and made the IV the first 16 bytes of the key ;)
+[23:03] <thecrypto> so use 48 bytes from the DH
+[23:04] <dm> we all make mistakes.
+[23:04] <jrand0m> hmm ok, pulling more bytes off the modPow will work. cool. but why 48?
+[23:04] <jrand0m> (why not just another 16?)
+[23:05] <thecrypto> i meant 32+16
+[23:05] <jrand0m> ah 'k
+[23:06] <jrand0m> ok cool, CBC with that. if you or nop or someone else has time (userx?), we can get rekeying / rotating keys in there. but for the moment I'll get it CBC'ed w/ that IV
+[23:06] <jrand0m> (rekey would be just drop the connection and re-DH)
+[23:06] <jrand0m> ok, 1.3) packaging up for 0.2
+[23:07] <jrand0m> that just means a make / ant script, install / build doc, plus a method for distributing seed routerInfo references
+[23:07] <jrand0m> (plus, most likely, a set of a few routers for people to connect to)
+[23:08] <jrand0m> I hope to have 0.2 out and ready for people to d/l and install by this time next week, if not sooner
+[23:09] <jrand0m> the one last point holding up 0.2 is the ElG session ack
+[23:09] <dm> can we use 0.2 to talk to each other?
+[23:09] <jrand0m> yes dm
+[23:09] <dm> ok, that's useful.
+[23:10] <mihi> dm: is talking with you really useful? *veg*
+[23:10] <dm> (Killer App: Cyber Sex)
+[23:10] <jrand0m> 0.2 is definitely not even alpha, so it won't be for the faint of heart
+[23:10] <jrand0m> heh
+[23:10] <jrand0m> (but we need to get some testing and experience on some platforms and usage patterns other than my xp box here)
+[23:11] <dm> I'll take care of the marketing for I2P, I have a knack for it.
+[23:11] <jrand0m> lol
+[23:11] <dm> 0.2 code name: CyberSex, features, anonymous CyberSex through text.
+[23:11] <jrand0m> ok, the ElG session ack stuff.
+[23:11] <wiht> I can test on FreeBSD and Gentoo Linux.
+[23:11] <jrand0m> awesome wiht!
+[23:11] * popopopo can test Debian
+[23:11] <jrand0m> nice
+[23:12] <thecrypto> i can test on mandrake
+[23:12] * dm can test windows XP
+[23:12] <jrand0m> damn we're going to have pretty good coverage :)
+[23:12] * dm stands out from the crowd.
+[23:12] <popopopo> I can test win2k as well I think, although that should be about the same as XP I think
+[23:12] <jrand0m> hopefully
+[23:12] <dm> stick to unix popopopo
+[23:13] * thecrypto plays the trump: I can test win 98 :)
+[23:13] <jrand0m> uuuugh
+[23:13] * dm welcomes his little brother to the crowd.
+[23:13] <popopopo> I have an old DOS disk around here. Will java run on that? :)
+[23:13] <wiht> popopopo: Probably not.
+[23:13] <jrand0m> actually, probably.
+[23:14] <jrand0m> since gcc supports java
+[23:14] <jrand0m> and djgpp runs on dos
+[23:14] <popopopo> I2P on DOS, now that would be an accomplishment
+[23:14] <mihi_backup> popopopo: there is a commercial java version for DOS ;)
+[23:14] * jrand0m is currently hacking around with gjc to see if we can compile to native
+[23:14] <dm> Getting PPP working on DOS would be accomplishment enough.
+[23:14] <mihi> dm: use arachne.
+[23:15] <popopopo> gcj
+[23:15] <mihi> should work via parallel modem.
+[23:15] <nop> oh shit
+[23:15] <nop> it's tuesday
+[23:15] <nop> haha
+[23:15] <jrand0m> ah right popopopo... I always type it wrong
+[23:15] <mihi> oops, serial modem ;)
+[23:15] <jrand0m> wb nop ;)
+[23:15] <thecrypto> nop: you and me both
+[23:15] <nop> haha
+[23:16] <nop> sorry
+[23:16] <nop> my brain is fried this week
+[23:16] <nop> re-cooping
+[23:16] <nop> from this weekend
+[23:16] <thecrypto> nop: you and me both
+[23:16] <jrand0m> ok, the ElG ack stuff.
+[23:16] <jrand0m> (take 4)
+[23:16] * CounterRev could test xp as well "its running.. its running... its stopped"
+[23:17] <jrand0m> right now the ElG+AES works by using session tags - 32 byte tags prepended to AES streams to identify what session key to decrypt with
+[23:17] <mihi> and "it's bluescreened, it's autorebooting"
+[23:17] <jrand0m> (these tags are distributed in the streams, and the session keys are distributed in the ElG)
+[23:18] <jrand0m> the problem comes up if we lose the first ElG+AES, we've lost the session key as well as the initial set of session tags
+[23:18] <thecrypto> brb, playing magic
+[23:18] <jrand0m> so we need to make sure messages use ElG instead of AES with a session tag unless we know for sure the session key has been received
+[23:19] <jrand0m> there are lots of optimizations and tradeoffs here - one could always ElG and just forget about acks
+[23:19] <jrand0m> (trading cpu for bandwidth)
+[23:19] <jrand0m> or one could always require an ack for the first block, and then AES
+[23:20] <jrand0m> but that breaks if the recipient crashes and loses the session key
+[23:20] * nop is backlogging
+[23:20] <jrand0m> there are a few different patterns that can be used to implement these sessions
+[23:21] <jrand0m> what I'm probably going to go with is requiring an ack for the ElG message, using AES from then on, but every {$timeperiod, numMessages, bytes} send another ElG
+[23:22] <dm> like P frames in MPEG!
+[23:22] <jrand0m> 'k, I dont know the MPEG standard really
+[23:22] <dm> sorry, I frames.
+[23:23] <jrand0m> the thing is, these ElG messages are expensive. ~0.5-1.0 seconds
+[23:23] <jrand0m> (cpu time)
+[23:23] <jrand0m> though, hmm, we could precalculate them
+[23:23] <jrand0m> (if we don't rotate session keys)
+[23:23] <mihi> which cpu? ;)
+[23:23] <dm> sender or reciever cpu time?
+[23:24] <jrand0m> exactly mihi - mine. p4 1.7g. so we need some perf tuning on the algorithm
+[23:24] <jrand0m> both dm
+[23:24] <jrand0m> (.5 encrypt, .5 decrypt)
+[23:24] <jrand0m> (hand wavey approx)
+[23:24] * mihi has celeron 700
+[23:24] * dm has PIII 850
+[23:24] <jrand0m> cool. I'm also getting a sun ultra1 (150Mhz) in a few weeks
+[23:25] <dm> Why you getting a SUN?
+[23:25] <jrand0m> I'm leaving the option open for reevaluating our ElG keysize if we need to
+[23:26] <jrand0m> dm> its free (you can buy a u1 for ~50-100 USD). I also have a few sparc for various purposes
+[23:26] <dm> sweet.
+[23:27] <jrand0m> ok, unless anyone has any comments on the ElG stuff, on to agenda item 2.x...
+[23:27] <jrand0m> ok, 2.x) apps
+[23:27] <jrand0m> 2.1) ns
+[23:27] <jrand0m> wiht, how goes?
+[23:28] *** Signoff: mihi_backup (Ping timeout)
+[23:30] <wiht> I have not done any coding on the naming server this past week.
+[23:30] <wiht> I should say "of" the naming server.
+[23:31] <jrand0m> 'k, understandable.. what do you think your schedule looks like for the next few weeks for implementation? no committment or anything, just wondering
+[23:31] <wiht> But I will be working on it this week, and should have something more to report during the next meeting.
+[23:31] <jrand0m> cool, great
+[23:31] <CounterRev> what is i2p like sans ns?
+[23:32] <jrand0m> icq, I suppose
+[23:32] <wiht> I should be less busy during the next few weeks, and will have time for this. I cannot say when the naming server will be completed at this time.
+[23:32] <jrand0m> you need the secret number for contacting someone, but once you have it, you're ok
+[23:33] <mihi> CounterRev: lots of very long destination keys...
+[23:33] <jrand0m> CounterRev> I suspect someone will install a squid and an i2ptunnel on their router, allowing people to point at the destination and browse the web anonymously
+[23:33] *** mihi_backup (~mihi@anon.iip) has joined channel #iip-dev
+[23:33] <jrand0m> ok, 2.2) i2pim...
+[23:33] <jrand0m> thecrypto> you still playing magic?
+[23:34] <dm> i2pim, is that the name of the IM app?
+[23:34] <jrand0m> yup
+[23:34] <wiht> dm: Yes.
+[23:34] <dm> crap! i2m, Invisible Instant messaging.
+[23:34] <dm> i^2m, just like i^2p!
+[23:34] <jrand0m> sounds like there's a market
+[23:35] <mihi> dm: we had that discussion last meeting...
+[23:35] <dm> fine fine... I'll have to live with it.
+[23:36] <jrand0m> ok, thecrypto is probably still off. he'll post to the list if there's any news on the i2pim
+[23:36] <jrand0m> (i hope)
+[23:36] <jrand0m> ok, 2.3) i2ptunnel
+[23:36] * jrand0m waves to mihi
+[23:37] <wiht> jrand0m: I see that we have three applications being developed at this time. Have others been proposed?
+[23:37] <mihi> oops...
+[23:37] <mihi> but i have nothing to tell anyway ;)
+[23:37] <mihi> i2p is in cvs; look @ it ;)
+[23:37] <dm> mihi speaks in code.
+[23:38] <jrand0m> heh word. any updates since you added that config> command?
+[23:38] <dm> or rather, his code speaks for itself.
+[23:38] <mihi> i2ptunnel is in cvs i mean...
+[23:38] * nop proposes ex-lax for i2p
+[23:38] <mihi> jrand0m: nope.
+[23:38] <jrand0m> coo'
+[23:38] <jrand0m> would that be like a LaTeX clone nop?
+[23:39] <jrand0m> wiht> some various discussions, but those three have been the main ones discussed
+[23:39] <jrand0m> (the i2ptunnel enables a shitload of normal apps to operate over it)
+[23:40] <dm> has it been tested with anything?
+[23:40] <mihi> i2ptunnel has been tested extensively with the local router.
+[23:40] <dm> (not locally)
+[23:40] <jrand0m> I've done some web browsing with it, as well as ssh
+[23:40] <jrand0m> (browsing a single site, that is)
+[23:41] * wiht wonders if that website can still track people through cookies.
+[23:41] <dm> great.
+[23:41] <jrand0m> sure wiht, cookies are still sent
+[23:43] <jrand0m> ok, thats it for apps atm, and on to 3.x) ???
+[23:43] <jrand0m> any questions, thoughts, concerns, toenail clippers, hedgehogs?
+[23:43] <mihi> a pony? ;)
+[23:43] <jrand0m> yeah, I want a pony!
+[23:43] * dm raises his glass.
+[23:43] <mihi> nop will give you onw...
+[23:43] <dm> TO 0.2!!!
+[23:44] <jrand0m> oh yeah, mihi pointed out that in 17 minutes we miss the deadline I set in my flog a month ago
+[23:44] <jrand0m> to 1.0!
+[23:45] <mihi> 7 minutes ;)
+[23:45] <dm> so 2 weeks from now, we'll have 20 people on the network who'll be able to send texts to each other?
+[23:45] <jrand0m> I said we'd have an alpha out by end of september. well, it looks like we'll be a little late on that, but I think we're still making a good pace
+[23:45] <jrand0m> yes dm (and files, etc)
+[23:45] <nop> sickening
+[23:45] <jrand0m> there will still be room for performance improvements, of course. there hasn't been much tuning at all
+[23:45] <nop> sorry, I already spent my budget the next month
+[23:45] <dm> Alrighty, well if that happens, I will applaud.
+[23:45] <nop> pony has to wait
+[23:46] <jrand0m> damnit!
+[23:46] <nop> bought a grand piano instead
+[23:46] <nop> ;)
+[23:46] <jrand0m> heh nice
+[23:47] <mihi> jrand0m: here are some virtual ponies for you: (Link: http://tinyurl.com/p8kx)http://tinyurl.com/p8kx
+[23:47] <dm> estimated latency?
+[23:47] <dm> with network < 30 nodes?
+[23:48] <jrand0m> dm> depends on the sender and receiver's tunnel length
+[23:48] <dm> order of magnitude.
+[23:48] <jrand0m> (e.g. if they have 0 length tunnels, it'll be approx 400ms)
+[23:49] <dm> 0 length tunnels, don't know how I2P works, but 0 length doesn't sound good ;)
+[23:49] <mihi> or (Link: http://tinyurl.com/p8l7)http://tinyurl.com/p8l7
+[23:49] <jrand0m> if they have 2 hop tunnels, the latency should be ~ 1s
+[23:49] <dm> alrighty.
+[23:49] <dm> throughput?
+[23:50] <dm> harder to estimate?
+[23:50] <jrand0m> depends on bandwidth
+[23:51] <dm> Say X is the non I2P bandwidth between 2 nodes, through all the hops I2P uses.
+[23:51] <dm> what is the equation for Y(X) where Y is the throughput of I2P from one node to the other.
+[23:51] <jrand0m> I2P doesn't add a significant overhead to the size of the data
+[23:52] <dm> alrighty.
+[23:52] <dm> wait and see I guess.
+[23:53] <jrand0m> once she's up and running, we'll definitely get some modeling going on
+[23:53] <dm> aye..
+[23:54] * dm raises his glass.
+[23:54] <dm> To women!
+[23:54] <mihi> dm: you forgot to lower it first ;)
+[23:55] <dm> You germans...
+[23:55] <dm> You wacky germans.
+[23:55] <jrand0m> ok, I think thazzabout it
+[23:55] <dm> It's no suprise an american is leading us into the 21st century of anonymous networking.
+[23:55] * mihi /igs dm
+[23:55] <jrand0m> american?
+[23:56] <mihi> jrand0m is spanish i guess.
+[23:56] <dm> I was referring to you!
+[23:56] <mihi> or italian or sth in CET timezone.
+[23:56] <dm> jrand0m, the quiet american.
+[23:56] <wiht> dm: jrand0m seems to be a European.
+[23:56] <dm> !thwap mihi
+[23:57] <dm> !thwap wiht
+[23:57] <dm> jrand0m: your team members don't know you well.
+[23:58] * jrand0m thinks dm has been drinkin a lil too much, but its time for me to do the same.
+[23:58] * jrand0m raises the *baf*...
+[23:58] <dm> nice try jr!
+[23:58] * jrand0m *baf*s the meeting away
+
\ No newline at end of file
diff --git a/pages/meeting61.html b/pages/meeting61.html
new file mode 100644
index 00000000..fa519515
--- /dev/null
+++ b/pages/meeting61.html
@@ -0,0 +1,80 @@
++ +[23:04] <jrand0m> 0.0) welcome +[23:04] <jrand0m> 1.0) dev status +[23:04] <jrand0m> 2.0) new server +[23:04] <jrand0m> 3.0) questions? +[23:04] <jrand0m> 0.0) welcome to the 61st iip meeting +[23:04] <jrand0m> hi. +[23:04] <mihi> hi all +[23:04] <dm> hi you two ;) +[23:04] <jrand0m> ok, 1.0) dev status +[23:05] <jrand0m> we're pretty much ready for 0.2 - which is where people would be able to run i2p. +[23:06] <dm> great! +[23:06] <dm> ETA? +[23:06] <jrand0m> it won't scale, and it is currently implemented with the insanely secure style of the ElG+AES (rather than the optimized w/ session tags) +[23:06] <jrand0m> eta: a few days (related point: agenda item 2.0) +[23:07] <jrand0m> but it will be functional. I'm able to send messages of 10 bytes as well as 100K in ~10s +[23:07] <jrand0m> (both on the same CPU, so its cpu contention) +[23:07] <jrand0m> still some tunnel failback I'm working through, then its time to build the ant scripts, etc +[23:07] <jrand0m> actually +[23:08] <jrand0m> a few seconds ago I built everything using Kaffe 1.1.1 on freebsd with not even a warning. +[23:08] * jrand0m <3 not having to make changes to code +[23:08] <mihi> but it wasn't working either, was it? ;) +[23:08] <jrand0m> heh +[23:09] <jrand0m> no, it works +[23:09] <jrand0m> the prob I'm working through is a failover (aka if one is shut down and starts back up, comm recovers cleanly) +[23:10] <mihi> have you tried to send a complete ASCII table (bytes 0x00 to 0xFF)? And does it appear as it should on the other end? +[23:10] <jrand0m> not yet, havent tried i2ptunnel yet either. but shall tonight +[23:10] <mihi> try i2ptunnel with a binary connection (like ssh), no text based one. +[23:11] <jrand0m> 'k +[23:11] <mihi> what if a node shuts down and does not come up again? +[23:11] <jrand0m> then communication with it will fail ;) +[23:12] <jrand0m> (guaranteed delivery now fails correctly and the SDK has been patched to act on that) +[23:13] <jrand0m> ok, thats it for status atm. I've been pulled in other directions for the last two days, but that should be quieting down shortly. +[23:13] <jrand0m> 2.0) new server +[23:13] <jrand0m> we have a new server on a triple homed T3. +[23:14] <jrand0m> its going to host webcvs, a default i2p router, a webserver with seed router references, and a few default services (e.g. an i2p tunnel pointing at a squid instance, an i2ptunnel pointing at cvs, an i2ptunnel pointing at a webserver) +[23:15] *** Signoff: mihi (EOF From client) +[23:15] *** mihi_ (~mihi@anon.iip) has joined channel #iip-dev +[23:15] <jrand0m> i'll also be tossing on a public isproxy later +[23:15] <dm> damn, how much is that costing you? +[23:15] <jrand0m> 65/mo +[23:15] <jrand0m> 40Gb transfer, 2Gb data +[23:15] <dm> bandwidth limit? +[23:15] <dm> cool. +[23:16] *** mihi_ is now known as mihi +[23:16] <jrand0m> perhaps that server will become our cvs, but no need to switch right now. +[23:16] <jrand0m> ok, 3.0) questions +[23:17] <jrand0m> [yes, this has been the fastest meeting I've ever seen ;)] +[23:17] <mihi_backup> do you know anything about naming service progress? +[23:17] <jrand0m> I hear wiht has committed a few files, but I haven't checked them out yet +[23:17] <dm> I'd like to offer my (mental) support to all the developers. Stay humble yet determined. +[23:18] <mihi_backup> they are only dummies afaik. +[23:18] <jrand0m> clueless wankers, for sure. +[23:18] <mihi_backup> interfaces to implement against. +[23:18] <dm> dummies? +[23:18] <jrand0m> lol +[23:19] <dm> ah +[23:19] * jrand0m extends MyParents +[23:19] <mihi_backup> java does not allow multiple inheritance ;) +[23:19] <dm> no bastards... +[23:20] * jrand0m implements MyDad, MyMom // just seems wrong +[23:20] <mihi_backup> although you do not extend either your mother nor your father (see the liskov (sp?) substitution principle) +[23:20] * dm implements jrandom'sMom +[23:20] <dm> ;) +[23:20] <jrand0m> oh, good point mihi +[23:20] * dm now implements mihi'smother +[23:20] <jrand0m> heh +[23:21] *** Signoff: mihi (Ping timeout) +[23:21] <mihi_backup> you just need a constructor public Human(Human father, Human mother) throws SameSexException +[23:22] <dm> nice one +[23:22] <jrand0m> I think modern science requires a few more constructors +[23:22] <dm> although it's not public +[23:22] <dm> it's pubic +[23:22] *** mihi (mihi@anon.iip) has joined channel #iip-dev +[23:22] <dm> I crack myself up. +[23:23] <jrand0m> ok, on that note +[23:23] <jrand0m> I think we've just gotten away with a 23 minute meeting :) +[23:23] * jrand0m slips the *baf*er out of my back pocket and *baf*s the meeting closed +\ No newline at end of file diff --git a/pages/meeting62.html b/pages/meeting62.html new file mode 100644 index 00000000..baa8a913 --- /dev/null +++ b/pages/meeting62.html @@ -0,0 +1,286 @@ +
+[23:01] <jrand0m> agenda
+[23:01] <jrand0m> 0) welcome
+[23:01] <jrand0m> 1) 0.2 status
+[23:01] <jrand0m> 2) www proxy
+[23:01] * dm ponders.
+[23:02] <dm> oh, meeting?
+[23:02] <jrand0m> 3) phttprelay
+[23:02] <jrand0m> 4) i2ptunnel
+[23:02] <jrand0m> 5) installation
+[23:02] <dm> sorry.
+[23:02] <jrand0m> 6) iip feature request
+[23:02] <jrand0m> 7) ???
+[23:02] <jrand0m> 0) welcome
+[23:02] <jrand0m> hi.
+[23:02] <jrand0m> meeting 62? is it?
+[23:02] <Dellammo> hi
+[23:02] <jrand0m> (no worry dm, we can forgive you)
+[23:02] <mihi> hi jrand0m
+[23:02] <dm> hi mihi
+[23:02] * mihi thinks so
+[23:03] <jrand0m> 1) 0.2 status
+[23:03] * jrand0m has had a severe case of feature-creep-itis as of late, so the 0.2 release still has about 30 minutes left of code left to do.
+[23:04] <jrand0m> but then we'll be able to run and communicate reliably regardless of NAT, firewall, or HTTP proxy.
+[23:04] * dm has just created I2PSecureRemoteShell 1.0
+[23:04] <dm> cool jr!
+[23:05] <jrand0m> everything is functional, the only thing left to do is to expire unused database entries after N minutes (probably 5 for a default)
+[23:05] <jrand0m> the comm across NAT/firewall/HTTP proxy is the PHTTP transport. its slow, but reliable.
+[23:05] <dm> how does it work? what ports does it use?
+[23:06] <jrand0m> it sends the message to a reachable PHTTP relay, which stores the message, and then the receiver polls for messages ever N seconds
+[23:06] <jrand0m> there is a LOT that can be tuned and improved on that side of things, which is agenda point 3 :)
+[23:06] <dm> P stands for?
+[23:06] <jrand0m> Polling HTTP
+[23:06] <dm> ok thanks.
+[23:07] <jrand0m> I'm going to update the "kludges" page on the wiki after the meeting too, to note the things that are funky
+[23:07] <jrand0m> (such as not yet handling a lease change during communication)
+[23:08] <jrand0m> the other point to discuss is agenda item 5 - installation. aka how we should handle installation of the router/sdk/tunnel/etc
+[23:08] <jrand0m> ok, thats it for 0.2 status
+[23:08] <jrand0m> 2) www proxy.
+[23:09] <jrand0m> moi had a really cool idea for browsing in-i2p www sites.
+[23:09] <jrand0m> wanna explain whats up moi?
+[23:09] * jrand0m puts the spotlight on ya
+*** moi is ~someone@anon.iip (someone)
+*** on channels: #freenet #anonymous #iip #iip-dev
+*** on irc via server anon.iip (Official IIP )
+*** moi has been idle 9 minutes, signed on at Thu Jan 01 01:00:00 1970
+[23:10] <moi> well
+[23:10] <moi> i am just modifying an HTTP proxy and using mihi's tunnel
+[23:10] <moi> so that you can go to (Link: http://i2p/BASE64KEYHERE)http://i2p/BASE64KEYHERE
+[23:10] <moi> eventually the naming server would be there--
+[23:11] <dm> sweet
+[23:11] *** Signoff: mihi (Ping timeout)
+[23:11] <moi> you have to paste in the first long key, but after that you should technically be able to follow links I think
+[23:11] <Dellammo> so an internal web page or a page outside of i2p?
+[23:11] <dm> i2p resolves to localhost?
+[23:11] <moi> so someone could put up an i2p Google, and go from there.... mabye
+[23:12] <mihi-backup> !thwap dm.
+[23:12] <mihi-backup> a proxy...
+[23:12] <jrand0m> for security, the proxy should 404 all hosts other than (Link: http://i2p/)http://i2p/
+[23:12] <dm> oops!
+[23:12] <moi> good point
+[23:12] <dm> missed that part
+[23:12] <mihi-backup> although a simple servlet would be nice too
+[23:12] <jrand0m> hmm?
+[23:13] *** mihi (~mihi@anon.iip) has joined channel #iip-dev
+[23:13] <jrand0m> hmm, there may be a problem.
+[23:13] <jrand0m> this would use HTTP 1.0 or 1.1?
+[23:14] <mihi> if the server requests a Host: header?
+[23:14] <jrand0m> [aka, would it have a Host: header?]
+[23:14] <jrand0m> exactly
+[23:14] * mihi wishes for something
+[23:14] <moi> I wonder if we can have the proxy blank that out
+[23:14] <jrand0m> if the server's outbound tunnel is always on the same host, thats fine
+[23:14] <jrand0m> you can set the proxy Host: to 127.0.0.1
+[23:15] *** dm_backup (~as@anon.iip) has joined channel #iip-dev
+[23:15] <jrand0m> but then you must run the tunnel on the same host as the server. not a bad problem, as its not for general normal-web browsing
+[23:15] <jrand0m> right?
+[23:15] *** Signoff: dm (Ping timeout)
+[23:16] * moi hadn't thought that deeply into it yet
+[23:16] <mihi> if you run the server on your own box you can also alias i2p to localhost or sth like that.
+[23:16] <dm_backup> so do people have to run web servers now?
+[23:16] <jrand0m> dm_backup> this is only for people who want to.
+[23:16] *** dm_backup is now known as dm
+[23:16] <Dellammo> like me
+[23:16] <dm> yeah, I mean for this (Link: http://i2p)http://i2p thingie
+[23:17] <mihi> if you want to provide content, yes.
+[23:17] <mihi> but you have to run one to provide content in good ol' www as well.
+[23:18] <Dellammo> why?
+[23:18] <dm> Hmmm, maybe I should build a P2P app for I2P.
+[23:18] <jrand0m> a filesharing app over i2p would rule.
+[23:18] <dm> yes sorry, filesharing.
+[23:19] <moi> I think it would be possible for someone to run an OpenNap server in conjunction with i2ptunnel
+[23:19] <jrand0m> yes.
+[23:19] <jrand0m> (though a native i2p p2p would have better performance)
+[23:19] <mihi> but the downloads will be hard.
+[23:20] <mihi> no way to get to the correct host as all are localhost ;)
+[23:20] <dm> Let's wait till we see PING running over i2ptunnel first.
+[23:20] * Dellammo is confused are we talking about a proxy thats not i2ptunnel that lets you access webservers that are internal to the i2p network by typing '(Link: http://i2p/')http://i2p/' ?
+[23:20] <jrand0m> perhaps just a simple FTP client designed to run over i2p?
+[23:20] <dm> (not ping literally)
+[23:20] <mihi> jrand0m: ftp needs 2 ports...
+[23:20] <jrand0m> designed to run over i2p.
+[23:21] <jrand0m> a general file transfer app, not the FTP protocol, specifically
+[23:21] <mihi> then it's not ftp.
+[23:21] <mihi> ATalk ;)
+[23:21] <jrand0m> (taking advantage of larger message sizes)
+[23:21] <dm> battle of the wise men!
+[23:21] <jrand0m> heh
+[23:21] <moi> Dellammo: right now you have to create an i2ptunnel for each website/Destination you want to browse. We are thinking of using a proxy server that would dynamically build an i2ptunnel for each site.
+[23:22] <jrand0m> (kind of)
+[23:22] <jrand0m> you won't want to use an i2ptunnel, specifically.
+[23:22] <jrand0m> you'll want to use the i2ptunnel protocol, and send messages directly, not via TCP/IP sockets.
+[23:23] <jrand0m> mihi> any idea what kind of time it would take to factor the protocol functionality out of i2ptunnel so other apps could send data to an i2p tunnel?
+*** mihi is mihi@anon.iip (mihi)
+*** on channels: #iip-dev #iip #headlines #german #freenet-opn #freenet #fredisdead #frazaa @#fiw #anonymous
+*** on irc via server anon.iip (Official IIP )
+*** mihi has been idle 3 minutes, signed on at Thu Jan 01 01:00:00 1970
+*** mihi-backup is ~mihi@anon.iip (mihi)
+*** on channels: #iip-dev
+*** on irc via server anon.iip (Official IIP )
+*** mihi-backup has been idle 12 minutes, signed on at Thu Jan 01 01:00:00 1970
+[23:25] <mihi> is there any large protocol functionality? I2PTunnelRunner can be used as is.
+[23:25] <mihi> You just have to adjust the client class for your needs.
+[23:25] <jrand0m> hmm, not really - i2ptunnelRunner uses a socket
+[23:26] <jrand0m> this is a plain java app that wants to generate a message ("HTTP GET /\n\n") and send it to an outbound I2PTunnel
+[23:27] <jrand0m> we don't want to redirect the client contacting the proxy to a new port to connect to the newly instantiated I2PTunnel (as there'd be no way to switch back for links off that site)
+[23:28] <jrand0m> but perhaps switching I2PTunnelRunner to use an InputStream (all it uses is socket.getInputStream) would be easy...
+[23:28] <jrand0m> but then we still need the listen side
+[23:28] *** Signoff: mihi (Ping timeout)
+[23:28] <jrand0m> d'oh
+[23:28] * jrand0m hopes the backup isn't about to ping out...
+[23:28] <dm> backup's gonna die as well ,watch it!
+[23:29] <mihi-backup> ;)
+[23:29] <jrand0m> w00t
+[23:29] <mihi-backup> [23:25] <jrand0m> hmm, not really - i2ptunnelRunner uses a socket
+[23:29] <mihi-backup> [23:25] <mihi> oops, right. and you want to do it completely without sockets?
+[23:29] <mihi-backup> [23:26] <mihi> then there is not much code left from i2ptunnel. most is for handling the sockets.
+[23:29] <mihi-backup> [23:26] <mihi> best stick to the protocol and implement it yourself (build the messages w/ the static method in i2ptunnel.java)
+[23:29] <mihi-backup> [23:28] <mihi> http would not need that many threads. Just run a reader over the incoming message until a double return and then send your thing out.
+[23:30] <jrand0m> ah 'k. thanks
+[23:30] <jrand0m> moi> tu sabes?
+[23:30] <mihi-backup> re switching I2PTunnel for an input stream. what for? you won't get anythin on it any more after you parsed the request.
+[23:31] * moi thinks
+[23:31] <dm> toi thinks
+[23:31] <mihi-backup> just forget the tunnelrunner. ;)
+[23:31] <jrand0m> right, I was just thinking to keep the I2PTunnel and the http proxy to use the same code - I2PTunnel would use socket.getInputStream(), the http proxy would use new ByteArrayInputStream("GET / \n\n".getBytes())
+[23:31] *** mihi (mihi@anon.iip) has joined channel #iip-dev
+[23:32] * moi will need to go over this later in detail
+[23:32] <mihi-backup> but that will cause the runner to send a "Connection closed" when the string is sent.
+[23:32] <mihi-backup> as the stream ends.
+[23:32] <jrand0m> right, which is normal HTTP
+[23:33] <mihi-backup> just forget the runner, i said ;)
+[23:33] <jrand0m> 'k
+[23:33] <mihi-backup> jrand0m: nope. the connection is closed when the answer is here, not when the question is out.
+[23:33] <jrand0m> oh yeah
+[23:33] <jrand0m> ;)
+[23:36] <jrand0m> cool moi, we can work through this stuff later on.
+[23:36] <jrand0m> ok, thats agenda item 2). now for 3)
+[23:36] <moi> ok
+[23:37] <jrand0m> 3) phttprelay
+[23:37] <jrand0m> phttp relay is a set of servlets wrapped in a .war file
+[23:38] <jrand0m> it works out of the box on windows / sun JVM, but I had to hack jetty to run w/ kaffe
+[23:38] <mihi> make .peace not .war
+[23:39] * jrand0m groans
+[23:39] <dm> you can run .war files without a J2ee server?
+[23:39] <dm> good to know.
+[23:39] <jrand0m> .war files run in any servlet container - tomcat, apache w/ mod_jk, jetty, etc
+[23:40] <jrand0m> we're going to want some people to run these on machines w/ publicly reachable IP addresses, but they're only necessary for people who don't have publicly reachable addresses (like me)
+[23:41] <mihi> which ports do you need to redirect if you want to go through a nat without that?
+[23:41] <jrand0m> its implementation is very rudimentary as well - it needs some limits as to how many routers it relays for, how many messages it queues up, how long before it times out, etc
+[23:41] <jrand0m> just the I2NP TCP port
+[23:41] <jrand0m> (or the I2NP UDP port)
+[23:41] * mihi does not know if his nat allows udp forwarding
+[23:42] * jrand0m doesn't know if mihi's nat does either
+[23:43] <jrand0m> right now, for example, my laptop is reachable via PHTTP only, and my server's router is reachable via PHTTP, TCP, and UDP. if my laptop establishes a connection to the server's router via TCP, it can send messages via TCP. but if my laptop doesn't first do that, the server must send messages via PHTTP
+[23:44] <jrand0m> the code is in i2p/code/apps/phttprelay/ for anyone with servlets experience who wants to hack on a small app
+[23:45] <jrand0m> (it should also work transparently with https as well as plain http)
+[23:45] <jrand0m> I'll doc up the PHTTP protocol Real Soon Now. :)
+[23:45] *** Signoff: mihi (Ping timeout)
+[23:45] <jrand0m> ok, thats it for item 3) phttprelay
+[23:45] <jrand0m> 4) i2ptunnel
+[23:46] <jrand0m> we've already discussed a bunch of stuff. unless mihi (or anyone else) has anything else on it, we can move to 5)
+[23:46] *** wilde (~anon@anon.iip) has joined channel #iip-dev
+[23:46] <jrand0m> hola wilde
+[23:47] <jrand0m> ok. that said, item 5 :)
+[23:47] <jrand0m> 5) installation
+[23:48] <jrand0m> to get 0.2 out the door, and beyond, I'm thinking of some ant scripts.
+[23:48] <jrand0m> or should we use another open source installation system?
+[23:48] <jrand0m> anyone have any experiences / thoughts on this?
+[23:49] <Dellammo> hmm
+[23:50] <jrand0m> ant has the benefit of being unified with the build system, platform independent, and has headless operation.
+[23:50] <wilde> hey
+[23:50] <jrand0m> but it requires ant (which requires java). and it doesn't have a GUI
+[23:51] <Dellammo> i can think of many install programs for windows... i dont know how many are gpl though
+[23:51] <jrand0m> yeah, I have a licensed InstallAnywhere Enterprise installation, but its bad for open source
+[23:51] <jrand0m> NSIS is open source, but has its nuances.
+[23:51] <dm> stupid question: is ant included in java?
+[23:52] <jrand0m> nope.
+[23:52] <jrand0m> oh, though we COULD distribute a GCJ'ed ant
+[23:52] <dm> alright, must have come with eclipse then.
+[23:52] <jrand0m> (compiled to native code)
+[23:52] <jrand0m> definitely dm.
+[23:52] <jrand0m> apache makes ant (ant.apache.org) and its apache licensed.
+[23:52] <jrand0m> oh, yuck.
+[23:52] * jrand0m just read the sentence I typed)
+[23:53] <jrand0m> gpl is not apl friendly, according to the FSF
+[23:53] <jrand0m> we probably can't distribute ant.
+[23:53] <dm> can't we just a script? what needs to be done for it to be installed?
+[23:53] <jrand0m> but we can use it.
+[23:53] <jrand0m> not much at all. a script is fine.
+[23:53] <jrand0m> but do we want a .bat and a .sh, etc.
+[23:54] *** shardy (~shardy@anon.iip) has joined channel #iip-dev
+[23:54] <dm> what does an installation entail, a couple of questions?
+[23:54] <jrand0m> writing a java installer to do the install platform independent is overkill, so we should ideally use an existing install framework
+[23:54] <jrand0m> yeah, a few questions
+[23:54] <jrand0m> the installation targets I forsee:
+[23:54] <Dellammo> do we get a flashy new logo? whos working on that?
+[23:54] <jrand0m> install-router
+[23:55] <jrand0m> install-www-tunnel, install-www-proxy, install-sdk, install-cvs-tunnel, update-seednodes
+[23:55] <moi> why not use InstallAnywhere? if the code is open that is what matters
+[23:55] * jrand0m thinks YOU are Dellammo :)
+[23:55] <jrand0m> InstallAnywhere isn't open source.
+[23:55] * Dellammo gets to work
+[23:56] <dm> script would probably be enough at this point, but I guess might as well think ahead.
+[23:56] <jrand0m> (its about 4k euro / seat)
+[23:56] <jrand0m> right. so for tomorrow, I'll probably just write ant scripts, but we need to look into a system
+[23:56] *** Signoff: wilde (Ping timeout)
+[23:56] <jrand0m> so if anyone can help out with that, it'd be appreciated :)
+[23:57] <dm> ah okay, I was thinking shell scripts.
+[23:57] <moi> Some of the package managers could do that on the Linux installs
+[23:57] *** wilde (~anon@anon.iip) has joined channel #iip-dev
+[23:57] <jrand0m> managing different installers for different platforms is a PITA
+[23:59] <dm> java installer? Why is it a PITA?
+[23:59] <jrand0m> a java installer would be great
+[23:59] <mihi-backup> pain in the a**e
+[23:59] <mihi-backup> oops, sorry...
+[23:59] <dm> system.out.println("Please enter where you would like to install I2P") ;)
+[23:59] <mihi-backup> s/tln/t; s/P"/P: "/
+[23:59] <mihi-backup> s/sys/Sys/
+[00:00] <jrand0m> writing a custom installer in java is possible, but its preferred to use an existing framework. but if you're volunteering to write a custom installer, I'm behind ya!
+[00:00] <dm> mihi's having an epileptic seizure.
+[00:00] * mihi-backup slaps dm around a bit with a large trout
+[00:00] <dm> Tell you what...
+[00:01] <dm> If you have time at any point to write out the exact steps needed in an install, I'll write a java installer.
+[00:01] <mihi-backup> dm: read the ant script ;)
+[00:01] <jrand0m> word dm. once I get the ant thing working I'll doc 'er up for you
+[00:01] <dm> fair enough, we'll see if I can figure out the ant script once it's out.
+[00:02] *** Signoff: wilde (Ping timeout)
+[00:02] <Dellammo> jrand0m, i2p I2P i^2p or I^2P ?
+[00:02] * jrand0m has some scribbles with a capital I, 2 and a capital P all superimposed on each other...
+[00:03] <Dellammo> hmm
+[00:03] *** wilde (~anon@anon.iip) has joined channel #iip-dev
+[00:03] *** mihi (~mihi@anon.iip) has joined channel #iip-dev
+[00:03] <jrand0m> ok, thats 5) installation
+[00:03] <jrand0m> 6) iip feature request
+[00:04] <jrand0m> someone came on here with a request for auto-nicktheifing
+[00:04] <jrand0m> basically, if someone has registered a nick, no one can stay as that nick unless they're identified
+[00:04] <jrand0m> nop or anyone who has done iip dev - thoughts?
+[00:04] * jrand0m thinks it'd be a great feature to have
+[00:05] * Dellammo draws an illuminati eye with a no 'as in no smoking sign' over it
+[00:05] <jrand0m> heh
+[00:05] <dm> Maybe I'll make an I2P logo as well... for the gui part of my installer ;)
+[00:05] *** Signoff: wilde ((null))
+[00:05] <Dellammo> lets all make them, so we dont get stuck with a sucky logo
+[00:05] <mihi> jrand0m: ask mids - he maintains trent.
+[00:06] <mihi> the trent source is in cvs btw
+[00:06] <Dellammo> the logo is the most important part of any activity
+[00:06] <jrand0m> definitely Dellammo.
+[00:06] * dm dusts off Corel Draw...
+[00:06] <dm> man I love Corel Draw.
+[00:07] <jrand0m> ok, thats it for 6)
+[00:07] <jrand0m> 7) ???
+[00:07] <jrand0m> any questions / thoughts / frisbees/ toenails?
+[00:07] <dm> Thought: hope it works.
+[00:08] <jrand0m> heh
+[00:08] * jrand0m too.
+[00:09] <mihi> jrand0m: keep the good work!
+[00:09] <dm> yes, keep it up.
+[00:09] <jrand0m> good work? you obviously haven't seen the code ;)
+[00:09] <dm> Love your code, except for the bliding underscores.
+[00:09] <dm> blinding...bleeding..etc..
+[00:09] <jrand0m> heh, instance variables have _, so we don't ever need to do this.var = var;
+[00:10] <jrand0m> ok... 68 minutes... if I can drag this out for one more minute...
+[00:10] <jrand0m> w00t
+[00:10] * jrand0m *baf*s the meeting closed.
+
\ No newline at end of file
diff --git a/pages/meeting63.html b/pages/meeting63.html
new file mode 100644
index 00000000..c4a90135
--- /dev/null
+++ b/pages/meeting63.html
@@ -0,0 +1,182 @@
++
+[22:59] <dm> so when IS this meeting? +[23:00] <jrand0m> now. +[23:00] <jrand0m> 0) welcome [63] +[23:00] <jrand0m> 1) roadmap: (Link: http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap)http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap +[23:00] <jrand0m> 2) 0.2 todo: +[23:00] <jrand0m> - long lasting comm testing +[23:00] <jrand0m> - lease rebuilding bugs +[23:00] <jrand0m> 3) prng (yay) +[23:00] <jrand0m> 4) apps / questions / etc +[23:00] <jrand0m> 0) hi +[23:00] <jrand0m> sorry for being stupid and forgetting about daylight savings time +[23:00] <jrand0m> welcome to meeting #63 +[23:01] *** darl_mcbride has left #iip-dev +[23:01] <jrand0m> 1) roadmap +[23:01] <jrand0m> the roadmap is at the above url and will be updated whenever necessary. +[23:02] <jrand0m> yes, the dates are further out than they've been in the past, and thats largely a reflection of 1) me not wanting to release shitty software 2) me overlooking details in previous estimates +[23:02] <jrand0m> but, of course, as it says on the roadmap, "If you get involved and help out with some of the coding, things will go faster" :) +[23:03] <jrand0m> 0.2 itself will allow actual useful functionality +[23:03] *** Signoff: thecrypto (Ping timeout) +[23:03] <dm> that's good news. +[23:03] <jrand0m> ok, item 2) 0.2 todo +[23:04] <jrand0m> i've been doing qa on the 0.2 release for the last week or so and have been tracking down some bugs that have been hard to spot +[23:04] <jrand0m> but i think I found their source a few minutes ago, and I'm running a test against it right now in the background. +[23:05] <jrand0m> (the problem has been that after a few hours of use, communication with a router or a destination fails) +[23:05] <dm> what kind of testing rig are you using? Is it all local at this point? +[23:05] <jrand0m> three routers local, three routers remote +[23:05] <sisr> Does 0.2 include the feature that when a router is not able to be contacted after a certain number of times it stops trying? +[23:05] <jrand0m> yes +[23:06] <jrand0m> every router publishes its contact info every N (currently 2) minutes to everyone it knows. if a router doesn't get new contact info every 2.5*N minutes, it drops its reference. +[23:06] <jrand0m> however, if it /wants/ to find a new router (aka it gets a reference to it via a Lease), it can do a search at any time and find it +[23:07] <jrand0m> however, running three routers plus two active destinations locally is, well, a CPU beast. +[23:08] <jrand0m> I've added a nasty feature which I feel dirty about, but it lets you add an environmental variable to basically turn off ElG and AES encryption. thats only useful for communication with other nodes with the encryption turned off (as otherwise you wouldn't be able to talk) +[23:09] <jrand0m> ok, thats it for 0.2 todo +[23:09] <dm> for your testing purposes? +[23:09] <jrand0m> yeah basically +[23:09] <jrand0m> (and/or for anyone else who is doing their own testing to add new features / etc ;) +[23:10] <jrand0m> in theory however, two destinations (like atalk) could set the -Di2p.encryption=off flag and still work (though there wouldn't be any end to end encryption) +[23:10] *** thecrypto (~thecrypto@anon.iip) has joined channel #iip-dev +[23:10] <jrand0m> but i think thats a Bad Idea. +[23:11] <jrand0m> this feature will most certainly get pulled once the AES+SessionTag stuff gets worked out +[23:11] <jrand0m> ok, 3) prng +[23:11] <sisr> Are there any suggested minimum CPU and RAM requirements? +[23:12] <sisr> sorry +[23:12] <jrand0m> hmm, RAM is minimal (sun's JVM takes 7-10Mb, kaffe 16-22Mb) +[23:13] <jrand0m> CPU is definitely the limiting factor at the moment,but I don't have a wide array of boxes to test on ;) +[23:14] <jrand0m> let me just say that running three routers and two i2ptunnels pointing offsite to a squid on the same box pretty much hoses my P4 1.7Ghz box +[23:14] <thecrypto> i might be a little more active if you want me to say somethingh +[23:14] <dm> alright, say something. +[23:15] <jrand0m> hiya thecrypto :) +[23:15] <sisr> Why would anyone run more than one router on the same computer? +[23:15] <jrand0m> sisr> only a developer would. +[23:16] <sisr> Ok, so the CPU should not be too bad and we can run some tests over the weeks +[23:16] <jrand0m> word +[23:17] <jrand0m> ok, the prng stuff turned out to be a bug in kaffe, which is now fixed. +[23:17] <jrand0m> with that, we don't have any hard need to get a yarrow impl, as they use sha1prng +[23:18] <jrand0m> (but it'd be nice, whenever we get it) +[23:18] <jrand0m> ok, 4) apps / questions / etc +[23:18] <jrand0m> I don't have anything else, so... hi :) +[23:19] <jrand0m> any questions / thoughts / comments on anything else? +[23:19] <sisr> How is the naming server? I have not seen co for a long time +[23:19] *** co (anon@anon.iip) has joined channel #iip-dev +[23:19] <jrand0m> speaking of the devil +[23:19] <jrand0m> hi co +[23:19] <sisr> haha +[23:19] <co> Hello. +[23:20] <jrand0m> we're at that point where there's not really anything left on the agenda 'cept for questions +[23:20] <jrand0m> [23:19] <sisr> How is the naming server? I have not seen co for a long time +[23:20] <jrand0m> [23:19] *** co (anon@anon.iip) has joined channel #iip-dev +[23:20] <jrand0m> and that happened :) +[23:20] *** Signoff: godmode0 (EOF From client) +[23:21] <co> There has been no progress on it. I wrote just a small part of the client, and none of the server. +[23:22] <jrand0m> coo' +[23:22] * dm points the shame-stick at co. +[23:22] <sisr> I believe the HTTP i2p tunnel is working good now +[23:22] <sisr> i have adapt mihis excellent httpclient so that you type it into your proxy setting +[23:23] <jrand0m> aweseme! +[23:23] <sisr> it also does some simple filter of non i2p site +[23:23] <sisr> i think jrand0m has commit this already, yes? +[23:23] <jrand0m> do we know what browsers it works with? I know moz... +[23:23] <jrand0m> yeah, I think I committed that stuff.. lemmie check +[23:23] * co is appropriately ashamed. +[23:23] <sisr> It working with Mozilla and the Konqueror +[23:24] *** godmode0 (~enter@anon.iip) has joined channel #iip-dev +[23:24] <jrand0m> dont worry co, I'm already 2 months behind schedule +[23:24] <sisr> I will try to get the mihi I2P tunnel to work with E-mail server this week +[23:24] <sisr> Also many wiki pages have updated +[23:24] <jrand0m> oh yeah! thanks for that +[23:25] * jrand0m actually added a caveat to one of the FAQs this afternoon :) +[23:25] * dm decides to concentrate his awesome analytical brainpower towards determining where sisr is from. +[23:25] <dm> "Also many wiki pages have updated" +[23:25] <sisr> Ok go ahead +[23:25] <dm> mmmm.....MMmmmm.....mmmmmm... +[23:26] <dm> ah, another clue? +[23:26] <sisr> But I can not tell you if you are correct +[23:26] <dm> "..... has commit this already, yes?" +[23:26] <co> jrand0m: If this has not been asked already, do you want to release the I2P framework and applications as a package at the same time? +[23:27] <jrand0m> I've found that what I want and what happens isn't always the same thing +[23:27] <co> I mean release them together. +[23:27] <sisr> I have a question after co +[23:27] <jrand0m> the current plan is up at (Link: http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap)http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap +[23:28] <jrand0m> i2p itself will be the router and the sdk, but with it will be bundled any applications that are ready, whenever they're ready. +[23:28] <jrand0m> (the installer right now bundles the router, sdk, phttprelay, atalk, and i2ptunnel) +[23:29] *** Signoff: dm (Ping timeout) +[23:29] <jrand0m> 'sup sisr? +[23:29] <co> That page is quite helpful. Thank you. +[23:30] <sisr> The I2P is very big and it can be used to browse the WWW, to browse I2P Tunnel connect programs and web pages and If someone write a direct I2P webserver and client, can go without the tunnel +[23:30] <jrand0m> absolutely. +[23:30] <sisr> My question is how is the I2P developer target towards? Make everything working with I2P Tunnels so that users can have the programs They are already familiar with like IE or +[23:31] <sisr> Is it better to try and make I2P web server program, I2P web browser everything special for the I2P ? +[23:31] *** dm (~as@anon.iip) has joined channel #iip-dev +[23:32] <jrand0m> personally, I'd love if the former could happen. however, there will be performance gains by designing apps native to i2p +[23:32] <mihi> unix principle: one job, one tool. so don't write new browsers. +[23:32] <jrand0m> right +[23:32] <sisr> How much is the overhead of the I2P Tunnel? So we should focus on use the I2p Tunnel to get existing program to work +[23:32] <dm> one job, one tool? silly principle. +[23:33] <sisr> I believe we will need tutorial for people to set up Squid and E-mail proxy to the regular WWW. This is valuable and more than one or two is needed so this means Easy instructions for others to set up their own +[23:33] <jrand0m> sisr> the only significant overhead of i2ptunnel is its reliance on i2p's guaranteed delivery mode, which requires waiting for an ack message after each message sent (a full round trip through the pair of tunnels, using all appropriate encryption) +[23:34] <sisr> Haha, ok sisr has a very old computer +[23:34] <sisr> It seem real slow to me because of this +[23:34] <dm> what was latency like on the first few real tests? Just out of curiosity. +[23:35] <jrand0m> I can pull news.google.com with all images in ~ 30-60 seconds +[23:35] <dm> k +[23:36] <sisr> How difficult will it be to set up a Freenet like content distribution system on top of I2P? Is that major effort or minor effort? +[23:36] <co> And how much time does it take without the tunnel? +[23:36] <jrand0m> sisr> if I worked on it fulltime, I'd suspect ~ 1 month to get a DHT on top of i2p +[23:37] <jrand0m> co> ~ 10-15 seconds +[23:38] <co> So i2ptunnel is 3 times as slow. +[23:39] <jrand0m> well, i2ptunnel + the routers. but that is not a linear time - sending 10 bytes over i2p takes about as long as sending 100k +[23:39] *** Signoff: thecrypto (Ping timeout) +[23:39] <co> For you, at least. +[23:39] <jrand0m> the overhead is in the message wrapping +[23:39] <sisr> If the I2P tunnel is to be the core of most application for I2P then we should concentrate on the User interface and make easy to click option to set up tunnel +[23:40] <sisr> Like checkbox to set up I2P Tunnel web server with port, and Checkbox for E-mail server, so it real simple +[23:40] <jrand0m> sisr> I personally really really like its interface atm :) +[23:40] <jrand0m> oh, definnitely. actually +[23:40] * sisr has never seen the interface but imagines it like the textbox +[23:40] <sisr> Maybe someone can screencap the I2P tunnel for tutorial +[23:41] <jrand0m> what I was planning on is having the installer create a set of .bat and .sh scripts to do so automatically (e.g. java .... I2PTunnel -e 'config basdfawer' -e 'server ...' ) +[23:42] <sisr> What should we be working on for I2P now +[23:42] <jrand0m> thats a big question. short answer is "whatever you can" +[23:43] <jrand0m> if someone were to go ahead and update the installer to build those .sh and .bat scripts, that would rule +[23:43] <jrand0m> if anyone has time to work on some of the things on the i2proadmap, that would also rule :) +[23:44] <jrand0m> I think there's going to be a large demand for doc and qa once 0.2 is out (aka Real Soon Now) +[23:44] <sisr> How will the Installer be? Install shield or Java? +[23:44] <jrand0m> the current installer is a single "install.jar" which prompts the user through a few questions +[23:45] <jrand0m> its a really crappy installer +[23:45] <jrand0m> but its as platform independent as it gets +[23:48] <jrand0m> ok cool, the routers are still working, I think this bugfix may have done it. +[23:48] <jrand0m> oh yeah. +[23:48] <jrand0m> the mailing list will be back sometime +[23:48] <jrand0m> if it isn't back by the time 0.2 is ready, I'll create a new mailing list +[23:49] <co> I have one other question. +[23:49] <jrand0m> fire away +[23:50] <co> Is there a list available of I2P nodes running right now? +[23:50] <jrand0m> nope. +[23:50] <jrand0m> no public i2p nodes are open +[23:50] <co> I see. +[23:50] <jrand0m> however, one of them will make its list of peers available via http once 0.2 is released +[23:50] <jrand0m> (and the URL to that list will be in the installer) +[23:50] <jrand0m> s/will be/is/ +[23:52] <mihi> it's in my bookmarks as well... +[23:52] <jrand0m> heh bastard +[23:52] <mihi> btw: size=777 is 111 bytes too large ;) +[23:53] <jrand0m> rofl +[23:53] <jrand0m> I totally didn't notice that. +[23:53] <jrand0m> they used to be 384 +[23:53] <jrand0m> but then I added some router sw version info to the routerInfo +[23:53] <sisr> I think nop can use the I2P tunnel to set up a test IRC server with the 0.2 router? +[23:54] <jrand0m> that'd be really cool +[23:54] <sisr> I wonder how the latency comparing to this IIP if nop does that +[23:54] <jrand0m> though we wouldn't be able to dcc +[23:54] <jrand0m> i2p would be a lot higher latency +[23:54] <jrand0m> (as each send would be a few seconds, since we don't have AES+SessionTag yet) +[23:57] <jrand0m> ok, if anyone has anything to say before the list is back, either talk here or toss stuff up on the wiki +[23:57] <dm> k, night +[23:57] *** dm has left #iip-dev +[23:57] * jrand0m *baf*s the meeting closed +\ No newline at end of file diff --git a/pages/meeting64.html b/pages/meeting64.html new file mode 100644 index 00000000..81b2dfe7 --- /dev/null +++ b/pages/meeting64.html @@ -0,0 +1,197 @@ +
+(meeting log edited to cover up the fact that iip crashed midway through the meeting and there were lots of ping timeouts, so don't try to read this as a plain narrative) +
+
+ +[22:02] <jrand0m> agenda +[22:02] <jrand0m> 0) welcome +[22:02] <jrand0m> 1) i2p router +[22:02] <jrand0m> 1.1) status +[22:02] <jrand0m> 1.2) roadmap changes +[22:02] <jrand0m> 1.3) open subprojects +[22:02] <jrand0m> 2) native modPow +[22:03] <jrand0m> 2) gui installer +[22:03] <jrand0m> 3) IM +[22:03] <jrand0m> 4) naming service +[22:03] <MrEcho> i saw that .c code +[22:03] <jrand0m> 5) licensing +[22:03] <jrand0m> 6) other? +[22:03] <jrand0m> 0) welcome +[22:03] <jrand0m> hi. +[22:03] <nop> hi +[22:03] <jrand0m> meeting 2^6 +[22:04] <jrand0m> got any agenda items to add to there nop? +[22:04] <jrand0m> ok, 1.1) router status +[22:04] <jrand0m> we're 0.2.0.3 and last I heard, its functional +[22:04] <MrEcho> > 0.2.0.3 +[22:04] <MrEcho> right? +[22:05] <MrEcho> im running it .. seems fine +[22:05] <nop> no +[22:05] <jrand0m> there have been minor commits after the 0.2.0.3 release, nothing release worthy +[22:05] <nop> I am jus trying to catch up +[22:05] <jrand0m> coo' +[22:06] <jrand0m> given the experiences and feedback of 0.2.0.x, the roadmap has been updated to get things less resource intensive to run +[22:06] <jrand0m> (aka so people can run webservers / etc and it won't eat up their CPU) +[22:06] <jrand0m> specifically (moving to agenda 1.2): http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap +[22:06] <MrEcho> what ive noticed is that most routers use: TransportStyle: PHTTP +[22:07] <MrEcho> does it auto go to phttp or does it even try tcp first +[22:07] <jrand0m> hmm, most routers should support PHTTP, and if they can accept incomming connections, should support TCP as well +[22:07] <jrand0m> if at all possible it uses TCP +[22:07] <jrand0m> PHTTP is weighted about 1000 times more expensive than TCP +[22:08] <jrand0m> (see GetBidsJob, which asks each transport how much it thinks it'd cost to send a message to a peer) +[22:08] <jrand0m> (and see TCPTransport.getBid and PHTTPTransport.getBid for the values used) +[22:08] <MrEcho> ok +[22:08] <jrand0m> are you using PHTTP often to send and receive messages? +[22:09] <jrand0m> (that might be a sign that your TCP listener isn't reachable) +[22:09] <MrEcho> i didnt put in the urls on my side +[22:09] <jrand0m> ah 'k. +[22:09] <MrEcho> ohh it is +[22:10] <jrand0m> ok, yeah, my routers have open TCP connections to you +[22:10] <dm> how hospitable of them. +[22:10] * jrand0m is glad y'all made me implement routerConsole.html so we don't have to dig through the logs for this crap +[22:11] <MrEcho> is there a timeout thing if it doesnt connect to the tcp it goes phttp? and whatz the timing on it +[22:11] <jrand0m> but anyway, the big change to the roadmap is that 0.2.1 will implement the AES+SessionTag stuff +[22:11] <MrEcho> or could we have that in a setting? +[22:11] <jrand0m> if it gets a TCP connection refused / host not found /etc, it fails that attempt immediately, and tries the next available bid +[22:12] <MrEcho> so no retrys +[22:12] <jrand0m> phttp has a 30 sec timeout iirc +[22:12] <jrand0m> no need to retry. you either have an open TCP connection and can send the data or you don't :) +[22:12] <MrEcho> lol ok +[22:13] <MrEcho> will it try tcp everytime after that or skip that and just go phttp for the next connection? +[22:13] <jrand0m> it'll try tcp each time at the moment. +[22:13] <jrand0m> the transports don't keep histories yet +[22:13] <MrEcho> ok cool +[22:14] <jrand0m> (but if a peer fails 4 times they get shitlisted for 8 minutes) +[22:14] <MrEcho> well once the otherside gets the phttp msg it should connect to the router that sent the msg via tcp right? +[22:14] <jrand0m> correct. once any tcp connection is established, it can use it. +[22:14] <jrand0m> (but if both peers only have phttp, they'll obviously only use phttp) +[22:15] <MrEcho> that would mean that it couldnt est. a tcp connection to anything +[22:15] <MrEcho> .. but ya +[22:16] <MrEcho> i wish there was a way around that +[22:16] <jrand0m> no, one of my routers doesn't have a TCP address - only PHTTP. but I establish TCP connections with peers who have TCP addresses. +[22:16] <jrand0m> (and then they can send back messages along that TCP connection instead of sending me slower PHTTP messages) +[22:17] <jrand0m> or is that not what you mean? +[22:17] <MrEcho> ya i got mixed up +[22:17] <jrand0m> word, np +[22:18] <jrand0m> so, see the updated roadmap for updated schedule information ((Link: http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap)http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap) +[22:18] <jrand0m> ok, 1.3) open subprojects +[22:19] <jrand0m> I finally put a bunch of my palmpilot's todo list into the wiki at (Link: http://wiki.invisiblenet.net/iip-wiki?OpenSubprojects)http://wiki.invisiblenet.net/iip-wiki?OpenSubprojects +[22:19] <jrand0m> so if you're bored and looking for code projects... :) +[22:19] <MrEcho> gezz +[22:20] <MrEcho> already got 2 +[22:20] <dish> You have a palmpilot this is elite +[22:20] <MrEcho> mine died +[22:20] <jrand0m> mihi> there's a line item in there wrt the I2PTunnel describing a thought I had a lil while ago +[22:20] <MrEcho> dont know whatz up wit hit +[22:21] <jrand0m> yeah, I used to have palms but just recently had this one donated to the cause ;) +[22:21] <dish> Could there be an agenda item at the meeting to discuss when the last time userX typed something was +[22:21] <MrEcho> damm thing doesnt even turn on anymore +[22:21] <MrEcho> lol +[22:22] <jrand0m> I don't think UserX has said anything in 4 or 5 months ;) +[22:22] <MrEcho> is that a bot or something? +[22:22] <dish> What did they say 5 months ago? +[22:22] <MrEcho> i bet its a bitchx running on some box he use to have access to .. and forgot about it +[22:22] <jrand0m> that they'd get back with comments about the anonCommFramework (i2p's old name) next week ;) +[22:23] <dish> haha +[22:23] <jrand0m> but I suppose he's busy. so is life +[22:23] <jrand0m> ok, 2) native modPow +[22:23] <MrEcho> i saw that c code +[22:24] <jrand0m> i put together a stub .c and java class to show how something like GMP or another MPI library could be integrated, but it obviously doesn't work +[22:25] <jrand0m> what would be good would be if we had a small package of C classes and that trivial associated Java wrapper class that we could build for windows, osx, *bsd, linux, and package up under GPL + +(insert major iip breakage here) + +[22:38] <MrEcho> last thing i saw was: [13:25] <jrand0m> ok, 2) native modPow +[22:38] <jrand0m> hi MrEcho +[22:38] <jrand0m> yeah, looks like a main proxy crashed +[22:39] <jrand0m> I'm giving it another 2 mins before restarting +[22:39] <MrEcho> k +[22:39] <MrEcho> for $25 1 time i can get full on java on thenidus.net ... one of my sites +[22:40] <jrand0m> $25? they charge you to install software? +[22:40] <MrEcho> no idea really .. its a package +[22:40] <MrEcho> talking to my friend right now +[22:40] <jrand0m> I'm not sure the code is quite stable enough to go out and rent a bunch of colo spots to put up routers though. yet :) +[22:41] <dm> package of what? +[22:41] <MrEcho> java - jsp +[22:41] <jrand0m> ok, resending what I sent before: +[22:41] <jrand0m> i put together a stub .c and java class to show how something like GMP or another MPI library could be integrated, but it obviously doesn't work +[22:41] <jrand0m> what would be good would be if we had a small package of C classes and that trivial associated Java wrapper class that we could build for windows, osx, *bsd, linux, and package up under GPL (or less restrictive license) +[22:41] <jrand0m> however with the new roadmap placing AES+SessionTag as my current action item, this isn't quite as critical as it was. +[22:42] <jrand0m> if anyone wants to run with this though, that'd be great (and I'm sure another project we're all familiar with would be interested in such a packaging) +[22:43] <dm> frazaa? +[22:43] <jrand0m> heh, in a way ;) +[22:44] <jrand0m> ok, 3) gui installer +[22:44] <jrand0m> MrEcho> hi +[22:44] <MrEcho> :) +[22:44] <MrEcho> hehe +[22:44] <MrEcho> its comming alog +[22:44] <jrand0m> cool +[22:44] <MrEcho> nothing fancy +[22:45] <MrEcho> ive got some really cool ideas to make it really fancy .. but thatz a way off +[22:45] <jrand0m> I was wondering if the installer should add 1) an option to auto-get the seeds from http://.../i2pdb/ 2) auto-get the http://.../i2p/squid.dest and create a runSquid.bat/runSquid.sh too? +[22:45] <jrand0m> word +[22:46] <jrand0m> yeah, we want the installer to be as simple as possible - what fancy stuff were you thinking of? +[22:46] <MrEcho> question is .. when you do java -jar installer it goes to the non gui by default because of the way u have things +[22:46] <MrEcho> how are we going to make it to were you dbl click the jar file and it loads the gui +[22:47] <jrand0m> install.jar <-- nongui, installgui.jar <-- gui +[22:47] <jrand0m> seperate code, seperate packages +[22:47] <MrEcho> fancy as in things you might not notice .. but its goingto be nice and clean +[22:47] <jrand0m> cool +[22:47] <MrEcho> aww ok +[22:48] <jrand0m> (or install <-- gui installcli <-- cli. we'll see how things progress) +[22:49] <jrand0m> anything else on the gui, or do we jump off to item 4)? +[22:49] <jrand0m> (any time frame you're thinking? no pressure, just wondering) +[22:51] <MrEcho> no idea right now +[22:51] <jrand0m> coo' +[22:51] <jrand0m> ok, 4) IM +[22:51] <jrand0m> thecrypto aint here, so..... +[22:51] <jrand0m> 5) naming service +[22:51] <jrand0m> wiht isn't here either... +[22:51] <jrand0m> ping +[22:52] <dish> you're off on the number agenda count +[22:52] <dish> 3) IM +[22:52] <jrand0m> yeah, I used to have 2 agenda item 2's +[22:52] <dish> 4) Naming +[22:52] <dish> ;) +[22:52] <jrand0m> (native modPow and gui installer) +[22:52] <jrand0m> see, we're dynamic and stuff +[22:59] <jrand0m> ok, for the logs I suppose I'll continue +[22:59] <jrand0m> 6) licensing +[23:00] <jrand0m> I'm thinking about going less restrictive than GPL. we are using some MIT code, plus one other file is GPL (but thats just the base64 encoding and can be replaced trivially). other than that, all of the code is either copyright by either myself or thecrypto. +[23:00] * dish look at mihi i2p tunnel part of code +[23:01] <jrand0m> oh right, mihi has released that as gpl but he may want to release it as something else if he wants, as well +[23:01] <jrand0m> (but i2ptunnel is essentially a third party app and can license how it wants) +[23:02] <jrand0m> (though since the i2p sdk is gpl, he's been forced to be gpl) +[23:02] <MrEcho> damm about time +[23:02] <jrand0m> I don't know. licensing is not my forte, but I'm inclined at least to move to lgpl +[23:02] * dish release the 10-20 line of change to I2P HTTP Client mihi code as whatever mihi license is +[23:03] <jrand0m> hehe :) +[23:06] <jrand0m> anyway, 7) other? +[23:07] <jrand0m> anyone have any questions / concerns / ideas wrt i2p? +[23:07] <dish> Let me ask +[23:07] <dish> Does the I2P have any group name feature? +[23:07] <jrand0m> group name feature? +[23:07] <dm> team discovery channel! +[23:07] <MrEcho> lol +[23:08] <dish> So that if you want to have private or seperate network, but some router get intermixed somehow without group name the two network would merge +[23:08] <MrEcho> hes thinking of waste +[23:08] <jrand0m> ah +[23:08] <dish> I don't know why you would want that, but I am just ask in case +[23:08] <jrand0m> yes, early on in the network design I was playing with that +[23:09] <jrand0m> its more advanced than we need for now (or for the relatively near future [6-12 months]) but may be integrated later +[23:09] <dish> Or is that a bad idea because it is better to keep it one large network +[23:09] <dm> i2pisdead +[23:09] <jrand0m> heh dm +[23:10] <nop> shad up +[23:10] <jrand0m> no dish, its a good idea +[23:10] <dm> nop: tough guy? +[23:10] <jrand0m> its essentially what release 0.2.3 is -- restricted routes +[23:10] <jrand0m> (aka you've got a small private (trusted) set of peers and you don't want everyone to know who they are, but you still want to be able to communicate with them) +[23:15] <jrand0m> ok, anything else? +[23:15] <nop> nah, I'm just being funny +[23:18] <dm> funny guy? +[23:20] <jrand0m> ok, well, /interesting/ meeting, with a few iip crashes in the middle ;) +[23:21] * jrand0m *baf*s the meeting to a close +\ No newline at end of file diff --git a/pages/meeting65.html b/pages/meeting65.html new file mode 100644 index 00000000..3ed42447 --- /dev/null +++ b/pages/meeting65.html @@ -0,0 +1,623 @@ +
+
+
+[22:02] <jrand0m> agenda:
+[22:02] <jrand0m> 0) welcome
+[22:02] <jrand0m> 1) i2p dev status
+[22:02] <jrand0m> - 0.2.1.1 is out (peer and tunnel updating and testing, tuning enhancements, tunnel throttling, a DoS defense)
+[22:02] <jrand0m> - don't use bw limiting (still some debugging)
+[22:02] <jrand0m> - keep your clocks generally correct (30 minute fudge factor) [used for lease expirations and garlics]
+[22:02] <jrand0m> 2) kademlia, 0.3, and idn
+[22:02] <jrand0m> 3) roadmap revise (0.2.3 --> 0.4, 0.2.2 --> 0.3.1)?
+[22:02] <jrand0m> 4) app status [ppp2p, i2ptunnel, im, ns, squid]
+[22:02] <duck> 5) why does jrand0m drink cheap local beer?
+[22:02] <jrand0m> 5) comments / questions / etc
+[22:02] <jrand0m> heh
+[22:02] <jrand0m> so yeah, basically that fits under 5 :)
+[22:02] <mihi_> double 5 ;)
+[22:03] <mihi_> oops...
+[22:03] <jrand0m> 0) welcome
+[22:03] * mihi_ did not look 2 the left column
+[22:03] <jrand0m> hi. 65th meeting I suppose.
+[22:03] <jrand0m> hehe
+[22:03] <jrand0m> 1) that code stuff
+[22:04] <jrand0m> 0.2.1.1 came out last night
+[22:04] <jrand0m> lots of goodness in there.
+[22:04] * mihi tests it atm.
+[22:04] <jrand0m> tunnels are tested and fail fast, penalizing all participants so they won't likely get into the rebuild
+[22:05] <jrand0m> messages in i2ptunnel are also throttled to max 64k size (larger messages caused badness)
+[22:05] <jrand0m> there are some bugs being worked out with the bw limiting code, so make sure your bw limits in router.config are negative values
+[22:06] <jrand0m> (i2p doesn't have enough traffic on it to cause real load atm anyway)
+[22:06] <jrand0m> (but bw limiting will be unit tested and fixed for 0.2.1.2)
+[22:07] <jrand0m> also, please try to keep your clocks close to correct. it sucks that we have to need that, but right now we do.
+[22:07] <jrand0m> we may be able to work out a way to not require semi-sync'ed clocks, but its delicate.
+[22:07] <jrand0m> 2) fun stuff
+[22:08] <jrand0m> a lot of the bugs being worked out in the last few releases are related to the crappy kludge of a BroadcastNetworkDB.
+[22:08] <jrand0m> since its planned for replacement in 0.3, might as well at least mention what its being replaced with
+[22:09] <jrand0m> kademlia is a structured distributed hash table (DHT) that lets us insert and fetch in under O(log(N)) time, guaranteed
+[22:09] <jrand0m> [with one small caveat thats still being worked out]
+[22:10] <jrand0m> that kademlia code needs to get written for 0.3 so we can do insert and fetch of RouterInfo and LeaseSet structures.
+[22:10] <jrand0m> however, things would be simpler if it were implemented seperately - and hence testable seperately.
+[22:10] <jrand0m> (unit testing == good)
+[22:11] <jrand0m> so, whats a simple way to unit test a dht? to write a simple file store/lookup service on it.
+[22:11] <dm> insert fetch? are we talking about content?
+[22:11] <jrand0m> enter idn: (Link: http://wiki.invisiblenet.net/iip-wiki?I2PIDN)http://wiki.invisiblenet.net/iip-wiki?I2PIDN
+[22:11] <Ophite1> dm: No, only routerinfo and leaseset structures.
+[22:12] <jrand0m> dm> i2p's networkDatabase currently contains only two specialized structures, as ophite said
+[22:12] <dm> okay, thanks.
+[22:12] <Ophite1> may or may not be useful to use it for bootstrapping other protocols too, but it's not anonymous itself. (?)
+[22:12] *** grimps (~grimp@anon.iip) has joined channel #iip-dev
+[22:12] <tusko> one question: which protocol is used now for networkDatabase?
+[22:13] <jrand0m> sorry, phone.
+[22:13] *** Signoff: godmode0 (Ping timeout)
+[22:13] <jrand0m> correct, kademlia is not anonymous, but not non-anonymous either
+[22:13] <Ophite1> modified kademlia will scale. random will not.
+[22:13] <jrand0m> tusko> currently we do a flooded broadcast
+[22:13] <duck> what about kademlia getting splitted?
+[22:13] <dm> no cell phones allowed into meeting.
+[22:13] <duck> <insert zooko comments>
+[22:13] <Ophite1> flooded broadcast aka gnutella method definitely won't ;)
+[22:13] <jrand0m> Ophite1> right, kademlia doesn't use random ones :)
+[22:13] <duck> Ophite1: works better as freenet routing :)
+[22:14] <jrand0m> duck> exactly (<jrand0m> [with one small caveat thats still being worked out] )
+[22:14] <Ophite1> duck: i rest my case... ;)
+[22:14] *** Signoff: mihi (Ping timeout)
+[22:14] <tusko> is kademlia some sort of hypercube?
+[22:14] <Ophite1> no, a circle.
+[22:14] *** Signoff: mihi_ (Ping timeout)
+[22:14] <jrand0m> and/or a xor tree :)
+[22:15] <Ophite1> splits/joins... reshuffle tree? can we take a peek at emule's overnetalike for this? :)
+[22:15] <jrand0m> its a fairly easy protocol, but we can definnitely look around.
+[22:16] <jrand0m> icepick has implemented kademlia in python too, for ent (as kashmir)
+[22:16] *** mihi (~mihi@anon.iip) has joined channel #iip-dev
+[22:16] <Ophite1> consider also malicious nodes deliberately fragmenting the tree.
+[22:16] <jrand0m> absolutely. but its fairly attack resistant
+[22:16] <Ophite1> 256 bit keyspace is more resistant to that though.
+[22:17] <Ophite1> plus would have to make a lot of routeridentity structures = hard.
+[22:17] <tusko> i found interesting the papers of gravepine: (Link: http://grapevine.sourceforge.net/)http://grapevine.sourceforge.net/
+[22:17] <jrand0m> this is also why I want to implement it first as an application, rather than rip out the core of i2p - so we can work out all the messy details first
+[22:17] <Ophite1> so I'm pleased with sec 3 of 0.9 draft.
+[22:17] *** Signoff: nickthief54450 (Excess Flood)
+[22:18] *** nickthief54450 (~chatzilla@anon.iip) has joined channel #iip-dev
+[22:18] <tusko> look to (Link: http://grapevine.sourceforge.net/tech-overview.php)http://grapevine.sourceforge.net/tech-overview.php
+[22:18] <Ophite1> though I might point out that if message 0, DatabasePing, is inplemented, you might want to include a hashcash in it.
+[22:18] <jrand0m> interesting tusko, I think their economic model might require some revision, as with their sybyl defenses
+[22:19] <Ophite1> (you may already; haven't ready that part)
+[22:19] <jrand0m> absolutely Ophite1. I was actually thinking about putting hashcash certs into all of the messages (DatabaseLookup included)
+[22:20] <Ophite1> good idea. though, be careful of performance and tuning vs. dos defense there, and you might want to run hashcash calc in a separate, lower-priority thread?
+[22:21] <jrand0m> well, hashcash verification should be near instantaneous
+[22:21] <jrand0m> and hashcash generation shouldn't be able to be precompiled
+[22:21] <jrand0m> er, precomputed
+[22:21] <dm> Ophite1 must be an avatar created by jrand0m so that he can finally talk about I2P with someone who understands wtf he's saying.
+[22:22] <jrand0m> lol
+[22:22] * dm is not fooled.
+[22:22] *** godmode0 (~enter@anon.iip) has joined channel #iip-dev
+[22:22] <Ophite1> one way of preventing that is to use derivatives of session keys as part of the hashcash..
+[22:22] <jrand0m> right. and/or put in a nonce and the date
+[22:22] <Ophite1> date leads to those troublesome timing problems though. that could be a real issue.
+[22:22] <Ophite1> unless you feel like rewriting ntp as well ;-)
+[22:22] *** Signoff: mihi (Ping timeout)
+[22:23] <jrand0m> heh
+[22:23] <jrand0m> well, we've already run into that a little bit
+[22:23] <jrand0m> (hence the 30 minute fudge factor)
+[22:23] <jrand0m> a session hash may be workable though. good idea.
+[22:24] <Ophite1> and no, i'm not jrand0m's clone ;)
+[22:24] <jrand0m> ok, so for idn, I'm probably only going to implement the stuff on that I2PIDN wiki page
+[22:25] *** Signoff: dm (Ping timeout)
+[22:25] <jrand0m> what would probably rule would be if someone would take that and run with it - make a real user interface, better get/store apps, fec/ecc/etc.
+[22:25] <jrand0m> also, I had some ideas about a search network built in parallel as well
+[22:26] <jrand0m> but, well, its probably more useful to i2p that I focus my time on the router
+[22:26] <Ophite1> it runs on top of i2p?
+[22:26] <jrand0m> (making it functional, scalable, and secure)
+[22:26] <jrand0m> yes
+[22:26] <jrand0m> i2p lets idn be anonymous
+[22:27] <Ophite1> what were your search network ideas?
+[22:27] <jrand0m> note: its not written yet, but its looking like its #2 on my task list
+[22:27] <Ophite1> can another dht be built through tunnels?
+[22:27] *** mihi (~mihi@anon.iip) has joined channel #iip-dev
+[22:27] <jrand0m> basically a distributed replicated db, with hashcash inserts and syncs, where people store idn keys along side metadata / etc
+[22:27] *** dm (~as@anon.iip) has joined channel #iip-dev
+[22:28] <jrand0m> hmm, yes, certainly. but i2p isn't inherently tunnel based - its message based (i2p is IP, i2ptunnel is TCP)
+[22:28] <Ophite1> if ~all node participate = very useful for "discovering" other protocols.
+[22:28] <jrand0m> definitely
+[22:28] <Ophite1> so, should be standard.
+[22:28] <Ophite1> dhcp/zeroconf for the i2p? :)
+[22:28] <jrand0m> idn would be a very good app to bundle with i2p to let people have an 'out of box experience'
+[22:29] <Ophite1> If it's meant to be a fully featured communication/file transfer/storage application, I'd like to propose the name "Darknet".
+[22:29] <jrand0m> :)
+[22:29] <Ophite1> You, of course, probably already know where that comes from. :)
+[22:30] <dm> Where does it come from?
+[22:30] <Ophite1> MS Research's paper: The Darknet and the Future of Content Distribution.
+[22:30] *** Signoff: godmode0 (Ping timeout)
+[22:30] <TC> link?
+[22:30] *** tonious (~Flag@anon.iip) has joined channel #iip-dev
+[22:30] <jrand0m> well, tim may says he invented the term ~11 years ago ;)
+[22:30] <tusko> where is the I2PIDN wiki page?
+[22:30] <dm> (Link: http://crypto.stanford.edu/DRM2002/darknet5.doc)http://crypto.stanford.edu/DRM2002/darknet5.doc
+[22:30] <jrand0m> tusko> (Link: http://wiki.invisiblenet.net/iip-wiki?I2PIDN)http://wiki.invisiblenet.net/iip-wiki?I2PIDN
+[22:30] <Ophite1> also implies that the network works "in the dark" - noone knows who anyone is ;)
+[22:30] <jrand0m> exactly.
+[22:31] *** mihi_ (~mihi@anon.iip) has joined channel #iip-dev
+[22:31] <jrand0m> well, i2p itself is a darknet in that sense, but its generic messaging - it is the IP layer for such a darknet.
+[22:31] <jrand0m> i2ptunnel is the TCP layer, and idn is NFS :)
+[22:31] <Ophite1> i2p is the protocol that allows such a network to be created from something broadly like overnet.
+[22:31] <Ophite1> speaking of which... is there a way to specify priority in messages?
+[22:32] *** mihi is now known as nickthief76430
+[22:32] *** mihi_ is now known as mihi
+[22:32] <jrand0m> funny that you mention that :)
+[22:32] *** nickthief76430 is now known as mihi_backup
+[22:32] <mihi> oops...
+[22:32] <jrand0m> I was just reading some of the upcoming HotNets2 papers ((Link: http://nms.lcs.mit.edu/HotNets-II/program.html)http://nms.lcs.mit.edu/HotNets-II/program.html) and got inspired for some QoS over i2p mechanisms
+[22:33] <Ophite1> would a bulk/low-latency bit compromise anonymity slightly (intersection attack?) by allowing traffic linkage? well, even if it were sometimes flips?
+[22:33] <Ophite1> ah, well that might work better of course =)
+[22:33] <Ophite1> Don't worry about local plausible denability.
+[22:33] <jrand0m> right, i2p assumes the local machine is trusted
+[22:33] *** Signoff: dm (Ping timeout)
+[22:33] <Ophite1> That is a problem to be solved by Rubberhose/Marutukku and Thermite, not I2P.
+[22:34] <jrand0m> exactly. (otherwise, the software is compromised and it doesn't matter what we do)
+[22:34] * TC hopes his local machine is trusted
+[22:34] <jrand0m> heh
+[22:34] <Ophite1> TC: easy way to find out; make death threats against bush and see if SS agents turn up at your door ;-)
+[22:34] <jrand0m> lol
+[22:34] <TC> done and done
+[22:34] *** Signoff: tonious (Ping timeout)
+[22:34] <jrand0m> hah!
+[22:35] * jrand0m watches my squid proxy get taken down by the fbi
+[22:35] <TC> its a trap!
+[22:35] <jrand0m> get an axe!
+[22:35] <jrand0m> :)
+[22:35] <TC> anybody play uplink?
+[22:35] <Ophite1> completed it. cracked it. released it.
+[22:35] <Ophite1> trained it too ;)
+[22:36] * jrand0m takes that as a "yes"
+[22:36] *** dm (~as@anon.iip) has joined channel #iip-dev
+[22:37] <Ophite1> there may be some dos possibilities in caching, in memory stuff...
+[22:37] <jrand0m> ok, so thats what I'm thinking with idn/kademlia. get idn implemented and working over the 0.2. code, smash it in a bit, then implement 0.3 with that kademlia implementation
+[22:37] <jrand0m> oh certainly. the todo list has 'sync pending and large messages to disk' :)
+[22:37] <dm> shouldn't IDN be implemented after I2P is tested and mature?
+[22:38] <jrand0m> thats one of the problems we ran into testing a large file of TC's eepsite
+[22:38] <Ophite1> dm: not given as it's a testbed for the fancy db.
+[22:38] <jrand0m> dm> I was thinking that too, but I need to implement the kademlia code to get 0.3 ready. basically the kademlia code IS 0.3
+[22:38] <Ophite1> I do like the hybrid dht nature such a network would provide though.
+[22:39] <dm> aha...
+[22:39] <jrand0m> but if no one wants to toss a normal UI onto it until i2p 1.0, that might be a good idea as well
+[22:39] <Ophite1> dht node discovery + ngr-like routing = scalability capable of handling critical mass
+[22:39] <dm> what happened to that original milestone list. secure-->anonymous-->not harvestable, etc...
+[22:39] <Ophite1> jrand0m: I will refrain from advertising it to pirates until it's ready. that enough?
+[22:39] <jrand0m> well, minus the ngr-like routing :) we tunnel :)
+[22:39] <TC> as long as we keep the cli
+[22:39] <dm> ah scalable was one of the items in that chain.
+[22:39] <jrand0m> dm> 0.3 is necessary for scalable. which is before not harvestable
+[22:39] <jrand0m> thanks Ophite1 :)
+[22:40] <jrand0m> definitely TC. I'll need the cli to test it
+[22:40] <Ophite1> scalability of the actual anonymous stuff is directly related to choices made in the routing for the tunnels, and that's a router implementation thing?
+[22:40] <jrand0m> (and, c'mon, we'll probably do software distribution / releases with idn)
+[22:40] *** godmode0 (~enter@anon.iip) has joined channel #iip-dev
+[22:40] <dm> alrighty... sounds okay then.
+[22:40] <jrand0m> absolutely ophite.
+[22:40] <Ophite1> suggestion: maximum message size?
+[22:40] <jrand0m> thats the Hard problem
+[22:41] <jrand0m> max message size is currently insanely large (4g) but I'm thinking of trimming it to 64k or 128k
+[22:41] <jrand0m> but I don't want to resort to that yet
+[22:41] * Ophite1 goes digging in notes
+[22:41] <Ophite1> BitTorrent/Scone scalability notes indicate 512K.
+[22:42] <jrand0m> heh ok cool. (any refs I can dig into?)
+[22:42] <Ophite1> but, think of it like tcp window size.
+[22:42] <jrand0m> right
+[22:42] <Ophite1> not for scone, sorry - friend's research project.
+[22:42] <jrand0m> coo', no worry
+[22:42] *** Signoff: mihi_backup (Ping timeout)
+[22:42] <Ophite1> fwiw, your kademlia is about as good as his though :)
+[22:42] <jrand0m> hehe
+[22:42] <jrand0m> (well, I haven't implemented it yet ;)
+[22:42] <Ophite1> uh, hers I mean :/
+[22:42] <jrand0m> oh wikked
+[22:43] <dm> boner..
+[22:43] *** mihi_backup (~mihi@anon.iip) has joined channel #iip-dev
+[22:43] <jrand0m> heh
+[22:43] <jrand0m> so, thats 2) kademlia, 0.3, and idn
+[22:43] <Ophite1> she named her toys after puddings. custard, crumble (Waste-like), strudel.. her bittorrent-a-like was the fastest pudding in the world - 'scone ;)
+[22:43] <jrand0m> haha
+[22:45] <Ophite1> she's a math.
+[22:45] <jrand0m> even better
+[22:45] <jrand0m> there's a lot of stats gathering / analysis that will be coming up for advanced peer selection
+[22:45] <Ophite1> but I'll see if I can bounce stuff past her. scalability from i2np 0.9 was from her - she likes it.
+[22:45] <jrand0m> (unfortunately we can't cheat like mnet, mixminion, and tor)
+[22:46] <jrand0m> great to hear
+[22:46] <Ophite1> one comment - dsa?
+[22:46] *** nickthief54450 (~chatzilla@anon.iip) has joined channel #iip-dev
+[22:46] <Ophite1> dsa 1024 bit, as in SHA-1?
+[22:46] <jrand0m> yea
+[22:47] <Ophite1> 'spose it is tried and tested.
+[22:47] <Ophite1> also small.
+[22:47] <jrand0m> right. but I'm not 100% tied to our particular crypto impls
+[22:47] <Ophite1> anyway. to roadmap.
+[22:47] <TC> haha, lets name a windows version 'Microsoft Darknet (r)'
+[22:47] <jrand0m> heh tc
+[22:48] <jrand0m> ok, 3) roadmap revise (0.2.3 --> 0.4, 0.2.2 --> 0.3.1)?
+[22:48] <jrand0m> because of all the bugs I've been running into wrt the broadcast db, I want to escalate the 0.3 (kademlia db) release
+[22:48] <TC> its nice not being limmited by trademarks like a normal open source project
+[22:49] *** tonious (~Flag@anon.iip) has joined channel #iip-dev
+[22:49] <jrand0m> 0.2.3 is restricted routes / trusted peers, and probably not a hard feature requirement that anyone here has. it can be shuffled out to 0.4 without problem, I think
+[22:50] <jrand0m> 0.2.2 is tunnel mods, but I think a lot of the pressure to get that implemented will be eased with the 0.2.1.1 release (which tests and rebuilds tunnels as necessary, rather than waiting 10 minutes)
+[22:50] <Ophite1> trusted peers is an area that needs some revision imho.
+[22:50] <jrand0m> agreed.
+[22:50] *** dm_backup (~as@anon.iip) has joined channel #iip-dev
+[22:50] <Ophite1> only area that doesn't give me warm fuzzies.
+[22:50] <Ophite1> though that may just be the word "trusted". :)
+[22:50] <jrand0m> basically my current thoughts are to publish tunnels to routers
+[22:50] <jrand0m> heh
+[22:51] <jrand0m> (if we publish tunnels to routers, we can get away with untrusted gateways, which drops the 'trusted' from trusted peers)
+[22:51] *** Signoff: dm (Ping timeout)
+[22:51] *** dm_backup is now known as dm
+[22:51] <Ophite1> need to analyse anonymity implications of that.
+[22:51] <jrand0m> but trusted peers is inherently necessary in a militant grade anon system, where /all/ nodes you can contact are considered attackers.
+[22:52] <Ophite1> don't think that is truly possible...
+[22:52] <jrand0m> certainly. yet another reason it should get 0.4
+[22:52] <jrand0m> Ophite1> trusted nodes with timed / triggered self destruct.
+[22:52] <jrand0m> set up a patsy, route through it, kill it
+[22:52] <jrand0m> exactly, if patsies delete their logs after N hours / N bytes / N messages
+[22:52] <Ophite1> I mean if you want me to release a worm that sets up a couple of million...
+[22:53] <Ophite1> logs? what logs?
+[22:53] <jrand0m> :)
+[22:53] <jrand0m> ok, format the disks ;)
+[22:53] * Ophite1 wrote kernel-level stealth trojan
+[22:53] <jrand0m> nice
+[22:53] * dm wrote kernel level outlook calendar plugin.
+[22:53] <Ophite1> ...when I was 19 :)
+[22:53] <Ophite1> still works. :)
+[22:54] <Ophite1> not going to include it in this though, don't worry, or, uh, check my code, which would probably be a Good Thing To Do anyway ;)
+[22:54] <dm> when I was 12.
+[22:54] <jrand0m> I don't think i2p will want /that/ large distribution until after 1.0 is stable and heavily peer reviewed
+[22:54] <jrand0m> heh Ophite1
+[22:54] <jrand0m> heh dm
+[22:54] <Ophite1> frankly, think that is a fluff feature.
+[22:54] <jrand0m> perhaps.
+[22:55] <jrand0m> restricted routes is a necessity though
+[22:55] <jrand0m> its basic functionality for people behind firewalls
+[22:55] <jrand0m> (very restrictive firewalls)
+[22:55] <Ophite1> hello, transports.
+[22:55] <Ophite1> we'll get to that.
+[22:55] <Ophite1> or is now the appropriate time to discuss them?
+[22:55] <jrand0m> sure, lets dig in :)
+[22:56] <jrand0m> we've already run into a problem with an unreachable peer that could be solved with restricted routes
+[22:56] *** tusko has left #iip-dev
+[22:56] <jrand0m> even though it was due to misconfiguration, it could be more common
+[22:57] <Ophite1> Also: given two cooperating peers behind inbound-filtering firewalls that drop bad packets, and one cooperating peer which is not behind a firewall and can send packets with forged IP source addresses to both of the other peers...
+[22:57] <Ophite1> You can establish a TCP connection between the two firewalled peers that both firewalls think is outbound.
+[22:57] <jrand0m> definitely
+[22:57] <dm> forged IP addresses?!?
+[22:58] <Ophite1> believe me, firewalls are a VERY common problem.
+[22:58] <Ophite1> sometimes they are user-controlled but the user is a doofus. that can be handled with the installer handling the firewall :)
+[22:58] <dm> I2P is gonna use IP spoofing? :)
+[22:58] <jrand0m> definitely. if i2p can't operate behind firewalls / NATs / proxies, there's no reason to continue.
+[22:59] <Ophite1> sometimes they are actively hostile, corporate or educational gateways seeking to deliberately mess up everything. It's got to traverse those, and traverse them cleanly.
+[22:59] <jrand0m> dm> transport options
+[22:59] <jrand0m> absolutely Ophite1
+[22:59] <Ophite1> dm: I have a working implementation - in the Direct Connect protocol.
+[22:59] <jrand0m> i2p wants to be the battleground for that code.
+[22:59] <Ophite1> dm: If *that* can handle it, i2p can.
+[22:59] *** Signoff: tonious (Ping timeout)
+[23:00] <Ophite1> I suggest leaving it turned off by default though. Only a very few want it turned on, and it would be nice if they can advertise which they are so requests can be routed to them.
+[23:00] <dm> you can't spoof IPs without native code can you?
+[23:00] <Ophite1> the advantage is that they don't have to route *through*, just help the setup.
+[23:00] <Ophite1> = massive speed boost.
+[23:01] <jrand0m> definitely Ophite1, thats what the RouterInfo.routerAddress[] structure is for
+[23:01] <Ophite1> dm: yeah, like this isn't going to be rewritten?
+[23:01] *** tonious (~Flag@anon.iip) has joined channel #iip-dev
+[23:01] <dm> okay, just checking...
+[23:01] <jrand0m> right dm, I have no qualms whatsoever with including native code in i2p
+[23:01] <Ophite1> I would like to state that I don't think java is a permanent solution.
+[23:01] <Ophite1> And that I regard java router as testbed/prototype.
+[23:01] <jrand0m> thats fine. if it gets us to 1.0, works out the protocol, etc, good enough.
+[23:02] <Ophite1> ...and hope it doesn't get stuck there as freenet has ;)
+[23:02] <dm> IPAddress.Spoof(192.168.32.1);
+[23:02] *** alient (alient@anon.iip) has joined channel #iip-dev
+[23:02] <jrand0m> lol dm
+[23:02] <dm> import IPSpoofing;
+[23:02] <Ophite1> mmm... raw sockets in java ;)
+[23:02] <jrand0m> fcntl / ioctl in java... mmMMmm
+[23:02] <mihi> hmm, raw sockets require root on unix, don't they?
+[23:02] <dm> women with large breasts lickig my penis.. mmMMmmm
+[23:02] <jrand0m> so we include a rootkit
+[23:03] <jrand0m> ;)
+[23:03] <Ophite1> jrand0m: got it covered =)
+[23:03] <jrand0m> heh
+[23:03] <Ophite1> besides as I said; only a few need it.
+[23:03] <jrand0m> right
+[23:04] <jrand0m> and only for legitimate reasons, of course.
+[23:04] <Ophite1> on my dc hub, only one (bot) had the capability, and the hub told it when passives wanted to connect to passives.
+[23:04] <Ophite1> caused a bit of amazement that did.
+[23:04] <jrand0m> hehe
+[23:04] <Ophite1> also got the bot's host shut down, hence my suggestion to perhaps turn it off by default :)
+[23:04] <jrand0m> thats definitely a good feature to have avail
+[23:04] <jrand0m> lol
+[23:05] *** Signoff: nickthief54450 (Excess Flood)
+[23:05] <jrand0m> ok, so with restricted routes pushed to 0.4, we have a month or so to continue the debate as to whether the functionality is necessary
+[23:06] <jrand0m> any other thoughts / things that should be in the roadmap that aren't, things that are in the wrong place, etc?
+[23:06] <Ophite1> I say push it to 0.4 definitely. It will cause firewall issues at the moment but we are still in testing...
+[23:06] <Ophite1> ...someone that can't open a firewall port probably shouldn't be trying it yet.
+[23:06] *** nickthief54450 (~chatzilla@anon.iip) has joined channel #iip-dev
+[23:06] <jrand0m> right. and even with firewalls, PHTTP lets them through.
+[23:07] <Ophite1> though need to test phttp against hostile proxies.
+[23:07] * jrand0m is behind a firewall I don't control and I participate fully in i2p
+[23:07] <dm> hax0r
+[23:07] <jrand0m> well, yes, hostile proxies can fake confirm, but its all signed, so the message can't go to the wrong place / etc
+[23:08] <jrand0m> but the phttp relay and transport does have a lot of features needed
+[23:08] <Ophite1> in particular, to examine the future possibilities application level routers might have at detecting/fucking up the protocol.
+[23:08] <jrand0m> hm?
+[23:08] <Ophite1> have some experience with firewall tunnelling though.
+[23:08] <Ophite1> might want to include a GET fallback.
+[23:09] <jrand0m> hmm. GET goes into logs. but perhaps as a fallback
+[23:09] <jrand0m> (POST can be to /index.html)
+[23:09] <Ophite1> jrand0m: but it's all signed/encrypted if noderefs are cool...?
+[23:10] <Ophite1> unless the proxy becomes an active attacker too, that's going to be quite hard for it.
+[23:10] <jrand0m> all messages are encrypted to the destination router, and the designation as to what phttp relay to go through is signed in the routerInfo
+[23:10] <jrand0m> right. phttp proxy as is certainly isn't strong enough to go against an active attacker
+[23:11] *** Signoff: grimps (Leaving)
+[23:12] <jrand0m> I think it'd be great if people posted some alternate transport ideas to the wiki :)
+[23:12] <jrand0m> ok, 4) app status [ppp2p, i2ptunnel, im, ns, squid]
+[23:12] <jrand0m> damn, tusko left
+[23:12] <jrand0m> tusko wrote a python script (ppp2p) to let people run ppp over i2p via i2ptunnel
+[23:13] <Ophite1> Told you someone would do that :)
+[23:13] <dm> ppp over i2p?
+[23:13] <jrand0m> I haven't looked at it, but last I heard he was running a vpn over i2p with 5s ping times
+[23:13] <jrand0m> heh yeah
+[23:13] <Ophite1> dm: of course.
+[23:13] <dm> when could you use that?
+[23:13] <dm> could/would
+[23:13] <jrand0m> dm> anonymous outproxy
+[23:13] <Ophite1> dm: anonymous ANYTHING.
+[23:13] <jrand0m> to, say, run a kazaa node anonymously, or whatever
+[23:13] * Ophite1 points out that anyone running an outbound i2p->ppp link is insane and will probably be blacklisted/hunted down
+[23:13] <dm> ah, I understand.
+[23:13] <jrand0m> definitely Ophite1
+[23:14] <jrand0m> so right now, its only for trusted peers.
+[23:14] <Ophite1> see also: the dresden JAP cascade... :)
+[23:14] <jrand0m> which, well, doesnt really make sense for anonymity...
+[23:14] <jrand0m> heh
+[23:14] <Ophite1> also most of the stuff going out of their node will be unencrypted...
+[23:14] * jrand0m thinks about ike over ppp over i2p
+[23:15] * jrand0m watches my head explode
+[23:15] *** fiaga (~po@anon.iip) has joined channel #iip-dev
+[23:15] <Ophite1> jrand0m: why not i2p over ppp over i2p?
+[23:15] <jrand0m> definitely doable. aint recursion fun?
+[23:15] <soros> i2p over i2p :-o
+[23:15] <jrand0m> or i2p over ppp over i2p over i2p over freenet over kazaa
+[23:15] <Ophite1> now that's just silly. Freenet wouldn't possibly work ;)
+[23:16] <godmode0> over slow connect :)
+[23:16] <jrand0m> heh it'd have latency issues, certainly :)
+[23:16] <mihi> ... over an icmp tunnel over ...
+[23:16] <Ophite1> ooh yes, loki :)
+[23:16] <Ophite1> 0ldsk00l :)
+[23:17] <Ophite1> I2P addresses, being the public keys, are ... rather long.
+[23:17] <jrand0m> yes.
+[23:17] <jrand0m> actually, since we're on agenda item 4: ns
+[23:17] <Ophite1> As in an I2P www url being actually too long to paste into any sane place (>512 chars?!!)
+[23:17] <mihi> co promised to write a naming service...
+[23:17] <jrand0m> yeah.
+[23:17] <jrand0m> I think with idn implemented, it would be very easy for someone to adapt the kademlia code into a distributed dns
+[23:17] <mihi> Ophite1: post them to the eepsite forum.
+[23:18] <Ophite1> trouble with namespace as I can figure it out is that there has to be either some degree of central control OR you have to allow collisions.
+[23:18] *** Signoff: fiaga (Ping timeout)
+[23:18] <jrand0m> (just toss on a CA or WoT CAs, and voila. (Link: www.mihi.i2p)www.mihi.i2p)
+[23:18] <jrand0m> not necessarily.
+[23:18] <Ophite1> please enlighten me with your better ideas then.
+[23:18] <jrand0m> Ophite1> check out co/wiht's specs on the iip-dev list.
+[23:19] <Ophite1> best I could come up with is root key creates signed namespaces. dnssec stylee.
+[23:19] <jrand0m> he doesn't go the full route with a dht, but he manages groups
+[23:19] <jrand0m> just like how we do now - we /all/ can choose who our root dns servers are.
+[23:19] <jrand0m> in the same vein, we /all/ should be able to choose who our CA (or CA WoT) is
+[23:20] <jrand0m> so I guess technically there /could/ be collisions, but only once there are multiple CA groups that don't interact
+[23:20] * Ophite1 notes that is unlikely
+[23:20] <jrand0m> agreed
+[23:20] <Ophite1> you either trust the root CA or you don't.
+[23:20] <jrand0m> and if you don't trust the root, you create your own
+[23:21] <jrand0m> (or find another)
+[23:21] <Ophite1> and if you don't trust the root CA it's for a reason, a reason that will rapidly get around.
+[23:21] <jrand0m> exactly
+[23:21] <jrand0m> especially when there's anonymous publishing :)
+[23:21] <Ophite1> being as CA's only real purpose is to insure anti-collision - like Trent...
+[23:21] <jrand0m> right
+[23:22] <Ophite1> about the only thing that would cause lack of trust in CA is (1) key leakage or (2) refusal to register something that isn't already registered.
+[23:22] * jrand0m notes verisign's "trustworthiness"
+[23:23] * Ophite1 notes that Verisign purports to verify the identity of the certificate holder - one of the properties that an I2P namespace is in fact guaranteed NOT to do
+[23:23] <jrand0m> self signed certs+++
+[23:24] <Ophite1> also I'd point out that distributed systems - like Darknet, as I will call it from here on in until it sticks :) - built on top of i2p probably wouldn't use the namespace.
+[23:24] <Ophite1> It's for servers, really.
+[23:24] <jrand0m> heh
+[23:24] <jrand0m> right
+[23:24] <Ophite1> Servers don't scale. That problem will be in i2p as much as in IP.
+[23:24] <Ophite1> so, I think that the usage in practice will actually be surprisingly limited.
+[23:24] <jrand0m> the idn ("darknet") would keep references to destinations - the full 387 bits of their keys, not some pretty name
+[23:24] <jrand0m> agreed.
+[23:25] <jrand0m> except / until someone writes a distributed outproxy system
+[23:25] <jrand0m> aka o-r / freedom over i2p
+[23:25] <TC> how many diffrent keys can we have?
+[23:25] * jrand0m looks forward to that day
+[23:25] <jrand0m> tc> 2^2048
+[23:25] <Ophite1> jrand0m: at which point the root key signs them a namespace: .proxy.i2p
+[23:26] <dm> This must be the most hypothetical/megalomaniac open source development meeting ever :)
+[23:26] <jrand0m> aint subspaces grand :)
+[23:26] <jrand0m> lol dm
+[23:26] <jrand0m> hey, we're alowed to aim high, aint we?
+[23:26] <dm> I'm sure most devl meetings are like: "So, do we put 3 bits for the mpeg-5 header or 4?"
+[23:26] <Ophite1> jrand0m: oddly as it may seem, not every number works for elgamal ;-)
+[23:26] <TC> dm, youve seen debian meetings right?
+[23:26] <jrand0m> awww c'mon, 000000000000000000000000000 is a secure key
+[23:26] * Ophite1 hands out Chocolate Digestives
+[23:26] <dm> TC: no, what are the like?
+[23:26] <Ophite1> jrand0m: ooh, identity.
+[23:26] <TC> dm, i dont know, i was asking
+[23:27] <jrand0m> ok. thecrypto isn't here either... anyone have im thoughts?
+[23:27] <Ophite1> damn, I was about to ask about that.
+[23:27] <Ophite1> quite an important app.
+[23:27] <dm> Anyway, this type of meeting is more lurker-friendly, so I'm all for it.
+[23:27] * dm is entertained.
+[23:27] <jrand0m> heh
+[23:27] <TC> where is co?
+[23:27] <Ophite1> as many people will expect i2p to be iip's successor.
+[23:28] <jrand0m> iip over i2p is fairly easy, if we don't want dcc
+[23:28] <Ophite1> (I guess it could be, if we just run an iip irc server over i2p...)
+[23:28] <jrand0m> iip over i2p with dcc requires a new app
+[23:28] <jrand0m> exactly Ophite1
+[23:28] <jrand0m> 0 coding
+[23:28] <TC> cant we just run irc over i2p?
+[23:28] <Ophite1> I don't like that idea 'cause ... well, it doesn't give us anything we don't already have :)
+[23:28] <jrand0m> but last I heard, thecrypto was doing some work on an IM app
+[23:28] <jrand0m> certainly tc
+[23:29] <jrand0m> right Ophite1, and it doesn't scale
+[23:29] <jrand0m> (all the traffic gets funneled to the ircd)
+[23:29] <Ophite1> Also the IRCd can spy on traffic.
+[23:29] <TC> ah, goodpoint
+[23:29] <jrand0m> (this would be when UserX should show up and discuss his ideas for iip2.0)
+[23:29] <jrand0m> right Ophite1
+[23:29] <jrand0m> all the problems of the current iip
+[23:29] <Ophite1> jrand0m: And absolutely nothing different.
+[23:29] <jrand0m> more lag.
+[23:30] <Ophite1> except it's in java. lovely. :)
+[23:30] <jrand0m> heh
+[23:30] <Ophite1> Now, shitloads of people have cut their undergraduate teeth trying and failing to build distributed chat applications.
+[23:30] <jrand0m> ok, so someone should either help thecrypto out or push him along some more :)
+[23:30] * Ophite1 points out IRC3
+[23:30] <jrand0m> yeah, its a perfect school project
+[23:30] <Ophite1> ..and SILC...
+[23:30] <Ophite1> ...and...
+[23:31] <Ophite1> well about a gazillion others.
+[23:31] <jrand0m> 'zactly
+[23:31] <Ophite1> Literally all of these, I might add, are pre-DHT as far as I can tell.
+[23:31] <jrand0m> yup
+[23:31] <Ophite1> That's disappointing 'cause that's a freakishly useful structure.
+[23:31] <jrand0m> a DHT for lookup / P3P, and then direct con for IM
+[23:31] <jrand0m> group chat is harder though, but not too hard
+[23:31] <Ophite1> well, direct in the i2p sense :)
+[23:31] <jrand0m> heh right
+[23:32] <Ophite1> what about darkmail/i2pmail?
+[23:32] <soros> group sex too
+[23:32] <dm> soros: agreed.
+[23:32] <jrand0m> group sex isn't that hard soros ;)
+[23:32] <jrand0m> lol
+[23:32] <jrand0m> email over i2p is easy. someone just needs to run a pop server
+[23:32] <jrand0m> or webmail
+[23:32] <jrand0m> hahah
+[23:33] <Ophite1> jrand0m: sure, as long as literally everyone is okay with bloody pgp :)
+[23:33] * Ophite1 gets CKT nightmares again
+[23:33] <jrand0m> oh, true. that'd expose the contents to hte server ;)
+[23:33] <Ophite1> Also... spam.
+[23:33] <jrand0m> yup
+[23:33] <Ophite1> We have this thing called hashcash.
+[23:33] <Ophite1> They sort of fit together, no?
+[23:34] <jrand0m> ok, so yeah, someone should get working on an i2p specific email app :)
+[23:34] <Ophite1> obviously that would work best as part of the im.
+[23:34] <Ophite1> What, after all, is the distinction between irc and email?
+[23:34] <jrand0m> true, like an IM VMB
+[23:34] <Ophite1> Whether or not you can page up and see what you missed after you rejoin...
+[23:34] <jrand0m> placed into the dht
+[23:34] <jrand0m> good point
+[23:35] * jrand0m wishes we had a team of a dozen coders
+[23:35] <Ophite1> note, however, that mail requires storage, as it is offline communication. irc requires no storage, as it is online communication.
+[23:35] <dm> also email has a lot more penis enlargement adverts.
+[23:35] <Ophite1> jrand0m: ask around for funding.
+[23:35] <Ophite1> dm: see above re: hashcash.
+[23:35] <jrand0m> right, the P3P could contain pending messages
+[23:36] <Ophite1> dm: A primitive that was not available to the bloke who hacked up email in a night.
+[23:36] <Ophite1> (At least we won't have to use ! paths to specify the tunnel manually. heh. heh. heh.)
+[23:36] * dm is gonna miss clear-text dead simple protocols.
+[23:36] <jrand0m> jrandom%ophite!dm!mihi
+[23:37] <Ophite1> no, this is i2p. Insert ~520 garbage characters between the bangs then you're closer ;)
+[23:37] <jrand0m> haha
+[23:37] <Ophite1> several of these things *are* sort of related.
+[23:37] <jrand0m> true, 387 bytes base64 encoded...
+[23:38] <Ophite1> or to put it another way, ELONGURL :)
+[23:38] <jrand0m> heh
+[23:38] <Ophite1> [does IE chop at 512?]
+[23:38] <jrand0m> naw, works fine
+[23:38] <Ophite1> you admit to using IE?
+[23:38] <Ophite1> To browse anonymously?!
+[23:38] <jrand0m> ;)
+[23:38] * Ophite1 pulls out six of Liu De Yiu's best and waits =)
+[23:38] * jrand0m uses ie for eppsites, moz for squiding
+[23:39] <duck> what item are we now?
+[23:39] <duck> 4?
+[23:39] <jrand0m> yeah, ok ok
+[23:39] <Ophite1> still 4 I think.
+[23:39] <jrand0m> i2ptunnel. still kicks ass.
+[23:39] <jrand0m> any thoughts? any comments mihi?
+[23:40] <jrand0m> one thing I want to note wrt the squid outproxy is that I've updated the header filtering to ALLOW COOKIES and replace the user agent with something silly
+[23:40] * mihi just waits for naming service...
+[23:40] <jrand0m> mihi (or someone else)> it'd be really easy to bootstrap such a naming service with an /etc/hosts style i2p ns
+[23:41] <mihi> btw: are there any other public dests except your squid and tc's eepsite?
+[23:41] <jrand0m> i2pcvs.dest
+[23:41] <jrand0m> (points at the i2p cvs pserver)
+[23:41] <jrand0m> (but isn't always up)
+[23:41] *** yodel (yodel@anon.iip) has joined channel #iip-dev
+[23:41] <jrand0m> hola yodel
+[23:41] <yodel> hela
+[23:42] <jrand0m> ok, I think thats it for 4) apps
+[23:42] <jrand0m> 5) comments / questions / etc
+[23:42] <mihi> gui installer?
+[23:42] <TC> hi yodel
+[23:43] <yodel> I have to start experimenting putting the xml-rpc over i2p
+[23:43] <yodel> should work with httptunnel
+[23:43] <jrand0m> good question mihi. last I heard MrEcho had some of it working
+[23:43] <jrand0m> awesome yodel
+[23:43] <jrand0m> definitely.
+[23:43] <jrand0m> how large are the streams?
+[23:43] <jrand0m> (aka how chatty is the protocol?)
+[23:44] * Ophite1 plans to try BitTorrent over I2P as a stress test
+[23:44] <yodel> xml over http
+[23:44] <yodel> the ssl layer wont be needed with i2p
+[23:44] <Ophite1> so, uh, very chatty? :)
+[23:44] <jrand0m> ah cool, large POST or large replies?
+[23:44] <jrand0m> (or just small and small?)
+[23:45] <jrand0m> damn you Ophite1 :)
+[23:45] <yodel> equal sizes
+[23:45] <yodel> does httptunnel support gzipped http?
+[23:45] <jrand0m> but doesn't bt use IP addresses?
+[23:45] <jrand0m> hmm, httptunnel doesn't have any inherent compression, its just a bitstream
+[23:45] <TC> hmm, package i2p+ppp\vpn+gui as a security solution for wireless windows shares
+[23:45] <yodel> so should work...
+[23:45] <godmode0> jrand0m> you test i2p in nntp news server ?
+[23:45] <jrand0m> yup yodel
+[23:45] <yodel> 500-1000 byte send, same for reply
+[23:46] <jrand0m> hmm I haven't tested that yet godmode0
+[23:46] <yodel> much less when zipped
+[23:46] <jrand0m> oh cool yodel, that'll work without any problem
+[23:46] <yodel> what is the latency for a single msg/package/whatever?
+[23:46] <jrand0m> 2-5s, sometimes up to 10s
+[23:46] <jrand0m> (currently)
+[23:46] <Ophite1> not bad for a pre-dht :)
+[23:46] <yodel> so 20s roundtime?
+[23:47] <jrand0m> I usually pull up a web page in 5-10s
+[23:47] <yodel> ah
+[23:47] <yodel> goo
+[23:47] <yodel> +d
+[23:48] <jrand0m> damn, we're coming up to the 2 hour mark. anyone have any other questions / thoughts?
+[23:48] <Ophite1> Pie is good.
+[23:48] <duck> jrand0m: why do you drink cheap local beer?
+[23:48] <Ophite1> Orgy and pie is better.
+[23:48] <jrand0m> rofl duck
+[23:49] <Ophite1> duck: It's better than Tesco Value Lager?
+[23:49] * Ophite1 spits from reflex
+[23:49] <jrand0m> heh
+[23:49] * duck is concerned about jrand0m's health
+[23:49] <jrand0m> you're concerned about my cheap beer habits but not my good whiskey habits?
+[23:50] * Ophite1 reminds about the single malt on Cary Sherman's head
+[23:50] <duck> do you eat well?
+[23:50] <godmode0> corona
+[23:50] <duck> do you do your daily exercises?
+[23:50] <jrand0m> well, i'm one of those veggies
+[23:50] <Ophite1> Isn't that a personal question, duck?
+[23:50] <jrand0m> does typing count?
+[23:50] <duck> you did drink that much already?
+[23:50] <duck> that you became a veggie
+[23:50] <jrand0m> heh
+[23:50] <Ophite1> cheap beer will do that.
+[23:51] <duck> Ophite1: jrand0m's health should concern us all, since it is essential for I2P
+[23:51] *** Signoff: mihi_backup (mihi hands jrand0m the *BAF*er)
+[23:51] <jrand0m> heh ok ok mihi
+[23:51] * jrand0m winds up
+[23:51] * jrand0m *baf*s the meeting closed
+
\ No newline at end of file
diff --git a/pages/meeting66.html b/pages/meeting66.html
new file mode 100644
index 00000000..1b0bb174
--- /dev/null
+++ b/pages/meeting66.html
@@ -0,0 +1,478 @@
++
+
+[22:04] <jrand0m> agenda:
+[22:04] <jrand0m> 0) welcome
+[22:04] <jrand0m> 1) status
+[22:04] <jrand0m> 2) transport futures
+[22:05] <jrand0m> 3) peer stats for selection
+[22:05] <jrand0m> 4) apps
+[22:05] <jrand0m> 5) ...?
+[22:05] <jrand0m> 0)
+[22:05] <jrand0m> hi.
+[22:05] <jrand0m> 66 is it?
+[22:05] <duck> 7) what brand of whiskey does jrand0m drink?
+[22:06] <jrand0m> bushmills, glenlivit
+[22:06] <jrand0m> (for whiskey and whisky, respectively)
+[22:06] <TC> yey, i made the meating
+[22:06] <jrand0m> woot
+[22:06] <jrand0m> ok, 1) status
+[22:06] <jrand0m> the kademlia stuff is coming along very well.
+[22:07] <jrand0m> I've build a little simulator that runs a network of five nodes and puts them through the basic tests
+[22:07] <jrand0m> also the idn stuff is implemented with some tests as well
+[22:08] <jrand0m> the last two days or so have been focused on making sure the kademlia code works for both idn and for the i2p netdb, which has caused a bunch of changes
+[22:09] <jrand0m> actually, the big change is that I'm forcing myself to be practical and make the kademlia code work first with the netDb and /then/ think about the idn stuff.
+[22:10] <jrand0m> idn right now is kind of functional, except for inter-node comm (which will be replaced with comm over i2p, of course ;)
+[22:10] <TC> idn is the stuff for the distributed storage?
+[22:10] <jrand0m> roadmap has been updated as well - http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap
+[22:10] <jrand0m> yes
+[22:10] <jrand0m> idn = Invisible Distribution Network
+[22:10] <jrand0m> (free open source anonymous akamai, basically)
+[22:11] <TC> is there a non anonymous public akamai implemintation i could play with?
+[22:11] *** leenookx (~leenookx@anon.iip) has joined channel #iip-dev
+[22:12] <jrand0m> mnet is probably up that alley
+[22:12] *** Signoff: nickthief60934 (Excess Flood)
+[22:12] <jrand0m> before I jump back into the router completely, I'm planning on leaving the idn code in a state that /hopefully/ someone would be able to jump in and make that into a usable app.
+[22:13] *** dm (~sd@anon.iip) has joined channel #iip-dev
+[22:14] *** nickthief60934 (~chatzilla@anon.iip) has joined channel #iip-dev
+[22:14] <jrand0m> if you see the roadmap, kademlia has been pushed into the 0.2.2 release. in addition, there are also two big outstanding things that I hope to have in there, fixing a pair of bugs that do annoying things
+[22:14] <TC> would it be posible do image grabs do idn from an i2ptunnel eepsite?
+[22:15] <jrand0m> hmm?
+[22:15] <jrand0m> oh, like <img src="idn:blah">?
+[22:15] <TC> i was just thinking of bandwidth saving, yes
+[22:15] <Ophite1> protocol would be the obvious way to go, yes.
+[22:16] <jrand0m> hmm Ophite1?
+[22:17] <jrand0m> (sorry, I'm sick again so might not be quite on top of my game today)
+[22:17] <dm> how many LOC have you written jr?
+[22:17] <TC> Ophite1, could i2p tunnel be modified to redirect?
+[22:18] <TC> or could the browser do it on its own somehow?
+[22:18] <jrand0m> dm> "find . -exec grep \\\; {} \; | wc -l" currently puts the sdk ~8kloc, the router ~11kloc
+[22:18] <dm> okay thanks.
+[22:19] <jrand0m> idn would want to support receiving requests from browsers.
+[22:19] <Ophite1> would mean integrating idn into i2ptunnel. very ugly.
+[22:19] <jrand0m> currently idn has a so-god-damn-easy api.
+[22:19] <jrand0m> the api is the file system.
+[22:19] <jrand0m> aka:
+[22:19] <jrand0m> command=get
+[22:19] <jrand0m> key=zGb1tPM6ARNRTWZLCWK4XXco2Ngk8ccx-ciDUCom~9U
+[22:19] <jrand0m> saveAs=testGetOutput.txt
+[22:20] <jrand0m> place that in a file in a directory, and voila.
+[22:20] <jrand0m> (that was the easiest possible for me to implement and test with. certainly better ones can be found and made)
+[22:21] <jrand0m> ok, so, yeah. thats the status. I'm hoping for a 0.2.2 release by this time next week, at least.
+[22:22] <jrand0m> that'll include the first integration of the kademlia stuff, tunnel fixes, and i2cp updates.
+[22:23] <jrand0m> ok, 2) transport futures
+[22:23] <jrand0m> I don't like our tcp transport. and our udp transport is disabled. and our phttp transport is tweaky.
+[22:23] * jrand0m would like to see the tcp transport replaced with tls / ssl / some-other-standard
+[22:24] <Ophite1> link-level encryption is a requirement?
+[22:24] <jrand0m> absolutely.
+[22:25] <Ophite1> tls is _hell_ though. ask openssl.
+[22:25] <tonious> ssh?
+[22:25] <Ophite1> that, too.
+[22:25] <jrand0m> yeah, I followed the nasty discussions on the cryptography list last month, with interest.
+[22:25] <jrand0m> ssh is definitely a possibility.
+[22:26] <jrand0m> safe, too, since we already essentially have the certificates (in the RouterInfo.publicKey)
+[22:26] <Ophite1> but we're in java. we'd have to code it ourselves? :/
+[22:26] <jrand0m> naw, there are ssl, tls, and ssh java libs
+[22:26] *** Signoff: nickthief60934 (Ping timeout)
+[22:26] <tonious> There's already at least one java ssh client. Dunno about servers.
+[22:26] <Ophite1> re: security of such libs, given numerous high profile holes in openssl, openssh, et al?
+[22:27] <jrand0m> Ophite1> most likely better than custom built code.
+[22:27] <jrand0m> not that I have any reason to think there are exploits in the tcp transport as written.
+[22:27] <jrand0m> but it has not been reviewed.
+[22:28] *** nickthief60934 (~chatzilla@anon.iip) has joined channel #iip-dev
+[22:28] <jrand0m> in any case, updating the transports isn't really on deck until january (after the 0.3 release goes out)
+[22:28] <jrand0m> but if anyone wants to look into it and do some research, that'd be great
+[22:29] <TC> how many devs do we have activly coding?
+[22:29] <dm> 1! :)
+[22:29] <jrand0m> you can see who commits via (Link: http://i2p.dnsalias.net/pipermail/i2p-cvs/2003-November/thread.html)http://i2p.dnsalias.net/pipermail/i2p-cvs/2003-November/thread.html
+[22:29] <tonious> But he's got the strength of ten men....
+[22:30] <jrand0m> mihi has been cleaning up some of my messes, thankfully :)
+[22:30] <dm> haha, it's all jrandom :)
+[22:30] <dm> nice way of saying "just me"
+[22:31] <dm> I noticed that about mihi, when he got involved in frazaa, he just showed up one day and started cleaning up my (horrid) java. It was quite entertaining.
+[22:31] <jrand0m> heh
+[22:31] <Ophite1> people like that are very, very useful :)
+[22:32] <jrand0m> quite
+[22:32] <dm> "who's writing all these catch statements who do nothing ;)" -mihi
+[22:32] <jrand0m> d'oooh
+[22:33] <Ophite1> it's cause of reminders like that the code won't get as bad as freenet (we hope?) :)
+[22:33] <jrand0m> if in 5 years any of the current i2p code is still in use, I'll be shocked.
+[22:34] <jrand0m> (it had better be ported into finely tuned ASM code by then!)
+[22:34] * Ophite1 makes his "java implementation is just a prototype" speech
+[22:34] <dm> well, if you're still working on it 4 years from now, I'll guarantee that It'll be in use 5 years from now :)
+[22:34] <TC> heh, comment it out and leave it in place
+[22:35] <dm> is there a link to see the source on the web? not just the changes.
+[22:35] <jrand0m> yes dm, http://i2p.dnsalias.net/
+[22:35] <dm> nm, found it.
+[22:35] <jrand0m> :)
+[22:35] <jrand0m> ok, 4) peer stats for selection
+[22:36] <jrand0m> calling this a nebulus topic is one hell of an understatement.
+[22:36] <jrand0m> doctoral theses could be written (and some have been) on how to choose what peers to use in an untrusted environment.
+[22:36] <dm> public interface Job
+[22:36] <dm> oops, meeting. Sorry didn't realize.
+[22:37] <jrand0m> the good part is that half of our peer selection is already taken care of - the selection of peers to find other peers.
+[22:37] <jrand0m> (thats the kademlia stuff)
+[22:38] <jrand0m> the part thats left is the selection of peers to participate in tunnels, to route garlics, and to bounce replies through
+[22:38] *** Signoff: dm (EOF From client)
+[22:38] *** Signoff: TC (EOF From client)
+[22:38] *** Signoff: leenookx (EOF From client)
+[22:38] <jrand0m> what I'm thinking for 0.3 is just going to be a simple history of each peer, tested periodically
+[22:39] *** TC (~TC@anon.iip) has joined channel #iip-dev
+[22:39] *** leenookx (~leenookx@anon.iip) has joined channel #iip-dev
+[22:39] <jrand0m> stats revolving around latency and uptime
+[22:39] *** Signoff: soros (Client exiting)
+[22:39] <Ophite1> suggest you be wary of including accurate information about bandwidth usage and latency in that stats.
+[22:40] <Ophite1> as per my drunken questions.
+[22:40] <Ophite1> perhaps a more indirect route, but it's an area that needs very careful, well considered attention.
+[22:40] <jrand0m> hmm, with the intent of keeping the accurate info unknown, or to defeat predictabilities?
+[22:40] <jrand0m> right
+[22:41] <jrand0m> this discussion is for a release that won't go out until at least jan 1
+[22:42] * jrand0m understands and agrees that we want to avoid the predictabilities
+[22:42] <jrand0m> but I think we want to gather and use as accurate info as we can, /then/ adjust for entropy
+[22:42] <Ophite1> mere entropy alone may not be enough.
+[22:43] <Ophite1> but, I need more research on this :/
+[22:43] <jrand0m> true - randomly deciding to garlic route a message rather than tunnel route it, or to use a sequence of tunnels instead of one directly, etc
+[22:44] <jrand0m> no rush, just wanted to plant the subject in the minds of those out there :)
+[22:44] <jrand0m> ok, 4) apps
+[22:45] <Ophite1> been troubling me for a week or more; though, I'm happy to announce I've run into a brick wall so far :)
+[22:45] <jrand0m> w00t :)
+[22:45] <Ophite1> inclusion of accurate or accurate+some%entropy statistics may make some attacks work though.
+[22:46] <TC> oh, before apps i have a question
+[22:46] <jrand0m> well, its always easy enough to simply discard accurate info as necessary
+[22:46] *** Signoff: nickthief60934 (Excess Flood)
+[22:46] <jrand0m> sure tc, whats up?
+[22:46] <jrand0m> (stats will also (hopefully) make it easier to debug the network's operation while in development)
+[22:46] <TC> when are manditory minium hop counts (or something like it) going to start?>
+[22:47] *** nickthief60934 (~chatzilla@anon.iip) has joined channel #iip-dev
+[22:47] <jrand0m> right now the default minimum tunnel length is one non-local hop
+[22:47] *** dm (~sd@anon.iip) has joined channel #iip-dev
+[22:47] * TC didnt know that
+[22:48] <Ophite1> which is okay as long as the non-local hop doesn't KNOW it's the only non-local hop.
+[22:48] <jrand0m> that will be up'ed to 2-4 once things are more reliable
+[22:48] <jrand0m> right Ophite1
+[22:48] <Ophite1> still one better than a gnunet shortcut, so it's cool :)
+[22:48] <TC> oh, and how do speed improvements look?
+[22:48] * jrand0m is basing that 2-4 # on o-r comments
+[22:49] <Ophite1> temporary stats for network testing are okay by me, and very useful, but please bear in mind they may be a dangerous feature for production anonymity.
+[22:49] <jrand0m> hmm, speed improvements will come through more reliable and faster peer selections, which is the 0.3 release
+[22:49] <dm> jeez, I forgot how jr's code looks like it was written by a robot.
+[22:49] <dm> Hmmm, that would explain a lot.
+[22:50] <Ophite1> and through more scalable routing, which is next weeks' :)
+[22:50] <jrand0m> heh sorry dm, I'll try to be more inconsistent ;)
+[22:50] <Ophite1> (did I just mean discovery?)
+[22:50] <jrand0m> right, its discovery, not routing, really.
+[22:51] <jrand0m> i2p is scale free for normal comm.
+[22:51] <jrand0m> (and o(log(n)) for discovery)
+[22:51] <TC> i think your average ai who lives on the net would be pro i2p, what do you think dm?
+[22:52] <dm> I think the average method size in this code is the smallest I've ever seen is what I think.
+[22:53] <Ophite1> dm: clean. very good for a proto :)
+[22:53] <dm> Do you comment as you go or do you go back and put those descriptions?
+[22:53] <jrand0m> I comment when I get confused
+[22:54] <jrand0m> (I really can't wait until collections are typesafe)
+[22:54] <jrand0m> but, yeah, 4) apps :)
+[22:54] <jrand0m> (unless anyone else has router / network questions?)
+[22:55] <TC> pnope
+[22:55] <jrand0m> ok, wiht isn't here, anyone else have any naming service thoughts / comments (mrecho?)
+[22:55] <TC> a distributed naming server?
+[22:56] <dm> is wiht ever here?
+[22:56] <tonious> It could probably just sit on top of IDN.
+[22:56] <jrand0m> yeah, I'd really love to see the naming service be a dht (perhaps reusing the idn / kademlia code) containing CA signed entries
+[22:56] <TC> did co die?
+[22:56] <jrand0m> exactly tonious
+[22:57] <jrand0m> perhaps you're right, it could be an app that /uses/ idn, not just uses the code. hmmm...
+[22:57] <jrand0m> that'd be Good.
+[22:57] <tonious> Mebbe have a key fingerprint associated in case of collisions.
+[22:57] <jrand0m> naw, co/wiht is around every few days
+[22:57] <tonious> Wouldn't even necessarily need a centralized CA?
+[22:57] <jrand0m> we'd need a CA if nyms are unique.
+[22:58] <Ophite1> The CA signing chain should elminiate collisions.
+[22:58] <jrand0m> (and we need nyms to be unique to do naming, really)
+[22:58] <Ophite1> of course this makes CA key very important.
+[22:58] <TC> how about dys dns? can i make my host file redirect to a eepsite?
+[22:59] <tonious> TC: Not really. The OS doesn't even see i2p.
+[22:59] <jrand0m> though we could have $nym.$ca be the thing looked up for
+[22:59] <Ophite1> perhaps so important we want to distribute trust by it signing some second level .*.i2p domains, and have virtually all stuff under that, *.*.i2p - i.e., jrand0m.nym.i2p
+[22:59] <jrand0m> right, though with tusko's ppp2p we can get i2p to IP mappings
+[23:00] <tonious> I dunno. The idea of a CA in an essentially distributed system disagrees with me.
+[23:00] <tonious> Not bein' a developer though I'm not gonna make a fuss :)
+[23:01] <TC> dns really isnt that importent
+[23:01] <jrand0m> tonious> we can do a web of trust, essentially. with, say, 8 seperate known CAs, everyone's local name server knows about those 8, and each of them manages a subdomain (e.g. tc.ca1 or Nightblade.ca2, or we add a .i2p at the end)
+[23:01] <Ophite1> if you can think of a better way?
+[23:02] <Nostradumbass> i have another question - its sort of spans the network-application area.
+[23:02] <jrand0m> (thats really the degenerate case of a WoT)
+[23:02] <Ophite1> what I said, sort of - get a root key to sign domains...
+[23:02] <jrand0m> agreed tc
+[23:02] <jrand0m> fire away Nostradumbass
+[23:02] <Ophite1> someone gets com.i2p or nym.i2p...
+[23:02] <Nostradumbass> has any thought been goven to guaranteed latency?
+[23:02] <Ophite1> allow them to sign jrand0m.nym.i2p, or whatever.
+[23:02] <Nostradumbass> i'm thinking of VoIP.
+[23:03] <jrand0m> Ophite1> we wouldn't even need a .i2p key with that
+[23:03] <tonious> Ophite1: What if the com ca gets taken out by an RIAA hitsquad or something?
+[23:03] <jrand0m> Nostradumbass> you mean VoI2P? :)
+[23:03] <Ophite1> then once you're done, destroy the master CA.
+[23:03] <Nostradumbass> yes
+[23:03] <Ophite1> tonious: then there's still the others.
+[23:04] <Ophite1> or some system that requires conspiring groups to get the nym signing key?
+[23:04] <jrand0m> Nostradumbass> we have already had people run shoutcast streams over i2p with some buffering at 96khz and no buffering problems at less speed. but there's latency.
+[23:04] <Nostradumbass> with the upcoming release of cryptophone's (Link: http://www.cryptophone.de/)http://www.cryptophone.de/ source it could make an interesting app for i2p.
+[23:04] <Ophite1> and a really freakin' big hashcash?
+[23:04] <jrand0m> definitely Nostradumbass
+[23:04] <tonious> Ophite1: Mebbe a majority signing protocol?
+[23:04] *** Signoff: dm (Ping timeout)
+[23:04] <jrand0m> tonious> majority is dangerous with sybil
+[23:05] <Ophite1> tonious: otoh, it HAS to be non-repudiatory, and has to be able to guarantee non-collision.
+[23:05] <Ophite1> and majority couldn't do that.
+[23:05] <Ophite1> a majority of well known users maybe.
+[23:05] <Ophite1> if it's a consolation, the internet has problems with this too (think Verisign).
+[23:05] <jrand0m> right, WoT :)
+[23:06] <Ophite1> but then WoT means that different people might have different ideas of who to trust, which violates non-collision maybe?
+[23:06] *** thecrypto (~thecrypto@anon.iip) has joined channel #iip-dev
+[23:06] <jrand0m> Nostradumbass> now if we could get some coders to work on a high performance RTSP over i2p tunnel... ;)
+[23:06] <Ophite1> it's important, given the length of an "I2P address", but also hard.
+[23:06] *** Drak0h (~Dr4k0h@anon.iip) has joined channel #iip-dev
+[23:07] <Ophite1> Nostradumbass: not guaranteed.
+[23:07] <TC> so how do we secure alias identification (important for commerce and seting up multiple eepsites)?
+[23:07] <Nostradumbass> over-provisioning of bandwidth is often the only simple way to try and guarantee latency. is there going to ba any way for a node to determine the available bandwidht at another node, so as to ease routing for VoIP apps?
+[23:07] <jrand0m> yes Nostradumbass, QoS can be done transparently within i2p, but unfortunately thats (I hate saying this) > 1.0
+[23:07] <tonious> Say we take root CAs out of it. You generate your key and sign your aliases.
+[23:08] *** Signoff: thecrypto (EOF From client)
+[23:08] <Ophite1> Nostradumbass: also, troublesome re some potential attacks?
+[23:08] <tonious> You also specify who's keys you trust, ala PGP. I think redundancy is more important than collision.
+[23:08] <Ophite1> tonious: so which jrand0m.nym.i2p did you want again?
+[23:08] * jrand0m attacks the ns dht to get my nym back
+[23:08] <Ophite1> if everyone doesn't trust the same, we might not be referring to the same thing when we use the same name.
+[23:09] <Ophite1> and it would probably allow freenet-KSK-style collision wars.
+[23:09] <jrand0m> right. either the naming service has CA signed nyms, or it just distributes H(destination) --> destination mappings
+[23:09] <tonious> Just pop up a menu or something. Or if you're designing an application that talks to a specific server, give it the public key of the signing agent?
+[23:10] <jrand0m> (and H(destination) == 42 chars as opposed to ~500 chars for a destination)
+[23:10] <Ophite1> tonious: if you're going to give it public keys, you might as well just sling around I2P addresses.
+[23:10] <Ophite1> now that's an interesting ideal
+[23:10] <Ophite1> assuming sha-256 can't be reversed that yields 256-bit I2P addresses that could be "looked up" to reveal the structure.
+[23:10] *** dm (~sd@anon.iip) has joined channel #iip-dev
+[23:11] <Ophite1> I smell kademlia again.
+[23:11] <jrand0m> :)
+[23:11] <Ophite1> It can also be simply checked.
+[23:11] <jrand0m> and there's existing code to reuse.
+[23:11] <Ophite1> somehow, that makes sense. why weren't we doing this already? :)
+[23:11] <jrand0m> because we want nyms
+[23:12] <Ophite1> nyms for hosts?
+[23:12] <jrand0m> but, I suppose, 42 chars is a good enough starting point
+[23:12] <Ophite1> need a root CA for that :/
+[23:12] <jrand0m> right
+[23:12] <Ophite1> in the case where you don't want to trust a root ca?
+[23:12] <Ophite1> 42 chars is short enough to paste.
+[23:12] <jrand0m> you don't need a root CA, you can have a forest instead of a tree
+[23:12] <Ophite1> 520 chars isn't :)
+[23:12] <jrand0m> heh
+[23:13] <Ophite1> but if you have a forest, how does anyone know which tree you're talking about?
+[23:13] <Ophite1> you could slap a key in there, but then, ooh, we've got huge strings of random garbage again.
+[23:13] <jrand0m> common suffix. $nym.$ca
+[23:13] <Ophite1> well, I'd like $nym.$ca.i2p :)
+[23:13] <Ophite1> avoid confusion :)
+[23:13] <jrand0m> right. I mean, there are possible attacks. I dunno. I'm with TC though
+[23:13] <jrand0m> good 'nuff for me
+[23:14] <jrand0m> ok, /other/ apps :)
+[23:14] <Ophite1> how do you know which ca is which?
+[23:14] <Ophite1> you have a list? what signs the list?
+[23:14] <jrand0m> i2pns.config
+[23:14] *** Signoff: Drak0h (Ping timeout)
+[23:14] <Ophite1> how're you going to get that?
+[23:14] <TC> if i could make my own dns list, hostfile style i would be happy
+[23:14] <jrand0m> on install
+[23:15] <Ophite1> how are you going to verify those are the "right" keys?
+[23:15] <Ophite1> ca substitution?
+[23:15] <jrand0m> right tc, we can even do that without any distributed naming service
+[23:15] <TC> because i say they are Ophite1
+[23:15] <jrand0m> Ophite1> you aren't, any more than you're verifying that the source code is running the "real" i2p
+[23:15] <TC> and if you trust me, you can download them off my eepsite
+[23:16] <Ophite1> I suppose at the end of the day you can only reduce that to trust in one key being right, so :)
+[23:16] <Ophite1> works for me, yeah.
+[23:16] <Ophite1> as long as I get o1.i2p ;)
+[23:16] <jrand0m> heh
+[23:17] <tonious> Hmm. Revised threshold scheme: Each CA works the entire namespace, but a majority of CAs must agree before handing out subspace?
+[23:17] <jrand0m> ok, last I heard tusko had found a way to get the ppp2p to run off windows machines as well as *nix
+[23:17] <TC> it would make the i2p\internet doman system much more community based if we all passed around a huge hostfile\cheat sheet
+[23:17] <Ophite1> tonious: back to majority again...
+[23:17] <jrand0m> scary for attacks tonious
+[23:17] <jrand0m> thats true TC
+[23:17] <jrand0m> (and the value of such a community should not be underestimated)
+[23:18] <Ophite1> tc: arpanet stylee?
+[23:18] <tonious> Sigh. :)
+[23:18] <Ophite1> I guess seeds have gotta come from somewhere, so yeah ;)
+[23:18] <TC> to get a domain name, you would say this is me, and if people agreed they would change the file, and if they where trusted, others would download updates
+[23:19] <jrand0m> sounds like that'd be a heavily retrieved key from idn :)
+[23:19] <Ophite1> smells vaguely ca-like too :)
+[23:19] <TC> you could even have a fight, with more then one file
+[23:19] <Ophite1> the fidonet nodelist!
+[23:19] <tonious> And in case of a netsplit there'd be multiple patchfiles.
+[23:19] <Ophite1> ...doesn't scale.
+[23:19] <jrand0m> with under a few hundred domains, its maintainable manually
+[23:20] <TC> after a few hundred you go trusted
+[23:20] <jrand0m> right Ophite1. this would just be until we argue out the Right Way.
+[23:20] <tonious> It might be enough to jumpstart a WoT.
+[23:20] <jrand0m> (or we convince people that CAs aren't that bad ;)
+[23:20] <jrand0m> true tonious
+[23:20] <Ophite1> if you're trusting someone to agree that someone is someone else, that's a CA, not just a nodelist :)
+[23:21] <tonious> Heh. Sorry for bein' the skeptic.
+[23:21] <TC> jrand0m, in the end i dont whant to be dependent on CA's
+[23:21] <Ophite1> just allow people to give space below theirs...
+[23:21] <Ophite1> castyle -- and those on the nodelist to be the cas.
+[23:21] <Ophite1> course then it's all "which ca is jrand0m on?"
+[23:21] <jrand0m> CA's aren't necessarily choke points. if they're unsatisfactory, we replace them.
+[23:22] <tonious> Ophite1: I like that.
+[23:22] <Ophite1> point. CA being crapped out would be Big Enough News for someone to simply replace them.
+[23:22] <Ophite1> tonious: so is it slashdot.org or slashdot.com? goatse.cx? :)
+[23:22] <dm> what does CA stand for? :)
+[23:22] <Ophite1> certification authority.
+[23:23] <dm> k, thanks.
+[23:23] <tonious> Heh. That's where your own WoT comes in, Ophite1.
+[23:23] <Ophite1> tonious: yes, but I still have to see goatse once before I realise it's the wrong bloody one. :)
+[23:23] <tonious> 'I trust Ophite1 not to show that horrible asshole, and he signed slashdot.org'
+[23:23] <jrand0m> lol
+[23:24] <Ophite1> so essentially you're trusting a limited subset of people, not to be horrible assholes.
+[23:24] * jrand0m reserves the right to be an asshole at times
+[23:24] <Ophite1> and to hand out domains to the rest.
+[23:24] <Ophite1> at least one of which ought, really, to be a trent-style first-comes-first-served bot.
+[23:24] <Ophite1> (with.. yes... hashcash.)
+[23:24] <tonious> Yeah. And there may be namespace collisions by people who are outside my WoT...
+[23:25] <jrand0m> yup, and another should be something like thetower's tfee/subpage redirects
+[23:25] <Ophite1> tonious: something that you can actually USE might be appreciated. it's just a naming system. :)
+[23:25] <tonious> Heh.
+[23:25] <Ophite1> the good thing about multiple cas is that they can do their own thing re: that kind of thing - different policies.
+[23:26] *** Signoff: nickthief60934 (Ping timeout)
+[23:26] <jrand0m> ok, other apps...
+[23:26] <jrand0m> IM?
+[23:26] <Ophite1> finally :)
+[23:26] <Ophite1> signed nyms! :)
+[23:26] <tonious> Sorry Ophite1 :)
+[23:26] <jrand0m> !thwap Ophite1
+[23:27] <Ophite1> what, what are you all looking at? :)
+[23:27] <Ophite1> yes, WoT would be appropriate for _that_ :)
+[23:27] <dm> I think I remember who was doing IM... thecrypto?
+[23:27] <Ophite1> in fact... elgamal 2048-bit... dsa 1024-bit... sha-256... sounds kind of familiar. openpgp?
+[23:27] <jrand0m> yodel was in here the other day, mentioned that they had tried out running yodel's xml-rpc interface over with their own local router, and it worked. so, yay
+[23:27] *** nickthief60934 (~chatzilla@anon.iip) has joined channel #iip-dev
+[23:28] <tonious> I've managed to get SOAP going on mine, too.
+[23:28] <jrand0m> yup dm
+[23:28] <tonious> No useful apps, beyond 'Yep, it works' so far.
+[23:28] <jrand0m> hehe
+[23:29] *** Signoff: nickthief60934 (Excess Flood)
+[23:29] <Nostradumbass> tonious: so SOAP over i2p = Black SOAP?
+[23:29] * jrand0m really wants to get idn up and running so we can use i2p as an IP layer, not a TCP layer
+[23:29] <jrand0m> lol Nostradumbass
+[23:29] <Ophite1> nicename :)
+[23:29] <tonious> Nostradumbass: Yep, you got it.
+[23:30] <tonious> Now I can set up my own I2P casino. w00t!
+[23:30] *** nickthief60934 (~chatzilla@anon.iip) has joined channel #iip-dev
+[23:30] <jrand0m> w33wt
+[23:30] <jrand0m> ok, I think thats 'bout it for the apps
+[23:30] <jrand0m> 5) ...?
+[23:31] <jrand0m> hi
+[23:31] <Ophite1> tonious: cool. we could use a few of those. donate a percentage to the i2p project? :)
+[23:31] <TC> merchandising
+[23:31] <tonious> Has anybody thought of a C implementation of I2P?
+[23:31] <jrand0m> yeah, rent out colo boxes and run routers :)
+[23:32] <jrand0m> tonious> lets wait until we get the router protocol implemented and thoroughly reviewed before porting ;)
+[23:32] <tonious> Or anonymous colo: Behind an I2P router and no internet routing :)
+[23:32] <Ophite1> merchandising = logo.
+[23:32] <TC> stickers, t-shirts, hats, we need the logo
+[23:32] <Ophite1> tonious: after it's working and anonymous and stuff? of course.
+[23:32] <tonious> Yeah, but I'm still running my P2 and I'm a poor guy.
+[23:32] <tonious> :(
+[23:32] <Ophite1> i2p needs a good logo.
+[23:32] <Nostradumbass> yes
+[23:32] <Ophite1> I mean, the internet doesn't have a logo, but that's just bad marketing. :)
+[23:32] <dm> I like the one on the WIKI.
+[23:32] <TC> also, each made-for-i2p program needs its own tweeked version, or take off of the logo
+[23:32] <jrand0m> how about a transparent logo... it'd, be, like, everywhere, dood
+[23:33] <Ophite1> an invisible logo. heh.
+[23:33] <tonious> A 1 pixel by 1 pixel blank gif?
+[23:33] <jrand0m> definnitely
+[23:33] <Ophite1> tonious: we'd be sued for copyright infringment? :)
+[23:33] <tonious> Ha!
+[23:33] <Ophite1> ("Hey, that's OUR blank gif!")
+[23:33] <jrand0m> lol
+[23:33] <Ophite1> Hey, if John Cage can do it...
+[23:33] <tonious> So we leave our names in the comments field :)
+[23:33] <Nostradumbass> Ophite1: how about a stream roller paving over the Internet?
+[23:33] <jrand0m> heh we're just rendering his audio
+[23:34] <Ophite1> that one on the bottom looks the best imho.
+[23:34] <tonious> I like the one on the top. It's simple. Like me.
+[23:34] <Ophite1> with the arc design.
+[23:35] <Ophite1> something that is small, very simple, and above all would work well as an icon, or in the system tray :)
+[23:35] <Ophite1> and yes, which can be customised and used as a basis for logos of apps.
+[23:35] <jrand0m> right
+[23:35] <dm> How about a black circle with white fill.
+[23:35] <Ophite1> that arc would be a good start (colour changes?)
+[23:35] <dm> or a triangle, maybe a square!
+[23:35] <dm> a parallelogram!
+[23:37] <tonious> Heh. Open up a cafepress store...
+[23:37] <Ophite1> god no, not cafepress.
+[23:37] <dm> a white cloud!
+[23:37] <Ophite1> we demand class. ... thinkgeek. ;-)
+[23:37] <dm> little fluffy cloud.
+[23:38] <TC> it would look toomuch like a cumpuddle in minature
+[23:38] * jrand0m associates clouds with the sky, thankyouverymuch
+[23:38] <tonious> Ophite1: First we've gotta convince 'em that we're whitehat.
+[23:39] <TC> no, lets be black hat
+[23:39] <jrand0m> tonious> can militant anarchists be whitehats too?
+[23:39] * TC doesnt like ppl in hats
+[23:39] <tonious> Dunno.
+[23:39] * tonious wears a grey fedora FWIW.
+[23:39] <Nostradumbass> how about a white and a black hat?
+[23:39] <TC> and modulus would say somthing about class distinction or something
+[23:40] <dm> a small picture of uncle sam's face?
+[23:40] <TC> checkered hat?
+[23:40] <jrand0m> heh tc
+[23:40] <Nostradumbass> or white and a black wizzard hats
+[23:40] <Ophite1> I am NOT a white hat. How dare you insinuate that. I want an apology.
+[23:41] <TC> or a black dunce hat
+[23:41] <jrand0m> well, anyway...
+[23:42] <tonious> "i2p inside"?
+[23:42] <jrand0m> heh
+[23:42] <dm> I, too, pee...
+[23:42] <jrand0m> dm> on a calvin sticker!
+[23:42] <Ophite1> "i2p ... somewhere"
+[23:42] <TC> so, logo ppl, come on! so can nop set us up a i2p cafepress site?
+[23:43] * jrand0m repeats the mantra No PR until its ready.
+[23:43] <Nostradumbass> dm: yeah, make it a "Concentration" style chrade logo-gram.
+[23:43] <Nostradumbass> <eye> 2 and a pee-ing penis.
+[23:44] <dm> Let's set a date.
+[23:44] <jrand0m> heh, yeah, and you'll have your mother click on that icon?
+[23:44] <dm> March 1st.
+[23:44] <Nostradumbass> grab it, in fact :)
+[23:44] <tonious> My mother disapproves of encryption :)
+[23:44] *** UserX (~User@anon.iip) has joined channel #iip-dev
+[23:44] <dm> Slashdot article! No matter how far (or not) jrand0m has gotten!
+[23:44] <dm> Let's pile on the pressure.
+[23:44] <Ophite1> nooooooo.
+[23:44] <Ophite1> not yet!
+[23:45] <jrand0m> damn dm, if you pulled that date out of thin air, you're good. in my palm I have 1.0 slotted as ~ march 1
+[23:45] * dm slaps Ophite1
+[23:45] <dm> i said march 1st.
+[23:45] <Ophite1> the appropriate time to promote is when we have a cool shiny thing to wave at them.
+[23:45] <Nostradumbass> please, no slashdot till the network is ready for the onslaught.
+[23:45] <jrand0m> right
+[23:45] <dm> I'm good, what can I say.
+[23:45] <Ophite1> I call launch date April 4th.
+[23:45] <Ophite1> 04/04/04 ;)
+[23:45] <jrand0m> no PR until AFTER 1.0 comes out.
+[23:45] <Nostradumbass> Mojo was almost destroyed by /.
+[23:46] <dm> no, none of this rational thinking. March 1st, end of story.
+[23:46] <jrand0m> ooOOo Ophite1
+[23:46] * jrand0m senses that I'm going to have to submit to /. to get them to NOT post dm^H^Han anonymous person's article
+[23:46] <Ophite1> no, don't do that. malda doesn't give a shit, and he'll post THAT :)
+[23:46] <jrand0m> heh
+[23:47] <dm> Yes, you will be ridiculed by my post: "Em, like, there's this like anonymous cool program that's better than kazaa, I2P it's awesome, it's fast, DSA124. yeah"
+[23:47] <jrand0m> anyway, as things progress, http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap will be updated
+[23:48] <dm> time to pack.
+[23:49] <jrand0m> (and some day I'm going to take a week off and go snowboarding)
+[23:49] *** soros (~soros@anon.iip) has joined channel #iip-dev
+[23:49] <jrand0m> yeah, we're about the 2hour mark.
+[23:49] <jrand0m> time to...
+[23:49] * jrand0m *baf*'s the meeting closed.
+
+
\ No newline at end of file
diff --git a/pages/meeting68.html b/pages/meeting68.html
new file mode 100644
index 00000000..768f6367
--- /dev/null
+++ b/pages/meeting68.html
@@ -0,0 +1,280 @@
+
+
+[22:02] <jrand0m> 0) welcome to $num
+[22:02] <jrand0m> 1) iip status
+[22:02] <jrand0m> 2) kademlia stuff + idn
+[22:02] <jrand0m> 3) peer profiling stuff
+[22:02] <jrand0m> 4) i2p services
+[22:02] <jrand0m> 5) stuff
+[22:02] <jrand0m> 0) welcome
+[22:02] <jrand0m> hi
+[22:03] <jrand0m> this is meeting 67 or 68...
+[22:03] <jrand0m> 1) iip status
+[22:03] <jrand0m> I dunno. anyone know what the situation has been as of late?
+[22:04] <jrand0m> the iip devs aren't here, so... dunno.
+[22:04] <jrand0m> [ping]
+[22:04] <jrand0m> (last week I typed for probably 10 minutes before my client pinged me out...)
+[22:05] <jrand0m> (i'm not going to type anything else until I get a p0ng, damnit ;)
+[22:05] *** Nostradumbass (nostradum@anon.iip) has joined channel #iip-dev
+[22:05] <jrand0m> 'lo Nostradumbass
+[22:06] <Nostradumbass> hi :)
+[22:06] <jrand0m> ok cool, so I haven't pinged out, people are just lurking. cool :)
+[22:06] * jrand0m hops on to the next agenda item
+[22:06] <Nostradumbass> how's i2p coming?
+[22:06] <Nostradumbass> sorry?
+[22:06] <jrand0m> good lead in ;)
+[22:07] <jrand0m> agenda item 3) i2p 0.2.3 status :)
+[22:07] *** nerox (~nerox@anon.iip) has joined channel #iip-dev
+[22:07] <jrand0m> there's been a lot of progress, even though I'm offline. commited a truckload of code a few hours ago
+[22:07] <jrand0m> that includes an implementation of the kademlia netDb
+[22:08] <jrand0m> so I'm pretty confident we'll hit the release for 0.2.3 next week (which is basically kademlia netDb + a shell script)
+[22:08] <jrand0m> there have been a few more variations on the kademlia proto though to make things more relevent for i2p
+[22:09] <jrand0m> we will always have a very, very, /very/ sparse kademlia tree.
+[22:09] <jrand0m> 2^256 possible slots, and 1-10 values per peer in the network.
+[22:09] <jrand0m> so, thinking insanely overzealous, we still wont be using jack shit, and everything will be in the furthest out kbucket
+[22:10] <jrand0m> so some parts of kademlia are going to be quietly ignored ;) but the basic gist stays the same, including the search algo & distance metric
+[22:10] <jrand0m> idn, however, is dead in the water.
+[22:11] <jrand0m> the idea that i2p's netDb code could run off the same code as a publishing DHT was a silly little idea
+[22:11] <jrand0m> and has been promptly abandonded.
+[22:11] <jrand0m> idn is still generally a good idea, but I'm not going to spend my i2p dev time working on it
+[22:12] *** tusko (~tusko@anon.iip) has joined channel #iip-dev
+[22:12] <jrand0m> but part of the 0.2.3 changes include a dramatic revamp of how we choose peers and organize router stats
+[22:12] <jrand0m> heya tusko
+[22:12] <jrand0m> that brings us to agenda item 3) peer profiling
+[22:12] <jrand0m> I've been pretty silly...and finally did some of the math
+[22:13] <jrand0m> the stats being gathered now are immense.
+[22:13] <jrand0m> about 6000 data points /per peer/
+[22:13] <duck> what is peer profiling?
+[22:13] <jrand0m> peer profiling is where the router keeps track of the performance of each peer so that it can decide who to use in the future
+[22:13] <duck> ah
+[22:13] <jrand0m> (aka fast routers, reliable routers, etc)
+[22:13] <duck> the process that eats up my memory :)
+[22:14] <jrand0m> heh actually that part isn't toooo bad
+[22:14] <jrand0m> though 6000 data points won't scale.
+[22:14] <jrand0m> 1000 routers @ 6000 data points each @ 4 bytes / data point = 24Mb
+[22:15] <jrand0m> though keeping detailed stats on a few hundred peers is probably fine, even as the net grows beyond that
+[22:15] <jrand0m> we /don't/ need to keep stats on everyone. just routers we want to 'use' for our tunnels, garlic routing, and source routing.
+[22:16] <jrand0m> we could probably get away in the long term with just keeping track of a hundred or so peers.
+[22:16] <jrand0m> but, for now, I'm going to say fuckit.
+[22:16] <jrand0m> keep stats on all peers
+[22:16] <duck> ping
+[22:16] <jrand0m> p0ng
+[22:17] <duck> will it try to learn about all peers?
+[22:17] <jrand0m> right now, yes
+[22:17] <duck> oh wait, your last lines covered that
+[22:17] <jrand0m> we also have some code for coallescing and running calculations on the peer profiles
+[22:18] <jrand0m> so one of those calculators will determine what peers to drop
+[22:18] <jrand0m> an example of the data set being collected: (Link: http://i2p.dnsalias.net/~jrandom/profile.txt)http://i2p.dnsalias.net/~jrandom/profile.txt
+[22:19] <jrand0m> (you'll notice lots of 0s :)
+[22:19] <jrand0m> I've written up a rough manifesto for peer selection and profiling, but need to get that onto the wiki
+[22:20] <jrand0m> but thats all 0.3 stuff, really. 0.2.3 just uses a little of it
+[22:21] <jrand0m> ok, thats it for the peer profiling. lots more later, just giving a lil view into whats up
+[22:21] <jrand0m> (of course, as always, anyone who wants to get down and dirty and figure out what other stats / calculations / attacks / etc should be used would be *very* much appreciated)
+[22:22] <jrand0m> ok, 4) i2p services
+[22:23] <jrand0m> tc's site is awesome & really reliable! I finally got to nightblade's page as well, and its a cool blog ('plog' ;).. I just wish I could leave comments :)
+[22:23] <jrand0m> there's also duck's jabber server, which works fairly easily with the instructions posted to tc's board
+[22:24] <jrand0m> things sometimes act up a bit, but thats related to some bugs in the router <= 0.2.2, and have been fixed (and will roll out in 0.2.3)
+[22:24] <jrand0m> the squid proxy is generally offline, since I'm offline too much to babysit my kaffe routers :/
+[22:25] <jrand0m> so for the moment, the eepsites and the jabber chat is probably the most reliable things on i2p, all running on top of i2ptunnel
+[22:25] <jrand0m> what services would be cool to show up next?
+[22:25] <duck> I did try to run an ircd over i2ptunnel
+[22:25] <duck> but before it got the full MOTD after logging in, I got ping timeouted already
+[22:26] <jrand0m> d'oh
+[22:26] <duck> and that was on the same router
+[22:26] <duck> so in the wild performance will be even worse
+[22:26] <jrand0m> on the local router it pinged out?!
+[22:26] <jrand0m> local router should never ping anything out
+[22:26] <jrand0m> oh, except for that race bug
+[22:26] <jrand0m> (which is probably what it was, since it was local and the race is faster there)
+[22:26] <duck> irc client pinged out for not responding in time
+[22:27] <duck> I'll retry with 0.2.3
+[22:27] <jrand0m> word
+[22:27] <duck> though jabber is nice for now
+[22:27] <jrand0m> totally
+[22:27] <jrand0m> and long term, irc is not the way to go
+[22:27] <duck> tc, jrandom and me are there to chat with!
+[22:27] <jrand0m> hehe :)
+[22:28] <jrand0m> we need an IM and group chat solution that doesn't give cleartext to anyone unauthorized, and doesn't require centralized choke points
+[22:28] <jrand0m> (aka iip 2.0)
+[22:28] <jrand0m> now would be a nice time for userx to come back into the fold ;)
+[22:29] * jrand0m stops holding breath
+[22:29] <jrand0m> an nntp server would /also/ really really rule.
+[22:29] <duck> I'll try that tomorrow
+[22:29] <jrand0m> r0x0r
+[22:30] <duck> jabber is really nice to run other things over
+[22:30] <duck> check out the jabber rpc specs
+[22:30] <duck> (Link: http://www.pipetree.com/jabber/jrpc/)http://www.pipetree.com/jabber/jrpc/
+[22:30] <duck> other services?
+[22:30] <jrand0m> thats interesting - doing jabber as a naming service, essentially
+[22:31] <duck> you mean:
+[22:31] <jrand0m> there will always be more services to add - with mail (usenet), chat (jabber) and publishing/browsing (eepsites), there's good coverage
+[22:31] <duck> name server has a jabber client through which you can register names (provided token)
+[22:31] <duck> also use it to query?
+[22:31] <jrand0m> naw
+[22:32] <jrand0m> jabber's registry being the naming service
+[22:32] <duck> ok
+[22:32] <jrand0m> its centralized but it works
+[22:32] <jrand0m> just like hosts.txt :)
+[22:33] <duck> are there mail solutions that are better suited for there environments than smtp and pop/imap ?
+[22:33] <jrand0m> thats a really good question
+[22:33] <duck> cause I dont think that it will just work when you hook up mail servers
+[22:34] <jrand0m> yeah, it'd probably need either a gateway (ala freemail) or the naming service doing some interesting tap dancing
+[22:34] <jrand0m> or it reverts back to centralized single POP3/IMAP server with everyone on the same server
+[22:35] <duck> I spoke with aum (author of freemail) yesterday
+[22:35] <duck> he was talking about reimplementing fred in python
+[22:35] <jrand0m> lol nice
+[22:35] *** mrflibble (mrflibble@anon.iip) has joined channel #iip-dev
+[22:35] <duck> so I did suggest him to work on the python routers for i2p instead
+[22:35] <jrand0m> ooh that would TOTALLY rule!
+[22:35] <duck> then he got totally upset about the pdf documents
+[22:36] <jrand0m> hey, if he wants the openOffice originals, or even a txt export I'll export
+[22:36] <duck> and I lost my patience and told him that you would also have the m$word docs if he did ask nicely
+[22:36] <duck> well, you were a fuckhead for not doing a html export or something
+[22:36] <jrand0m> naw, I tried that ;)
+[22:36] <duck> I lost my patience and told him to talk to you
+[22:36] <jrand0m> the openOffice html export SUCKS
+[22:37] <duck> hm
+[22:37] <mrflibble> true jr
+[22:37] <jrand0m> when the specs turn 1.0 (aka when the router turns 1.0 and they're updated to match the code), they'll be on the wiki.
+[22:37] <duck> wiki has most info though
+[22:37] <jrand0m> exactly
+[22:37] <mrflibble> i tried using that for that kevin mitnick book. it was worse than ms office
+[22:37] <duck> oh well
+[22:37] <jrand0m> zactly.
+[22:37] <duck> he might appear here once
+[22:37] <jrand0m> that'd be awesome
+[22:38] <duck> but maybe it is better with his attitude to join the freenet gang
+[22:38] <duck> ...
+[22:38] <jrand0m> well, effort on freenet is always a good thing
+[22:38] * duck goes back to beeing friendly
+[22:38] <jrand0m> :)
+[22:38] <duck> aums work rocks
+[22:38] <duck> hopefully he'll rock on i2p
+[22:39] <jrand0m> yeah whenever someone talked about searching on freenet, I always just said "well just do a McNabb"
+[22:39] <jrand0m> we need the help, certainly
+[22:39] <duck> which brings me to the following question:
+[22:39] <duck> are the changes to I2P that you do specced?
+[22:39] <duck> or is the java source the documentation for the latest info
+[22:40] <jrand0m> there are notes taken in my palmpilot, filesystem, and notebook, but unfortunately I haven't updated the openoffice docs in a while
+[22:40] <jrand0m> feb is doc-month for jrandom.
+[22:40] <jrand0m> (and qa, and bugfixing)
+[22:41] <jrand0m> ((and benders ;))
+[22:41] <jrand0m> the specs are still pretty much correct, there are just more details.
+[22:41] <duck> awesome
+[22:41] <jrand0m> but the datastructures have had more changes
+[22:42] <jrand0m> ok, anything else for services?
+[22:43] <jrand0m> ok, 5) stuff
+[22:43] <jrand0m> hi
+[22:43] <duck> hi!
+[22:43] <jrand0m> how's tricks?
+[22:43] <jrand0m> [any questions / thoughts / issues / etc go here]
+[22:43] <duck> the base64 tricks should be added to the i2ptricks pages
+[22:44] <jrand0m> ooh good point
+[22:44] <duck> might be some other tricks too that I dont know yet
+[22:44] <duck> will grep the sources for 'main'
+[22:44] <jrand0m> I feel guilty for not having the installer let someoene automatically fetch hosts.txt and reseed
+[22:44] <jrand0m> lol
+[22:44] <jrand0m> there are lots and lots of main() methods, but they're mostly test functions
+[22:45] <jrand0m> oh!
+[22:45] <jrand0m> one thing. DONT run the current code from cvs and expect it to work with normal routers.
+[22:45] *** joda (--@anon.iip) has joined channel #iip-dev
+[22:45] <joda> hi
+[22:45] <jrand0m> the db messages changed :)
+[22:45] <jrand0m> hi joda
+[22:45] <joda> sorry, if I interrupt something
+[22:45] <duck> I got a bit upset that I couldnt get cvs to work
+[22:45] <duck> but then I did remember that this isnt freenet
+[22:45] <joda> I was just wondering what happend to "anonymail" ?
+[22:46] <duck> so you dont need latest cvs to be able to use it
+[22:46] <jrand0m> joda> the user who runs it doesn't seem to be online at the moment. should be back soon
+[22:46] <jrand0m> hehe duck - did it fail for you today after I committed, or do you mean from before today?
+[22:46] <duck> last week somewhere
+[22:46] <joda> jrand> thx :)
+[22:46] <joda> cu :)
+[22:46] <jrand0m> ah 'k duck
+[22:46] <jrand0m> l8r joda
+[22:47] <jrand0m> yeah, I only endorse running the released code
+[22:47] <duck> will 0.2.3 put the version files in a directory? :)
+[22:47] <jrand0m> 0.2.3 gets rid of the version files :)
+[22:47] <jrand0m> (lots and lots and lots of changes)
+[22:47] <jrand0m> but that means 0.2.3 (and beyond) will require g enerally correct clocks
+[22:48] <jrand0m> (current Router.CLOCK_FUDGE_FACTOR = 30 minutes)
+[22:48] <duck> what will the fudge facter be for 0.2.3?
+[22:48] <jrand0m> probably the same
+[22:49] *** joda has left #iip-dev
+[22:49] <duck> oh, current = your code
+[22:49] <jrand0m> that time will be used to expire db entries
+[22:49] <duck> k
+[22:49] <jrand0m> ah, right, yeah :)
+[22:49] <jrand0m> (in 0.2.2 that clock_fudge_factor is spread out throughout half a dozen files)
+[22:49] <duck> maybe the installer could be a bit more userfriendly
+[22:49] <duck> as in less questions
+[22:49] *** Signoff: nickthief66282 (Excess Flood)
+[22:50] <duck> default phttp urls included, no bandwidth limiting etc
+[22:50] <jrand0m> I guess we could autoguess random ports too
+[22:50] <jrand0m> you're right
+[22:50] <jrand0m> want commit privs? :)
+[22:50] *** Signoff: nerox (EOF From client)
+[22:50] <jrand0m> (if not I can update it for 0.2.3)
+[22:51] <duck> an argument against it can be that users will take settings too easily for granted
+[22:51] <duck> and everybody uses the same phttp relay
+[22:51] *** nickthief24373 (~chatzilla@anon.iip) has joined channel #iip-dev
+[22:51] <jrand0m> true. though 0.3.1 plans include an update to the phttp relay code to let relays talk to each other, and redirect users to a less loaded relay
+[22:52] <jrand0m> i'm generally happy with the install process atm though - i built a new 0.2.2 install and was browsing tc's page in under a minute
+[22:52] <jrand0m> (though thats because i know what all the text says and didn't read it...)
+[22:52] <duck> I dont like the long keys
+[22:53] <duck> especially not if you have to copy&paste them
+[22:53] <duck> better use them as file
+[22:53] <jrand0m> hmm?
+[22:53] <duck> but distributing the binary files are a pain
+[22:53] <duck> so you have to do the base64 trick..
+[22:53] <duck> could the i2ptunnel read base64 destination keys too?
+[22:53] <duck> from a file that is
+[22:53] <jrand0m> I was just typing that ;)
+[22:53] <jrand0m> yeah, that wouldnt be much work
+[22:54] <jrand0m> perhaps even 1 line
+[22:54] <duck> also, what about armouring?
+[22:54] <duck> with a header&footer
+[22:54] <duck> like pgp etc
+[22:55] <jrand0m> true, it would be useful to have that sort of validation
+[22:55] <duck> ofcourse that is a gadget
+[22:55] <duck> but it could be helpful for those who want to use the tunnel
+[22:55] <jrand0m> though the Destination structure itself is pretty picky
+[22:55] <jrand0m> but you're right, a raw base64 isn't the most intuitive or safe thing to pass around
+[22:56] <jrand0m> we need a bugzilla
+[22:56] <jrand0m> so things like this can get posted as todo
+[22:56] <jrand0m> i'd move off my palm's todo list for that
+[22:56] <duck> bugzilla has nazi registration requirements
+[22:56] <duck> with emails etc..
+[22:56] <jrand0m> true
+[22:57] <duck> but better as nothing
+[22:57] <duck> other bugtrackers all have their shortcomings
+[22:57] <jrand0m> yeah, every company i've worked at has pretty much ended building their own
+[22:58] <jrand0m> we'll see. we need a bugtracker by the time we start doing full on qa (once 0.3 comes out)
+[22:58] <jrand0m> so we've got a few weeks ;)
+[22:58] <jrand0m> but if someone did some research and found a really nice one, that'd be great
+[22:59] <jrand0m> [not you specifically duck, anyone who's reading these meeting logs at home ;)]
+[22:59] <duck> so far phpBugTrackers has been okay for me
+[22:59] <jrand0m> hmm haven't used that
+[22:59] <duck> yes, I am not talking to jrandom either
+[22:59] <jrand0m> lol
+[22:59] <duck> but to the group of I2P code developers :)
+[22:59] * jrand0m is actually 12 people acting under a single nym
+[23:00] <jrand0m> ok, 1 hour, on the dot
+[23:00] <jrand0m> anyone else have anything before I get the *baf*er out?
+[23:01] * duck demands 1 more minute
+[23:01] <duck> since we did start on 21:02
+[23:01] <jrand0m> yeah yeah
+[23:01] <jrand0m> la la la
+[23:01] <jrand0m> what should i have for dinner?
+[23:01] <jrand0m> there's a nice falafel place next door...
+[23:01] <jrand0m> had gnocci for lunch too
+[23:01] <jrand0m> hmm...
+[23:01] <jrand0m> maybe a liquid dinner
+[23:02] <duck> soup?
+[23:02] <jrand0m> ooOooo whiskey soup!
+[23:02] * jrand0m *baf*'s the meeting closed on that note
+
+
\ No newline at end of file
diff --git a/pages/meeting69.html b/pages/meeting69.html
new file mode 100644
index 00000000..5a79c5f0
--- /dev/null
+++ b/pages/meeting69.html
@@ -0,0 +1,248 @@
++[22:04] <jrand0m> 0) hi +[22:04] <jrand0m> 1) iip +[22:04] <jrand0m> 2) 0.2.3 & 0.2.3.1 +[22:04] <jrand0m> 3) hi +[22:04] <jrand0m> 0) hi +[22:04] <jrand0m> welcome to the ... something'th meeting +[22:05] <jrand0m> (68? 69?) +[22:05] <MrEcho> damm its 1pm here +[22:05] <jrand0m> GMT-8? +[22:05] <duck> 69 +[22:05] <jrand0m> h0t. +[22:06] <jrand0m> ok, 1) iip +[22:06] *** Signoff: tusko (EOF From client) +[22:06] * MrEcho compiles a kernel for the meeting +[22:06] <jrand0m> iip is acting crazy. all i know is nop is "moving servers", whatever that means. i don't know when it'll be done, etc. +[22:06] <jrand0m> anyone have any more info they want to share with the class? +[22:06] *** mids (mids@anon.iip) has joined channel #iip-dev +[22:06] <MrEcho> no info from nop +[22:07] <mids> this morning I was told that I could start Trent again +[22:07] <mids> (I did do so already last night) +[22:07] <jrand0m> wikked +[22:07] <jrand0m> gracias +[22:07] <mids> so that indicates that nop believes that IIP is more stable again +[22:07] <mids> if that is worth anything... +[22:07] <mids> *cough* +[22:07] <jrand0m> ok cool +[22:08] <jrand0m> [woot roommate just handed me a glass of wine for the meeting] +[22:08] <MrEcho> lol +[22:08] <jrand0m> ok, since nop is online and won't come to hte meeting, we'll have to save the lynch mob for later +[22:09] <jrand0m> 2) 0.2.3 & 0.2.3.1 +[22:09] <mids> what specific question do you want to ask him? +[22:09] <protocol> when is the meeting +[22:09] <jrand0m> specific question> when will he make an official announcement describing the past problems and how the future ones will be addressed? +[22:09] <jrand0m> the meeting is now +[22:10] <jrand0m> (aka, at what point should we explore non-iip means of communication) +[22:10] <mids> if I get an answer I'll let you know. +[22:10] <jrand0m> thanks +[22:11] <jrand0m> ok, i2p stuff. 0.2.3 came out yesterday, and while most of hte kademlia code is working fine, there are some 0.2.2 bugs showing up as well as some other bugs being explored. +[22:11] <jrand0m> i've committed a change to use tunneled messages for dbStore instead of garlics, which should reduce the load tc (et al) have been seeing on servers +[22:12] <jrand0m> there is also a new persistent sessionKeyManager that will make it so restarts won't totally b0rk a router for 15 minutes +[22:12] <MrEcho> what about client connect times to routers? +[22:12] <duck> so far it feels as good/bad as 0.2.2; unless my router/tunnels go down again this night, in which case it is worse as 0.2.2 +[22:13] <jrand0m> MrEcho> that seems to be in the interaction of two bugs from 0.2.2 thats acting up more than before. those two are my top priority. +[22:13] <MrEcho> ok cool +[22:13] <jrand0m> duck> my feeling is that its worse than 0.2.2, from an end user perspective. i'm working on fixing that without sacrificing anonymity or security. +[22:13] <MrEcho> its hard to work on the dns with that damm bug .. i have to restrt the dns server alot +[22:14] <jrand0m> MrEcho> with local only routers i have not been able to reproduce the bugs - does it work for you w/ local only? +[22:15] <MrEcho> no +[22:15] <jrand0m> could you send me debug logs for that? +[22:15] <MrEcho> already deleted +[22:16] <jrand0m> ok, if you try again and it doesn't work, if you could send me debug logs from both the router and client I'd appreciate it. +[22:16] <MrEcho> its doing the samething as before .. client gets msg that its sent .. but never makes it to the client +[22:16] <MrEcho> to the other client +[22:17] <MrEcho> ya .. ill see what i can do +[22:17] <jrand0m> ok, sounds like the i2psessionImpl2 bug. i haven't been able to reproduce that locally, but once its fixed for remote hopefully it will work for your situation +[22:17] <jrand0m> gracias +[22:17] <jrand0m> in any case, thanks for y'all's patience with the update. we're making progress, even if it doesn't feel like it on the surface +[22:18] <protocol> shine on you crazy diamond +[22:18] <duck> in the future, say once i2p is actually used, how will the development / release process change to prevent broken releases from mess up the net? +[22:19] <jrand0m> once 1.0 is out, i'll do dev & roll out to an insane group of volunteers to play with for a week, then if things wokr great, it'll get rolled out to general release. +[22:20] * FireRabbit will be an insane vollunteer +[22:20] <jrand0m> right now i've got to battle with kaffe & jetty for updates on i2p.dnsalias.net +[22:20] <duck> what species? +[22:20] * MrEcho already is +[22:20] *** tusko (~tusko@anon.iip) has joined channel #iip-dev +[22:20] <jrand0m> y'all already are insane (and very helpful) volunteers :) +[22:20] <FireRabbit> thank you! +[22:20] <FireRabbit> :) +[22:21] *** TC (~TC@anon.iip) has joined channel #iip-dev +[22:21] <jrand0m> hey if it aint tc +[22:21] * MrEcho wips TC .. your late +[22:21] <TC> hey +[22:21] <TC> we back up and running? +[22:21] <MrEcho> ya i can type todya... +[22:22] <jrand0m> iip seems up... +[22:22] <TC> yay +[22:22] <jrand0m> in any case, i'm hoping to have 0.2.3.1 out in the next few days, once the two critical bugs get fixed (the cpu overload tc has seen has already been updated) +[22:23] *** wiht (anon@anon.iip) has joined channel #iip-dev +[22:23] <TC> what was the cause? +[22:23] <FireRabbit> i seem to have noticed increased disk activtiy since updating to 0.2.3 but i havent spent any time to see if thats actually i2p or just the comp being stupid +[22:23] *** Signoff: wiht ((null)) +[22:23] <TC> FireRabbit, how much memmory do you have? +[22:24] <FireRabbit> that computer has 128 i believe +[22:24] <FireRabbit> you think it could be the paging file? +[22:24] <jrand0m> the cause was that 0.2.3 sends all dbStore messages via garlic routed messages instead of directly, which uses either ElGamal or AES+SessionTag (depending on whether tags are known). the persistentSessionKeyMAnager will make tags last longer, and 0.2.3.1 will send dbStore messages through tunnels instead +[22:24] <TC> because i have 512 and i2p gave me an 'out of memmory' error last night +[22:24] <jrand0m> really? shite +[22:24] <FireRabbit> oh, intresting +[22:25] <MrEcho> wow +[22:25] <jrand0m> yeah, thats #3 on the list of bugs left to crack (though thats not a 0.2.3.1 showstopper) +[22:25] <jrand0m> OOMs don't use all 512 +[22:25] <TC> but it seems to be running fine now +[22:25] <jrand0m> they only use what java's given (e.g. 64M) +[22:26] <TC> yes +[22:26] <duck> Memory: In use: 8187KB +[22:26] <jrand0m> word +[22:26] <duck> that is not much! +[22:26] <duck> yet +[22:26] <MrEcho> Memory: In use: 8908KB Free: 4088KB +[22:27] <jrand0m> right, there is something growing in there, i hope to have it tracked down by 0.3 +[22:27] <jrand0m> cool, free means it used to use 12.9M, now it only uses 8.9 +[22:27] <TC> its running at 30megs of memory at the moment but last night it jumped up to (what windows told me) '70' about then is where it crashed +[22:27] <jrand0m> yeah, kaffe does that for me tc +[22:28] <jrand0m> ok, in any case, people should subscribe to the i2p mailing list +[22:28] * FireRabbit is thinking when he gets home today hes going to rewrite the meshwork lib since it has some problems +[22:28] <FireRabbit> sigh +[22:28] <jrand0m> ((Link: http://i2p.dnsalias.net/pipermail/i2p/)http://i2p.dnsalias.net/pipermail/i2p/) +[22:28] <jrand0m> d'oh FireRabbit +[22:28] <FireRabbit> this thing is never going to gte done +[22:28] <TC> yah, and memory is no biggy for the most part +[22:28] <jrand0m> heh, no project goes as easily as one hopes +[22:28] <FireRabbit> nope +[22:28] <protocol> jrand0m: the maillist triggers Yahoo! spam protection +[22:28] <protocol> just a heads up +[22:28] <jrand0m> really protocol? +[22:29] <protocol> yeah +[22:29] <jrand0m> perhaps thats what triggered the spam guard when i cc'ed iip-dev +[22:29] * jrand0m will write my isp +[22:29] <jrand0m> (or perhaps its the .dnsalias.net thing) +[22:30] <protocol> i didn't get any mailings so far, and i emptied my bulk mail b4 i could check +[22:30] <duck> or the jrandom nicknam +[22:30] <jrand0m> lol duck +[22:30] <FireRabbit> :) +[22:30] <jrand0m> that'd be awesome if my nick was filtered :) +[22:30] <FireRabbit> hehe +[22:30] *** wiht (anon@anon.iip) has joined channel #iip-dev +[22:30] <jrand0m> wb wiht +[22:30] <jrand0m> speaking of which, I suppose I should inject 3.1) apps :) +[22:31] <jrand0m> hey MrEcho, how goes the battle? +[22:31] <wiht> jrand0m: Hello. +[22:31] <MrEcho> the day somone writes a autodetect program for the linux compile config +[22:31] <MrEcho> well its on its way +[22:31] <duck> knoppix uses some autodetect thing, isnt it? +[22:31] <jrand0m> ./configure ; make ; make check ; make install ; reboot +[22:31] <duck> </offtopic> +[22:31] <MrEcho> ive pritty much maped out how i want to do everything +[22:31] <jrand0m> word +[22:32] <jrand0m> do you have a clear view on how i2ptunnel could be updated to make use of what you're doing MrEcho? +[22:32] <FireRabbit> i think knoppix uses hotplug +[22:32] <MrEcho> 0.1 wont be/might be locked down .. dont know yet +[22:32] <jrand0m> coo' +[22:33] <TC> oh jrand0m, i have a question about the cvs +[22:33] <jrand0m> que tal? +[22:33] <MrEcho> for dns querys im going to have a server port on the Client and RS side for Names querys +[22:33] <FireRabbit> ok jrand0m so enlighten me on this, if you have two arrays, one thats storing data just recieved and one thats acting as a buffer what would you name them +[22:33] <MrEcho> and im going to build a lib for any app to use +[22:33] <jrand0m> FireRabbit> src, dest +[22:34] <FireRabbit> humm +[22:34] <TC> i thought it would be a good idea if i updated the host file directly to the i2p based cvs so it could be included with future versions +[22:34] <jrand0m> definitely tc +[22:34] <FireRabbit> this is a pretty big class, i think id want to go a little more specific than that +[22:34] * jrand0m should get you a cvs account +[22:34] <TC> im just wondering how to connect to it +[22:34] <duck> TC: you want (Link: http://www.tortoisecvs.org/)http://www.tortoisecvs.org/ +[22:34] <duck> easiest CVS client for windows that I know +[22:35] * MrEcho uses the dos ver :) +[22:35] <mihi> duck: for windows != win9x ;) +[22:35] * FireRabbit uses the cvs command line port +[22:35] <duck> mihi: I did test it with win9x +[22:35] <jrand0m> tc> have you used cvs before? or are you concerned w/ anonymity? (you should be able to cvs through i2p at the moment) +[22:35] * mihi uses either WinCVS or the cygwin cvs +[22:35] * jrand0m uses cvs.exe +[22:35] <TC> ok, so i use that client and set up the proxy? +[22:35] <TC> no, ive never used cvs before +[22:35] <jrand0m> ok, i'll walk you through the setup after the meeting +[22:36] <TC> sure, thanks +[22:36] <duck> about cvs-ing through the tunnel: +[22:36] <duck> wouldnt the double messages be a big problem? +[22:36] *** Signoff: wiht (Ping timeout) +[22:37] <duck> especially for commits +[22:37] <jrand0m> yes duck, but I haven't run into that problem (cvs messages are typically small) +[22:37] <jrand0m> >64k messages (e.g. the specs .pdf or .sxw) should for now be done through the normal internet +[22:38] <duck> jabber msges get also duplicated quite often +[22:38] <jrand0m> you're right though, in that its not a rock solid solution for cvs yet +[22:38] <duck> even though they are XML, they are not that big +[22:40] <jrand0m> right, lost acks are one of the bitches of the current lost i2psessionimpl2 bugs :/ +[22:40] <duck> k +[22:41] <duck> (that was a partly lost ack) +[22:41] <jrand0m> (with the network this size, there should be no resends ever, unless that the peer is offline) +[22:42] <jrand0m> hmm ok, any other i2p stuff? +[22:42] <mihi> jrand0m: how about adding some kinda sequence number into the i2p packets? +[22:43] <jrand0m> i2ptunnel packets? +[22:43] <mihi> this would help with the doubling things. +[22:43] <mihi> no, i2pnp packets +[22:43] <mihi> okay, one could do it on i2ptunnel level as well. +[22:43] <TC> so jrand0m did you get your conncetion back or are you still at a cafe? +[22:43] <mihi> just if you get twice the same number, disregard the second one. +[22:44] <jrand0m> those already handle dup ids for most things, though you're right in that there's going to be an update on 0.3 for the remaining messages +[22:44] <jrand0m> right, currently we keep a history of the last 1000 msgIds to drop dups +[22:44] <mihi> okay, if anyone volunteers to write a good tcp impl for i2p, that would be better ;) +[22:44] <jrand0m> yes! :) +[22:44] *** Nostradumbass (nostradum@anon.iip) has joined channel #iip-dev +[22:45] * jrand0m thinks there's going to be a bounty for some [yet to be determined killer app/feature] once 1.0 gets near +[22:45] <duck> win a 1 hour private chat session with UserX! +[22:45] <jrand0m> lol +[22:45] <MrEcho> lol +[22:46] <jrand0m> ok, any other i2p things, or iip things, or anything else for this, the 69th iip-dev meeting? +[22:46] <jrand0m> (other than userx pinup girl comments) +[22:47] <duck> any other apps that duck inc. should run? +[22:47] <jrand0m> bluebeep! +[22:47] <TC> 1. jrand0m did you fix your connection issues? 2. what do you think of my new eepsite? +[22:47] <TC> bluebeep? +[22:47] <jrand0m> oh sorry tc. yes, i finally have net access :) haven't seen your new eepsite beyond the board (which kicks ass), but i'll check later :) +[22:48] <duck> TC: I like the new design +[22:48] <TC> hmm, i should change the board as well to cut down on the load time +[22:48] <duck> only think you should try to disable the email function in the phpboard, now you get an error each time +[22:48] <TC> thanks duck +[22:48] <jrand0m> dropping images would be a plus +[22:49] <TC> good idea +[22:49] <jrand0m> (bluebeep is an old wardialer) +[22:49] <MrEcho> ya +[22:49] <jrand0m> (and all around fun toy) +[22:49] <duck> please keep in mind that the average age is 16 here +[22:50] * MrEcho is 24 +[22:50] * duck ducks +[22:50] * jrand0m doubts there are too many 3 year olds to balance out the geriatrics among us ;) +[22:50] *** wiht (anon@anon.iip) has joined channel #iip-dev +[22:50] <MrEcho> lol +[22:50] * TC built a blackbox once +[22:50] <jrand0m> w3wt +[22:50] <lonelynerd> is the meeting already over? +[22:50] <duck> last Q: +[22:50] *** protocol is now known as proto_afk +[22:51] <duck> how can we read the kademlia stats? +[22:51] * jrand0m hasn't !baf'ed yet lonelynerd, so ask away :) +[22:51] * MrEcho kills pcmcia support in the kernel +[22:51] <duck> just so that we understand what routerConsole.html dumps +[22:51] <MrEcho> im getting pissed +[22:51] <jrand0m> ok, the JobQueue stats I assume you mean? +[22:52] * duck guesses that it is all obvious probably +[22:52] <jrand0m> basically when I look at JobQueue stats, I check to see that the avg execution time for the Build garlic message, buld tunnel, and handle * message jobs are small +[22:52] <jrand0m> (those are the jobs that usually take the longest, and when the pending side of things gets large, everything suffers) +[22:53] <lonelynerd> (actually, i better read the logs first) +[22:53] <duck> gotcha +[22:53] <jrand0m> the .1-.6s avg pending time i've been seeing is shit poor and one of the big things i'm going to aim for once its time to tune 'em +[22:54] <jrand0m> the netDb contents liveliness and reliability are largely random numbers, as long as they're > 100. last sent successfully means when was the last time it was sent to 2 or more peers +[22:54] <jrand0m> (we resend randomly if it isn't local) +[22:54] <jrand0m> (no more than once every 5 minutes though) +[22:55] <jrand0m> is there a stat that would be helpful for people, or some other visualization that might help? (if its nontrivial i might not throw it in, but if its easy, i probably would) +[22:56] <duck> thanks +[22:57] <jrand0m> any other comments / questions / concerns / frisbees? +[22:59] <jrand0m> in that case +[22:59] * jrand0m winds up +[22:59] * jrand0m *baf*s the meeting closed +\ No newline at end of file diff --git a/pages/meeting70.html b/pages/meeting70.html new file mode 100644 index 00000000..8bf2a898 --- /dev/null +++ b/pages/meeting70.html @@ -0,0 +1,164 @@ +
+ +[22:01] <jrand0m> 0) hi +[22:01] <jrand0m> 1) administravia +[22:01] <jrand0m> 2) dev status +[22:02] <jrand0m> 3) services on i2p +[22:02] <jrand0m> 4) app status [ns, im, i2ptunnel, ...] +[22:02] <jrand0m> 5) ??? +[22:02] <thecrypto> wow, i picked a good time +[22:02] <jrand0m> 0) hi +[22:02] <jrand0m> yes you did thecrypto :) +[22:02] <jrand0m> hi +[22:02] <jrand0m> welcome to meeting 70 +[22:02] <TC> woot +[22:03] <jrand0m> 1) administravia +[22:03] <thecrypto> w00t! +[22:03] <jrand0m> mailing list, get on it for announcements / discussion / etc: (Link: http://i2p.dnsalias.net/pipermail/i2p/)http://i2p.dnsalias.net/pipermail/i2p/ +[22:04] <jrand0m> bugzilla: tell me where shit is broken (and perhaps look for ways you can help! :) (Link: http://i2p.dnsalias.net/bugzilla/index.cgi)http://i2p.dnsalias.net/bugzilla/index.cgi +[22:04] <jrand0m> i think thats it for administravia +[22:05] <jrand0m> (note that i'm just talking i2p stuff here, i don't see any iip things on the agenda) +[22:05] <jrand0m> 2) dev status +[22:05] <jrand0m> 0.2.3 as originally released had a chunk of bugs, so there have been perhaps a dozen subsequent builds, but none quite stable enough to be called 0.2.3.1 yet +[22:06] <jrand0m> i'm rebuilding the tunnel management subsystem now, since that is the source of the bugs and 0.3 (scheduled for jan 1) needs the new pooling tunnel manager anyway. +[22:07] <jrand0m> making good progress on that, I'm hoping it'll be ready for use in the next day or two (i'm testing it now) +[22:07] <jrand0m> a description of whats up with that is on (Link: http://wiki.invisiblenet.net/iip-wiki?TunnelManagement)http://wiki.invisiblenet.net/iip-wiki?TunnelManagement +[22:08] <jrand0m> duck among others have been incredibly helpful in submitting bugs, logs, and helping track down a ton of problems and memory / cpu issues. +[22:08] <jrand0m> y'all rule, I really appreciate the help +[22:09] * thecrypto pulls out the "APPLAUSE" sign +[22:09] <jrand0m> ;) +[22:09] <jrand0m> the # of routers have also been increasing... on avg we're at around 9-12 +[22:09] <jrand0m> (up from 3-5 a week ago, and 6-8 in 0.2.2 times) +[22:10] <jrand0m> the next release will improve the reliability dramatically +[22:10] <jrand0m> (aka it won't get out the door until it does) +[22:10] <jrand0m> ok, 3) services on i2p +[22:11] <jrand0m> fillament started hosting his flog on i2p :) +[22:12] <FillaMent> and I've got another trick up my sleeve =) +[22:12] <jrand0m> ooOOoo :) +[22:12] <luckypunk> tw +[22:12] <luckypunk> hm +[22:12] <luckypunk> hello. +[22:12] <luckypunk> Does it work yet? +[22:12] <jrand0m> duck started a new irc server on i2p with dcc disabled (for security reasons) plus some ident-ish features +[22:13] <luckypunk> lol +[22:13] <jrand0m> luckypunk> people with 350Mhz machines will need to wait until 0.3 is out before being able to use it effectively ;) +[22:13] <luckypunk> yes, but is i2p reliable enough for that? +[22:13] <jrand0m> (but subscribe to the i2p mailing list so you can get announcements) +[22:13] <luckypunk> i overclocked to 377 +[22:13] <luckypunk> does that help? +[22:13] <luckypunk> lol +[22:13] <jrand0m> i was chatting on that irc server the other day, until my irc client b0rked +[22:14] <jrand0m> but yes, things are a bit unreliable at the moment while the tunnel management subsystem is rebuilt +[22:14] <luckypunk> well, im happy my computer didn't molassify overnight again. +[22:15] <jrand0m> any other new services i've missed? +[22:15] <luckypunk> well, when .3 comes out...t here'll be a yahooish service. +[22:15] <luckypunk> ;) +[22:15] <jrand0m> cool +[22:15] <TC> i should run somthing else +[22:16] <TC> whats a service we need that doesnt require messing with apache? +[22:16] <jrand0m> your bbs is kick ass tc, i just can't wait until i2p is reliable enough for me to get to it consistently +[22:16] <jrand0m> you could run a telnet based games server (e.g. adventure, etc) +[22:16] <luckypunk> lol +[22:16] <TC> hah +[22:16] <FillaMent> MUSH +[22:17] <luckypunk> i'll do that... it's low demand. +[22:17] <luckypunk> and i already had about 300k of tinymush code. +[22:17] <jrand0m> yeah, the whole mush/mud/moo/ style thaang +[22:17] <luckypunk> heh +[22:17] <TC> what about ultima online? +[22:18] <thecrypto> ooh that's be fun +[22:18] <luckypunk> "Slay FreeNet Databugs!" +[22:18] <luckypunk> TC: =| +[22:18] <thecrypto> we need to get a telnet client then +[22:18] <luckypunk> maybe if we all obtained 6 ghz computers with oc-128 lines. :D +[22:18] <jrand0m> thecrypto> /bin/telnet + i2ptunnel +[22:18] <thecrypto> ...yeah +[22:18] <thecrypto> i'm sloew +[22:19] <thecrypto> :) +[22:19] <jrand0m> any other low hanging fruit for services? a mail server (pop3/imap without internet mail) would rule +[22:19] <jrand0m> (and if it could /receive/ internet email that'd rule too) +[22:21] <jrand0m> ok, 4) app status +[22:21] <jrand0m> naming service +[22:21] <jrand0m> wiht / co was here earlier, but not now +[22:21] <jrand0m> MrEcho> how goes? +*** MrEcho is echo@anon.iip (Digital_Light) +*** on channels: #iip-dev #anonymous +*** on irc via server anon.iip (Official IIP ) +*** MrEcho has been idle 3 minutes, signed on at Thu Jan 01 01:00:00 1970 +[22:23] <jrand0m> ok, perhaps we'll get back to that +[22:23] <jrand0m> hosts.txt has been growing as destinations have come online +[22:23] <jrand0m> there's a bot on the jabber server that will let you register / fetch entries +[22:24] <jrand0m> (plus the hosts.txt distributed with new installs is managed in cvs and mirrored at (Link: http://i2p.dnsalias.net/i2p/hosts.txt)http://i2p.dnsalias.net/i2p/hosts.txt) +[22:24] <jrand0m> next up, IM +[22:24] <jrand0m> hi thecrypto :) +[22:24] <jrand0m> welcome back +[22:25] <thecrypto> hi +[22:25] <thecrypto> i2pim is being started from scratch +[22:25] <thecrypto> i need to figure out how this network works but tearing apart ATalk and slowly putting it back together +[22:25] <thecrypto> so it's slowly coming along +[22:25] <jrand0m> word +[22:25] <thecrypto> i don't know if i can get group chat working +[22:25] <thecrypto> but it's an idea +[22:26] <jrand0m> you had mentioned the idea of 'tossing around the baton' style of group chat - not centralized, but still workable... I think that might be a way to go +[22:26] <thecrypto> it might involve some difficult baton passing to get it, but if anyone has an idea for how to do group chat under my model, e-mail the list i just signed onto +[22:26] <jrand0m> hehe +[22:26] <jrand0m> cool +[22:27] <jrand0m> yeah, starting off with one on one (perhaps with send/receive file) would probably be prudent +[22:27] <thecrypto> yeah, the only problem would be syncronizing the baton will be difficult +[22:27] <thecrypto> because you don't want 2 people grabbing the baton at the same time, or have the person who has the baton to drop of then et +[22:27] <thecrypto> nety +[22:27] <TC> token-ring-chat? +[22:27] <jrand0m> yup, voting systems are a pain. +[22:28] <jrand0m> right, good ol' 2phaseCommit +[22:28] <thecrypto> TC: no, basically the IM network has no central presence server +[22:28] <thecrypto> so what i'm thinking about doing is have a virtual server baton +[22:29] <duck> ok, using a bootdisk from now on... +[22:29] <jrand0m> the other option is to do group chat fully distributed: "group" just being "send these messages to peer X, Y, Z" +[22:29] <jrand0m> d'oh duck +[22:29] <thecrypto> yeah, but that's network by broadcast +[22:29] <jrand0m> not really +[22:29] <thecrypto> which is usually the stupidest idea +[22:29] <jrand0m> the messages have to get sent to peer X, Y, Z from someone sometime +[22:30] <jrand0m> its actually 1 less message than the (temporary) server based model +[22:30] <thecrypto> yes, but then each person has to keep track of the group +[22:30] <jrand0m> (and the UI can make the group 'pretty') +[22:30] <thecrypto> and now there has to be messages passed around about what the group is current +[22:30] <jrand0m> right, perhaps a control message stating "I think group A is X, Y, Z" +[22:31] <jrand0m> instead of the voting protocol +[22:31] <jrand0m> right, I'm not sure what way is best +[22:31] <jrand0m> just saying there's an option +[22:31] <jrand0m> no lo se +[22:31] <thecrypto> yeah +[22:32] <jrand0m> anyway, if you want a 'product' on bugzilla for i2pim, lemmie know, as well as if theres anything i can do to help +[22:32] <thecrypto> well, i need code for there to be bugs in first +[22:32] <jrand0m> ;) +[22:33] <thecrypto> so wait a bit and i'll have something to put on bugzilla +[22:34] <jrand0m> cool, whenever, its trivial to add +[22:35] <jrand0m> ok, i2ptunnel +[22:35] <jrand0m> i've tossed in two bug-ish things into bugzilla: (Link: http://i2p.dnsalias.net/bugzilla/show_bug.cgi?id=1)http://i2p.dnsalias.net/bugzilla/show_bug.cgi?id=1 and (Link: http://i2p.dnsalias.net/bugzilla/show_bug.cgi?id=2)http://i2p.dnsalias.net/bugzilla/show_bug.cgi?id=2 +[22:36] <jrand0m> plus there's a thing wrt some browsers b0rking on missing trailing / +[22:37] <jrand0m> getting sequence numbers into i2ptunnel would be really good, as large transfers sometimes are getting corrupted (missing message thats dropped, but sequence numbers would notice that immediately and fail fast) +[22:37] <jrand0m> other than that, the things are minor, i2ptunnel is behaving a lot better than the router :) +[22:38] <jrand0m> ok, any other apps? +[22:39] <jrand0m> there was some discussion about NAT/SOCKS the last few days on the channel +[22:39] <jrand0m> a socks enabled proxy that would let people ftp, bittorrent, etc would be really great +[22:39] <jrand0m> plus there's the discussion aum started on the i2p list wrt file sharing / cdn +[22:40] <jrand0m> (i swear i didn't tell him to make that post ;) +[22:41] <jrand0m> i probably won't be doing anything on the app side beyond help out integrating with i2p, as there's a truckload of stuff to do in the router, so if you're interested in seeing them show up, get hackin' +[22:44] <jrand0m> ok, thats it for apps +[22:44] <jrand0m> 5) ??? +[22:44] <jrand0m> hi +[22:44] <jrand0m> any comments / questions / concerns / etc? +[22:45] <ardvark> I think everyone fell asleep ;) +[22:46] <jrand0m> someone posted a question to the wiki's FAQ and it got answered after about a day, so if anyone has concerns, either post them there, to the i2p@i2p.dnsalias.net mailing list, ask it in this channel, or spraypaint it on the wall +[22:46] <duck> oh, meeting +[22:46] <jrand0m> yeah, exciting, aint it ;) +[22:46] * jrand0m slings mud at duck +[22:46] * mihi did not follow, sorry. he will stand in the corner for the next 5 minutes... +[22:46] <jrand0m> hehe +[22:47] <jrand0m> ok, thats about it. +[22:48] * jrand0m *baf*s the meeting to a close + +\ No newline at end of file diff --git a/pages/meeting71.html b/pages/meeting71.html new file mode 100644 index 00000000..1264a79d --- /dev/null +++ b/pages/meeting71.html @@ -0,0 +1,335 @@ +
+<jrandom> 0) hi
+<jrandom> 1) router status
+<jrandom> 2) i2ptunnel
+<jrandom> 3) im
+<jrandom> 4) 0.3 plans
+<jrandom> 5) time synchronization
+<jrandom> 6) ???
+<jrandom> hello mihi, polo
+<polo> hello !
+<mihi> hi jrandom
+<jrandom> 0) hi
+<jrandom> :)
+<rsk> hi
+<i2p> <duck> hi
+<jrandom> 1) router status
+<jrandom> 0.2.3.3 is out, and it seems to be working
+<jrandom> still lots to do, of course
+<jrandom> but this should be the last 0.2 release
+<jrandom> 0.3 is going to add the peer profiling to allow routers to avoid bad routers
+<jrandom> (and 0.3.1 is a revamp of the transports)
+<jrandom> hola Ophite1
+<Ophite1> Heya.
+<rsk> so more overhead for 0.3?
+<jrandom> yes and no
+<jrandom> it will have peer testing, but its going to be more focused
+<rsk> will we see a speed up with path selection?
+<jrandom> yes
+<jrandom> there are those 'liveliness' calculators, and there will be new latency and throughput calculators added
+<jrandom> plus people will be able to tweak their own preferences for particular peers
+<jrandom> e.g. if you know you want to prefer peer X over peer Y, you will be able to give them a weighting bonus of
+ some random points
+<mihi> will there be a clean shutdown? *g*
+<jrandom> thats actually a good question mihi
+<jrandom> i2p is getting to the point where it needs an admin interface.
+<jrandom> the longest Job thats holding up its operation is the GenerateStatusConsoleJob
+<jrandom> which can now take up to 4-6 seconds
+<jrandom> (holding everything else up)
+<jrandom> that needs to go async and on demand.
+<jrandom> but i dont want to write a web listener / etc.
+<jrandom> perhaps the reverse - a servlet that starts the router and communicates with it
+<mihi> you don't need a full web server. just when you see GET, return your data.
+<jrandom> right
+<jrandom> you're right, that stuff should be in 0.3 as well.
+<mihi> and when you see something else (like SHUTDOWN), do as you please. of course only from localhost ;)
+<jrandom> aww c'mon
+<mihi> then someone can make a nice admin program
+<jrandom> right
+<mihi> you had some triggers by files, didn't you? are they documented somewhere?
+>>> mihi [~mihi@ags9-d9ba536a.pool.mediaWays.net] requested PING 1072820995 from jrandom
+<jrandom> those were in IDN, not the router itself
+<jrandom> but that might be a good way to go
+<jrandom> its a trivially easy system
+<jrandom> good idea, lets go that way
+<jrandom> (and i can just reuse that code :)
+<i2p> <duck> this magical filestuff starts to look like plan9
+<jrandom> lol
+<mihi> but file triggers require polling
+<jrandom> right mihi, reading a directory every 30s aint that bad
+<mihi> but a ServerSocket#accept is cheaper.
+<mihi> as it won't eat any time. (provided a good OS)
+<mihi> okay, file triggers are better than nothing, sure.
+<jrandom> server socket would allow remote admin
+<jrandom> (when appropriate)
+<jrandom> dunno.
+<jrandom> something to be worked out.
+<jrandom> (or if someone wants to jump on it and code... :)
+<mihi> and server socket could deliver the routerConsole as well.
+<jrandom> right
+<jrandom> ok, 2) i2ptunnel
+<jrandom> :)
+<jrandom> i2ptunnel still rules, and its looking like we want to add a socket based API to control it
+<i2p> <anon> aum's ic2cp2pc plans are off for now?
+<jrandom> yes, ci2cp is dead in the water, replaced with the socket based API to control I2PTunnel
+<jrandom> I think I may be able to throw on that API in the next few days, so he can get churning on the impl
+<mihi> just use a socket, make in.readLine() and feed that line to runCommand() ;)
+<rsk> what does the api give i2p?
+<jrandom> pretty much mihi (except it formats the results and send them back in a standard way)
+<mihi> with an appropriate "logger" to send the commands back.
+<mihi> s/commands/results/
+<jrandom> rsk> it lets application developers build client and server sockets over i2p without dealing with I2CP's
+ encryption needs
+<jrandom> right right
+<jrandom> i2ptunnel /does/ have an overhead for situations where there are lots of i2ptunnels
+<jrandom> regardless of the JVM
+<jrandom> i2ptunnel clients create a new destination per client contacted, and the router will perform much worse as
+ the number of local destinations grows.
+<rsk> ah
+<jrandom> this is due to the anonymity needs of the network tied to how our encryption works
+<jrandom> for applications who just want to open a tunnel or two to a peer, this new api will RULE
+<jrandom> but for applications that need to talk to lots of other peers, I2CP is the way to go.
+<jrandom> (since that is a single destination, multiplexed by i2cp)
+<jrandom> I suppose its the old TCP vs UDP balance, in a way
+<jrandom> mihi> do you have any thoughts, or some ideas for the future of i2ptunnel?
+<rsk> hows the work on the ip over i2p, or the vpn stuff going?
+<mihi> jrandom: someone write a good streaming api, and then lets i2ptunnel use it.
+<mihi> same for naming server.
+<mihi> perhaps add some sequence numbers if no one does the things above.
+<mihi> which will mean an incompatible change.
+<jrandom> incompatible changes aren't bad, we're early in dev
+<jrandom> (if we could increase the size of of the IDs too to two or four bytes per side as well?)
+<mihi> the streaming api will be an incompatible change nevertheless. and if i2p worked, we don't need sequence
+ numbers.
+<jrandom> rsk> on hold, until someone has time to run with it?
+≡ rsk/#i2p thinks incompatible chages are the best kind
+<jrandom> right mihi
+<mihi> ID should be 3 byte atm, so why *increase* to 2 bytes?
+<jrandom> mihi> actually, I'd like to slowly deprecate mode=GUARANTEED and implement that in the streaming api
+≡ mihi/#i2p too
+<jrandom> leaving i2p = IP, not TCP or UDP
+<jrandom> damnit I wish I had another 14 hours in the day.
+<mihi> only 14? ;)
+<jrandom> ;)
+<jrandom> aren't the 3 byte ids derived by both sides of the con? or maybe i'm just confused
+<mihi> each side has an ID of 3 bytes, hovever, only one must be sent at a time.
+<jrandom> perhaps I'll implement the streaming API, rip out GUARANTEED, and add that socket controller next.
+<jrandom> ah ok
+<mihi> see /apps/i2p/i2ptunnel/java/src/protocol.txt
+<jrandom> right right
+<mihi> btw, who misplaced that file *there*?
+≡ jrandom blames eco ;)
+<jrandom> wait, naw, you put 'em there
+<jrandom> didnt you?
+<jrandom> oh wait, no I imported them
+≡ jrandom blames self for being stupid.
+<jrandom> (la la la)
+<jrandom> damn. ok, yeah, working on the streaming API and the socket controller will allow me to mull over the peer
+ testing / profiling / selection manifesto
+<jrandom> I'll post that in a few days for comment
+<jrandom> (and it'll get my head out of the router. variety++)
+<jrandom> mihi> anything else on i2ptunnel?
+<mihi> not that i know
+<jrandom> coo'
+<jrandom> (thanks again for taking the time to chime in on this stuff, I know you're busy with fiw and the rest)
+<jrandom> ok, thecrypto isn't here, but he's making progress on the IM app.
+<jrandom> (thats agenda item 3)
+<jrandom> 4) 0.3 plans
+<jrandom> 0.3.0 ~= peer profiling stuff, and now it'll also include the streaming api and that socket controller for
+ i2ptunnel
+<jrandom> but, if you couldn't guess, its not going to be released on jan 1
+<jrandom> jan 15 is an outside possibility. we'll see how things go.
+<jrandom> 0.3.1 isn't a full month of work, so it may not need to get bumped.
+<jrandom> other than that, the roadmap is still pretty much on track and representative of where we're moving
+<jrandom> 5) time synchronization
+<jrandom> a new faq is posted at http://wiki.invisiblenet.net/iip-wiki?I2PTiming
+<jrandom> mihi, you had a suggestion about the fourth option there (building our own in-i2p timing)?
+<jrandom> hi brawl
+<mihi> yep.
+∙φ∙ brawl is now known as eco_
+<eco_> hi guys
+<jrandom> oh heya eco
+<mihi> you should connect 3 random nodes and remember the diff between the avg time and local time.
+<jrandom> we just discussed the streaming API / tunnel api
+<mihi> and then hack up your own getTimeMillis that corrects that.
+<Ophite1> mihi: No, you shouldn't.
+<jrandom> mihi> so if an attacker creates 1000 nodes with the wrong time, everyone gets screwed
+<jrandom> (since avg would skew randomly in between)
+<mihi> if an attacker creates 1000 nodes, everyone gets screwed anyway...?
+<rsk> wouldnt that be self corecting?
+<Ophite1> mihi: OK, 3.
+<jrandom> no, we should be able to handle that mihi.
+<mihi> okay, then only use avg, if standard deviation is lower than 1sec or so.
+<rsk> if everyone has the same time your ok, even if that time is wrong, right?
+<jrandom> rsk> if all 1000 nodes were in sync, but what if they're all random
+<mihi> only use times that are close enough together. if not, take 3 new nodes.
+<jrandom> mihi> right, we could implement NTP (which basically does what you say, using a series of candidate averages
+ to iteratively close in on the correct time
+<mihi> but we need not care of everything (like ping latencies), as ntp does.
+<Ophite1> if we did not, mihi, time would slowly creep backwards.
+≡ mihi/#i2p thinks that is better than let users set their time individually.
+<jrandom> so anyone who randomly picks 3 of those skewed nodes gets sent onto their own private network?
+<jrandom> what about that third option -
+<jrandom> i2p has a component that checks with a real NTP server via NTP or SNTP
+<mihi> if you have only skewed notes in your netDB, you are on that private net as well...
+<jrandom> rather than reimplementing the wheel
+<Ophite1> while I partially like that one...
+<Ophite1> NTP isn't signed, it's subject to an MITM attack.
+<Ophite1> or dns cache poisoning for, say, time.nist.gov
+<jrandom> right Ophite1, though with 200,000+ SNTP or NTP hosts, thats a large set to attack.
+<jrandom> we would definitely not sync of time.nist.gov.
+<Ophite1> connections from i2p to the NSA's time server might raise a few eyebrows, ne? :)
+<jrandom> and if an attacker goes after time.nist.gov, everyone everywhere is affected
+<jrandom> heh
+<mihi> then we combine both. ask a "real" ntp server and your neighbor. if both say the same, it's okay.
+<jrandom> so even /more/ code ;)
+<jrandom> but yeah, thats reasonable.
+<Ophite1> That's interesting. And if they don't?
+<Ophite1> pick another ntp server?
+<jrandom> refuse the peer.
+<mihi> try other ntp server and another peer.
+<mihi> until you have a match. then refuse all prev peers.
+≡ mihi/#i2p types slower than jrandom :(
+<Ophite1> match within a certain threshold, say 1sec?
+<jrandom> 1s would be good.
+<jrandom> accepting peers up to 30s or so (to deal with lag)
+<Ophite1> is 1 sec okay on HEAVILY LADEN connections?
+<jrandom> 1s for syncing, 30s for comm.
+<Ophite1> I've seen latency on DSL get to 5 seconds when doing evil things to it.
+<jrandom> with tcp or udp?
+<Ophite1> but then, in that case, that host might not be the one you want to sync time to anyway ;)
+<jrandom> right
+<Ophite1> udp.
+<jrandom> hmm 'k
+<Ophite1> you'd have thought it'd get dropped :)
+<i2p> <duck> I think that the problem is more letting the user know that there is a problem
+<jrandom> duck> that is true.
+<i2p> <duck> only after walking through big logs they see that their clock is off (if they find it)
+<Ophite1> Maybe. Sort of.
+<i2p> <duck> or that the port is already bound
+<jrandom> an admin interface would be nice.
+<i2p> <duck> the world is better with everybody using NTP connected to their local stantrum (sp) 2 server
+CTCP Cloaking is now [On]
+<jrandom> perhaps we'll have a 0.4 release with a bunch of cleanups and end user things, prior to going 1.0?
+<jrandom> right (stratum)
+<i2p> <duck> only windows clients are not likely to have that
+<i2p> <duck> but they are also not likely to be stable
+<jrandom> windows has NTP
+<i2p> <duck> so who cares
+<Ophite1> duck: Windows XP and Windows Server 2003 include NTP.
+<jrandom> a shitload easier than with unix too
+<Ophite1> sync'ed by default to time.windows.com iirc.
+<jrandom> with drop down options for others
+<Ophite1> It's an essential part of Windows Product Activation.
+<Ophite1> can't expire if you don't know the time :)
+<jrandom> heh
+<mihi> no option at my university... all clocks are 1 hour to 5 hours off. but i might not be allowed to run i2p there
+ anyway...
+<Ophite1> mihi: i2p should try especially hard to work in such a situation...
+<jrandom> mihi> awesome! you can help test out the hidden operation :)
+<jrandom> as an aside, I'm going to be doing some traveling this summer
+<jrandom> i'll likely be offline, without my laptop.
+<i2p> <duck> sidethought: ntp.duck.i2p :)
+<Ophite1> Look at it like this: Brianna Kazaa downloads cool new anonymous filesharing client which her best friend
+ told her was really cool and lets you chat to people secretly and stuff. Do we want to tell her that she
+ needs to set her clock within 30 seconds (how will she get some?)? Or do we want it to just work?
+<jrandom> but I'm going to make sure I can still be on I2P with just public terminals.
+CTCP Cloaking is now [Off]
+<jrandom> no brainer Ophite1. just work (with docs for geeks)
+<jrandom> duck> bootstrap ;)
+<jrandom> and i2p will /not/ require root.
+<Ophite1> That's my point.
+<Ophite1> jrandom: would you run a router on a box you didn't have root to?
+<jrandom> so yeah, a mix between option 3 and 4
+<Ophite1> option 3.5 sounds cool to me ;)
+<jrandom> Ophite1> i'd run a hundred of them :)
+<mihi> option 3.1415926...
+<jrandom> (and move on to the next lab, run a hundred more)
+<Ophite1> Ooh. Pie. Tasty.;)
+<Ophite1> jrandom: I said you didn't have root on. Amateur. :)
+<jrandom> lol
+<jrandom> so thats basically where we're looking.
+<jrandom> until the time stuff is implemented, everyone should use option 1 or 2.
+<jrandom> for option 2, if someone could write up some docs, I'd appreciate it
+<Ophite1> that's acceptable for now as we are Not Yet Ready for Brianna Kazaa et al ;)
+<mihi> jftr: i won't test "hidden operation". my univ account has already been disabled once and i don't want it
+ another time blocked...
+<Ophite1> mihi: You are the best test we could possibly have.
+<jrandom> Ophite1 > not for test.
+<jrandom> 'k mihi, we'll find a way, and once its ready you'll be able to use it.
+<Ophite1> OK, maybe not test. Some unis get shirty enough to chuck you out rather than just block you.
+<Ophite1> I know someone at the most anti-filesharing pro-RIAA university in the USA. He runs a 2gbit dumpsite.
+<jrandom> lol nice
+<Ophite1> I appreciate that very, very few people are this ballsy.
+<jrandom> ok, thats it for time synchronization.
+<jrandom> eco_> hi. any bt stuff you want to talk about? {or save till next week}
+<Ophite1> but bear in mind the majority of the internet is in future probably going to become university/corporate.
+ i2p might be banned. i2p might WELL be considered abuse by major ISPs. i2p will have to work anyway.
+<Ophite1> I have a few interesting ideas along that angle I will present at a future date.
+<jrandom> word
+<Ophite1> (transport)
+<rsk> i2p is considered abuse by major ISPs, read your contract
+<Ophite1> rsk: running a distributed proxy cache?
+<rsk> running any 'server'
+<Ophite1> rsk: Not unless it relays to SMTP or WWW.
+<jrandom> running services of any time
+<jrandom> right
+<Ophite1> rsk: Hehe, I have a solution to that ;)
+<eco_> jrandom: can give a brief update
+<jrandom> floor is yours :)
+<eco_> i'm porting the java-based bittorrent client snark (www.klomp.org/snark) to get aquainted with i2p
+<eco_> first port runs on top of i2ptunnel, directly calling the java classes
+<eco_> current state: does work with 2 peers, things get messed up with > 2, tunnels aren't cleaned up, so restarting
+ is painful
+<eco_> eta: this weekend
+≡ eco_/#i2p realises that this might be considered > 2003
+<jrandom> w00t!
+≡ jrandom hacks time.nist.gov
+<eco_> a "real" port would probably cut the overhead of the tunnels, but that's a next step
+<jrandom> cool
+≡ eco_/#i2p gives floor back to mc jrandom
+<jrandom> 'k, I think that was it
+<jrandom> 6) ???
+<jrandom> anyone have anything else?
+≡ eco_/#i2p would like to express his thanks for the job well done by jrandom cs up to now
+<eco_> and that sleep has some use for home sapiens, though jrandom seems to prove this false
+<jrandom> ;)
+<jrandom> what are y'all's thoughts on meeting here as opposed to iip, until i2p is reliable enough?
+<jrandom> personally, I'm tired of meetings being cut to shreds every week.
+<i2p> <anon> lilo sucks!
+<eco_> we might be shutting people out by going here
+<jrandom> we are, I know.
+<jrandom> if we can get an iip<-->here bridge
+<i2p> <duck> IIP is shutting ppl out each day
+<jrandom> that'd be good.
+<jrandom> right.
+<jrandom> iip is, unfortunately, unusable for a reliable development community.
+<i2p> <duck> http://banaan.zeelandnet.nl/open/changate.html
+<i2p> <duck> that is the code where eyeKon etc is based on
+<jrandom> and while I like to go off coding on my own, y'all come up with really good ideas and do good stuff that is
+ essential
+≡ rsk/#i2p is writing a windows update script
+<i2p> <duck> theoretically it could connect to 3 servers and mirror each of them
+<jrandom> word duck, perhaps I'll try to get one running on i2p.dnsalias.net
+<jrandom> ping flood from hell ;)
+<eco_> irc at duck.i2p was pretty good today, beat iip
+<jrandom> agreed
+<jrandom> dropped me a few times though.
+<jrandom> perhaps it'll be more reliable next week
+<eco_> it's in your hands :-)
+<jrandom> reliability probably won't improve until 0.3, which is ~2 weeks out
+<jrandom> (1 week to do the tunnel/streaming stuff, 1 week for peer profiling / testing)
+<jrandom> then there'll be whatever bugs that introduces :)
+<jrandom> though I should say I was really excited to stream audio from aum last night
+<jrandom> and ardvark was able to stream for 42 minutes without buffering!
+<jrandom> so perhaps we can be reliable enough
+<jrandom> (my local router is phttp only, which is probably a slight cause)
+<jrandom> ok, anyone have anything else?
+<i2p> <duck> cant thing of anything
+≡ eco_/#i2p can't either
+≡ jrandom winds up...
+≡ jrandom *baf*s the meeting closed
+
+
\ No newline at end of file
diff --git a/pages/meeting72.html b/pages/meeting72.html
new file mode 100644
index 00000000..3d65dc39
--- /dev/null
+++ b/pages/meeting72.html
@@ -0,0 +1,657 @@
+
+[22:02] <jrand0m> agenda:
+[22:02] <jrand0m> 0) hi
+[22:02] <jrand0m> 1) http://i2p.dnsalias.net/pipermail/i2p/2004-January/000069.html
+[22:02] <jrand0m> 2) [discussion]
+[22:02] <wiht> Can I add installer to agenda?
+[22:02] <jrand0m> 0) hi
+[22:02] <jrand0m> oh yes, certainly!
+[22:02] <jrand0m> we're trying something new this week
+[22:03] <wiht> You can put it at the end of the agenda.
+[22:03] <jrand0m> rather than the old talktalktalkreplytalktalktalk, the http://i2p.dnsalias.net/pipermail/i2p/2004-January/000069.html post describes most of the things I had planned on saying
+[22:03] * mihi_ has joined #i2p
+[22:04] <jrand0m> instead, we're trying this week to make the meeting more discussion oriented - things people want to talk about from that post, any follow up posts, and/or anything else people want to discuss
+[22:04] <jrand0m> such as a new installer
+[22:05] <jrand0m> so, that said, people should start by checking out that email/post and we'll go from there :)
+[22:05] * mihi_away is now known as mihi
+[22:05] * kaji reads the post
+[22:05] * mihi_ is now known as mihi_backup
+[22:06] <jrand0m> 27 users with only one dup! w0w
+[22:07] * dm is now known as dup
+[22:07] <jrand0m> ok, when people have read that, perhaps we can start by going over the index and seeing if there's anything someone wants to add / comment on / discuss?
+[22:07] <mihi> jrand0m: where do you know from that there are no more dupes?
+[22:07] <jrand0m> heh thanks dm
+[22:07] <jrand0m> mihi> I installed keyloggers on everyone's computers (bwhahahaha)
+[22:07] <wiht> I would like to add installer as topic 10, and possibly naming service as topic 11.
+[22:07] * mihi sent the followup to the wrong address :(, resending...
+[22:08] <jrand0m> good call wiht
+[22:09] <MrEcho> mrecho's new dns is in the works
+[22:09] <jrand0m> cool mihi, yeah I was wondering ;)
+[22:09] <kaji> how is dns coming along? - ah
+[22:09] <jrand0m> MrEcho> your post, right?
+[22:09] <MrEcho> working on the post
+[22:10] <jrand0m> ok, in the meantime, anyone have anything on 1) streaming? or should we jump to 2) I2PTunnel, TunnelManager, and i2pmgr?
+[22:10] <lucky> good lord... i could spend the rest of my life attempting to figure out these dependecnies.
+[22:10] <wiht> So let's say DNS/NS as topic 11.
+[22:10] <jrand0m> sounds good wiht
+[22:10] * duck walks in
+[22:11] <jrand0m> ev'nin duck
+[22:11] <mihi> ad 1, i committed code for i2ptunnel using the streaming api
+[22:11] <jrand0m> ah right, awesome mihi :)
+[22:11] <lucky> hi duck
+[22:11] * twosandals has quit IRC (Leaving)
+[22:11] <kaji> jrand0m can several sevices use the same key if they are on diffrent ports?
+[22:11] <jrand0m> no kaji
+[22:11] <mihi> btw: why do your ant files always delete the jar before rebuilding it?
+[22:11] <jrand0m> mihi> paranoia
+[22:12] <mihi> stealing me time with debugging, i'd say ;)
+[22:12] <jrand0m> kaji> in i2p, a key /is/ a port, essentially
+[22:12] <jrand0m> heh
+[22:12] <kaji> ah
+[22:13] <jrand0m> mihi> if you want to update that, as long as it'll build the jar if the class files change thats fine
+[22:13] <mihi> if the file is newer than all files in it, and could skip it otherwise.
+[22:13] <jrand0m> right
+[22:13] <mihi> and for paranoia it is better to add a <depends> task
+[22:13] <jrand0m> agreed
+[22:13] <FillaMent> yo yo
+[22:13] <jrand0m> 'lo FillaMent
+[22:14] <jrand0m> ok, 2) i2ptunnel / tunnelmanager / i2pmgr
+[22:14] * TC has joined #i2p
+[22:15] <human> i did a little hacking to make the TunnelManager return the job ids when "openclient" or "openserver" commands are called
+[22:16] <jrand0m> kickass :)
+[22:16] <human> this way, apps using the TunnelManager know which job to close later, without parsing the "list" output
+[22:16] <jrand0m> yeah, I've not been too comfortable with using tunnelmanager's list and close, since multiple clients can b0rk each other that way
+[22:17] <jrand0m> we'll get that patch in there right after the meeting. gracias human :)
+[22:17] <human> it involved making I2PTunnel.runCommand return some stuff (currently a Property)
+[22:17] <human> s/Property/Properties/
+[22:17] <jrand0m> oh right, there's some things to modify in that before getting it into the code
+[22:18] <human> but mihi would prefer to add some asynchronous callbacks to the Logging clas, as far as i understand...
+[22:19] <jrand0m> right - so that things can get information from the tasks immediately, without waiting for it to finish
+[22:20] * mihi has quit IRC (EOF From client)
+[22:20] <human> jrand0m: the idea is: let's I2PTunnel.runCommand() return immediately, and eventually use callbacks to get more info, right?
+[22:21] <jrand0m> right
+[22:21] <jrand0m> so the tasks fire callbacks whenever there is data to distribute
+[22:21] * mihi has joined #i2p
+[22:21] <human> well, IMHO there is another question: «how many java apps (will) use I2PTunnel.runCommand() asynchronously?» *All* the apps currently using I2PTunnel (even via the TunnelManager) are perfectly fine with synchronous (even if long) .runCommand() calls, and making all the stuff asynchronous would only make things more complicated (IMHO)
+[22:22] * mihi uses it via the gui
+[22:22] <human> (well, "all" means the TunnelManager and apps parsing the Tunnel manager output)
+[22:22] <jrand0m> right, the gui will hang while the command is executed
+[22:22] <mihi> and entering the next 3 tunnel open commands is blocked while the first is running
+[22:23] <human> mihi: ok, i didn't know about your app... then we need some solution :-)
+[22:24] <human> mihi: asynchronous .runCommand() behaviour would require to revise the TunnelManager
+[22:24] <mihi> human: when (iyo) should runCommand terminate? when the tunnel is built, when the connection got through?
+[22:25] <mihi> "destination unreachable" will be known *after* the first connection attempt was made.
+[22:25] <jrand0m> the command pattern would have the execute() return only after it was complete.
+[22:26] <mihi> what does *complete* mean?
+[22:26] <jrand0m> (so if we're following the command pattern, runCommand would block until everything required to do that command was complete)
+[22:26] <human> mihi: eheh, that's the question :-)
+[22:26] <jrand0m> complete for "server 1234 privkeys" would be when the server can accept connections on port 1234
+[22:26] <human> mihi: well, for TunnelServer's IMHO it should return after tunnel creation
+[22:27] <jrand0m> complete for "client 234 peer" would be complete when a connection to port 234 would successfully reach peer
+[22:27] <jrand0m> at least, thats my take
+[22:27] <mihi> how can you determint the latter?
+[22:27] <jrand0m> I really don't feel strongly either way
+[22:27] <jrand0m> perhaps a ping?
+[22:27] * Sciatica has joined #i2p
+[22:28] <mihi> and if the peer goes down just after the ping?
+[22:28] <mihi> imo it is impossible to do network apps without callbacks
+[22:28] <jrand0m> right
+[22:28] <mihi> or lotsa threads, and i prefer callback on threads synchronized to death
+[22:29] <jrand0m> perhaps it should only return after its able to /attempt/ to connect?
+[22:29] <jrand0m> or maybe the command pattern isn't the desired pattern
+[22:29] <mihi> that's what it's doing now. and what result should it return then?
+[22:30] <mihi> the point is that you want to have a result (different from an int for the connection id)
+[22:30] <jrand0m> right, for the client command, one wants the job (so it can be closed later), but for the genkey command, one wants the public key and private key
+[22:30] * mihi cannot think of any other info that is known at that point.
+[22:30] <jrand0m> agreed, me neither.
+[22:31] <dup> 0!
+[22:31] <mihi> and genkey should wait? okay, if you think so.
+[22:31] <human> mihi: well, something like a status ("ok" or "error") and error messages...
+[22:31] <mihi> human: error messages will be "too late" imo
+[22:31] <mihi> but do what you want...
+[22:32] <mihi> as long as you make it work with the streaming api afterwards as well...
+[22:32] <jrand0m> the pain points human is addressing are the kludges in the TunnelManager that parses the logging messages. but I agree, as long as we can expose that information via the logging interface, thats fine
+[22:32] <dup> mihi is wise.
+[22:32] <human> human: some can be communicated immediately (e. g. when the tunnel port is still in use)
+[22:32] <mihi> human is talking to himself ;)
+[22:32] <human> oops! :-)
+[22:35] <human> maybe we should see what kind of applications are being built upon I2PTunnel
+[22:35] <human> the asynchronous interface is the Right Thing(TM), but it's more complicated to use
+[22:35] <jrand0m> I think it would be best if we could keep the same functionality for the current software - including the gui.
+[22:35] <FillaMent> maybe I'm jumping in ignorantly, but perhaps a method like one might find many that deal with HTTP: getHeader(String headerName)
+[22:35] <FillaMent> smake me as needed
+[22:35] <FillaMent> smack
+[22:36] * jrand0m smake's FillaMent
+[22:36] <human> and the TunnelManager doesn't need it (since it will *never* be able to properly support asynchronous events, due to its nature)
+[22:36] * kaji has a completely off-topic idea
+[22:36] * FillaMent resigns himself to advocacy =)
+[22:37] <human> but if mihi application needs to monitor the tunnels state, then the asynchronous interface is a Must(TM)
+[22:37] <jrand0m> human> java -jar lib/I2PTunnel.jar\n. We need to support async.
+[22:37] <kaji> i2p as a java applet so you can run it from strange computers quickly by going to a website
+[22:37] * Sciatica has quit IRC (EOF From client)
+[22:37] <human> jrand0m: yes, then we must rework the TunnelManager :-)
+[22:37] <jrand0m> kaji> i2p 3.0 :)
+[22:38] <jrand0m> agreed human, the tunnelmanager implementation was a quick and dirty impl
+[22:38] <jrand0m> do you think you could look into how that'd need to proceed?
+[22:38] * human can volunteer to adapti the TunnelManager to the asynchronous interface, when ready
+[22:38] <jrand0m> w00t :)
+[22:40] <jrand0m> ok, are we ready for agenda item 3) I2COCP
+[22:40] <human> otherwise, it would be possible to create sync and async methods for I2PTunnel
+[22:40] <jrand0m> true
+[22:40] <jrand0m> but duplication might be overkill when a little refactoring would serve the purpose
+[22:41] * baffled has quit IRC (Leaving)
+[22:41] <duck> personal concern about the tunnels: apps not closing them, so your whole tunnelmanager becomes flooded
+[22:41] <human> jrand0m: yes, we should choose the easiest solution between reworking the TunnelManager or adding new APIs to I2PTunnel :-)
+[22:42] <jrand0m> thats a good point duck. currently there are no timeouts / expirations, and it assumes the apps using the tunnelManager are well behaving (and that the tunnelManager has no bugs [hah!])
+[22:43] <mihi> apropos new apis: should the Streaming api classes "replace" the old ones or should it be possible to use both (w/ different commands?)
+[22:43] <jrand0m> mihi> I think the streaming ones will want to replace, since once the streaming api is solid mode=GUARANTEED will go away
+[22:43] <jrand0m> (and hence the old ones wont work)
+[22:44] * MrEcho 's email sent
+[22:46] <jrand0m> anything else for the tunnel discussion? (this obviously isn't the end of tunnel discussions overall ;)
+[22:47] * dup is now known as dm
+[22:47] <jrand0m> ok, I2COCP
+[22:47] <jrand0m> this was just something human suggested the other day and it seems to fill a gap thats not currently met. but I think we want to hold off on implementing until we have something that wants to use it :)
+[22:48] <wiht> That is a somewhat long name, even abbreviated.
+[22:48] * jrand0m now calls I2COCP "Wilma"
+[22:48] <human> jrand0m: well, i was going to write the same words :-)
+[22:48] <jrand0m> heh cool
+[22:49] <jrand0m> ok, jumping on to 4) roadmap
+[22:49] <human> jrand0m: IMHO, in general, there should be a way for non-java apps to have a somewhat full access to the I2P network
+[22:49] <jrand0m> agreed
+[22:49] <jrand0m> the intent is that they'd use I2CP
+[22:50] <jrand0m> (as all java apps, i2ptunnel and the streaming library included, use that)
+[22:50] <human> jrand0m: yes
+[22:50] <MrEcho> I2PDNS "Janessa"
+[22:50] <jrand0m> but you're right, they'd want streaming too, so either tunnelmanager->i2ptunnel or i2cocp->streaming lib
+[22:50] * jrand0m has never met a Janessa
+[22:51] * Sciatica has joined #i2p
+[22:51] <jrand0m> ok, so, yeah, the roadmap has been updated. no real big changes beyond pushing back 0.3 and 0.3.1 by 2 weeks, adding 2.0 info, and some more 1.0 criteria
+[22:51] <human> jrand0m: yeah, there should be "TCP" and "UDP"-like protocols for I2P, with complete protocol event reporting, accessible from non-java apps
+[22:52] <MrEcho> human, sounds good
+[22:52] <jrand0m> I want there to be every possible interface, but I don't want to overcommit with too many interfaces to be supported
+[22:52] * human wanted I2COCP (or whatever) for his I2P twisted transport (see http://www.twistedmatrix.com/), but for now he will happily kludge around the TunnelManager :-)
+[22:53] * w0rmus has quit IRC (Lost terminal)
+[22:53] <jrand0m> word. that'd be best for now
+[22:54] <jrand0m> ok, any comments on the roadmap?
+[22:55] <jrand0m> [nothing to see here, la la]
+[22:55] <jrand0m> ok, 5) i2pIM
+[22:55] <jrand0m> thecrypto isn't here, so we can just wait for a post to i2p@ with updates :)
+[22:55] <wiht> We have Jabber now, if I am not mistaken. Do we still need i2pIM?
+[22:55] <jrand0m> yes
+[22:55] <jrand0m> jabber has a server that gets cleartext.
+[22:56] <wiht> Oh. Very well, then; I was not aware of this.
+[22:56] <jrand0m> thats two strikes (a server, and cleartext)
+[22:56] <jrand0m> its a good solution for some things though, certainly
+[22:56] <jrand0m> actually, once thing I was thinking about this morning was if we could get i2pIM and i2psnark merged together, that would be Good.
+[22:57] <jrand0m> (but once thing at a time)
+[22:57] <jrand0m> actually, speaking of the devil, 6) i2psnark :)
+[22:57] <human> jrand0m: i sometimes used jabber with gnupg...
+[22:57] <jrand0m> for >2 person chats?
+[22:58] <jrand0m> for one on one, I totally agree there are existing solutions
+[23:01] <jrand0m> ok, on to a fun one, 7) introducing I.Toopie :)
+[23:01] <human> how would you implement encrypted >2 people chats? a shared private key?
+[23:01] <jrand0m> yes human
+[23:01] <jrand0m> or through n! shared keys in the group
+[23:02] <human> well, maybe it could be done above the existing jabber protocol...
+[23:02] <mihi> human: a shared symmetric key sent to all participants
+[23:02] <jrand0m> the hard part is dealing with joins & leaves - key rotation /etc
+[23:03] * Sciatica has quit IRC (Ping timeout)
+[23:03] <jrand0m> its in no way a trivial issue. its really really really hard.
+[23:03] * mihi acks
+[23:03] * human agrees
+[23:04] <jrand0m> (which is why having an app designed for it rather than trying to kludge it on top of another protocol may be worthwhile)
+[23:04] <jrand0m> but thecrypto can best describe his plans
+[23:04] <jrand0m> (though its my understanding he's still open to ideas for how to deal with groups)
+[23:05] * Sciatica has joined #i2p
+[23:06] <jrand0m> ok, moving on :) [further discussion on i2p@, etc]
+[23:06] <wiht> What is I.Toopee, though?
+[23:06] <lucky> the mascot...
+[23:06] <jrand0m> I.Toopie is a guy holding a yellow mask in front of his face
+[23:06] * lucky shudders.
+[23:07] <lucky> uh huh.
+[23:07] <lucky> can i see it?
+[23:07] <jrand0m> http://wiki.invisiblenet.net/iip-wiki?I2PLogo
+[23:07] * mihi_backup has quit IRC (EOF From client)
+[23:07] <lucky> i have added java to my compile queue...
+[23:07] <lucky> but.. lol
+[23:07] <lucky> i already have 7 things running
+[23:07] <lucky> it'll be a while.
+[23:08] <lucky> aw, cute :P
+[23:08] <MrEcho> lol
+[23:08] <jrand0m> there have been lots of cool logos (I can't believe we've had the logo contest going on for 3 months!), and it looks like we've got some strong potential with I.Toopie. in its simplicity, its conception, and its versatility.
+[23:08] <jrand0m> and, yeah, its cute ;)
+[23:08] <mihi> are some imgs broken or is my browser buggy?
+[23:08] <jrand0m> yeah, some are broken
+[23:09] <jrand0m> (they were put on temporary hosting sites 3 months ago)
+[23:09] <MrEcho> I.Toopie's stick is now all yellow ...
+[23:09] <MrEcho> changed lastnight
+[23:09] <jrand0m> it is?
+[23:09] <jrand0m> people should UPDATE THE WIKI then
+[23:09] <jrand0m> ;)
+[23:09] <MrEcho> hehe
+[23:09] <MrEcho> i dont have the pic anymore .. sorry
+[23:10] <wiht> I see the pictures with Opera, but not with Mozilla somewhy.
+[23:10] <jrand0m> you can see http://img.villagephotos.com/p/2003-10/437060/badass.jpg ?
+[23:10] <jrand0m> (thats one of the images on that page)
+[23:11] <duck> Access Denied (User Account Disabled)
+[23:11] <jrand0m> yeah, same here.
+[23:11] <MrEcho> i can see it
+[23:11] <jrand0m> but yes, DrWoo has done some kickass stuff with I.Toopie
+[23:11] <MrEcho> moz 1.5
+[23:11] * soros has quit IRC (EOF From client)
+[23:11] * mihi_away has joined #i2p
+[23:11] * lucky has quit IRC (EOF From client)
+[23:12] <jrand0m> same here MrEcho. strange.
+[23:12] <wiht> MrEcho: I am using Mozilla 1.4.
+[23:12] <jrand0m> (same as in I'm on moz 1.5 and I'm getting access denied)
+[23:13] * jrand0m looks forward to a tray icon w/ i.toopie :)
+[23:13] <jrand0m> ok, moving on to 8) chess server
+[23:14] * Sciatica has quit IRC (Ping timeout)
+[23:14] * ion has quit IRC (Ping timeout)
+[23:14] <jrand0m> the latest hosts.txt (http://i2p.dnsalias.net/i2p/hosts.txt) contains the reference for chess.fillament.i2p
+[23:14] <jrand0m> you can use any old FICS client or just telnet to that and play away :)
+[23:14] <jrand0m> (yay)
+[23:15] <kaji> is there a goog fics client for windows?
+[23:15] <jrand0m> dunno, I ended up using telnet
+[23:15] <wiht> Does eboard work?
+[23:15] <jrand0m> (which had some fairly tough rampup to learn the commands)
+[23:15] * ion has joined #i2p
+[23:16] <jrand0m> dunno
+[23:16] * BpX has joined #i2p
+[23:16] <wiht> I will try it later.
+[23:16] <jrand0m> cool, if you could post up what you find, that'd be great
+[23:17] <jrand0m> ok, 9) DHT
+[23:17] * wilde has quit IRC (Ping timeout)
+[23:17] <jrand0m> we still don't have a dht, but perhaps this is a lead for something we can start to port
+[23:18] <jrand0m> (it uses UDP so getting it to use I2CP wouldn't be hard)
+[23:18] <MrEcho> dht???
+[23:18] <MrEcho> im blanking on that one
+[23:18] <jrand0m> MrEcho> see [10] in the email ;)
+[23:18] <jrand0m> http://wiki.invisiblenet.net/iip-wiki?DHT
+[23:18] <Nightblade> entropy is a good enough temporary solution
+[23:18] <jrand0m> agreed
+[23:19] <jrand0m> though I think we need to look at a long term solution as well
+[23:19] * soros has joined #i2p
+[23:19] * lucky has joined #i2p
+[23:20] * human is worried about gcj/kaffe compatibility with DHTs like Bamboo (http://bamboo-dht.org/)
+[23:20] <jrand0m> yeah, bamboo is 1.4
+[23:20] <MrEcho> afk
+[23:20] <jrand0m> thats the glory of i2cp though - the router & tunnels can be gcj'ed, while things that access them can be whatever
+[23:21] <jrand0m> it /is/ purely for an app though - not as part of the core
+[23:21] <jrand0m> I'm just trying to think of things that would help the end users who end up downloading i2p do something useful right off the bat
+[23:22] <jrand0m> (being able to post uncensorable content anonymously would be a good useful thing)
+[23:22] <jrand0m> s/uncensorable/very censorship resistant/
+[23:23] <human> jrand0m: ah, ok - i thought that bamboo was going to replace Kademlia for the NetworkDB :-)
+[23:23] <Nightblade> the squid proxy is something they can do... for users for example in china that would be a very nice thing to have
+[23:23] <jrand0m> Nightblade> right, but the squid isn't scalable
+[23:24] <Nightblade> yeah i think it would be interesting to have a kind of distributed JAP
+[23:24] <jrand0m> agreed
+[23:24] <jrand0m> so that's also another thing that would be great if people could check into :)
+[23:24] <mihi> Nightblade: the prob is abuse handling - i won't open my box for any outgoing http
+[23:24] <jrand0m> I'm sure some people will though
+[23:25] <Nightblade> with an additional part where an individual node could choose what sites they want to proxy for people... a client could send a requst for "whitehouse.com" and then one of the nodes that will do the proxying and will permit that url can answer
+[23:25] <Nightblade> yeah i think it would have to have some kind of access controls
+[23:25] <Nightblade> blacklist or whitelist
+[23:25] <jrand0m> right
+[23:25] <Nightblade> of domain names
+[23:26] <jrand0m> its the "exit policy" system. though this is a whole project in and of itself
+[23:27] <MrEcho> it could ride on the DNS system... i guess
+[23:27] <jrand0m> certainly
+[23:27] <wiht> mihi: What if you limit the bandwidth used? Or is it the websites accessed that could get you in trouble?
+[23:27] <MrEcho> at a very later date lol
+[23:27] <jrand0m> wiht> many providers explicitly disallow running servers of any kind
+[23:28] <MrEcho> verizon fucks with port 21 for sure...
+[23:28] <wiht> jrand0m: Oh. Yes, that is a problem.
+[23:28] <Nightblade> there would have to be some way for clients to request the sites they want downloaded for them.. Broadcast requests are not a very good solution, especially on i2p
+[23:29] <mihi> wiht: the problem is the websites that can be accessed. compare the lawsuit of JAP some time ago. /me lives in the same country
+[23:29] <jrand0m> agreed. though broadcast isn't possible without brute forcing a ~2^2300 keyspace ;)
+[23:30] <jrand0m> right mihi, people in oppresive regimes would not be able to safely run outproxies
+[23:30] <wiht> mihi: What was the lawsuit? I do not remember.
+[23:30] * dm has quit IRC (Ping timeout)
+[23:30] <Nightblade> i mean, even if you had a list of destinations that provide web proxying, you would not want to have to broadcast to them all
+[23:30] <jrand0m> right Nightblade
+[23:30] <Nightblade> request broadcast i mean
+[23:31] <mihi> the prob was that someone had accessed a child porn site and it went over a JAP proxy and they could not tell where the request came from. this was interpreted as thowing stones into police's work
+[23:31] <jrand0m> people may want to check out crowds or rewebber to see other projects that worked on this same task
+[23:31] <wiht> mihi: Ah. Thank you for the explanation. I see understand you are concerned now.
+[23:31] * mihi_away has quit IRC (Ping timeout)
+[23:31] <mihi> and made that change to the jap software that makes it possible to catch people. which was removed later
+[23:32] <wiht> Er, I understand why you are concerned.
+[23:32] <mihi> at the end it came out that the JAP would not have to disclose the data, but i don't want to know what the lawyers cost...
+[23:32] <Nightblade> yeah but didn't the police seize the information anyway?
+[23:32] <jrand0m> yes
+[23:33] <mihi> they did...
+[23:33] <jrand0m> but anyway, yes, both a scalable DHT and a scalable web proxy would be Really Good Things to have by 1.0
+[23:34] <mihi> and they cannot give it backk, can they?
+[23:34] * BpX has quit IRC (Ping timeout)
+[23:36] * Sciatica has joined #i2p
+[23:36] <jrand0m> ok, anything else for point 9? or are we on to 10/11) NS/DNS?
+[23:36] <wiht> I would like to make a brief comment about the installer after topic 10.
+[23:37] <jrand0m> 'k perhaps lets hit that now, since NS/DNS might not be uber-brief? ;)
+[23:37] <wiht> All right. The router has a start script and a stop script.
+[23:37] <jrand0m> right
+[23:37] <wiht> I would like all of the services to be done that way--to have both a start and a stop script.
+[23:37] <jrand0m> most of them do
+[23:37] <jrand0m> don't they?
+[23:38] <jrand0m> oh, not stop scripts
+[23:38] <wiht> No, just the router.
+[23:38] <wiht> That way, desired services could be started on computer bootup, just like the router. I made a post to that effect to the mailing list.
+[23:38] <jrand0m> aum is working on the i2pmgr, which is going to be both a console based and gui based control center for the services and the router itself
+[23:38] <wiht> Let's say I want to start the eep and nntp on bootup. Currently, I can't do that.
+[23:39] <jrand0m> right, you'd need to nohup startEepProxy.sh &
+[23:39] <wiht> All right. By the way, where are these scripts in CVS?
+[23:39] <MrEcho> k im back
+[23:39] * mihi_away has joined #i2p
+[23:39] <jrand0m> wiht> the scripts are in the Install.java (aka hacked)
+[23:39] <wiht> jrand0m: Thanks./
+[23:40] <jrand0m> but good point, we want it to be as simple as possible to start on boot, as well as start on demand
+[23:41] <jrand0m> ok, on to 10/11) ns/dns
+[23:41] <MrEcho> well check my email
+[23:41] <MrEcho> theres a few things i forgot about putting in there
+[23:41] <jrand0m> unfortunately your email didn't really go through to the web interface well :/
+[23:41] <MrEcho> like "temp" names
+[23:41] <MrEcho> ??
+[23:42] * Sciatica has quit IRC (Ping timeout)
+[23:42] * ion has quit IRC (Ping timeout)
+[23:42] <jrand0m> MrEcho> http://i2p.dnsalias.net/pipermail/i2p/2004-January/000072.html
+[23:42] <MrEcho> because of the gif or something
+[23:42] <MrEcho> shit .. i singed it
+[23:43] <MrEcho> sorry
+[23:43] <jrand0m> the mailing list is really intended to be text only. pgp sigs are fine (others have posted signed things)
+[23:43] <kaji> whats a good free small antivirus?
+[23:43] * ion has joined #i2p
+[23:43] <jrand0m> kaji> linux
+[23:43] * Sciatica has joined #i2p
+[23:43] <wiht> LOL.
+[23:43] <kaji> that runs with my hardware
+[23:43] <wiht> kaji: Try AVG Antivirus for Windows.
+[23:44] * MrEcho_ has joined #i2p
+[23:44] * MrEcho has quit IRC (EOF From client)
+[23:44] <MrEcho_> fuckign iip
+[23:44] <jrand0m> MrEcho / (and anyone else interested in the NS/DNS issue)> have you read http://zooko.com/distnames.html ?
+[23:44] <MrEcho_> j, should i resend the email?
+[23:44] <jrand0m> it went through to the list fine, it just didn't get web archived correctly
+[23:44] <MrEcho_> ya
+[23:45] <wiht> jrand0m: I did not read it yet.
+[23:45] <MrEcho_> ill take a look at it later
+[23:45] * mrflibble has joined #i2p
+[23:45] <jrand0m> for those who aren't on the list, I've saved MrEcho_'s email at http://i2p.dnsalias.net/~jrandom/mrecho_dns.txt
+[23:46] <MrEcho_> thanks J
+[23:46] <kaji> its gay, it wants an email adress
+[23:46] <jrand0m> my concern is with the security and scalability of the naming service. once we find a solution that meets those needs, fantastic, but until we do, we should be careful of interim solutions.
+[23:47] <jrand0m> kaji> email lists usually want an email address, yeah ;)
+[23:47] <kaji> i mean AVG Antivirus
+[23:47] <jrand0m> oh ;)
+[23:48] <wiht> MrEcho has several good ideas that I did not have in my specification, such as a ban list for bad clients.
+[23:49] <MrEcho_> not really a ban list
+[23:49] <jrand0m> once there are 1000 clients, does that mean that it would take 125 lookups to find a value?
+[23:49] <MrEcho_> no
+[23:49] <wiht> Not a list, but banning bad clients is something I did not have.
+[23:50] <MrEcho_> 2-4 clients for checking
+[23:50] <jrand0m> so every client will have 250 entries?
+[23:50] * mihi_away is now known as mihi_backup
+[23:50] <MrEcho_> no
+[23:50] <wiht> With what I have, it would be one lookup, possibly forwarded a couple of times to reach an authoritative server.
+[23:50] <MrEcho_> clients will only have what they need
+[23:51] <MrEcho_> it will keep querying other Clients untill they get data that matches for the check
+[23:51] <jrand0m> so with 4 peers, it'd do a random search and on average it'd take 125 lookups
+[23:51] <jrand0m> (1000/4/2)
+[23:51] <jrand0m> or are the peers a DHT?
+[23:52] <jrand0m> (with some maintenance protocol?)
+[23:52] <jrand0m> or a search tree?
+[23:52] <MrEcho_> in a way yes
+[23:52] <MrEcho_> ill have a cut off on client searches, it will just query the MS
+[23:53] <jrand0m> secure distributed naming is a fairly well studied problem - what would make your proposal easier to analyze the security and scalability would be if you could draw comparisons and validate variations on other approaches, perhaps?
+[23:54] <MrEcho_> if it doesnt find / or get enough data from Clients within a set range it will then just query the MS.
+[23:54] <jrand0m> as is, there isn't enough detail for me to have confidence in the scalability or security of the architecture. not to say it couldn't work out well, I just can't see that it would yet.
+[23:54] <MrEcho_> cany u stop typing for a sec
+[23:54] * jrand0m stops typing.
+[23:55] <MrEcho_> its going to work .. it will have scalability, it will have security
+[23:56] <MrEcho_> the more users the better it will get
+[23:56] <jrand0m> so "trust me", 'eh?
+[23:56] <MrEcho_> do you trust the Internet DNS system?
+[23:56] <jrand0m> for some tasks.
+[23:57] <jrand0m> for many, no.
+[23:57] <jrand0m> (its quite easy for govts / etc to get records changed - court cases order registrars to update all the time)
+[23:58] <MrEcho_> only other way of doing it is having big ass lists of Names and lots of crypto on every client
+[23:58] <MrEcho_> and being dynamic .. forget about it
+[23:59] * mrflibble has quit IRC (EOF From client)
+[23:59] <jrand0m> I suggest reviewing zooko's paper before proceeding further, and answering his final point 5 ("why I'm wrong")
+Session Time: Wed Jan 07 00:00:00 2004
+[00:01] <jrand0m> ok, thats probably about it for point 10/11 (lots of future discussion still left on that, of course)
+[00:02] <jrand0m> anyone have any other thoughts, etc?
+[00:02] <wiht> Yes.
+[00:03] <jrand0m> care to share with the class? :)
+[00:03] <wiht> I will be rewriting the specification I wrote. I would like to use a local SQL server to store data, not files.
+[00:03] <jrand0m> ah cool
+[00:03] <jrand0m> (same concerns go for the spec you wrote too - if you could answer zooko's last question, that'd be key :)
+[00:03] * mrflibble has joined #i2p
+[00:03] <wiht> Let MySQL or a similar server manage data storage, and let Java query that server.
+[00:04] <duck> huh ? zooko specs?
+[00:04] <wiht> I think that will be easier to implement.
+[00:04] <jrand0m> duck> naw, I'm just pointing people at his old article "Names: Decentralized, Secure, Human-Meaningful: Choose Two"
+[00:04] <duck> ah that
+[00:04] <Nightblade> wiht: what specification is that (i missed a lot of the meeting)?
+[00:04] * MrEcho has joined #i2p
+[00:04] <jrand0m> (a lot easier than rehashing why supernode/centralized servers are scary security issues ;)
+[00:05] * MrEcho_ has quit IRC (EOF From client)
+[00:05] * mihi 'd have something for the log as well ;)
+[00:05] <mihi> something longer ;)
+[00:05] <mihi> *** I2Ping results:
+[00:05] <mihi> + + + eco.i2p
+[00:05] <mihi> + - - jabber.duck.i2p
+[00:05] <mihi> - + + i2pcvs.i2p
+[00:05] <mihi> - + + duck.i2p
+[00:05] <mihi> - + - jap.eco.i2p
+[00:05] <jrand0m> Nightblade> it was posted to iip-dev back in... august?
+[00:05] <mihi> - + + irc.duck.i2p
+[00:05] <mihi> - + + human.i2p
+[00:06] <mihi> - - + nntp.duck.i2p
+[00:06] <mihi> - - - tc.i2p
+[00:06] <mihi> - - - dyad.i2p
+[00:06] <mihi> - - - bozo.i2p
+[00:06] <mihi> - - - ogg.aum.i2p
+[00:06] <mihi> - - - fcp.entropy.i2p
+[00:06] <mihi> - - - http.entropy.i2p
+[00:06] <Nightblade> jrandom: oh, before my time.. :)
+[00:06] <mihi> - - - www.mail.i2p
+[00:06] <mihi> - - - mp3.aum.i2p
+[00:06] <mihi> - - - smtp.mail.i2p
+[00:06] <wiht> Nightblade: I posted it on September 15th.
+[00:06] <mihi> - - - pop.mail.i2p
+[00:06] <mihi> - - - mp3.tc.i2p
+[00:06] <mihi> - - - lp.i2p
+[00:06] <mihi> - - - kaji.i2p
+[00:06] <mihi> - - - nm.i2p
+[00:06] <mihi> - - - squid.i2p
+[00:06] <mihi> - - - chess.fillament.i2p
+[00:06] <mihi> - - - mesh.firerabbit.i2p
+[00:06] <mihi> - - - nightblade.i2p
+[00:06] <mihi> - - - aum.i2p
+[00:06] <MrEcho> gezz is anyone up and running?
+[00:06] <mihi> - - - fillament.i2p
+[00:06] <mihi> *** Finished.
+[00:06] <mihi> why are so many hosts down...?
+[00:06] * jrand0m isn't running my servers atm
+[00:07] <FillaMent> I can connect to myself on both eep and chess
+[00:07] * mrflibble has quit IRC (Ping timeout)
+[00:07] <jrand0m> oh wait, i2pcvs is up, neat
+[00:07] <Nightblade> mihi: mine isn't up because the i2ptunnel crashes for me after a few hours
+[00:07] <mihi> so my router is broken (or it's usual I2P problems...)
+[00:08] <jrand0m> really Nightblade? please report i2ptunnel crashes (bugzilla would be nice)
+[00:08] <Nightblade> it is in the bugzilla
+[00:08] <lucky> hi
+[00:08] <Nightblade> hold..
+[00:08] <FillaMent> Nightblade: what JVM?
+[00:08] <Nightblade> #39
+[00:08] <wiht> My router has been running for more than 12 hours now, although it had a problem in registering itself.
+[00:09] <Nightblade> java version "1.4.2-p5"
+[00:09] <Nightblade> on freebsd... it could be a jvm problem, i don't know. java support isn't too good on freebsd
+[00:09] <jrand0m> you're right Nightblade, my bad
+[00:09] <jrand0m> thats the fairly infrequent i2cp bug
+[00:09] <jrand0m> is that consistent for you?
+[00:09] <Nightblade> the router is very stable for me, just the i2ptunnel server tunnel gives me problems
+[00:09] <Nightblade> yeas it happened several times
+[00:10] <Nightblade> i haven't tried it recently though
+[00:10] * jrand0m just pulled fillament's eepsite
+[00:10] <jrand0m> (first try, just noticed the window was complete)
+[00:10] <FillaMent> Yeah,, I just jabbered with duck, wiht's trying to hit chess
+[00:10] <jrand0m> ah cool
+[00:10] <jrand0m> but yes, there are still reliability issues to be dealt with in the network.
+[00:10] * FillaMent nudges people with the included winking, "He'll probably be wanting to play."
+[00:10] * human 's eepsite is still up - it means that 'killall java' really helped... :-)
+[00:10] <wiht> I just successfully connected to chess server.
+[00:10] <duck> yeah?
+[00:11] <jrand0m> lol FillaMent
+[00:11] * mrflibble has joined #i2p
+[00:12] <Nightblade> is it safe to run the cvs version of i2p
+[00:12] <jrand0m> /me succesfully fetches human's 1984-2004: twenty years of GNU! :-)
+[00:12] <jrand0m> yes Nightblade
+[00:12] <FillaMent> could not get eco...
+[00:12] <Nightblade> ok maybe i'll give that a try
+[00:12] <duck> with freenet you should always run the latest cvs version!
+[00:13] <duck> only then it is bugfree
+[00:13] <duck> s/freenet/i2p/
+[00:13] * jrand0m pulled eco.i2p
+[00:13] <FillaMent> just got duck
+[00:13] <jrand0m> "Jan 4: First field test of I2PSnark. Pretty catastrophic: no transfer at all. Guess my single router test environment wasn't very representative :-) Back to the drawing board... "
+[00:13] <jrand0m> d'oh
+[00:13] <duck> well, it worked actually
+[00:13] <duck> ardvark could snark something from me
+[00:14] <jrand0m> bt precreates the files - were the files actually valid?
+[00:14] <duck> but ze did find out the next day
+[00:14] <duck> because it was obscured in the logs
+[00:14] <jrand0m> what, you mean the logs i2p generates are fairly insane? nawwwwww
+[00:14] <duck> no
+[00:14] <duck> the i2psnark output
+[00:14] <jrand0m> ah
+[00:15] <duck> additionally, I suspect that snark does too much churning (sp?)
+[00:15] <duck> the normal bittorrent client seems to be more easy
+[00:15] <duck> also the high delays on i2p might cause premature blocks
+[00:16] * mrflibble has quit IRC (Ping timeout)
+[00:16] <duck> last thing is that we had to restart i2ptunnel a few times :/
+[00:16] <jrand0m> agreed
+[00:16] <human> final question about I2PTunnel / I2PTunnelManager (yes, i know, i'm boring): what about my patch to make "openclient" and "openserver" return a meaningful jobId?
+[00:16] <jrand0m> so, yeah, lots of work to do
+[00:16] <human> 1. let's accept it to make the TunnelManager work until the new asynchronous architecture will be roxoring
+[00:17] <human> 2. your patch plain sucks, fuck off, and fuck the TunnelManager
+[00:17] <human> 3. ...
+[00:17] * MrEcho_ has joined #i2p
+[00:17] * mihi is for 3 ;)
+[00:17] * MrEcho has quit IRC (EOF From client)
+[00:17] <jrand0m> 4. lets see how we can update the tunnel manager to go async? shouldn't be too hard
+[00:17] <jrand0m> the patch is good, but mihi has a point
+[00:18] <human> jrand0m: yes, i agree
+[00:18] <jrand0m> we still have 1+ weeks until 0.3, so we've got time until the next full release
+[00:18] <human> jrand0m: but my doubt is: how long will it take to have the async interface to be implemented in the TunnelManager?
+[00:18] <jrand0m> tunnelmanager itself was 2 hours, I could add async tonight
+[00:19] <jrand0m> (all that needs to happen is an update to the BufferedLogging to accept .set calls)
+[00:19] <human> jrand0m: (with "to have" i also mean "to have it implemented even in I2PTunnel)
+[00:19] <jrand0m> (or .nofity/etc)
+[00:19] <jrand0m> right
+[00:19] * mrflibble has joined #i2p
+[00:20] <jrand0m> if you'd prefer, I could start with your patch (which adds the job id) and merge it with the updates for async
+[00:21] <human> jrand0m: i could add the async interface to TunnelManager myself, but the interface still doesn't exist :-)
+[00:22] <jrand0m> right, just add public void notifyEvent(String eventName, Object value); to Logging.java
+[00:22] <human> jrand0m: i'd suggest "let's merge the dirty hack to make the job ids in the 0.3 release somewhat work, and then work on the async interface"
+[00:23] <jrand0m> 0.3 is still a ways off
+[00:23] <mihi> 0.3 should have the streaming api anyway, shouldn't it?
+[00:23] <human> jrand0m: i'm talking about the worst case
+[00:23] <wiht> jrand0m: Maybe there should be another version before 3.0 to settle these issues?
+[00:23] <jrand0m> yes mihi
+[00:23] <mihi> human: the worst case is "cvs rollback && patch -p0 your.patch"
+[00:24] <jrand0m> ok, how about this. I'll get the async implemented and committed tonight, if you could look at it tomorrow human and see what needs to be done to get your update in there?
+[00:26] <FillaMent> jrand0m: do you have a job?
+[00:27] <jrand0m> i2p
+[00:27] <duck> get 1.0 done!
+[00:27] <FillaMent> I mean a source of income
+[00:27] <jrand0m> :)
+[00:27] <FillaMent> that you have to work for
+[00:27] <jrand0m> income is overrated.
+[00:27] * jrand0m fired my boss
+[00:27] <Nightblade> "will code for food" - that's my motto
+[00:27] <Nightblade> lol
+[00:27] <human> mihi: well, but i and aum (who is working on a python app for the TunnelManager) would like to have jobIds ASAP...
+[00:28] <human> jrand0m: ok, i'll work on your changes later/tomorrow
+[00:28] <FillaMent> Job/Money, sleep/hygiene, food, side projects, social life: Choose any 3
+[00:29] * jrand0m only choses one.
+[00:29] <jrand0m> word human
+[00:30] <FillaMent> Anyone have any other ideas for "just tunnel to" services that would be nice to have on the network?
+[00:30] * jrand0m still wants a telnet based Adventure :)
+[00:30] <jrand0m> or a waffle bbs
+[00:30] * duck is now known as enduser
+[00:30] * jrand0m kicks enduser
+[00:31] <jrand0m> (damn, no ops)
+[00:31] <FillaMent> For OS/2 there was a comm driver that could map a comm port to a TCP port =)
+[00:31] <enduser> what difference will I see as enduser when I2PTunnel uses the SteamingAPI?
+[00:31] * enduser is now known as duck
+[00:31] <jrand0m> none
+[00:31] <human> lol
+[00:31] <FillaMent> FillaMent: friend of mine ran a BBS that way for a while
+[00:31] <jrand0m> performance, and perhaps anonymity
+[00:31] * human would like a I2P tunnel to a rootshell
+[00:32] <human> any volunteer? :-)
+[00:32] <duck> rootshell on a UML
+[00:32] <jrand0m> chroot'ed rootshells would be good
+[00:32] <jrand0m> or UML'ed :)
+[00:32] <FillaMent> human: had I a spare boxen, I'd do it
+[00:32] <jrand0m> hehe FillaMent
+[00:32] <duck> vnc connection to my vmware win98?
+[00:32] <FillaMent> seriously though guys...
+[00:32] <wiht> E-mail server would be a good one as well. Or do we have that already?
+[00:32] <FillaMent> wiht: think TC has pop and SMTP
+[00:33] <jrand0m> thats aum, but they're offline, as his box is offline
+[00:33] * human could offer telnet accounts on his GNU/Hurd system...
+[00:33] <jrand0m> ooOOoo
+[00:33] <FillaMent> well, I'm not too keen on setting up open SMTP access yet
+[00:33] <jrand0m> understandable
+[00:34] <FillaMent> maybe when the network is more stable and I've got money to up my bandwidth
+[00:34] <wiht> How about a PGP keyserver?
+[00:34] <mihi> FillaMent: you could set up a tunnel pointing to a cleartext remailer
+[00:34] <FillaMent> wiht: now THAT's a great idea =)
+[00:35] <FillaMent> mihi heh... I could just point the tunnel to my ISP SMTP box =)
+[00:35] <mihi> FillaMent: this would make *you* be resposible for abuse...
+[00:35] <mihi> s/be//
+[00:35] <duck> http://www.mit.edu/people/marc/pks/pks.html
+[00:36] <duck> seriously, should duck enterprises consider running a pgp keyserver?
+[00:37] <FillaMent> duck: I was poking into that myself... you want to handle it?
+[00:37] <duck> we have been one of the most stable service providers according to mihi's independent ping logs
+[00:37] <jrand0m> hehe
+[00:37] <wiht> duck: Yes, please consider it.
+[00:37] <jrand0m> btw duck, how do you do that? do you restart periodically or just run on a reliable OS and JVM?
+[00:38] <FillaMent> question: does the JVM cache DNS resolves?
+[00:38] <duck> restarting is for kernel updates
+[00:38] <jrand0m> yes, but you can do some nasty trickery to avoid it FillaMent
+[00:38] * wiht notes that the meeting has gone on for 2h40m now.
+[00:38] <jrand0m> oh yeah,
+[00:39] * mrflibble sticks his hand up
+[00:39] <jrand0m> um, this meeting's log is going to be huge. and here I was thinking posthing things up front would /shorten/ the meeting
+[00:39] <jrand0m> sup mrflibble?
+[00:39] <FillaMent> jrand0m: okay... because I am without downage but my IP changes periodically... my dyndns update script runs every hour so max 60+~10min of my named addy not pointing to my IP...
+[00:39] <FillaMent> how would that affect my router's presence on the network?
+[00:40] <mrflibble> my box could be availalbe for some kind of demony thing
+[00:40] <jrand0m> cool FillaMent, shouldn't be much of a problem, as long as you point to your dyndns
+[00:40] <wiht> mrflibble: demony?
+[00:40] <mrflibble> i guess it depends how much bandwidth the thing would use
+[00:40] <mrflibble> daemony
+[00:40] <jrand0m> w3rd mrflibble - has the router been working reliably for you, or are you just being a good sameritan? :)
+[00:41] <mrflibble> not really, but that's because my local bw is saturated atm
+[00:41] <mrflibble> im not running it on my colo yet
+[00:41] <mrflibble> want to play around with it locally first
+[00:41] <jrand0m> ah cool. yeah, i2p isn't really ready for wide deployment, still for testing mainly
+[00:42] <FillaMent> Heh.. I'll point a tunnel to my CUPS server and you can have anonymous printing =)
+[00:42] <jrand0m> rofl
+[00:42] <mrflibble> if there's something that u want me to run that would use <40gb bw a month, lmk
+[00:42] <FillaMent> just include a banner page so I know where to mail the hardcopy =)
+[00:42] <mrflibble> hehe
+[00:43] <jrand0m> wikked mrflibble, I'm sure we'll take you up on that :)
+[00:43] <mihi> banner | lpr ? ;)
+[00:43] <FillaMent> mihi you cah set up CUPS with a banner page
+[00:43] <mrflibble> oky doky!
+[00:43] <mihi> banner will most likely create lots of pages ;)
+[00:43] <jrand0m> ok, before we get to the mixminion->printer->post office gateway discussion, lets close this meeting ;)
+[00:44] * jrand0m readies the *baf*'er
+[00:44] * jrand0m *baf*'s the meeting closed.
+
\ No newline at end of file
diff --git a/pages/meeting73.html b/pages/meeting73.html
new file mode 100644
index 00000000..0c3e45f1
--- /dev/null
+++ b/pages/meeting73.html
@@ -0,0 +1,142 @@
++[22:01] <jrand0m> 0) hi +[22:01] <jrand0m> 1) 0.2.3.4 +[22:01] <jrand0m> 2) 0.3 +[22:01] <jrand0m> 3) streaming library, I2COCP, CI2CP +[22:01] <jrand0m> 4) apps +[22:01] <jrand0m> 5) ??? +[22:01] <jrand0m> 0) hi +[22:01] <jrand0m> hi everyone +[22:01] <jrand0m> y'all seen http://i2p.dnsalias.net/pipermail/i2p/2004-January/000082.html? +[22:01] <jrand0m> if not, now's your chance :) +[22:02] <jrand0m> iip has been acting up a bit, so if someone could say something every once in a while, that'd be swell +[22:02] <MrEcho> . +[22:02] <jrand0m> w3rd +[22:02] <jrand0m> ok, moving on, 1) 0.2.3.4 +[22:03] <jrand0m> there'll be a new release in the next day or so with the current state of the code, which includes a lot of bugfixes and more features +[22:03] <jrand0m> e.g. tunnelmanager isn't in 0.2.3.3 yet +[22:03] <MrEcho> col +[22:03] <jrand0m> it'll be backwards incompatible, because i'm mean +[22:04] <jrand0m> jumping onto 2) 0.3 +[22:04] <MrEcho> :P +[22:04] <jrand0m> that'll be out fairly soon, but obviously not on thursday +[22:04] <jrand0m> it won't be out until 0.2.3.4 is performing reliably so that everyone can reach all sites they should be able to +[22:05] <MrEcho> cool +[22:05] <jrand0m> well, moving right along to 3) streaming lib / etc +[22:05] <jrand0m> well, thats all spelled out in the email :) +[22:05] * eco has joined #i2p +[22:05] * mihi_away is now known as mihi +[22:05] <jrand0m> if anyone wants to get involved in it, please let me know +[22:06] * ion has joined #i2p +[22:06] <jrand0m> 'lo eco, mihi, ion +[22:06] <jrand0m> ok, moving on to 4) apps +[22:06] <jrand0m> anyone working on an app that will run over i2p that has anything to add? +[22:07] * wiht has joined #i2p +[22:07] <MrEcho> re ask the quest j +[22:07] <jrand0m> well, we're at the last agenda item, so might as well :) +[22:08] <MrEcho> wiht .. get my email? +[22:08] <jrand0m> anyone have anything to bring up outside the http://i2p.dnsalias.net/pipermail/i2p/2004-January/000082.html post? +[22:08] <wiht> Yes, let me read it. +[22:08] <jrand0m> MrEcho> have you read zooko's naming page yet? +[22:08] * jar has joined #i2p +[22:08] <MrEcho> no .. lost the link +[22:09] <jrand0m> (from the logs last week, http://zooko.com/distnames.html) +[22:10] <jrand0m> anyone have anything to add, or are we at a record breaking 10 minute meeting? +[22:10] <MrEcho> still working on my dns idea +[22:10] <jrand0m> coo' +[22:10] <wiht> MrEcho: Yes, I would like to work together on naming service. +[22:10] <MrEcho> sweet +[22:11] <wiht> But I will not have time until next Wednesday. +[22:11] <MrEcho> ok +[22:11] <MrEcho> will give me some time to finish up on a few things +[22:11] <mrflibble> how long till the meet? +[22:11] <jrand0m> -11 minutes +[22:11] <mrflibble> oops +[22:11] * mrflibble is v late +[22:11] <mrflibble> :) +[22:12] <jrand0m> (we've gone through the 5 agenda items very very quicky :) +[22:12] * mrflibble goes back to lurking and the backscroll +[22:12] <jrand0m> heh +[22:12] <wiht> jrand0m: Have you measured how much CPU is used per tunnel by the server? +[22:14] <wiht> Let me restate that: if you have five connections to other routers, and they are using 20% of CPU, how much will be used after 6th connection? Have you measured this? +[22:15] <jrand0m> they shouldn't consume 20% of the cpu, or even 1% +[22:15] <jrand0m> (for client tunnels - server tunnels may consume more) +[22:15] <wiht> Server tunnels. +[22:16] * eco has quit IRC (Ping timeout) +[22:16] <wiht> But that will probably be dependent on your CPU speed, so that was a badly stated question. +[22:16] <jrand0m> server tunnels before the streaming lib will require cpu load whenever a new peer connects +[22:18] <wiht> All right. +[22:19] <duck> are we at #5 already? +[22:19] * ion has quit IRC (Ping timeout) +[22:19] <jrand0m> yup +[22:20] * duck mentions the hosting options that home.duck.i2p provides +[22:20] <jrand0m> ooOOoo +[22:20] <duck> it hasnt been tested by anybody besides me though +[22:20] <duck> waiting for betatester Ardvark to show up +[22:20] <jrand0m> so the hosting lets someone run apache / etc? +[22:21] <jrand0m> (or do they have to run the i2p router? +[22:21] <duck> neither +[22:21] <duck> they can put their html files on /home/username/public_html/ +[22:21] <duck> and it will show up on http://home.duck.i2p/~username/ +[22:21] <jrand0m> ah nice +[22:21] <jrand0m> php support? cgi / .pl / etc? or just html? +[22:22] <jrand0m> (thats kick fucking ass, in any case) +[22:22] <duck> php and html +[22:22] <jrand0m> wwwwwwwwwicked +[22:22] <mihi> duck: won't that compromize your anonymity? +[22:22] <duck> how? +[22:22] <mihi> phpshell? +[22:22] <mihi> or is the full apache in a vmware/UML box? +[22:22] <duck> system, exec, etc are disabled +[22:23] <duck> plus the host cant connect to the outsite +[22:23] * wilde has joined #i2p +[22:23] <duck> (it is inside an UML box) +[22:23] <duck> (pl and other cgis are too difficult to debug without shell access, plus they often break) +[22:23] * mihi_backup has joined #i2p +[22:23] <jrand0m> jsp access? :) +[22:23] * madman2003 has quit IRC (12( www.nnscript.de 12:: NoNameScript 3.8 12:: www.XLhost.de 12)) +[22:23] <duck> ofcourse not +[22:24] <mihi> and why not ssh access as well, when it's an UML box? +[22:24] <duck> because the average IIP user will start running forkbombs +[22:24] <jrand0m> with ssh access, they could traceroute i2p.dnsalias.net +[22:24] <mihi> man ulimit +[22:24] <jrand0m> ah true +[22:24] <mihi> man limiting cpu time on uml boxes. +[22:25] <mihi> (okay, it will crash apache, shit...) +[22:25] <duck> man run your own host :) +[22:25] <jrand0m> hehe +[22:25] <lucky> hi +[22:25] <duck> I'll add it on the todo +[22:25] <jrand0m> a reliable hosting service provider will RULE +[22:25] <kaji> now all we need is a wiki +[22:25] * wiht has left #i2p (wiht) +[22:26] * lucky has a reliable net connection... +[22:26] <duck> you already have a wiki +[22:26] <jrand0m> kaji> duck.i2p has one +[22:26] <duck> wiki.invisiblenet.net +[22:26] <jrand0m> that too +[22:26] <kaji> oh sweet then +[22:26] <jrand0m> (yeah, the main i2p wiki is http://wiki.invisiblenet.net/iip-wiki?I2P ) +[22:26] * dm has quit IRC (Ping timeout) +[22:28] * mihi is now known as mihi_away +[22:28] * mihi_backup has quit IRC (Ping timeout) +[22:29] <jrand0m> 'k, anything else before we close out the meeting? +[22:29] <kaji> doh, i missed the meeting? +[22:29] <jrand0m> we're not quite done yet, but about it +[22:29] <lucky> meeting? +[22:29] <lucky> Oh, thats so not fair +[22:29] <lucky> i just got home. +[22:29] <wilde> are there logs anywhere? +[22:29] <wilde> meeting log +[22:30] * lucky has a log... +[22:30] <kaji> can some one write a howto for using wget over i2p in windows? +[22:30] <jrand0m> meeting logs at http://wiki.invisiblenet.net/iip-wiki?Meetings +[22:30] <jrand0m> kaji you'll probably need to add the http_proxy to the environment +[22:32] <jrand0m> ok, lets wrap this one up, and I'll post up the logs momentarily. anyone who has anything else can post to the mailing list or just chat on here :) +[22:32] <kaji> also im now sharing /books/ and /audio/ at kaji.i2p and i think i will make a short howto about the bugs in apache alias for windows +[22:32] <jrand0m> word kaji! +[22:32] * jrand0m *baf*s the meeting closed on that note + +\ No newline at end of file diff --git a/pages/meeting74.html b/pages/meeting74.html new file mode 100644 index 00000000..57fee142 --- /dev/null +++ b/pages/meeting74.html @@ -0,0 +1,188 @@ +
+[22:07] <jrand0m> agenda: +[22:07] <jrand0m> 0) hi (read http://i2p.dnsalias.net/pipermail/i2p/2004-January/000101.html) +[22:07] <jrand0m> 1) router dev status +[22:07] <jrand0m> 2) twisted-i2p +[22:07] <jrand0m> 3) unit tests +[22:07] <jrand0m> 4) network testing / monitoring +[22:07] <jrand0m> 5) ??? +[22:07] <jrand0m> 0) hi +[22:07] <jrand0m> hi +[22:07] * jrand0m waves +[22:07] <dm> ohhhh meeting! +[22:07] * dm waves back. +[22:07] <jrand0m> 9p gmt every tuesday :) +[22:08] <jrand0m> people should read that url (http://i2p.dnsalias.net/pipermail/i2p/2004-January/000101.html) since there's stuff in it that I need feedback on during agenda item 4 +[22:08] <jrand0m> 1) router dev status +[22:09] <jrand0m> making progress, code currently in cvs is looking good. i've had a script testing a series of routers for the last day or so and none of them have popped out a single ERROR message +[22:09] <duck> reading... +[22:10] <jrand0m> but of course thats just baseline testing (keeping the routers building tunnels correctly, tunneling data through one to another via i2ptunnel, etc) +[22:11] * jnk has joined #i2p +[22:11] <jrand0m> theres certainly other things that need to be fixed up in the wild, which is why there's going to be a 0.2.3.5 release in the next day or so to confirm functionality or to find new bugs +[22:11] <jrand0m> ok, moving on +[22:12] <jrand0m> 2) twisted+i2p +[22:12] <duck> I do have errors +[22:12] <duck> but probably due to others +[22:12] <jrand0m> dropped messages and unknown tunnels, right? +[22:12] <duck> checking +[22:13] <jrand0m> (those are the errors I see with one of my 'live' routers but not on the test network) +[22:13] <duck> 22:13:15.371 ERROR [ Sender 1148] er.transport.phttp.PHTTPSender: Error sending the message +[22:13] <jrand0m> ah ok, yeah, i've been smacking around the phttp relay too +[22:13] <duck> 21:01:01.509 ERROR [JobQueue28 ] eDatabaseSearchReplyMessageJob: Invalid router info returned from [Rout +[22:14] <jrand0m> hmm that one is funky - could you bounce me the stacktrace? +[22:14] <duck> I'll put it up. +[22:14] <duck> . +[22:14] <jrand0m> gracias +[22:15] <jrand0m> actually, thats going to be a general rule with the future releases - WARN or INFO or DEBUG messages are fine, and ERROR or CRIT messages are things I'd like to hear about +[22:16] <jrand0m> ok, back to 2) +[22:16] <jrand0m> human has put together a way to use i2p via python and the twisted framework (yay!) +[22:17] <jrand0m> see his email for more info (http://i2p.dnsalias.net/pipermail/i2p/2004-January/000100.html) +[22:17] <jrand0m> anything to add human? (if you're here) +[22:17] <duck> it is _so_ cool +[22:17] <jrand0m> yeah, the sample code for the echo server and client look kick-ass +[22:18] <jrand0m> ok, moving on to 3) unit tests +[22:19] <jrand0m> yeah, there are some unit tests for most of the data structures, but they aren't "one click testable" so I don't run them on every build. +[22:20] <jrand0m> current thoughts are to migrate them to jUnit, as well as to merge as many of the other unit tests currently implemented in the main(..) method of various components (specifically the crypto ones) +[22:21] <duck> probably it is difficult to test more complex things +[22:21] <jrand0m> thats going to come up to be on the critical path sooner rather than later, depending on where the debugging leads us +[22:21] <jrand0m> right, the unit tests as is just test the basics +[22:21] <duck> like routing, tcp stuff etc +[22:21] <jrand0m> right +[22:21] * dm sees a debate on value of unit testing coming. +[22:21] <jrand0m> but things like the AESInputStream can be tested in collaboration with AESOutputStream +[22:22] <duck> unit test = kickass +[22:22] <jrand0m> (and for those watching their logs closely, there's been some funky "pushed back" behavior during decrypt streaming) +[22:22] <jrand0m> definitely. +[22:23] <jrand0m> unit tests are just for the, er, units. not for the larger components (which is what agenda item 4 is about ;) +[22:24] <jrand0m> but in any case, if someone is interested in helping out convert the existing data structure unit tests to the jUnit framework, lemmie know - it'd be much appreciated (and would give you a good foundation of the i2p codebase) +[22:24] * mihi_away is now known as mihi +[22:25] <dm> If it's not done by the weekend I can take a look. I know nothing about unit testing so I could learn through it. +[22:25] <jrand0m> wikked! +[22:25] <dm> No promises though. +[22:25] <jrand0m> right right +[22:25] <jrand0m> ok, moving on to 4) network testing / monitoring +[22:26] <jrand0m> has everyone read http://i2p.dnsalias.net/pipermail/i2p/2004-January/000101.html? I don't want to just copy and paste that +[22:26] * Frontier has joined #i2p +[22:27] * jrand0m gives people time to digest +[22:27] * dm says... +[22:28] <Frontier> digest wat? +[22:28] <dm> C) but not with automatic sending. +[22:28] <dm> i.e. you type emaillogstojrandom.sh (.bat) +[22:28] <dm> email or post, or whatever. +[22:29] <dm> and when it does that it clears you log, or moves it somewhere, so you don't submit the same data twice. +[22:29] <jrand0m> so basically B +[22:29] <jrand0m> (or A) +[22:29] <dm> Yeah, user-friendly B) :) +[22:29] <jrand0m> thats one of the tricks wrt the data... that log grows to tens of megs per night +[22:29] <jrand0m> right +[22:30] <dm> sorry, didn't see history=false for C. +[22:30] <jrand0m> Frontier) we're discussing section 4 of http://i2p.dnsalias.net/pipermail/i2p/2004-January/000101.html? +[22:30] <mihi> jrand0m: man bzip2 +[22:30] <dm> So history=false with a script to post on command. +[22:30] <dm> sorry, history=true :) +[22:30] <dm> god, I've made a mess of it. +[22:31] <jrand0m> right mihi, but bzip2 isn't on windows (unless we require it and install it). or do you mean bzip2 has a flag to submit a file to a url? +[22:32] <dm> I wouldn't worry about the size, 10s of megs for the small group of people you have here is fine. +[22:32] <Ophite1> I vote C. +[22:32] <dm> As long as it gets archived when you run the script to submit. +[22:32] <Ophite1> This is a debug client. +[22:32] <Ophite1> A in a production client of course :) +[22:32] <mihi> jrand0m: then use GZipOutputStream +[22:32] <jrand0m> right right Ophite1 ;) +[22:33] <jrand0m> mihi> people might like to read these files ;) +[22:33] <duck> yeah, opt-in for debugging participation, but once you join, make it as easy as possible for the user (so C) +[22:33] <mihi> man zcat ;) +[22:33] <Ophite1> jrandom: gzcat | less ;-) +[22:33] <mihi> Ophite1: zless ;) +[22:33] <jrand0m> C:\Documents and Settings\dev>man +[22:33] <jrand0m> 'man' is not recognized as an internal or external command, +[22:33] <jrand0m> operable program or batch file. +[22:33] <jrand0m> ;) +[22:34] <mihi> cd \cygwin <Ctrl+T> call cygwin.bat +[22:34] * dm twiddles his thumbs. +[22:34] <Ophite1> double-click -> winrar -> view +[22:34] <jrand0m> ok, so we have one B, two C, whats your take mihi? +[22:34] <jrand0m> (and anyone else?) +[22:34] <dm> twiddle thumbs, pick nose, click click. +[22:34] <mihi> double-click - 7zop - view. I'd say C. +[22:35] <mihi> s/7zop/7zip/ +[22:35] <jrand0m> 3 c one b. i kind of prefer c too, and of course if someone /doesnt/ want to submit this data, they can always say so and it won't do shit +[22:36] <jrand0m> i'll see if i can implement both c and b +[22:36] <dm> Looks like C it is. +[22:36] <dm> Don't waste your time, the B person is on dialup and would offer very little data anyway ;) +[22:36] <jrand0m> hehe +[22:36] <jrand0m> well, c is probably going to be implemented on top of b, so it won't take any more work +[22:37] <jar> for me : just like Ophite1 said ! A for prod client, C for debug ... +[22:37] <jrand0m> word jar +[22:37] <jar> just like Ophite1 said ! A for prod client, C for debug ... +[22:37] <Ophite1> obviously not anything other than A for prod client... +[22:37] <jar> just like Ophite1 said ! A for prod client, C for debug ... +[22:37] <Ophite1> that's a no-brainer :) +[22:37] <jar> sorry ... :( +[22:37] <jrand0m> s'all good jar, we won't kickban you (... this time ;) +[22:38] <jrand0m> ok, so i'll get cracking on that, and pretty much once thats tested we'll have a new 0.2.3.5 release (sometime tomorrow) +[22:39] <jrand0m> ok, moving on to 5) ??? +[22:39] <jrand0m> anyone have anything else? questions, thoughts, concerns? +[22:39] * duck offers free hosting +[22:39] * dm accepts free hosting +[22:39] <jrand0m> oh word. yeah, people should host sites on host.duck.i2p, its nice having reachable pages +[22:39] <jrand0m> (of course people should also feel free to host for themselves too ;) +[22:40] <duck> sure, just for those who can't stay online 24/7 +[22:40] <jrand0m> right +[22:40] <mihi> what happened (will happen?) to the streaming api? +[22:40] <jrand0m> mihi> its in the task list, but getting the network functioning reliably is higher priority at the moment :/ +[22:41] <mihi> but it is not dropped completely? (that's what i wanna know...) +[22:41] <jrand0m> i'll get back to the streaming api for the 0.3.1 release (perhaps sooner, but not sure) +[22:41] <jrand0m> its definitely NOT dropped completely. +[22:41] <jrand0m> it will be done. +[22:41] <dm> What's this streaming API? A different way of exposing the network to clients? +[22:42] <jrand0m> dm> http://wiki.invisiblenet.net/iip-wiki?I2PSocketLibrary +[22:43] <jrand0m> I made what is arguably a mistake of including mode=guaranteed in the router from the beginning instead of putting it in a seperate lib (and now i'm trying to move it out of the router :) +[22:43] <jrand0m> (the insanely awesome benefit of that mistake was mihi coming along and writing i2ptunnel :) +[22:44] * wn-user has joined #i2p +[22:44] <jrand0m> anyone else have anything? +[22:44] * dm gets it. +[22:45] <jrand0m> w3rd +[22:45] <dm> Hmmm, too early to end meeting, ain't it? +[22:45] <duck> what about the hosts.txt +[22:45] <duck> it is growing and growing +[22:45] <jrand0m> well, 45 mins. two weeks ago we had 20 mins +[22:45] <jrand0m> ah, true that +[22:45] <duck> but 75% is offline +[22:45] <duck> and it looks like 50% is permanently offline +[22:45] <jrand0m> prolly +[22:46] <jrand0m> I dunno +[22:46] <duck> just keep it growing, to raise the incentive for a DNS solution :) +[22:46] <jrand0m> heh exactly +[22:46] <Ophite1> I'm all for a little delay, I'm having a lot of fun with all kinds of Windows problems... +[22:46] <dm> Ophite1: windows is the devil! +[22:46] <Ophite1> You never really understand just how awful Windows is, until you write software for it. +[22:47] <jrand0m> reason #941 to use java +[22:47] <dm> Unless you're using .NET. +[22:47] <dm> also known as java++ +[22:47] <Ophite1> dm/jrand0m: it's still running *on* Windows, and there are still some things you just keep running into. +[22:47] <duck> jrand0m: those last patches, would they solve disconnects? or more connection problems +[22:47] <Ophite1> Path lengths for example. Bloody unicode. +[22:48] <mihi> Or not to use \n in file names ;) +[22:48] <mihi> which will crash cvs anyway (on *nix, BTDT) +[22:48] <jrand0m> duck> no patches today are critical +[22:48] <duck> from yesterday I mean +[22:49] <dm> What happens if you use \n in a filenamE? :) +[22:49] <mihi> dm: try it ;) on *nix, nothing happens, as long as you don't try to run cvs update afterwards. +[22:49] <jrand0m> oh, yesterday there were Good patches that would solve some (most? all?) i2ptunnel Peer unreachable messages. not i2cp disconnects though +[22:50] <dm> I think it would throw an exception. +[22:50] <jrand0m> (which is one of the reasons 0.2.3.5 is coming out) +[22:51] <mihi> dm: it works w/ local repository, but not w/ pserver or ssh. +[22:51] <mihi> something like 'protocol error'. +[22:51] <mihi> (the protocol terminates file names by \n ;) ) +[22:51] <Ophite1> sort of like what happens with direct connect if you have filenames with $ and | in them. I hate DC. +[22:51] <duck> . +[22:52] <Ophite1> No matter what I code, ever, it could never be that bad :) +[22:52] <jrand0m> naw, you c devs just treat \0 as special instead of $ ;) +[22:52] <jrand0m> ok, anything else on i2p or we good to go? +[22:53] * madman2003 has quit IRC (12( www.nnscript.de 12:: NoNameScript 3.8 12:: www.XLhost.de 12)) +[22:54] <jrand0m> 'k thazzit +[22:54] * jrand0m *baf*s the meeting to a close +\ No newline at end of file diff --git a/pages/meeting75.html b/pages/meeting75.html new file mode 100644 index 00000000..09dfbf0f --- /dev/null +++ b/pages/meeting75.html @@ -0,0 +1,102 @@ +
+[22:03] <jrand0m> 0) hi +[22:03] <jrand0m> 1) router dev status (0.2.4) +[22:03] <jrand0m> 2) RTCP +[22:03] <jrand0m> 3) i2p.net +[22:03] <jrand0m> 4) ??? +[22:03] <jrand0m> 0) hi +[22:03] * jrand0m waves +[22:03] <jrand0m> this is meeting $num +[22:03] <duck> . +[22:03] * mihi_backup has joined #i2p +[22:03] <jrand0m> logs will go up onto the wiki once we're through +[22:03] * Robert has quit IRC (Ping timeout) +[22:04] * baffled has quit IRC (Ping timeout) +[22:04] <jrand0m> ok, moving on (hopefully battling ping timeouts)... 1) router dev status +[22:04] * baffled has joined #i2p +[22:05] <jrand0m> some more bugfixes this week, and a large part of the delay and associated message loss has been narrowed down the PHTTP transport +[22:06] <jrand0m> to avoid repeating myself from the email [http://i2p.dnsalias.net/pipermail/i2p/2004-January/000113.html], so, does anyone have any questions / comments on the dev status? +[22:06] <duck> yes +[22:06] <jrand0m> sup? +[22:06] <duck> seems that still after a while the whole tunnel thing locks up +[22:07] <duck> then madman2003 and human have to shout at me +[22:07] <duck> and restart everything +[22:08] <jrand0m> hmm, yeah, I think thats due in large part to the fucked up nature of the 0.2.3.5 PHTTP code. There are some routers out there that are only reachable via PHTTP, and if they are still running plain 0.2.3.5, they won't be able to talk to each other (but will be able to talk to you) +[22:08] * jar has joined #i2p +[22:08] <madman2003> i'd like to say one thing(a bit offtopic): a 404 page in 0.3 would be nice, because a lot of browsers get confused if they don't get an expected response +[22:08] <jrand0m> that means that whenever you build a tunnel through them, your tunnel is unreachable +[22:09] * DrWoo has quit IRC (Ping timeout) +[22:09] <jrand0m> duck> thats one of the reasons on the 'pro' camp for releasing a 0.2.3.6 asap, with 0.2.4 coming out with RTCP in few days +[22:09] * DrWoo has joined #i2p +[22:09] <duck> ok, so that is phttp part? +[22:09] <jrand0m> (the 'con' camp being led by "upgrading sucks") +[22:10] <jrand0m> hmm? the phttp code has been patched in cvs +[22:10] <duck> what con camp? +[22:10] <jrand0m> madman2003> I think baffled might be looking at that :) +[22:10] <madman2003> upgrading is easy :) +[22:10] <kaji> upgrading rox +[22:10] <madman2003> with i2pmgr it's even easier +[22:11] <madman2003> just a touch of a button :) +[22:11] * Robert has joined #i2p +[22:11] <baffled2> I'm looking at it madman might be a while! +[22:11] <jrand0m> well, the con side is that if there's a release (in, say, a few hours), people will have to do another upgrade in, say, 2-3 days +[22:11] <jrand0m> if thats fine, i can wrap up a 0.2.3.6 quite easily +[22:11] <duck> updating makes me happy +[22:12] <kaji> what does .6 fix? +[22:12] <baffled2> I'd say go for it most of us don't have any problem with upgrading regularly. +[22:12] <madman2003> i'd upgrade every 24 hours if that does it +[22:12] <jrand0m> 0.2.3.6 fixes PHTTP to be, er, functional +[22:12] <jrand0m> ok cool +[22:13] <jrand0m> i'll get a 0.2.3.6 wrapped up after the meeting then (perhaps 1-2 hours to clean up) and post on the list when its ready +[22:13] <jrand0m> (as well as here) +[22:13] * Masterboy has quit IRC (Ping timeout) +[22:14] <jrand0m> ok, anything else for the dev status, or shall we jump to 2) RTCP +[22:15] * jrand0m jmp 2 +[22:15] <madman2003> you can always get back to it +[22:15] <jrand0m> right right +[22:15] <jrand0m> ok, rtcp is coming along, and I'm hoping to have the client side libs working after a few more hours of coding +[22:16] <jrand0m> Kirk brought up a good point on the list for chaining - in theory, all of these relays could have an inter-relay connection to build a virtual relay network +[22:16] <jrand0m> but, well, that essentially grows into IRC, or another full on anon network +[22:17] <madman2003> you mean totally eliminating PHTTP? +[22:17] <jrand0m> while thats possible (and quite interesting), I think for now we'll just have the stand alone RTCP relay (and/or integrated relay in the router) +[22:18] <jrand0m> madman2003> no, PHTTP will stay (if only for time sync and people behind HTTP only firewalls), but RTCP provides a faster, low latency alternative +[22:18] <madman2003> (i'd intergrate in the router, because that would spread the load of the relaying) +[22:18] <jrand0m> agreed +[22:19] <jrand0m> basically the topology I forsee with the RTCP is everyone who can have a reachable address will run their own RTCP relay (with their own targetId on that), plus anyone who doesn't have a reachable address can just pick any of those that do and create a target on them +[22:20] <jrand0m> these relays essentially become switchboards for peer comm, but in a fully distributed fashion (since none of them depend in any way on any of the other ones) +[22:20] <madman2003> or use multiple relays if the there are more relays then people who need relays +[22:20] <baffled2> How would folks find the various rtcp relays? +[22:20] <madman2003> phttp :) +[22:20] <jrand0m> right, thats a good point - routers can create targets on multiple relays +[22:20] <jrand0m> baffled> rtcp relays will be listed in a router's RouterInfo (published in the networkDb) +[22:21] <jrand0m> basically a router will see "oh, router XYZ has an rtcp address at 127.0.0.1:8999 targetId 3123" and then connect to 127.0.0.1:8999 and request its own target +[22:23] <madman2003> something i just thought off: auto restart of tunnels every 12 or 24 hours +[22:23] <madman2003> and an auto restart of router + the rest every few days +[22:24] * jrand0m is working on making it so that wouldn't be necessary +[22:24] <jrand0m> one of my routers on a linux box has been up without interruption for several days +[22:24] <mihi> madman2003: you can add your own threads to the jvm to quit it after 12 hours +[22:24] <jrand0m> (and it only went offline when I upgraded it) +[22:24] * madman2003 has to go +[22:25] <jrand0m> l8r madman2003 +[22:25] <madman2003> have a nice meeting +[22:25] * madman2003 has quit IRC (12( www.nnscript.de 12:: NoNameScript 3.8 12:: www.XLhost.de 12)) +[22:25] <jrand0m> ok, anything else on rtcp? +[22:26] <duck> no, sounds good +[22:26] <jrand0m> ok, moving on to a brief one +[22:26] <jrand0m> 3) i2p.net. +[22:26] <jrand0m> nuff said +[22:26] <jrand0m> 4) ??? +[22:26] <jrand0m> anyone have anything else? +[22:28] <duck> . +[22:28] * jrand0m senses a record breaking 26 minute meeting +[22:29] <Reskill> lol +[22:29] * Reskill ambles in +[22:29] <jrand0m> 'mornin Reskill +[22:29] <jrand0m> ok, I'm going to get working on pushing out a 0.2.3.6, then crunch away on the rtcp code for a 0.2.4 +[22:30] <jrand0m> if there is nothing further... +[22:30] <Reskill> Oo... +[22:30] <baffled2> Okay, I'll see you all when I get home. +[22:30] * jrand0m *baf*'s the meeting closed +\ No newline at end of file diff --git a/pages/meeting76.html b/pages/meeting76.html new file mode 100644 index 00000000..6b5b7066 --- /dev/null +++ b/pages/meeting76.html @@ -0,0 +1,518 @@ +
+[22:01] <jrand0m> 0) hi
+[22:01] <jrand0m> 1) testnet
+[22:01] <jrand0m> 2) updated roadmap
+[22:01] <jrand0m> 3) updated application list
+[22:01] <jrand0m> 4) volunteers needed
+[22:01] <jrand0m> 5) ???
+[22:01] <jrand0m> 0) hi
+[22:01] * jrand0m waves
+[22:01] * mihi waves back
+[22:02] * jrand0m has to warn that i've been up for too long, so may be a little out of it
+[22:02] <jrand0m> but anyway, as we proceed, everyone should read (or have read) http://i2p.dnsalias.net/pipermail/i2p/2004-February/000132.html
+[22:02] <jrand0m> lets jump right into 1) testnet
+[22:03] <mihi> you should change the subject for each mail... they all get sorted into one thread here
+[22:03] <jrand0m> hah nice
+[22:03] * jrand0m tried for consistency (for ease of filtering)
+[22:03] <jrand0m> would you like me to add the date to it?
+[22:03] <madman2003> how is the testent really doing?(pessimistic opnion please)
+[22:03] <jrand0m> madman2003> poorly, but better than before
+[22:04] <mihi> jrand0m: date (or meeting number) would be great
+[22:04] <jrand0m> 'k mihi, consider it done
+[22:04] <jrand0m> (anyone other than me want to give some feedback to madman2003's question?)
+[22:04] <duck> madman2004: baffled and me have been connected for 4h now
+[22:04] <baffled> Really that long?
+[22:04] <duck> before test3 the maximum time was 10 min
+[22:05] <jrand0m> w00t
+[22:05] <duck> baffled: since 18:15:07 CET
+[22:05] <jrand0m> yeah i had a 90m session the other day too
+[22:05] <duck> but maybe we are directly hopped
+[22:05] <madman2003> and you're sure the link is intact?
+[22:05] <jrand0m> duck> all tunnels are 2 hop (unless your router is failing, in which case your tunnels will break at least once)
+[22:06] <jrand0m> madman2003> when the tunnels fail, they fail hard
+[22:06] <madman2003> how's general latency on the testnet?
+[22:06] * Ophite1 has joined #i2p
+[22:06] * jrand0m usually gets 2-10s latency through the squid
+[22:06] * lucky has joined #i2p
+[22:06] <jrand0m> 5-20s latency through irc
+[22:07] <madman2003> is the 30 secs delay on local sites fixed yet?
+[22:07] <jrand0m> duck> can you /ping duck on your ircd? how long does it take to reply with a CTCP refused error?
+[22:07] <jrand0m> (or baffled>)
+[22:08] <jrand0m> madman2003> there have been significant bugfixes that would account for 30s+ delays locally
+[22:08] <jrand0m> (jobs got locked up causing insane delays)
+[22:08] <duck> response to admin request to baffleds ircd is ~8s
+[22:08] <jrand0m> duck> to local?
+[22:09] <duck> fido ping/pong is 3 seconds, which is local
+[22:09] <jrand0m> coo'
+[22:09] <duck> for local eepsites it also seems to be ~3s
+[22:09] <jrand0m> (still much higher than i'd like, but <<30s)
+[22:09] <duck> initial request longer, might be ~30s
+[22:10] <jrand0m> interesting
+[22:10] <duck> ,
+[22:10] <jrand0m> ok, so there's definitely still work to be done on the testnet, but there's been progress
+[22:10] <madman2003> is the testnet going to run until poor performance becomes perfect, what is the exact requirement of succes?
+[22:11] <madman2003> (i know about 3 days of working good)
+[22:11] <jrand0m> success == 3 consecutive days of things that should succeed succeeding.
+[22:11] <jrand0m> human has volunteered to help out and implement something along the lines of what I posted in the email
+[22:11] * mihi floods the testnet with pings ;)
+[22:11] * leenookx has quit IRC (Ping timeout)
+[22:11] <jrand0m> basically a way we can just leave a pair of bots connected to the two ircds and measure our progress and failures
+[22:12] <jrand0m> (yay human!)
+[22:12] <mihi> hmm, if there is no netsplit, i2p is working, but you cannot make the other way conclusion...
+[22:13] <jrand0m> the i2p roadmap [http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap] has the 0.2.4 release (~= testnet completion) in a week and a half
+[22:13] <madman2003> why don't you focus on making local delay <1s?
+[22:13] <jrand0m> that i will.
+[22:13] <madman2003> good chance that will solve some other problems too
+[22:13] <jrand0m> the cause of >1s delay is likely the load
+[22:14] <jrand0m> for routers with no peers, local only requests are near instantaneous
+[22:14] <jrand0m> (but as the testnet is actually showing some load, we're stressing different things)
+[22:15] <duck> baffled and me also had a little chat about making statsbots, but if human wants to do it; cool for me
+[22:15] <madman2003> maybe delays have to do with requests being send to other routers
+[22:15] <madman2003> before it see that it's local
+[22:15] <jrand0m> oh word duck
+[22:15] <jrand0m> naw, doesn't work that way madman2003
+[22:16] <jrand0m> (it gets pumped to the client manager first, which checks if its local, and only if it isn't does it get placed in the router's net pool)
+[22:16] * madman2003 wonders where all that load is coming from
+[22:16] <jrand0m> france.
+[22:16] <jrand0m> er, germany.
+[22:16] <jrand0m> (since *someone* is pinging everyone ;)
+[22:17] <duck> kuala lumpur
+[22:17] * duck hopes nobody gets that joke
+[22:17] * jrand0m is pleased to meet duck's hopes
+[22:17] <mihi> all that pings made my local box thrashing as well... (with no router!)
+[22:18] <jrand0m> mihi> the i2cp lib does the crypto ;)
+[22:18] * wiht has joined #i2p
+[22:18] <madman2003> doesn't i2p protect from ping floods?
+[22:19] <jrand0m> madman2003> the load isn't that significant, its just the code currently has very course grain synchronization (and during the testnet thats being adjusted to more fine grained sync)
+[22:19] <madman2003> grain sync?
+[22:19] <mihi> jrand0m: congrats: seems that ping -ns does not only produce - - - now
+[22:20] <jrand0m> lol mihi :)
+[22:20] <mihi> why lol? ping -ns never worked for me. (only the synchronized one)
+[22:20] <duck> synchronized one never worked for me...
+[22:20] <jrand0m> oh really? word, -ns has been working well for me
+[22:21] <jrand0m> madman2003> its a tradeoff of memory and CPU vs concurrency
+[22:22] <jrand0m> (course grained synchronization minimizes CPU and memory usage, while fine grained synchronization uses more CPU and memory in exchange for higher concurrency)
+[22:22] * TrueSeeker has quit IRC (Leaving)
+[22:22] * mihi will post ping stats in #flood in a few secs
+[22:22] * ion has quit IRC (Ping timeout)
+[22:23] <lucky> bah.
+[22:23] <jrand0m> but yeah, the plan is to have the testnet wrap up once it passes the 3 day test. my current estimate is the 14th, but we'll see.
+[22:23] <lucky> miserably day.
+[22:23] <lucky> stupid capitalist pigs
+[22:23] <lucky> taking all my money..
+[22:24] <baffled> looks like there a are new goodies in cvs, how long before test4?
+[22:24] <jrand0m> not today, hopefully tomorrow
+[22:24] * jrand0m is going to bed after the meeting :)
+[22:25] <baffled> cool.
+[22:26] <madman2003> bye everyone
+[22:26] <jrand0m> later madman2003
+[22:26] <madman2003> don't forget the other points of the meeting :)
+[22:26] <jrand0m> ok, so thats testnet. anything else on that, or shall we move to 2) updated roadmap?
+[22:26] <jrand0m> hehe
+[22:26] <baffled> Are there other stressers we need on the test net?
+[22:26] * madman2003 has quit IRC (12( www.nnscript.de 12:: NoNameScript 3.8 12:: www.XLhost.de 12))
+[22:26] <duck> what date is it?
+[22:27] <jrand0m> Feb 3
+[22:27] <baffled> 3rd here.
+[22:27] <mihi> 2004-02-03
+[22:27] * leenookx has joined #i2p
+[22:27] <duck> ah, thanks
+[22:27] <jrand0m> baffled> actually, has anyone tried out i2psnark on testnet?
+[22:27] <wiht> baffled: What do you mean by stressers?
+[22:28] <mihi> wiht: i guess people stressing the testnet
+[22:28] <baffled> Well, the other day you asked aum and I to siess and desist on nntp I was kinda thinking about setting up a 128kbps ogg stream.
+[22:28] * mihi 'd like a public echo service set up by anyone - would allow good latency checks
+[22:28] <baffled> so those two items I guess.
+[22:28] <jrand0m> we've had a good crew hitting the squid
+[22:28] <jrand0m> oh, nntp would rule, as would an ogg stream!
+[22:29] * jrand0m doesn't recall asking y'all to stop (except maybe temporarily during an update?)
+[22:29] <jrand0m> agreed mihi
+[22:29] * jrand0m checks what port 'echo' is
+[22:29] <jrand0m> 7
+[22:29] <mihi> afaik 9
+[22:29] <mihi> oops ;)
+[22:29] <baffled> You may been frazelled about something else at the time.
+[22:30] <wiht> Port 7.
+[22:30] <duck> 4
+[22:30] * ion has joined #i2p
+[22:30] <jrand0m> prolly baffled ;)
+[22:30] <duck> echo 4/ddp # AppleTalk Echo Protocol
+[22:30] <jrand0m> echo 7/tcp
+[22:30] <jrand0m> echo 7/udp
+[22:30] <jrand0m> echo 4/ddp # AppleTalk Echo Protocol
+[22:30] <wiht> Port 7 for TCP and UDP.
+[22:30] <mihi> duck: we want [0-9]*/tcp
+[22:30] * duck ducks
+[22:31] * Synonymous has joined #i2p
+[22:31] <jrand0m> so, anyone want to wrap up human's test app (the echo server and client)?
+[22:32] <jrand0m> (though running twisted does seem a bit much for that ;)
+[22:32] <duck> the non-twisted one would work
+[22:33] <duck> .
+[22:33] * jrand0m didn't realize his i2p code could work w/out twisted
+[22:33] <jrand0m> but anyway, anyone wnat to volunteer to run point on getting an echo service up?
+[22:33] * duck sits on his hands
+[22:33] <wiht> Reachable through I2P, or reachable through regular Internet?
+[22:34] <jrand0m> through i2p
+[22:34] <baffled> I can look into it with some specific specs.
+[22:34] <mihi> duck: do ducks have hands? i thougt wings ;)
+[22:34] <jrand0m> spec: receive a line of text and echo it back :)
+[22:34] <baffled> oh, okay no prob.
+[22:34] <lucky> bah... i have to start filing taxes next year!
+[22:34] <mihi> jrand0m: s/line/byte chunk/
+[22:34] <lucky> Stupid, damn government...
+[22:35] <jrand0m> mihi> line is so much easier to parse ;)
+[22:35] <duck> lucky: hush
+[22:35] <jrand0m> baffled++
+[22:35] <jrand0m> ok, moving on to 2) updated roadmap
+[22:35] * jrand0m directs people's attention to http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap
+[22:36] <mihi> jrand0m: why? while (len=in.read(b) != -1) {o.write(b,0,len);}
+[22:36] <jrand0m> (which, of course, y'all have already read)
+[22:36] * MrEcho has joined #i2p
+[22:36] <jrand0m> mihi> single byte messages vs nagle, etc
+[22:37] <jrand0m> but anyway, whatever baffled implements to do echoing to support testing is Good
+[22:37] <jrand0m> (or you and he can work out what works best for you)
+[22:37] * wiht has quit IRC (Ping timeout)
+[22:37] <baffled> If you have requirements write them down and let me know later mihi and I'll try.
+[22:38] * ion has quit IRC (Ping timeout)
+[22:38] <mihi_backup> baffled: not really. if needed adding a newline after a timestamp is no problem at all.
+[22:38] * jar_ has quit IRC (Ping timeout)
+[22:38] <duck> (netsplit after 4:20)
+[22:38] <jrand0m> heh
+[22:39] <jrand0m> not good :/
+[22:39] <jrand0m> well, iterative and incremental.
+[22:39] <mihi> 22:38:09.430 ERROR [WrC1->Pz83 ] .i2p.i2ptunnel.I2PTunnelRunner: Error sending
+[22:39] <mihi> message to peer. Killing tunnel runner
+[22:39] <jrand0m> are all 9/10 routers up atm?
+[22:39] <jrand0m> (or did one go down?)
+[22:40] <jrand0m> i only see 8
+[22:40] <jrand0m> 22:41:02.758 ERROR [TCP Read [9]] er.transport.tcp.TCPConnection: Error reading from stream to [RouterIdentity:
+[22:40] <jrand0m> Hash: 4Sb3aJoFusrhpHgYA2xCZCkn0P5jBo822qu9C0wsE1w=
+[22:40] * duck did just update
+[22:40] <duck> where goes the i2cp admin stuff fit in the roadmap?
+[22:41] <duck> afaik that isnt implemented, but 0.2.5 talks about finalizing the spec
+[22:41] <jrand0m> current plan is to make I2CP the plain client protocol, leaving admin functionality seperate
+[22:41] <jrand0m> (e.g. through the :7655 admin web port)
+[22:41] <duck> ok
+[22:42] <jrand0m> (and rip out all that other crap)
+[22:42] * jar_ has joined #i2p
+[22:42] * ion has joined #i2p
+[22:42] <jrand0m> ((shrinkingCodebase)++)
+[22:43] <jrand0m> does anyone have any thoughts on the two Big Issues?
+[22:43] <jrand0m> = aborting the current PHTTP transport (until 2.0)
+[22:43] <jrand0m> = keeping support for a restricted route topology at 2.0
+[22:43] <baffled> Well gang, gotta boogie so I'll have to read the logs later.
+[22:43] <jrand0m> cool, glad you could make it, l8r
+[22:43] * baffled has quit IRC (Leaving)
+[22:44] <duck> secure i2cp would lower the direct need for restricted route topology a bit
+[22:44] <duck> so thats fine
+[22:45] <jrand0m> agreed, though the 'secured' in this sense won't be ideal (all i2cp payloads will of course be encrypted, but sniffers can detect that $client is sending a $n byte message to $destination)
+[22:46] <jrand0m> the only difference from the current i2cp is a little update to the authentication protocol / structure
+[22:46] <jrand0m> ((well, the $client can't detect $n, since messages are padded randomly. nm)
+[22:46] <jrand0m> er, $sniffer, not $client
+[22:47] * wiht has joined #i2p
+[22:47] <jrand0m> (of course that doesn't defeat a global passive adversary)
+[22:48] <jrand0m> anyone have any other concerns / suggestions / ideas / comments?
+[22:48] <jrand0m> (on the roadmap)
+[22:49] <duck> no
+[22:49] <jrand0m> nor do i
+[22:49] * jrand0m hops on to 3) updated application list
+[22:49] <jrand0m> [insert "mihi rules" rant here]
+[22:50] <duck> help jrand0m to say no!
+[22:50] <jrand0m> mihi> any thoughts on the muffin thing? http://wiki.invisiblenet.net/iip-wiki?I2PApplications
+[22:50] <jrand0m> heh
+[22:51] <mihi> jrand0m: you know what i think about that...
+[22:51] <jrand0m> (i'm not specifically asking you to integrate it, i'm just seeing what your thoughts are as to whether it would be good)
+[22:52] <mihi> httpclient has to get out of i2ptunnel, since i2ptunnel is for stream forwarding and httpclient does content forwarding
+[22:52] <mihi> hacking that into i2ptunnel would be just more hackish.
+[22:52] <jrand0m> word, so the app down below [Scalable web proxies]
+[22:52] <jrand0m> that makes sense
+[22:53] <jrand0m> (apps that do One Thing and One Thing Well)++
+[22:53] <mihi> jrand0m: you misunderstood me...
+[22:53] <jrand0m> whaddimiss?
+[22:54] <mihi> i don't have anything against an app that reads a http request, parses it, sends it over i2p, reads the answer, parses it, sends it back (maybe with filtering) - just not do it as httptunnel does.
+[22:54] <mihi> httptunnel forwards everything except the first few lines.
+[22:54] <jrand0m> ah you're right
+[22:55] * jrand0m doesn't quite have head screwed on correctly
+[22:55] <mihi> it would be hard to build effective filtering into it (if it should filter html and not text or sth like that)
+[22:55] <jrand0m> right - perhaps just have MUFFIN as a standalone
+[22:55] <jrand0m> (filtering whatever comes out of the httpclient)
+[22:55] <mihi> so i'd say, an extra app for that. but that would require streaming lib... (or sth like that)
+[22:56] * duck likes how you can do proxies xmlrpc/soap with httpclient though
+[22:56] <wiht> jrand0m: I did not see an entry for "muffin" on the list of applications.
+[22:56] <jrand0m> wiht> http://muffin.doit.org/
+[22:56] <mihi> muffin is a http content filter
+[22:57] <mihi> if we have a content filter, we could drop that shitty "proxy" thingy.
+[22:57] <jrand0m> duck> hopefully the muffin filter would be set to pass through xmlrpc/soap, only filtering things like VBScript / etc
+[22:57] <wiht> I see.
+[22:57] <jrand0m> hm, mihi?
+[22:57] <duck> ah wait, xmlrpc/soap would be content type xml
+[22:57] <jrand0m> mihi> wouldn't it still need to do the name translation, at the least?
+[22:58] <mihi> sure, but not as a proxy. http://localhost:12345/duck.i2p/ would work much better.
+[22:58] <Synonymous> muffin is gpl, u have to be careful in a public domain project to use gpl code, its still copyrighted ;)
+[22:58] <mihi> since you can link to that from the regular web
+[22:58] <jrand0m> hrm mihi.
+[22:58] <mihi> Synonymous: i2ptunnel is gpl anyway
+[22:58] <jrand0m> Synonymous> I2PTunnel is GPL
+[22:58] <Synonymous> ya
+[22:59] * jrand0m is well aware of the fact that some people consider copyrights valid, and tries to accomodate them.
+[22:59] <Synonymous> make sure to put that up where it is visible (if you use muffin) it already says that iptunnel is gpl
+[22:59] <jrand0m> of course, if we use muffin it'd get attributed and marked as gpl.
+[22:59] <Synonymous> ya thats what i said, becareful about it
+[23:00] <jrand0m> (we're not going to get into the copyright discussion here)
+[23:00] <jrand0m> ok, any other thoughts on the apps listed?
+[23:00] <Synonymous> then don't, and my comment was not intended to start one
+[23:00] * duck laughts at http://muffin.doit.org/demo/evil/
+[23:01] <jrand0m> what do y'all think will be necessary app functionality for 1.0?
+[23:01] <jrand0m> heh duck
+[23:01] <jrand0m> (or are we already there, and 1.0 app functionality == things proxied through i2ptunnel :)
+[23:02] <Synonymous> ppl would want functional chat, and maybe a freenet like ap for 1.0 if thats what you are asking, maybe a set of tools so ppl can easily set up their own services on it
+[23:02] <mihi> an IM and a naming service are still missing
+[23:02] <jrand0m> mihi> irc over i2p?
+[23:02] <wiht> Yes, naming service should be in place by 1.0 version of I2P.
+[23:03] <duck> eep
+[23:03] <mihi> jrand0m: irc over i2p would be okay as well, but a naming service ;)
+[23:03] <jrand0m> wiht> do you have any thoughts on whether a naming service will be implemented and ready to go live by April?
+[23:03] * jrand0m really doesn't think a naming service is necessary. useful, yes
+[23:04] <jrand0m> (all we *need* is a way to easily update a hosts.txt file)
+[23:04] <kaji> or a distributed vpn layer
+[23:04] <jrand0m> heh
+[23:04] <mihi> jrand0m: for me even that (if automated) is a naming service
+[23:04] <wiht> jrand0m: Probably by the middle of April.
+[23:05] <jrand0m> kaji> a distributed vpn layer is a solid month of 1-2 devs ;)
+[23:05] <wiht> I want to make it scalable for accomodating many more entries than we have in hosts.txt now.
+[23:05] <jrand0m> 1.0-->3.0 wont have millions of entries
+[23:05] <wiht> MrEcho: Do you have any thoughts on this?
+[23:05] <jrand0m> thousands, yeah
+[23:06] <jrand0m> Synonymous> freenet like app would be cool, but then we need to recruit someone to implement :)
+[23:07] <jrand0m> Synonymous> tools to set up services - definitely. hopefully i2pmanager or i2pmole will do
+[23:07] <Synonymous> that might be hard, esp since freenet doesnt work hehe
+[23:07] <wiht> Speaking of which, what is the progress of I2PManager?
+[23:07] <jrand0m> aparently its coming along, the console / cli mode is making progress (aum now uses it to manage his services via init scripts)
+[23:08] <jrand0m> i've used the gui, and aum's logged a few bugs on the tunnelmanager that are still outstanding
+[23:08] <jrand0m> (due to large #s of tunnels being created, not due to a small #)
+[23:08] <wiht> I think I2PManager should be an application for 1.0.
+[23:09] <jrand0m> i hope so too
+[23:09] <jrand0m> (especially since that would mean we can throw out the kludged installer, since i2pmanager has that built in)
+[23:09] <jrand0m> so, people with python experience should get in touch with aum to see how they can help :)
+[23:09] <human> re
+[23:09] <jrand0m> wb human
+[23:10] * human read about the muffin proxy
+[23:10] <human> i know about another privacy-oriented personal proxy called privoxy
+[23:11] <jrand0m> yeah, privoxy was another one i had been looking at. good potential as well
+[23:11] <jrand0m> (reason i leaned towards muffin was the ease of integration, since its java)
+[23:12] * jrand0m won't be the one who implements / integrates it, so my view is only a suggestion
+[23:12] <@Nightblade> i think a group chat (or irc) would be a good program because if you can get chat to work reliably then you know i2p's latency and stability are good
+[23:13] <jrand0m> agreed
+[23:13] <Synonymous> how would trent work on such a system though, is it possible to do it with a system of public and private keys (like frost)
+[23:13] <Synonymous> the channel would be the 'board' ?
+[23:13] <jrand0m> Synonymous> duck has actually done some neat stuff
+[23:13] <Synonymous> kool
+[23:14] <duck> which is: users login with a secret password to the ircd, the ircd publishes the sha1 of the password
+[23:14] <jrand0m> Synonymous> in his modified ircd, you can provide a password that has its hash shown in the ident
+[23:14] <Synonymous> it would also be like waste i guess, even though I didnt usei t
+[23:14] <jrand0m> duck> though if anyone else creates their own ircd, they can spoof that :/
+[23:14] <duck> so others can check the sha1 against a local list, without requiring a centralized database
+[23:15] <duck> sure
+[23:15] <jrand0m> but people could just remember what ircd someone usually connects from, i suppose
+[23:15] <jrand0m> would it be possible to have a nickserv?
+[23:15] * jrand0m doesn't know much about how irc nets work
+[23:16] <duck> yes, but I didnt want that
+[23:16] <duck> because Trent was made as a temporary hack
+[23:16] <jrand0m> right, it'd be Good if we could do without
+[23:16] <jrand0m> hehe
+[23:16] <jrand0m> until iip 2.0, right? ;)
+[23:16] <duck> now it is the longest running joke in the world
+[23:17] <duck> .
+[23:18] <jrand0m> ok, so if we go 1.0 with: irc, eepsites (and a way to set up your own), squid, and cvs, thats reasonable?
+[23:18] <@Nightblade> yeah
+[23:18] <jrand0m> (obviously it'd be fantastic if we could include i2psnark, naming, I2PIM, and the other apps)
+[23:19] <duck> with irc you mean native i2pirc?
+[23:19] <duck> or if not, why not nntp etc too
+[23:19] <jrand0m> oh, right
+[23:19] <jrand0m> of course
+[23:20] * jrand0m !thwaps self.
+[23:20] <duck> not too much ofcourse
+[23:20] * duck thinks that the pgp keyserver is silly
+[23:20] <jrand0m> i just meant that its easy to overwhelm people with options
+[23:20] <duck> ah, sure
+[23:20] <duck> as in officially bundeled stuff
+[23:20] <jrand0m> "why should I use I2P" "well you can [.............]"
+[23:20] <jrand0m> right
+[23:20] * duck agrees
+[23:21] <jrand0m> with i2ptunnel, we can support all that we've seen (and more :)
+[23:21] <jrand0m> ok, in that case, I don't think we need to worry too much about the i2papps
+[23:21] <mihi> btw: we should deprecate the -nogui option of I2PTunnel...
+[23:22] <jrand0m> to default to -nogui?
+[23:22] <jrand0m> (or you trying to get us all to use awt? ;)
+[23:22] <mihi> no. not to use -nogui at all. -cli and -nocli are more "transparent"
+[23:22] <Synonymous> you should also package all these options in 1 distro if you can
+[23:22] <jrand0m> ah ok mihi
+[23:22] <Synonymous> unlike freenet, which mentions no otehr utilities and its up to you to go find them out
+[23:22] <jrand0m> Synonymous> definitely
+[23:22] <jrand0m> Synonymous> have you used i2pmgr yet?
+[23:23] <mihi> -nogui acts differently whether you use -e "run configfile" or use "configfile"
+[23:23] <Synonymous> no, i couldnt get it working :)
+[23:23] <jrand0m> (its still pre-alpha, but functional)
+[23:23] <jrand0m> ah ok
+[23:23] <Synonymous> from before but it didnt try the gui
+[23:23] <Synonymous> i might try now that it has one
+[23:23] <Synonymous> :)
+[23:23] <jrand0m> word, its been makin progress
+[23:23] * duck suppresses a yawn
+[23:24] <jrand0m> yeah yeah yeah duck, ok ;)
+[23:24] <jrand0m> i think thats it for apps - unless someone else has something?
+[23:24] <jrand0m> moving on to 4) Volunteers needed
+[23:25] <jrand0m> we're making good progress, and the pace is fine and imho sustainable
+[23:25] <jrand0m> but we've all been talking about some really neat things that we'd like added on
+[23:25] <jrand0m> if there were another N hours in the day, yadda yadda yadda
+[23:26] <duck> what do you mean with 'development bandwidth'?
+[23:26] <jrand0m> more hours of developer activity
+[23:26] <duck> aye
+[23:27] <jrand0m> (e.g. 2 developers == 16/20 hours/day)
+[23:27] <jrand0m> my gut feeling is of the 'if you build it, they will come' variety
+[23:28] <jrand0m> (but i've also worked at companies that thought they had a kickass product, made it more kickass, released it, and didn't see much market activity)
+[23:28] * duck doesnt think that hiring cheap indians will work
+[23:28] <jrand0m> heh
+[23:29] <duck> product marketing != developer marketing
+[23:29] <jrand0m> right, i agree
+[23:29] <jrand0m> i just meant as an analogy
+[23:30] <jrand0m> we'll see how things progress. i just wanted to throw that stuff out there
+[23:30] <@Nightblade> it is a complex program which makes it harder to find people who can figure it out
+[23:31] <jrand0m> agreed Nightblade
+[23:31] * greasyaxelsex__ has joined #I2P
+[23:31] <jrand0m> Nightblade> thats what 1.0 release criteria #3 on the roadmap is for: " Javadoc and code walkthrough / guidebook updated"
+[23:32] * dm has joined #i2p
+[23:32] * wiht has quit IRC (EOF From client)
+[23:32] <jrand0m> we currently have a generally up to date wiki providing an overview of the java impl
+[23:32] <mihi> hi dm
+[23:32] <jrand0m> but i will definintely need help with the documentation
+[23:32] <dm> hello mihi.
+[23:33] <jrand0m> (since what makes sense to me != what makes sense to people learning the code)
+[23:33] * dm accuses jrand0m of using terms he's invented when explaining things.
+[23:34] <jrand0m> occationally ;)
+[23:34] <Synonymous> i will help wtih the webpage if u want
+[23:34] <jrand0m> (though the only thing i knowingly have coined wrt i2p is 'militant grade anonymity' ;)
+[23:34] <Synonymous> i already have a template
+[23:34] <dm> How far are we from a bugless 0.2.x? I get my broadband in less than a week's time.
+[23:34] * wiht has joined #i2p
+[23:34] <Synonymous> the website needs major owkr
+[23:34] <Synonymous> im working on my own anonymous p2p website, but you can borrow mine :)
+[23:35] <jrand0m> hehe
+[23:35] <Synonymous> its modeled after freenet's
+[23:35] <Synonymous> but better
+[23:35] <Synonymous> :P
+[23:35] <jrand0m> actually, yeah, perhaps we can start a thread on the i2p list describing goals of the website and seeing how it fits together?
+[23:35] <dm> Synonymous: are you building a p2p app, or just the website?
+[23:35] <Synonymous> just the website
+[23:35] <jrand0m> (and if that traffic grows, we'll move to something like i2p-www@)
+[23:36] <duck> ROFL at anonymous p2p website boilerplates
+[23:36] <jrand0m> dm> roadmap updated at http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap with 0.2.4 slated for February 14
+[23:36] <Synonymous> explaing anonymous p2p, the different topologies of networks, the philosophy of it, cypherpunkdom, digital imprimature, links to projects, a mailing list for ppl to discuss it
+[23:36] <mihi> dm> bugless sw does not exist
+[23:36] <jrand0m> duck> gotta keep the anonymity set large ;)
+[23:36] <Synonymous> also links to the other website that does that
+[23:37] <dm> mihi: does too!
+[23:37] <jrand0m> mihi> i worked on one project a few years ago that actually shipped with 0 bugs. no p1 or even p5s
+[23:37] <dm> func addints(int a, int b) { return a + b; }
+[23:37] <mihi> jrand0m: they just did not find them...
+[23:37] <mihi> dm: which language?
+[23:37] <jrand0m> mihi> then its not a bug ;)
+[23:37] * greasyaxelsex__ has left #I2P (greasyaxelsex__)
+[23:37] <dm> pseudo-language
+[23:38] <mihi> and how does this pseudo-language react on an overflow?
+[23:38] <wiht> dm: In a project with thousands of lines of code, having no bugs is much less likely.
+[23:38] <duck> .
+[23:38] <Synonymous> so April is the deadline for something for public release? Why not try to recruit some devls, or would it take to long for you to explain to them how it works etc.
+[23:39] <dm> input is never over max_value /2
+[23:39] <jrand0m> (we're currently ~20KLOC, using the "grep \; | wc -l" algorithm)
+[23:39] <jrand0m> Synonymous> I don't think we want to just go around posting on lists "hey, we're doing a kickass thing, come code on it" (thats essentially a 1.0 announcement)
+[23:40] <dm> that's a lotta lines.
+[23:40] <dm> Java bloat!
+[23:40] <jrand0m> but if there are people who are interested in helping out, i'll most definitely go out of my way to find out how i can get them involved
+[23:40] * jrand0m kicks dm
+[23:40] <jrand0m> java bloat is when the jvm uses ram. you're suggesting OO bloat
+[23:40] <dm> What a project leader jrand0m is.
+[23:40] <Synonymous> well, how will u know if ppl are interested if there is no knowledge of it, thats a contradiction
+[23:41] <Synonymous> and by 'recruit' i mean email them, not pubically anounce on say, zeropaid, about i2p
+[23:41] <Synonymous> like someone did ;)
+[23:41] <jrand0m> Synonymous> what are your thoughts on the explanation of that issue from the email?
+[23:41] <dm> Right OO bloat.
+[23:41] <jrand0m> yeah, I was pissed when someone told me about that zp article
+[23:41] <Synonymous> ya your the one that did the interview
+[23:41] <jrand0m> (you can read the august iip-dev messages)
+[23:41] <Synonymous> they just quoted you?
+[23:41] <jrand0m> "interview"? more like some random person on iip asking me questions
+[23:42] <dm> mihi: are you working on the streaming lib?
+[23:42] <Synonymous> ah :)
+[23:42] <mihi> dm:no
+[23:42] <mihi> Standard@laptop /cygdrive/c/eigenes/notback/cvsprojects/i2p/i2p/code
+[23:42] <mihi> $ grep \; `find . -name "*.java"` | wc -l
+[23:42] <mihi> 30593
+[23:42] <jrand0m> ah.
+[23:42] <Synonymous> well, make get a list of project leaders for anonymous p2p and say "here is a project you might be interested in looking at, if you have any ideas on code or projects that might help it please let me know"
+[23:42] <mihi> 30kLOC ;)
+[23:42] <jrand0m> grep -v \^import
+[23:43] <jrand0m> Synonymous> stealing project leads == bad form ;)
+[23:43] <jrand0m> (there are many good projects, and while I obviously think i2p is important, others are too)
+[23:44] <Synonymous> not stealing, and i dont think the 'leader' can be stolen, he would just desolve the project
+[23:44] * jrand0m cant believe we're at 30kloc
+[23:44] <jrand0m> heh
+[23:46] <jrand0m> ok, moving on to 5) ???
+[23:46] <duck> 2 eepsite proposals, for those who dont know what to do: 1) meshmx FE tunnel (with stunnel) 2) pastebin.de site
+[23:46] <jrand0m> anyone have anything else to discuss / bring up?
+[23:46] <jrand0m> oh word duck
+[23:46] <jrand0m> whats pastebin.de?
+[23:46] <jrand0m> (similar?)
+[23:47] <duck> site where you can paste code/logs/stuff publically
+[23:47] <duck> for irc debugging
+[23:47] <duck> http://pastebin.de/
+[23:47] <jrand0m> interesting
+[23:47] * @Nightblade just prefers flooding channels with code
+[23:48] <jrand0m> wow that is one hell of an innovative idea
+[23:48] <jrand0m> insanely simple.
+[23:48] <jrand0m> focused.
+[23:48] <jrand0m> practical.
+[23:48] <dm> Only python though?
+[23:48] <jrand0m> oh reall?
+[23:48] <jrand0m> :/
+[23:48] <duck> I think this one has python highlighting
+[23:48] * jrand0m takes back 'practical' ;)
+[23:48] <duck> but I have also seen php ones etc
+[23:48] <duck> and you might have a general approach
+[23:48] <dm> I think I've seen one which accepts any language.
+[23:49] <dm> Good idea, mind you.
+[23:49] <duck> anyway, just something simple
+[23:49] <duck> you dont need highlighting at all
+[23:49] <duck> online linenrs would be useful
+[23:49] * dm looks at python code.
+[23:49] <dm> What's so special about this again?
+[23:50] <jrand0m> its got a y
+[23:50] * Nightblade sets mode: +o jrand0m
+[23:50] <@jrand0m> w00t
+[23:50] * Trent@anon.iip sets mode: +o mihi
+[23:50] <duck> there is nothing special about it,
+[23:51] <dm> A lot of people really like it, I think.
+[23:51] <duck> oh, you mean about python
+[23:51] <dm> yes, sorry.
+[23:52] * duck moves that to 6) offtopic
+[23:52] <duck> :)
+[23:52] <@jrand0m> heh
+[23:52] <@jrand0m> [beuler, beuler]
+[23:52] <dm> Sorry, didn't realize you guys were having a meeting.
+[23:52] <@jrand0m> every tuesday 9p gmt :)
+[23:53] <duck> ok, php stuff: http://pastebin.com/pastebin.php?showsource=php
+[23:53] <@jrand0m> anyone have anything else they want to bring up wrt i2p, etc?
+[23:54] <@mihi> i2p rocks!
+[23:54] <@jrand0m> (if only it were more reliable..)
+[23:55] <@mihi> it is more reliable than freenet for me ;)
+[23:55] <@jrand0m> heh :)
+[23:55] <@jrand0m> if i just hadn't fucked with your i2ptunnel to set the retry count to 0 we'd be fine ;)
+[23:56] <@jrand0m> (corrupt a lil data here and there, but that never hurt no one...er......)
+[23:56] <@jrand0m> ok
+[23:56] <dm> don't baf
+[23:56] * @jrand0m isn't going to try to drag it out 4 more minutes to reach 2 hours
+[23:57] <dm> do not baf
+[23:57] * @jrand0m denies dm and *baf*'s the meeting closed
+
\ No newline at end of file
diff --git a/pages/meeting77.html b/pages/meeting77.html
new file mode 100644
index 00000000..9631ef14
--- /dev/null
+++ b/pages/meeting77.html
@@ -0,0 +1,500 @@
++[22:00] <jrand0m> <incoming> +[22:00] <jrand0m> 0) hi +[22:00] <jrand0m> 1) testnet status +[22:00] <jrand0m> 2) naming in i2p +[22:00] <jrand0m> 3) minwww and i2cp +[22:00] <jrand0m> 4) i2p.net website +[22:00] <jrand0m> 5) ??? +[22:00] <dm> I was thinking the other day, that we could make a .NET interface to I2P. Anyway.. +[22:00] <FireRabbit> well there will be one +[22:00] <madman-away> hello +[22:00] <jrand0m> -1) .net interface would be cool +[22:00] <jrand0m> 0) hi +[22:00] * madman-away is now known as madman2003 +[22:00] <jrand0m> hey y'all +[22:00] <wilde> hi +[22:00] <FireRabbit> <-- will write a .net interface +[22:00] <FireRabbit> anyway hi +[22:00] <jrand0m> r0x0r. +[22:00] <dm> awesome +[22:01] <jrand0m> welcome to the 70somethingth meeting +[22:01] <FireRabbit> <-- needs that URL with the client protocol +[22:01] * ion has joined #i2p +[22:01] <jrand0m> i2p.net/ has links to the wiki, you'll probably want to use the tunnelManager +[22:01] <FireRabbit> ok +[22:01] <jrand0m> (people should review http://i2p.dnsalias.net/pipermail/i2p/2004-February/000142.html for this weeks status update) +[22:01] <FireRabbit> and that works good in the latest release? +[22:02] <jrand0m> yup, aum uses it (and i just fixed a bug he was running into a few hours ago) +[22:02] <jrand0m> (specs @ http://wiki.invisiblenet.net/iip-wiki?I2PTunnelManager) +[22:02] <jrand0m> ok, movin' on +[22:02] <jrand0m> 1) testnet status +[22:02] <FireRabbit> okc ool yes, +[22:03] <jrand0m> i hate sounding like a broken record here, but... testnet is making progress. +[22:04] <jrand0m> we're still not there, but we have multihour sessions without hiccup on the latest build +[22:04] <jrand0m> some setups aren't giving that level of reliability, but some are. so, we're working on making them all up to speed +[22:04] <FireRabbit> excellent +[22:04] <baffled> We're at least populating the net with animals +[22:05] <jrand0m> hehe +[22:05] <jrand0m> dog, cat, mouse, duck... +[22:05] * wiht has joined #i2p +[22:05] <FireRabbit> rabbit! +[22:05] <baffled> maybe I should become a bafflo +[22:05] <human> human! +[22:05] <jrand0m> !! +[22:05] <jrand0m> #animalfarm +[22:06] <dm> dm +[22:06] <jrand0m> but, yeah, thats basically what i've got to say about the testnet status (beyond whats in that status email) +[22:06] <wilde> people will read the logs offline so stay on topic please +[22:06] <jrand0m> heh sorry dad ;) +[22:07] <jrand0m> i think we're still on track for the roadmap +[22:07] <wiht> How many more testnet releases do you plan to distribute? +[22:07] <jrand0m> (plus i've been getting some future things done while running tests, such as the >2 hop tunnels) +[22:07] <jrand0m> wiht> as many as it takes +[22:08] <jrand0m> we're quite close to being done with this round of the testnet though, in my opinion +[22:08] <dm> isn't >2 hop tunnels just a setting? +[22:08] <jrand0m> yes +[22:08] <jrand0m> but in the past it wasn't well tested +[22:08] <dm> cool +[22:09] <jrand0m> while the testnet has been going on, i've had my own seperate testnet on my laptop doing other things +[22:09] * human is open to suggestions to make the ircmonitor more useful +[22:09] <jrand0m> <dreaming>an http listener to render .png on demand?</dreaming> +[22:09] <jrand0m> (or just a /msg cat renderPNG) +[22:10] <human> jrand0m: ok, it should be feasible +[22:10] <baffled> I'd still like to see text summaries. +[22:10] <jrand0m> human++ +[22:10] <baffled> on the ircmonitor. +[22:10] <jrand0m> yes, (text summaries)++ too +[22:10] <human> jrand0m: i was still thinking to make it use gnuplot to generate graphs (instead of gnu plotutils) +[22:11] <jrand0m> potato, potato +[22:11] <jrand0m> (ah, the glory of accents on irc) +[22:11] <FireRabbit> lol +[22:11] <human> jrand0m, baffled: could you give me an example of a text summary? +[22:11] <baffled> If you leave it with me a bit. +[22:11] * dm read that as "potato, potato" +[22:12] <jrand0m> period: 4 hours avg latency: 5.3s missed messages: 95 missed message frequency: 1 every 49 seconds +[22:12] <jrand0m> (perhaps max & min latency) +[22:12] <human> jrand0m: oh, ok +[22:12] <jrand0m> if thats possible / not too much trouble +[22:13] <jrand0m> (at least thats what i think of when i hear text summary) +[22:13] <wilde> max latency, min latency +[22:13] <mihi> human: look @ the summary i give for the ping tester +[22:13] <mihi> hmm, anyone running an echo server this week? +[22:13] <jrand0m> not to my knowledge +[22:14] <human> jrand0m: it should be feasible - i'll basically make the ircmonitor log more raw data, and then i'll create some utility scripts to generate graphs and/or text summaries +[22:14] <jrand0m> kickass +[22:14] <baffled> Sorry mihi, I've been meaning to set yours up but keep forgetting. +[22:14] <jrand0m> i think this will be a good part of the overall functional testing that will grow with us +[22:15] <jrand0m> ok, do we have anything else for the testnet discussion? +[22:16] * jrand0m moves on to 2) naming in i2p +[22:16] <wilde> what's the biggest issue with testnet right now? +[22:16] <jrand0m> biggest issue in testnet is two fold - +[22:16] <jrand0m> 1) finding and fixing the cause of router disconnect +[22:17] <jrand0m> 2) determining the cause of the frequent inter-ircd disconnects +[22:17] <mihi> 1b) coping w/ the fact that routers may disconnect sometimes +[22:17] <jrand0m> right +[22:17] <jrand0m> well, thats not really part of this testnet. +[22:17] <jrand0m> 0.3.x is a series of updates to deal with unreliable routers +[22:18] <jrand0m> thats really why i've been limiting the # of routers that run on the testnet - I know it acts poorly when routers aren't up most of the time +[22:18] <wiht> So you are assuming reliable routers for now, right? +[22:18] <jrand0m> in the 0.2.3.6 testnet, yes +[22:18] <jrand0m> (it recovers from failure, but not quickly enough) +[22:19] <jrand0m> (more graceful recovery will be with multiple leases per destination, increased peer profiling, replay prevention, and retries on alternate lease targets) +[22:20] <jrand0m> ok, moving towards 2) naming in i2p +[22:21] <jrand0m> wiht brings up the core of the issue - global names are really useful, and people like them +[22:21] <jrand0m> (people who arent familiar with this discussion should review http://i2p.dnsalias.net/pipermail/i2p/2004-February/000135.html and the subsequent replies) +[22:22] <wiht> People are used to them, perhaps more than to local names (such as your ICQ analogy). +[22:22] <jrand0m> i'm not sure. +[22:22] <jrand0m> lets say for instance that my name is John. +[22:22] <jrand0m> John isn't global. +[22:22] <jrand0m> not even John Q. Random is global. +[22:22] <jrand0m> nor is John Q. Random born in 1942 in Argentina. +[22:23] <human> well, it has been said that the naming system could have more than one flavor +[22:23] <jrand0m> thats true +[22:23] <human> people could choose a trusted "registration authority" to pick unique names from +[22:23] <jrand0m> absolutely. +[22:24] <jrand0m> though there is the danger there +[22:24] <wiht> The scheme I originally proposed allows for multiple certification authorities, as I recall. +[22:24] <human> jrand0m: of course, it's the tradeoff between comfort and security +[22:24] <FireRabbit> i think someone should write up a quick "centrlized" dns system for the time being then worry about security +[22:24] <human> jrand0m: :-) +[22:24] <FireRabbit> just to make testing easyer +[22:25] <jrand0m> multiple CAs works more easily without the global naming +[22:25] <wiht> jrand0m: Going back to your example, if you are the first to register jrandom.i2p, another John Random would have to register as jrandom2.i2p, for example. +[22:25] <baffled> There isn't really any problem until a conflict occures right? +[22:25] <jrand0m> FireRabbit> I have a strong feeling that what we start with will stay in place for 12+ months. +[22:25] <jrand0m> correct baffled, in any of the plans +[22:25] <wiht> baffled: That is the problem, yes. +[22:25] <jrand0m> wiht> not if there are multiple CAs +[22:25] <FireRabbit> suppose +[22:25] <wilde> eepsites will be a mess if there is local naming, links will not work +[22:25] <baffled> so you only need an authority in the case of conflict resolution. +[22:26] <jrand0m> yes they will wilde +[22:26] <jrand0m> names to be shared and used by others should be fully qualified - self certified - names +[22:26] <wiht> jrand0m: Could you give an example of a self-certified name? +[22:27] <jrand0m> from my email - http://i2pref/[base64 of the NameReference] +[22:27] <wilde> so when I link to your site, and there are three jrandoms out there...which one will be used? +[22:28] * human thinks that a decentralized NS without global naming is Good(TM), because it makes people understand the risks of delegating hostname verification and certification +[22:28] <jrand0m> you link with the fully qualified name - which includes the actual Destination *in it*. +[22:28] <jrand0m> (the NameReference structure from my email) +[22:28] <wilde> so it's like base64 linking +[22:28] <jrand0m> right human - it gets rid of that attack point +[22:28] <wiht> So people will have to type many characters again? That seems self-defeating. +[22:28] * madman2003 has quit IRC (EOF From client) +[22:29] <jrand0m> no one types base64 names +[22:29] <jrand0m> (well, maybe mihi does) +[22:29] <jrand0m> <a href="http://i2pref/[base64 of the NameReference]">jrandom's page</a> +[22:29] <wiht> Oh. That makes sense. +[22:30] * mihi does not *type* anything he can copy&paste +[22:30] <jrand0m> :) +[22:30] <wilde> ok but basically it's long URLS +[22:30] <jrand0m> within eepsites, yes +[22:30] * dm has quit IRC (Ping timeout) +[22:30] <wilde> k that was the question +[22:30] <jrand0m> there are several other scenarios worth looking at though +[22:31] <jrand0m> such as when people want to browse or search for new sites +[22:31] <jrand0m> those are situations where having servers that contain a lot of name references is useful +[22:31] <baffled> Could I propose the idea of a history server rather than an authority. +[22:31] <jrand0m> history server? +[22:32] <jrand0m> ah, so whoever was first "gets it"? +[22:32] <baffled> If someone adopts a new domain which is used the history server sends a note to that person outlining the original holder and how to contact them. +[22:32] <human> maybe an archive to see how a domain name changed during time? +[22:32] <baffled> The conflict can then be resolved by the two parties providing they are both available. +[22:33] <wiht> baffled: What if the new domain's operator is sleazy and continues to hold that already-taken domain name? +[22:33] <baffled> If one party is not available the the conflict goes o the available party in some amount of time. +[22:33] <human> of course it implies to give some trust to the server operator +[22:33] <wilde> that's just authority but in another way +[22:33] <jrand0m> right +[22:34] <baffled> Any arbitrator is either going to act as an authority. +[22:34] <human> well, using non-global names will make people understand that everything built on top of them will ease their life, but possibly make it less secure +[22:34] <jrand0m> right, right +[22:34] <baffled> I don't expect it will become a major problem. +[22:34] <jrand0m> (but why do we need an arbitrator? can't there be two johns in the world?) +[22:35] <jrand0m> if i2p is used for commerce or other such activities, I expect the names to be heavily attacked +[22:35] <baffled> If I want jrandom.i2p and jr won't give it up I can always chose jrandom.i3p or put out a contract. +[22:35] <wilde> I vote for the cryptic nameref solution´ +[22:35] <wiht> Again, that would be fine, as long as _new_ users would understand the implications and which John they want to contact. +[22:35] <jrand0m> (since someone would be able to hijack and get money, etc) +[22:36] <jrand0m> right - its likely we're always going to bundle some name references with the software +[22:36] <jrand0m> (ala the current hosts.txt) +[22:36] <wiht> One idea we should keep, though, is MrEcho's idea of attaching a timed lease to a reference. That way, domain names can expire. +[22:37] <jrand0m> why would domain names want to expire again? +[22:37] <baffled> They're tired of life? +[22:37] <jrand0m> oh, to replace the Destination included? +[22:37] <jrand0m> heh +[22:38] <wiht> Some because the operators want their domain names for just a day or a month. Others, if domain ownership is transferred to a different destination. +[22:38] <jrand0m> hmm, but without uniqueness, there really isnt such a thing as ownership +[22:38] <jrand0m> its not scarce +[22:38] <jrand0m> and if someone wants to change the dest they listen at, they sign a note with their dest saying "hey, I'm moving over here" +[22:39] <wilde> so the nameref is protected by one key, the destination is another +[22:39] <jrand0m> the nameref is signed by the destination's signing key +[22:40] <wilde> you may want another key just for namerefs if possible +[22:40] <jrand0m> hm, i understand and agree, but that'd mean Destination gets yet another 1024bit segment +[22:40] <wilde> so even if a machine gets compromised you can keep the nameref key on a paper +[22:41] * wiht has quit IRC (Ping timeout) +[22:41] <jrand0m> (and Destination is used all over the place) +[22:41] <jrand0m> hmm not sure I follow the compromised part? +[22:42] <wilde> the destination privkey is on the machine all the time +[22:42] <jrand0m> ah right right +[22:42] <wilde> the nameref private key doesn't to be, they can be kept on paper in the wallet +[22:43] <jrand0m> thats a good point. perhaps the comment block could be used for that (containing a PGP signature surrounding the Destination's hash)? +[22:43] <wilde> but that maybe overkill +[22:43] <wilde> i just don't like keeping the most valuable keys on the machine if isn't necessary +[22:44] <jrand0m> right - we need the Destination signing key and the destination decryption key, but nothing else, functionally. +[22:44] <jrand0m> hmm +[22:45] <jrand0m> perhaps the name reference could have a 1024bit public key on it as well +[22:45] <jrand0m> and we'd use that to verify via DSA +[22:45] <jrand0m> rather than the destination's public key +[22:45] <jrand0m> yeah, that'd fly +[22:45] <jrand0m> additional 32bytes, but only for nameReference, not for Destination +[22:46] * jrand0m doesnt know why I thought that'd imply it goes in the Destination +[22:46] <wilde> lots of keys :) but extra security and flexibility +[22:46] <jrand0m> right +[22:46] <jrand0m> (though, c'mon, we know everyone is going to keep their key in the same dir) +[22:46] <jrand0m> ((but maybe commerce shops wont)) +[22:47] <wilde> you can hand over a "domain" but not the destination, or change to someone elses destination +[22:47] <jrand0m> well, ok. i wish MrEcho and wiht were here +[22:47] <jrand0m> right +[22:48] <jrand0m> well, this is all fine and good, and I think it'll fly +[22:48] <jrand0m> but it needs to get coded :) +[22:49] <jrand0m> so, well, perhaps we'll have additional discussions about it later, but until that time, hosts.txt it is +[22:49] <wilde> hire some indians +[22:50] * jrand0m /dcc gets a grant to hire a team of 80 to work on i2p +[22:51] <wilde> :) +[22:51] <jrand0m> ok, do we have anything else for naming, or for the time being are we covered? +[22:51] <baffled> Skip on brother. +[22:52] * wiht has joined #i2p +[22:52] * jrand0m does a hop, skip, and a jump to 3) minwww and i2cp +[22:52] <jrand0m> d'oh, wb wiht +[22:52] <baffled> 1, 2, 5 uh 3 sitr. +[22:52] <wiht> I had trouble getting back on IIP network. I will read logs later. +[22:53] <jrand0m> cool wiht, and we can continue later on the list, etc +[22:54] <jrand0m> ok the other day I finally wrote up why I think i2cp is worth looking into using directly, and sketched up a minimal web system for use in i2p (and for proxying outside web pages through i2p) +[22:54] <jrand0m> (reference the wiki at http://wiki.invisiblenet.net/iip-wiki?MinWWW ) +[22:56] <jrand0m> for HTTP, the cost of establishing and tearing down TCP/IP connections is small, but over I2P, the difference is between 10 destination to destination messages vs 2 +[22:56] * sheer has joined #i2p +[22:56] <duck> did the meeting already start? +[22:57] <jrand0m> yeah, 56 mins ago +[22:57] * jrand0m sends duck to the corner +[22:57] <duck> so I am right on time +[22:57] * wilde has quit IRC (Ping timeout) +[22:57] <jrand0m> heh +[22:57] <baffled> No doubt about it, he's gotta get a new clock. +[22:58] <jrand0m> one part of minwww that I wasn't sure about was whether minwww proxies should automatically also be external gateways as well? +[22:58] * wiht has quit IRC (Ping timeout) +[22:59] <jrand0m> that'd increase the number of outproxies available, decreasing the load +[22:59] <jrand0m> plus with a round robin algorithm tied to the 64/128KB limit, there isn't much likelihood people would use it for large file sharing +[22:59] * wiht has joined #i2p +[23:00] <jrand0m> or should we just have something like a small set list of outproxies (thats periodically updated)? +[23:01] <jrand0m> (or is the idea not worth looking too much into?) +[23:01] * wilde has joined #i2p +[23:02] <jrand0m> (or i've timed out and no one can read anything i've said) +[23:02] <wilde> jrand0m: can see +[23:02] <jrand0m> 'k coo' +[23:02] <baffled> I'll need to understand it better but for now I have another appointment in ten minutes so I'll bbl. +[23:02] <jrand0m> word, l8r +[23:03] <jrand0m> yeah, there's still the absolutely key functionality of i2ptunnel to handle 8bit clean streams +[23:03] <jrand0m> thats necessary for e.g. irc over i2p and such +[23:03] <mihi> jrand0m: don't forget ss[lh] +[23:04] <jrand0m> but for message oriented protocols, such as http, smtp, bittorrent, etc, i2cp may be more appropriate +[23:04] <jrand0m> right, absolutely +[23:04] <jrand0m> (well, more like 'telnet', since ssh over i2p is a bit of an overkill) +[23:04] <wilde> ssh -X +[23:05] <jrand0m> true +[23:05] <jrand0m> (plus certs, etc) +[23:05] <wilde> there is never too much crypto +[23:05] <jrand0m> but if we're pulling web pages through squid in 5-10s, using i2cp would drop that to .5-2s +[23:06] <jrand0m> (without any subsequent tuning of the network, and would reduce overal network load) +[23:06] <wilde> how many man hours does it take to make i2cp? +[23:07] <jrand0m> imho, i2cp has a fairly simple API, bundled into the java i2p SDK +[23:07] <jrand0m> mihi can more fairly say how much effort it is to use / learn it +[23:08] * wiht has quit IRC (Ping timeout) +[23:08] <mihi> it's a bit confusing sometimes (when you have to put a value to the constructor and when to a method after calling default constructor, but w/ i2ptunnel and atalk as examples it should be not too hard. +[23:09] * ion has quit IRC (Ping timeout) +[23:09] <jrand0m> we can obviously improve upon the sdk, i just based it off the JMS api +[23:10] <jrand0m> (and i'd be more than willing to help out anyone who wanted to hack around with it to get familiar) +[23:11] <jrand0m> ok, do we have anything else on the minwww/i2cp? +[23:11] <jrand0m> if not, moving on to 4) i2p.net website +[23:11] <jrand0m> (and there was much rejoicing) +[23:11] <jrand0m> ok +[23:12] <duck> about search functionality +[23:12] <duck> wikipedia uses google for search functionality +[23:12] <jrand0m> thats true. and we're already the #1 result for i2p :) +[23:13] <duck> so a nifty thing might not be needed for searching. +[23:13] <mihi> duck: atm yes ;) +[23:13] <duck> I mean for internal searching +[23:13] <mihi> #1 is www.crestron.com/company_info/i2p/ +[23:13] <jrand0m> ah yeah, i forgot to bribe the pigeons this week +[23:14] <duck> LeaseSet site:wiki.invisiblenet.net +[23:14] <jrand0m> nice +[23:14] <jrand0m> yeah, absolutely. +[23:14] <wilde> drupal has internal search, and you can filter on content types +[23:15] <wilde> it's also VERY google friendly with the clean urls, no index.php?Zillions of arguments +[23:15] <wilde> everything looks like directories +[23:16] * ion has joined #i2p +[23:16] <wilde> ok I've played around with different CMS:s so far and Drupal is my current favourite +[23:16] <duck> I prefer Ian's home-baked solution +[23:16] <duck> :) +[23:16] <jrand0m> what does it use for a backend? mysql/bdb/txt/? +[23:16] <wilde> it's used by http://kerneltrap.org/ http://www.debianplanet.org/ http://www.linuxgazette.com/ +[23:16] <wilde> for example +[23:17] <wilde> it can take heavy loads +[23:17] <wilde> their designs sucks though +[23:17] <wilde> but a nice CSS stylesheet fixes that +[23:17] <wilde> here some other somewhat better looking ones: +[23:17] <duck> The Drupal core platform, additional plug-in modules, and many theme templates are freely available for download under the GNU GPL. Drupal, written in PHP and using either MySQL, PostgreSQL or mSQL as the database backend, can run on many platforms, including Apache or Microsoft IIS web servers. +[23:17] <wilde> http://www.sudden-thoughts.com/ +[23:17] <jrand0m> thats an important point - we need to make sure the underlying software can support the design (and the design can be workable on the underlying software) +[23:18] <wilde> http://www.codemonkeyx.net/ +[23:18] <wilde> http://www.disguast.org/index.php +[23:18] <wilde> http://trip.ee/ +[23:18] <wilde> http://www.blainepeterson.com/image +[23:18] <wilde> . +[23:19] * jrand0m gets the feeling wilde is a raving drupal fan :) +[23:19] <wilde> I'm starting to become that yes, as I like the information management ideas behind it +[23:19] <wilde> everything is a node +[23:20] <wilde> great taxonomy system +[23:20] <wilde> you can create vocabularies for Geographic location, content type, language, etc +[23:20] <wilde> and create custom urls that filters on content those +[23:21] <jrand0m> could it essentially include two blog sections on the homepage? e.g. one small blog area containing titles of the most recent dev blogs, and the main large seperate blog area containing the most recent i2p announcements? +[23:21] <wilde> and it's updated often and the changes are good +[23:21] <duck> in other words we are stupid that we dont have drupal already +[23:21] <wilde> we have duck +[23:21] <wilde> drupal.i2p.net +[23:21] <jrand0m> :) +[23:21] <wilde> you're so in the 90:s duck +[23:22] <duck> that is good +[23:22] <wilde> the design sucks of course +[23:22] <duck> cause that design is so in the 80:s +[23:22] <jrand0m> lol +[23:22] * wilde mud wrestles with duck +[23:22] <jrand0m> right, there are 3 different things that need to get worked out - the tech, the IA, and the graphic design +[23:23] <wilde> you could try the user interface +[23:23] <wilde> login: test pw: test +[23:23] <duck> warning: Bad arguments to implode() in /var/www/html/i2p/modules/project/issue.inc on line 360. +[23:23] <duck> user error: You have an error in your SQL syntax near ') AND (p.state = 1 OR p.state = 2) ' at line 1 +[23:23] <duck> query: SELECT COUNT(*) FROM project_issues p LEFT JOIN node n USING (nid) WHERE n.status = 1 AND () AND (p.state = 1 OR p.state = 2) in /var/www/html/i2p/includes/database.mysql.inc on line 90. +[23:23] <jrand0m> search still doesn't work wilde, right? +[23:24] <duck> user error: You have an error in your SQL syntax near ') AND (p.state = 1 OR p.state = 2) ORDER BY n.changed DESC LIMIT 0, 20' at line 1 +[23:24] <jrand0m> oh nice1 duck +[23:24] <duck> query: SELECT n.nid FROM project_issues p LEFT JOIN node n USING (nid) WHERE n.status = 1 AND () AND (p.state = 1 OR p.state = 2) ORDER BY n.changed DESC LIMIT 0, 20 in /var/www/htm +[23:24] <duck> sucky +[23:24] <jrand0m> AND () AND +[23:24] <wilde> whoops, i had some problems with search i must admint +[23:25] <duck> . +[23:25] <wilde> there is some full text indexing cron script not yet configured +[23:25] <wilde> 2 minutes and duck crashed my life work +[23:25] <jrand0m> (!hi5 duck) +[23:26] <jrand0m> but i do think its worth looking at +[23:26] <wilde> what did you do duck? +[23:26] <jrand0m> i don't know if we're at the point where we want to commit to some CMS yet +[23:26] <wilde> no +[23:26] <jrand0m> (s/some/some specific/) +[23:27] <duck> jrand0m did already make an overview of the requires features didnt he +[23:27] <jrand0m> http://i2p.dnsalias.net/pipermail/i2p/2004-February/000133.html +[23:27] <duck> so now all parties should come with proposals and the price +[23:28] <duck> ofcourse the winning solution will be paid in i2p stocks +[23:28] <jrand0m> which, let me tell you, is quite valuable +[23:28] <jrand0m> *cough* +[23:29] <jrand0m> you'll get your own @i2p.net email +[23:29] <jrand0m> and chicks will love you +[23:29] <jrand0m> (or guys, whatever) +[23:30] <wilde> we had some CMS options +[23:30] <wilde> we should go for some CMS +[23:30] <wilde> and wiki isn't really a long term solution +[23:30] <jrand0m> yeah some listed in point 4 @ http://i2p.dnsalias.net/pipermail/i2p/2004-February/000142.html +[23:30] <jrand0m> agreed, for the website itself +[23:31] <jrand0m> a wiki based section of the site might be good though, perhaps for the user guide / hackers guides +[23:31] <jrand0m> (but not for everything) +[23:32] <wilde> what about the hosting? +[23:32] <jrand0m> there's always the 53 entries at http://dmoz.org/Computers/Software/Internet/Site_Management/Content_Management/Open_Source/ +[23:32] <wilde> it should survive a slashdot +[23:32] <jrand0m> hosting? +[23:32] <jrand0m> ah, right. +[23:33] <jrand0m> thats actually a really huge draw of plain HTML in and of itself +[23:33] <jrand0m> (dirt easy to mirror) +[23:33] <wilde> and on +[23:33] <wilde> http://www.oscom.org/ +[23:33] <jrand0m> i2p.net is at a colo that is used by several large sites +[23:34] <jrand0m> ah right +[23:34] * jrand0m would love if people would keep at it and find the Right solution +[23:35] <wilde> http://www.opencms.org/ is interesting +[23:35] <wilde> but's maybe too corporate +[23:35] <wilde> with workflows, projects, etc +[23:35] <wilde> I really liked, used it for one project +[23:36] <jrand0m> interesting +[23:36] <wilde> but its java ;) +[23:36] <jrand0m> hmm, and xml +[23:36] <wilde> jsp templates etc +[23:36] <wilde> tomcat +[23:36] <jrand0m> (or jetty) +[23:36] <jrand0m> ((or resin)) +[23:37] <duck> (((lisp))) +[23:37] <wilde> I would never use if for this project, it's really too heavy +[23:37] <jrand0m> wilde> would you be willing to look over the main CMSes and map out pros and cons? +[23:38] <wilde> i have :), and chose Drupal ;) +[23:38] * jrand0m should have known +[23:38] <wilde> I've tried about ten of the major ones +[23:38] <wilde> for some earlier projects +[23:38] <wilde> different CMS works for different projects +[23:39] <duck> so say drupal is used +[23:39] <wilde> Zope and friends are nice too +[23:39] <duck> is the structure clear? +[23:39] <duck> is the next step doing the gui? +[23:40] <wilde> it's really just a CSS template that's needed for the gui, some changes to the xtemplate to prettify things +[23:41] <wilde> www.csszengarden.com could be an inspiration +[23:41] <jrand0m> wilde> could it essentially include two blog sections on the homepage? e.g. one small blog area containing titles of the most recent dev blogs, and the main large seperate blog area containing the most recent i2p announcements? +[23:41] <jrand0m> basically I want to avoid dev blog entries pushing news & announcements off the main stage +[23:42] <wilde> jrand0m: don't know, gonna check, blogs doesn't have to go front page, i configured it that way +[23:42] <jrand0m> ah cool +[23:42] <wilde> we can change to just stories go front page +[23:42] <wilde> everything that is a node could be frontpage, polls, stories, book pages, articles etc, +[23:43] <jrand0m> would it be possible to have stories at the top, with latest N blog entries below? +[23:43] * jrand0m stops micromanaging +[23:43] <wilde> blogs are linked to the bottom left right now, +[23:44] * godmode0 has joined #i2p +[23:44] <wilde> there are nice galleries as plugin, good for screenshots +[23:44] <jrand0m> word +[23:44] <wilde> the filestore plugin would be nice too +[23:45] <wilde> and more cvs, developer plugins too +[23:45] <wilde> and mailinglist +[23:45] <jrand0m> I'm no CMS expert, and it sounds like you've done your homework and are enthusiastic about it +[23:45] <jrand0m> w0ah nice +[23:45] <wilde> jrand0m: i need people pulling the brake for me sometimes :) +[23:46] <wilde> but the design really must be fixed, who are the design gurus here? +[23:46] * wilde can't stand poor design, wikis and current drupal kills him +[23:46] * jrand0m points at DrWoo and frontier +[23:46] <wilde> anyone here now? +[23:47] <duck> no, I left +[23:47] * jrand0m stares at the lurkers +[23:47] <wilde> so what should the site communicate? +[23:47] <duck> http://i2p.dnsalias.net/pipermail/i2p/2004-February/000133.html +[23:47] <wilde> this is a bit broader, we have marketing and donations to think of +[23:48] <jrand0m> (what duck said) +[23:48] <wilde> yeah i've read that, but we are more people here :) +[23:48] <jrand0m> :) +[23:48] <duck> but the puny humans dont matter! +[23:48] * wilde attaches to the borg collective +[23:49] <jrand0m> obviously one of the things I'd like the web site to communicate is "hey, this is a kickass project, you devs should join us and work for the revolution" +[23:49] <duck> ok; I am falling asleep +[23:49] <duck> enjoy +[23:49] <jrand0m> heh cool duck, g'night +[23:49] <duck> wilde: cool work on the CMS stuff +[23:49] * wilde remembers the thing about 80:s design, 5 months of work! +[23:50] <jrand0m> well, good thing we have 2 months then ;) +[23:50] <wilde> night duck +[23:50] <duck> oh yes, the design should BEG for peer reviews and useful comment +[23:50] * ion has quit IRC (Ping timeout) +[23:50] <jrand0m> agreed +[23:50] <wilde> about the toopie +[23:51] <jrand0m> i like 'im, he's humorous, simple, and topical +[23:51] <wilde> doesn't toopie look a bit ... hmm... stupid +[23:51] <jrand0m> (and he can serve as an icon with nearly any purpose) +[23:51] * ion has joined #i2p +[23:51] <wilde> he squints +[23:52] <jrand0m> heh i think we can wrestle up a top-left-logo-quality toopie +[23:52] <jrand0m> there've been a lot of revs going around for different purposes +[23:53] <wilde> i like him, but he must meet a personality consultant +[23:53] * jrand0m suggests bouncing some ideas off DrWoo, both for the design and toopie stuff +[23:54] <wilde> agreed +[23:54] <wilde> ok maybe we should leave it there +[23:54] <jrand0m> there's no rush, lots to digest and churn through +[23:54] <wilde> but please it you find this new kickass CMS, scream out +[23:54] <duck> can we have this as background: http://www.artchive.com/artchive/B/bruegel/death.jpg +[23:55] <jrand0m> but I agree with duck, nice work setting up a drupal to work off +[23:55] <jrand0m> that is so going straight to my desktop +[23:55] <jrand0m> wow I wonder what text over that would look like +[23:55] <wilde> cool picture +[23:55] <jrand0m> actually, on that note, 5) ??? +[23:56] <jrand0m> anyone have anything else to add? +[23:56] * jrand0m prods the peanut gallery +[23:56] <wilde> it's been very quiet in here today +[23:56] <wilde> everyone comes here to listen to messiah Jrandom +[23:57] <duck> 2h is a bit longish +[23:57] <mihi> *ggg* +[23:57] * jrand0m is just here for the beer +[23:57] <duck> maybe you could try 2 weekly meetings of 30 min each +[23:57] <wilde> nah +[23:57] <duck> and then the layoffs at friday afternoon +[23:57] <wilde> that's too often +[23:58] <jrand0m> i do think 2h meetings are very excessive +[23:58] <jrand0m> (unless they're specifically topical. e.g. a meeting discussing the web page design, or some router functionality, etc) +[23:58] <jrand0m> (hey look, we're meta) +[23:59] <jrand0m> perhaps I should shut up more and limit it to 1h? +[23:59] <jrand0m> or perhaps the bulk of the 'meeting' should go to the mailing list, with #i2p for discussion? +[23:59] * godmode0 has quit IRC (Ping timeout) +[23:59] <wilde> the mailinglist could be used more for discussions +Session Time: Wed Feb 11 00:00:00 2004 +[00:00] <duck> I think that the heavy email pre-logs are already good +[00:01] <jrand0m> so maybe the weekly meetings turn more into "ok guys, whats up? anyone have anything to discuss?" +[00:01] <jrand0m> (but open ended meetings like that are a danger in and of themselves) +[00:01] * godmode0 has joined #i2p +[00:02] <jrand0m> ok, maybe we can move this meta to the list or to later +[00:02] <jrand0m> we've already broken the 2h mark +[00:02] <jrand0m> so... +[00:02] * jrand0m winds up... +[00:02] <fidd> :) +[00:02] * jrand0m *baf*s the meeting closed +\ No newline at end of file diff --git a/pages/meeting78.html b/pages/meeting78.html new file mode 100644 index 00000000..9b390a49 --- /dev/null +++ b/pages/meeting78.html @@ -0,0 +1,287 @@ +
+Considering we did not have a very official meeting do to Jrand0m not +feeling very well, here are my logs of the meeting from slightly +before it started to sometime after it ended. I have edited out the +kick offs and start screens from iip restarting at least twice during +that period. If someone else has better logs feel free to replace +these. (baffled) +
+<human> baffled: we're experimenting a psychic communication towards jrand0m, to ask him to be here for the meeting +<human> baffled: just focus your mind on him, and help us +> Don't we have to hold hands or something like that? +<human> baffled: if it helps you focusing your mind... well, yes +> Cool, gimme your hand I'm commensing to focus! +
+[22:00] <jrand0m> 0) hi +[22:00] <jrand0m> 1) 0.2.4.2/0.2.5 +[22:00] <jrand0m> 2) docs +[22:00] <jrand0m> 3) ??? +[22:00] <jrand0m> 0) hi +[22:00] <human> hi +[22:00] * jrand0m waves to the newly-restarted iip-ircd :) +[22:01] <jrand0m> (and, uh, to you :) +[22:01] <jrand0m> weekly status notes (that we're running off) located at http://i2p.dnsalias.net/pipermail/i2p/2004-February/000148.html +[22:01] <jrand0m> (and posted to the mailing list, obviously) +[22:01] <jrand0m> 1) 0.2.4.2/0.2.5 +[22:02] <jrand0m> Dev has been making some good headway on the 0.2.5 release, which will allow and exploit both 2+ hop tunnels and clients with multiple inbound tunnels +[22:03] <jrand0m> the key functionality that will provide will be increased reliability and functional anonymity +[22:04] <jrand0m> the 1-hop tunnels we have now exposes you to statistical attack by an active opponent, but with 0.2.5 you'll be able to determine the length of your own hops (and increasing the default to 2) making the statistical attack much more complex +[22:06] <jrand0m> i also found a pair of bugs in the client send process and the network db which could account for some of the latest instability +[22:06] <jrand0m> (bugfixes underway) +[22:07] <jrand0m> as an aside, I think the roadmap [http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap] is still an accurate reflection of the dev schedule +[22:07] * mihi has joined #i2p +[22:07] <jrand0m> heya mihi +[22:07] * protocol has quit IRC (Ping timeout) +[22:07] <jrand0m> ok, thats it for the router dev status, moving on to 2) docs +[22:07] * human would like to say that he finds I2P unusable since 0.2.4 (it seems to behave *far* worse than the 0.2.3 age, at least on my PC) +[22:07] <jrand0m> hm +[22:08] <human> maybe we could talk about it after the meeting... +[22:08] <jrand0m> in reliability terms, latency, CPU, bandwidth? +[22:08] * protocol has joined #i2p +[22:08] <mihi> hi jrand0m, hi all +[22:08] <human> jrand0m: i can't reach any eepsite or I2P service (with few temporary exceptions) +[22:08] * mihi seconds human +[22:09] <jrand0m> most eepsites are down - duck, baffled, madman2003 are the most consistently up lately +[22:09] <human> jrand0m: i can't reach them, nor irc.*.i2p +[22:09] <jrand0m> squid I use constantly for all my web browsing - are you unable to use that? +[22:09] <human> jrand0m: nope +[22:09] <jrand0m> hm +[22:10] <madman-away> well an uptime of about 8 hours daily for my i2p site +[22:10] <human> jrand0m: we could talk about it after the meeting, i don't want to monopolize the discussion :-) +[22:10] * madman-away is now known as madman2003 +[22:10] <mihi> it might be my provider's problem as well, http://babelfish.altavista.com/babelfish/urltrurl?tt=url&url=http%3A%2F%2Fwww.expressnet.de%2Fnews%2Fnews.php&lp=de_en :( +[22:10] <Janonymous> me too +[22:10] <human> jrand0m: just to point out that some problems seems to exist (that weren't shown before) +[22:10] <Janonymous> mine should be up now +[22:11] <madman2003> what destination? +[22:11] <jrand0m> well, 'k, if things are going backwards in reliability we need to address that before moving on to 0.2.5 +[22:11] * mihi hates babelfish's english :( +[22:11] <jrand0m> heh +[22:12] <jrand0m> (well, it got the Thank you for your understanding. sentence correct at least...) +[22:12] <human> jrand0m: it should be investigated... i thought about an ISP issue, too, but the problem seems to be constant since 0.2.4 (and doesn't seem to happen with other network services) +[22:12] <jrand0m> 0.2.4.0 was shit, as was 0.2.4.1 +[22:12] * wilde has joined #i2p +[22:13] <human> jrand0m: i know, and it worries me... +[22:13] <wilde> hey i2p +[22:13] <jrand0m> heya wilde +[22:13] <madman2003> one thing i noticed is that tunnels tend to get unstable more often +[22:13] <human> jrand0m: i didn't change too much with 0.2.4.2 (at least for me) +[22:13] <human> jrand0m: s/ i / it / +[22:14] <jrand0m> madman2003> thats easily due to routers going on and offline (which will be a big problem until 0.3) +[22:14] <jrand0m> hmm ok +[22:14] <wilde> jrand0m: does that mean we should avoid running transients for now? +[22:15] * mihi has quit IRC (Ping timeout) +[22:15] <jrand0m> hm, I think there are going to be significant fixes in 0.2.5, but we can hold off on moving from 0.2.5 to 0.3 until after the reliability issues are cleared. +[22:16] <jrand0m> wilde> i don't like the term transients, it makes me think of another project that treats unreliable routers differently than reliable ones. we treat all routers equally (and need to, for anonymity) +[22:16] <jrand0m> but as long as routers generally stay up or generally down, they're fine +[22:17] <jrand0m> (just not up 10 minutes, down 10 minutes, up 30, down 30, etc) +[22:17] <madman2003> i do have one request: an option for the router(and tunnels) to be reastablished +[22:17] <baffled> i2p is an equal router opertunity organization? +[22:17] <jrand0m> heh baffled +[22:18] <jrand0m> madman2003> router to be reestablished? your router is shutting down still? +[22:18] <madman2003> i mean reconnecting everything +[22:18] <madman2003> sort of a warm restart of the router +[22:18] <madman2003> without pissing of the other routers +[22:18] <madman2003> (i have to restart router and tunnels a lot) +[22:18] <jrand0m> you can safely restart your client apps (e.g. i2ptunnel eepproxy, etc) without touching the rotuer +[22:19] <jrand0m> you should /never/ need to restart your router. +[22:19] <jrand0m> (almost all config settings are updated dynamically) +[22:19] * Trix has joined #i2p +[22:19] <jrand0m> hi Trix +[22:19] <Trix> hi +[22:19] <madman2003> usually restarting the tunnels does the trick +[22:21] <jrand0m> there's only one situation where that's technically necessary (old lease expirations in a client's leaseSet, which occurred on startup randomly), and thats been fixed in CVS, so you shouldn't need to do that. +[22:22] <jrand0m> (in fact, restarting tunnels can cause temporary problems, depending on the type of tunnel) +[22:22] <madman2003> sometimes i just don't know if i'm causing problems or if someone else is +[22:22] <jrand0m> if your router console doesn't have any of the red warnings, its the network (or someone else) +[22:22] * jnk has joined #i2p +[22:23] <jrand0m> patience fixes more of the current i2p bugs than restarts do ;) +[22:24] <jrand0m> but we'll have another series of bugfix releases after 0.2.5 +[22:24] <jrand0m> (like testnet, except without the restrictions on the userbase) +[22:25] <jrand0m> (and, as always, whenever things break, logs are appreciated :) +[22:25] <jrand0m> anyway, moving on to 2) docs +[22:26] <jrand0m> as posted in http://i2p.net/pipermail/i2p/2004-February/000147.html there've been some new overview docs +[22:27] <jrand0m> I'd appreciate some critiques to improve them, as they referred to pages are essentially going to turn into the main starting point for learning about I2P +[22:28] <madman2003> i read them and i hope you were right about the possibilty to safely reduce the amount of crypto +[22:29] <wilde> layers of crypto or # of bits? +[22:29] <jrand0m> I'm not convinced that the crypto is the bottleneck, but its a possibility +[22:30] <jrand0m> we couldnt safely reduce the layers, but we could use different levels of crypto at different layers, rather than reusing the same code for everything +[22:30] <madman2003> the problem is finding your way +[22:30] <jrand0m> hmm? +[22:31] <madman2003> a static path is usually well found +[22:31] <madman2003> a more dynamic one is more difficult to establish +[22:32] <madman2003> (i'm talking about the inability to properly handle routers going offline) +[22:32] <jrand0m> ah, thought you were talking about crypto +[22:32] <jrand0m> its going to be fairly easy to handle unreliable routers, its just the 0.3 code +[22:33] * jrand0m has ~30 pages of notes on different techniques, its all workable, just lots to do +[22:33] * protocol has quit IRC +[22:34] <madman2003> maybe an idea to have backup routes ready +[22:34] <madman2003> tunnel redundancy +[22:34] <jrand0m> right, thats 0.2.5 - multiple leases +[22:35] <jrand0m> (lease == declaration that a destination can be reached through a specific tunnel) +[22:35] <madman2003> i'll be awaiting that :) +[22:36] <jrand0m> w3rd +[22:37] <jrand0m> well, if anyone has any suggestions for improving the docs, feel free to hit the wiki, post to the list, or send me an email +[22:38] <jrand0m> ok, moving on at a rapid pace to 3) ??? +[22:38] <jrand0m> anything people want to bring up and discuss? +[22:39] <DrWoo> potatoes are fucking cheap yet potatoe chips are expensive, what's up with that? +[22:39] <DrWoo> :) +[22:39] <jrand0m> its a conspiracy! +[22:40] * DrWoo thinks jrand0m has the answer for most anything :) +[22:40] <jrand0m> of course, you can blame anything on conspiracies. +[22:40] <jrand0m> ok +[22:40] <wilde> Stego ? +[22:40] * human accepts suggestions about how to expose I2CP-like message-oriented functionality to non-java apps +[22:41] <wilde> how I2P will implement Stego so an ordinary portscan will reveal nothing +[22:41] <wilde> not even random bytes +[22:41] * human may (does?) sound repetitive... he's thinking about VPNs over I2P with http://openvpn.sf.net/ +[22:41] <jrand0m> well, for one, PHTTP. +[22:42] <jrand0m> openvpn does look very interesting - I hadn't realized tun/tap had windows ports +[22:42] <jrand0m> a simple message oriented socket bridge for I2CP should be very easy +[22:43] <wilde> Isn't freenet calling it Silent Bob, when the node shuts up it you don't give the secret knock (know the router ID) +[22:43] * madman2003 has quit IRC (12( www.nnscript.de 12:: NoNameScript 3.8 12:: www.XLhost.de 12)) +[22:43] <baffled> okay as usual I have another appointment in 15m so I'll catch up later. +[22:43] <jrand0m> right, if we wanted to integrate with a webserver/etc to silent bob, we could +[22:43] <jrand0m> cool, later baffled +[22:44] <jrand0m> (but silent bob doesnt prevent portscan detection, it just makes it look like another service) +[22:44] <wilde> I rather not have random people or ISP:s portscan me and find ports open +[22:44] <wilde> ok +[22:44] <human> jrand0m: ok, i'll work on it when I2P will work again on my PC :-) +[22:44] <jrand0m> UDP would work as well +[22:44] <jrand0m> :) human +[22:45] * kaji has joined #i2p +[22:46] <jrand0m> I hadn't realized reliability had gone down that bad, we'll go through sufficient iterations after 0.2.5 to get it back for you human +[22:46] <wilde> is there a way of hiding an open port from java program, without messing with the OS or firewall +[22:46] <human> w00t! +[22:47] <jrand0m> you mean to have a listening TCP socket that can't be portscanned? no, not directly from Java. +[22:47] <wilde> ok +[22:48] <jrand0m> (i dont even know how to do that in other langs) +[22:48] <jrand0m> udp would probably be the best way to go for that +[22:48] * human invites people to try to telnet human.i2p (tunneled TCP echo server) and type something in +[22:48] <wilde> that would be a little C program filtering and forwarding to another port maybe +[22:49] * kaji_ has joined #i2p +[22:49] <jrand0m> if it accepts TCP connections, its already too late, if I understand your concern correctly. +[22:49] <Janonymous> how do you telnet? +[22:49] <kaji_> finaly +[22:50] <kaji_> that took forever, iip usability sucks dick atm +[22:50] * kaji has quit IRC (Ping timeout) +[22:51] <duck> if you are concerned about open ports, you could use rTCP / PHTTP / whatever couldnt you? +[22:51] <Janonymous> damn... hey, jr, are those new docs accessable from the main i2p page? +[22:51] <human> Janonymous: java -jar lib/i2ptunnel.jar -nogui -e "config localhost 7654" -e "client 12221 human.i2p" +[22:51] <jrand0m> no Janonymous, just from the links on that email +[22:51] <human> Janonymous: then telnet localhost 12221 +[22:51] <jrand0m> duck> right +[22:52] <Janonymous> k +[22:52] <duck> (ofcourse whatever can be a silentbob/stealth/stego transport) +[22:52] <jrand0m> human> Message send failed after 61226ms with 391 bytes +[22:53] <human> jrand0m: and it means that...? +[22:53] <jrand0m> that means I cant reach your echo +[22:53] <duck> -nogui is depricated :) +[22:53] <jrand0m> can you reach duck.i2p? +[22:54] <wilde> scary, i googled for rtcp: http://dret.net/glossary/rtcp +[22:54] <jrand0m> right, rtcp is taken :/ +[22:54] <human> jrand0m: i'm trying, but i can't reach duck.i2p since a looong time ago... +[22:54] <jrand0m> wilde> http://wiki.invisiblenet.net/iip-wiki?RelayingTCP +[22:54] <wilde> "Wilde's WWW Online Glossary" +[22:55] <jrand0m> hehe oh yeah :) +[22:55] <jrand0m> human> thats a definite Bad Thing, as its up almost always - could you bounce me your log-*.txt? +[22:56] <human> Started on: Tue Feb 24 10:21:22 GMT 2004 +[22:56] <human> Version: Router: 0.2.4.2 / SDK: 0.2.4.2 +[22:56] <human> Bandwidth used: 56096295 bytes sent, 34308394 bytes received (avg 1.44KBps sent 0.88KBps received) +[22:56] <human> jrand0m: ok, logs coming on meshmx +[22:56] <jrand0m> gracias +[22:56] <jrand0m> ok, anyone have anything else to bring up? +[22:58] * jrand0m winds up +[22:58] * jrand0m *baf*s the meeting closed +\ No newline at end of file diff --git a/pages/meeting80.html b/pages/meeting80.html new file mode 100644 index 00000000..c7aedcec --- /dev/null +++ b/pages/meeting80.html @@ -0,0 +1,357 @@ +
+
+13:07 < jrandom> 0) hi +13:07 < jrandom> 1) Dev status +13:07 < jrandom> 2) Cascades +13:07 < duck> I'll stop +13:07 < jrandom> 3) Roadmap +13:07 < jrandom> 4) Website +13:07 < jrandom> 5) ??? +13:07 < jrandom> 0) hi +13:07 * jrandom waves to the first over-i2p i2p dev meeting :) +13:07 < ughabugha> nick is Janonymous. +13:08 < ughabugha> Ok. +13:08 < duck> hi +13:08 < jrandom> weekly status notes are posted to the mailing list (online at http://i2p.net/pipermail/i2p/2004-March/000155.html) +13:08 < ughabugha> hi. +13:08 < jrandom> as usual, we'll be following that as a guide +13:08 < nick> hello +13:09 < jrandom> jumping into 1) Dev status +13:09 * jrandom repeats mantra of "Progress is being made" +13:10 < jrandom> 0.2.5 has some Good Stuff, and we're finding long hidden bugs +13:10 < jrandom> latest one is db related, but thats not fixed up yet, so no need to track CVS HEAD +13:11 < jrandom> echo tests show pretty good results, but there's still issues to be worked out wrt irc and snark +13:12 < jrandom> how has eepsite retrieval been for people? +13:12 < jrandom> (and/or squid?) +13:12 < nick> here and there +13:12 < duck> generally okay with janonymous or ugha +13:13 < duck> sometimes janonymous goes down etc +13:13 < ughabugha> Yeah. +13:13 < duck> <mihi_backup> jrandom: you *really* know how to make me angry... +13:13 < jrandom> d'oh +13:13 < nick> I've been putting new content +13:13 < jrandom> whats up mihi? +13:13 < jrandom> nice nick +13:14 < jrandom> er janonymous +13:15 < nick> eh? +13:15 < nick> :) +13:15 < ughabugha> IIP <ughabugha> I started a two-way relay now. +13:15 < jrandom> ah cool +13:15 -!- nick [~Janonym@localhost] has quit [Client closed connection] +13:15 < jrandom> whats up mihi? +13:15 < ughabugha> IIP <ughabugha> Automatic. +13:16 < ughabugha> IIP <ughabugha> :) +13:16 < ughabugha> :) +13:16 < ughabugha> IIP <ughabugha> Oops, a bug. +13:16 < ughabugha> Oops, a bug. +13:16 < jrandom> heh is he still there or is there anything else wrt dev status? +13:17 < duck> lets go on +13:17 < jrandom> 'k +13:17 < jrandom> jumping to 2) Cascades +13:17 < ughabugha> IIP <ughabugha> * mihi_backup is now known as mihi_away +13:17 < ughabugha> * mihi_backup is now known as mihi_away +13:17 < ughabugha> IIP <ughabugha> Argh, relaying for my own text doesn't work. +13:17 < ughabugha> Argh, relaying for my own text doesn't work. +13:17 < jrandom> ;) +13:18 < ughabugha> IIP <ughabugha> No, wait. +13:18 < ughabugha> No, wait. +13:18 < madman> then don't speak :) +13:18 < jrandom> mix cascades are one of the two big styles of low latency mix nets, and while we don't use them in i2p, if some people think they're useful, they can tweak their router to get the same effect +13:19 < ughabugha> IIP <ughabugha> Test +13:19 < ughabugha> Test +13:19 < ughabugha> IIP <jrandom> mix cascades are one of the two big styles of low latency mix nets, and while we don't use them in i2p, if some people think they're useful, they can tweak their router to get the same effect +13:19 * jrandom senses an incoming recursive echo... +13:19 < ughabugha> IIP <ughabugha> Damn! +13:19 < ughabugha> Damn! +13:20 < jrandom> anyway, I think its always good to ask fundamental design questions, to poke at i2p and see why we do things the way we do +13:21 < jrandom> i've got the feeling we'll be hearing more about cascade-like systems in the future, so hopefully the description in the email will help explain i2p's relation to cascades +13:21 < ughabugha> Ok, it should work _now_. +13:21 < ughabugha> IIP <ughabugha> Say something. +13:21 < ughabugha> IIP <Janonymous> I move to not go after a mix net implementation within the current roadmap, and leave that for later +13:21 < ughabugha> Yeah, it works now. +13:21 -!- wilde [~anon@localhost] has joined #i2p +13:22 < jrandom> janymous> well, i2p /is/ a mixnet, just not a mix cascade +13:22 < madman> i'm going offline +13:22 < jrandom> 'k, ttyl madman +13:22 < jrandom> heya wilde +13:22 < madman> so bye +13:22 < ughabugha> IIP <wilde> finally +13:22 < ughabugha> IIP <wilde> hello meeting +13:22 < jrandom> but I concur, I don't think mix cascade functionality needs to be on the roadmap +13:23 < ughabugha> IIP <madman2003> bye everyone +13:24 < jrandom> ok, anything else on cascades, or should we move to 3) Roadmap? +13:26 < ughabugha> Hi, wilde@IIP +13:26 < ughabugha> Bye, madman@IIP +13:26 -!- madman [~a@localhost] has quit [( www.nnscript.de :: NoNameScript 3.8 :: www.XLhost.de )] +13:26 < ughabugha> IIP <Janonymous> Just seems like it could be implemented later, like a DHT might be. High Wilde +13:26 < ughabugha> IIP <Janonymous> bye Madman +--- Log closed Tue Mar 02 13:27:07 2004 +--- Log opened Tue Mar 02 13:27:52 2004 +13:27 -!- jrandom [~jrandom@localhost] has joined #i2p +13:27 -!- Irssi: #i2p: Total of 3 nicks [0 ops, 0 halfops, 0 voices, 3 normal] +13:27 -!- wilde [~anon@localhost] has joined #i2p +13:27 < jrandom> back +13:28 < ughabugha> Uhoh, jrandom quitted. +13:28 < ughabugha> IIP <Janonymous> bah +13:28 < jrandom> ok last I saw was 13:26:08 < ughabugha> IIP <Janonymous> bye Madman +13:28 -!- Irssi: Join to #i2p was synced in 36 secs +13:28 < jrandom> (irssi missed a ping so it dropped it) +13:29 < ughabugha> You missed IIP <Janonymous> Roadmap +13:29 < ughabugha> IIP <Janonymous> ah.. We all agreed to go onto the roadmap ;) +13:29 < jrandom> w3rd +13:29 < jrandom> ok, the roadmap change is likely why mihi hates me now +13:30 < ughabugha> Uh, then you missed alot more than that. +13:30 < ughabugha> Just a second. +13:30 < ughabugha> [23:23 39] <ughabugha> IIP <wilde> oh we have to camps now, the iip gang and the I2P hood +13:30 < ughabugha> [23:23 47] <ughabugha> IIP <wilde> two +13:30 < ughabugha> [23:23 50] <ughabugha> Hehe. +13:30 < ughabugha> [23:23 54] <ughabugha> IIP <Janonymous> :) got a relay going +13:30 < ughabugha> [23:24 22] <ughabugha> This is a temporary script I hacked together quickly. For future meetings we should think of something better. +13:30 < ughabugha> [23:24 44] <ughabugha> IIP <Janonymous> It works +13:30 < ughabugha> [23:25 18] <ughabugha> Ok, concentrate on I2P now, not the relay. +13:30 < ughabugha> [23:25 39] <ughabugha> IIP <Janonymous> So, mix cascades could feasably implemented quite well over i2p +13:30 < ughabugha> Sorry for the flood. +13:30 < duck> this is chaos +13:31 < ughabugha> IIP <Janonymous> but i think we can emphasize /over/ +13:31 < ughabugha> Ok, 3) Roadmap +13:31 < ughabugha> duck: Pretty much. +13:31 < jrandom> this aint nothing compared to meeting 67 ;) +13:31 < jrandom> ok, on to 3 +13:31 < jrandom> anyone have any thoughts wrt the roadmap? +13:32 < jrandom> the changes / views / concerns? +13:32 < ughabugha> IIP <Janonymous> Multi-tunneling +13:32 < jrandom> janonymous> we've already got that +13:32 < jrandom> (as of 0.2.5) +13:32 < jrandom> if I understand you correctly +13:33 < ughabugha> IIP <Janonymous> but, as in, sending one file over two tunnels to accelerate transmission? +13:33 < ughabugha> IIP <Janonymous> at the same time +13:34 < jrandom> i2p doesn't deal with files, but yes, each individual i2p message can now go down multiple tunnels +13:34 < ughabugha> IIP <Janonymous> I think that would be a great addition for the 2.0 area +13:34 < jrandom> e.g. first 32kb sent down tunnel X, next 32kb sent down tunnel Y +13:35 < ughabugha> IIP <Janonymous> right.. thats what I'm getting at.. that seems very necessary to me +13:35 < jrandom> but i2psnark with i2cp support would be able to maximize things +13:35 < jrandom> janonymous> we do that now +13:36 < ughabugha> IIP <Janonymous> oh. I2PSnark will utilize multiple tunnels for point to point communication? +13:36 < jrandom> all messages can go down multiple tunnels. +13:36 < duck> theoretically +13:37 < jrandom> not just theoretically - if a message takes > 15s, its sent down the other available lease +13:37 < jrandom> and if it takes > 30s, the leaseSet is dropped and refetched, with subsequent messages going down found leases +13:37 < jrandom> BUT +13:38 < jrandom> i2ptunnel (any anything else that uses i2p's mode=guaranteed) waits until each message is delivered before sending the next one +13:38 < jrandom> native i2cp apps don't need to do that +13:38 < jrandom> (nor will any apps that use the socket library, once the socket library is both implemented and supports SACK) +13:38 < ughabugha> IIP <Janonymous> ok.. I just think that will be a great method for these tunnels in the future.. for speed and anomymity +13:38 < ughabugha> IIP <Janonymous> and keeping strain off individual tunnels +13:39 < jrandom> agreed +13:39 < jrandom> ok, anything else on the roadmap? +13:40 < jrandom> (anyone going to bitch me out for dropping the socket lib? mihi? :) +13:41 < ughabugha> IIP <Janonymous> I used an analogy earlier today to describe multi-tunneling to someone.. and I said it was like adding lanes to a road +13:42 < jrandom> pretty much +13:42 < jrandom> (though one's on-ramp is always the same number of lanes ;) +13:42 < duck> if mihi is angry he can do the socket api cant he? +13:43 < jrandom> sure, and/or anyone else. the socket lib is Good +13:43 < jrandom> (but hard, and imho not functionally essential to the operation / security of the network) +13:44 < jrandom> i just wish i had the time to do it and keep moving on the core i2p code +13:44 < jrandom> but, c'est la vie +13:45 < ughabugha> IIP <Janonymous> looks like mihis not here +13:45 < ughabugha> Ok, i'm back now. +13:45 < jrandom> coo' +13:45 < jrandom> ok, moving on to 4) website +13:46 < ughabugha> IIP <Janonymous> big on ramp == cable / small on ramp == dialup ?? +13:46 < ughabugha> Hmm +13:46 < ughabugha> What was the socket library going to do? +13:46 -!- nick [~Janonym@localhost] has joined #i2p +13:46 < jrandom> right nanonymous +13:46 < jrandom> er, janonymous +13:46 < jrandom> (no matter what, i2p cant make your local net connection faster) +13:46 < jrandom> ughabugha: http://wiki.invisiblenet.net/iip-wiki?I2PSocketLibrary +13:47 < ughabugha> I mean a socket library for Java? Don't you already have one? +13:47 < jrandom> the socket lib factors out the TCP-esque code out of i2p, letting i2p specialize in IP-like messages +13:47 < nick> yup +13:47 -!- nick [~Janonym@localhost] has quit [Client closed connection] +13:48 < jrandom> ah, right, yes, but this would let applications stream data over i2p much more efficiently (if/when the socket library supports selective ACK, rather than requiring an ACK after each message like it does now) +13:49 < jrandom> i'm not comfortable with implementing SACK within the router, since it can safely go outside of it (into the socket lib) +13:49 < ughabugha> But why drop it? Does it really take that much work? +13:49 < jrandom> yes, to get right +13:49 < jrandom> there's some code thats part way implemented, but i dont have time to maintain and test it +13:49 < ughabugha> Ok. You're the man. +13:50 < jrandom> well, $devWhoImplements it is the man ;) +13:50 < jrandom> anyway, moving on to 4) website +13:50 < ughabugha> :) +13:51 < ughabugha> Any volunteers? +13:51 < ughabugha> IIP <Janonymous> research on implementations of anonymous p2p +13:51 * jrandom echoes ughabugha's question :) +13:51 < jrandom> hmm janonymous? +13:51 < ughabugha> Janonymous: This will be covered under 5) ??? +13:51 < jrandom> :) +13:52 < ughabugha> IIP <Janonymous> wll its content that goes on the site +13:52 < jrandom> ah, yeah, I agree +13:52 < jrandom> (see item 7 on http://i2p.net/pipermail/i2p/2004-February/000133.html) +13:53 < jrandom> and item 8 +13:53 < jrandom> or is that not what you mean? +13:53 < jrandom> I'll probably post up the truckload of papers i dug through last summer when researching and designing i2p +13:53 < jrandom> (or at least pointers to their citeseer entries) +13:54 < ughabugha> IIP <Janonymous> Ok. Were we going to discuss the next CMS for I2P? +13:54 < ughabugha> jrandom allready chose the CMS. +13:55 < jrandom> yes/no - rather than researching the pros and cons of CMSes for another month or two, we'll just go with drupal for now +13:55 < ughabugha> IIP <ughabugha> /topic #i2p +13:55 < ughabugha> IIP <Janonymous> Ok.. well, as far as what to put there.. We need a presentation +13:55 < jrandom> if we need to migrate to another one, wilde assures me its simple enough to export content +13:55 < jrandom> a presentation? +13:56 < ughabugha> IIP <Janonymous> with lots of illustrations and a step by step introduction to I2P +13:56 < jrandom> we do need the graphic design implemented +13:56 < jrandom> ah right +13:56 < jrandom> a user's intro +13:56 < jrandom> the wiki intro is generally a technie intro +13:56 < ughabugha> IIP <Janonymous> Almost like a multimedia presentation +13:56 < ughabugha> IIP <jrand0m> w0ah +13:56 < ughabugha> IIP <Janonymous> right +13:57 < ughabugha> IIP <ughabugha> Yay! +13:57 < jrandom> ok, i think we can get that together, but we'll probably want to wait on producing that content until we have both a Real installer, and a GUI control system +13:57 < ughabugha> IIP <Janonymous> In it, there should be more pictures, than words. :) +13:57 < jrandom> right +13:58 < ughabugha> IIP <Janonymous> righto +13:58 < jrandom> but we don't have a real installer yet, and (as much as i2pmgr and i2pmole are great) i think there's still work to be done on a control panel +13:58 < ughabugha> This is not the top priority right now. +13:58 < ughabugha> IIP <Janonymous> certainly not. but for those of us not programming... +13:59 < jrandom> right. so we need volunteers to work on 1) designing what content needs to be on the i2p website 2) designing the graphics / css / layout for the i2p website 3) people to work on creating content for the i2p website +14:00 < ughabugha> IIP <Janonymous> I've got a month to spare. Think it would be time well spent. +14:00 < jrandom> w00t :) +14:00 * jrandom marks Janonymous down as a volunteer... for content design & content creation? +14:00 < wilde> back +14:00 < ughabugha> Well, I could do HTML, CSS and the technical stuff, but I'm not much of a writer, nor a designer. +14:01 < jrandom> r0x0r +14:01 < ughabugha> IIP <Janonymous> right.. I'm not so good at the designing part yet +14:01 < ughabugha> IIP <Janonymous> I could try to write, but not without some good critique.. I've never writen editorial type things +14:01 < ughabugha> I can also use Photoshop and other tools as long as I'm given specific instructions on what to do. ;) +14:01 < wilde> I'll take care of drupal and features +14:02 < ughabugha> IIP <Janonymous> I've got some good ideas for you ughabugha +14:02 < jrandom> right, by content design i don't mean layout, but more "ok, we need a user intro page, a tech intro page, a faq" etc +14:02 < ughabugha> Heh, ok. :) +14:02 < jrandom> r0x0r0r +14:02 * jrandom marks down wilde and ughabugha as volunteers :) +14:02 < ughabugha> Looking forward to them. +14:02 < ughabugha> IIP <Janonymous> there's a shaby picture I made that can be found linked to the new I2POverview doc on I2p +14:03 < jrandom> word, yeah janonymous, that pic is pretty good, some minor tech issues with it, but quite useful +14:03 < ughabugha> IIP <Janonymous> It would look alot nicer in photoshop I'm sure +14:04 < ughabugha> Heh. +14:04 < ughabugha> Janonymous: Let's discuss that privately tomorrow. +14:04 < ughabugha> IIP <Janonymous> eh, actually I may have accidentally deleted it :/ +14:04 < jrandom> ok, anything else for the website, or can we move on to 5) ??? +14:04 < ughabugha> IIP <Janonymous> ok +14:07 < wilde> ok one thing: +14:07 < ughabugha> Anything else on website? +14:07 < wilde> what is the first feeling you should get on the site? +14:07 < wilde> keywords please +14:07 < jrandom> wilde> see http://i2p.net/pipermail/i2p/2004-February/000133.html (the "rom a branding perspective" paragraph :) +14:08 < jrandom> i do like the anonymous bit by bit thing +14:08 < ughabugha> I suppose not. Should we go on to 5) ??? ? +14:08 < ughabugha> IIP <Janonymous> should we make a more detailed user roadmap? +14:08 < ughabugha> IIP <Janonymous> one describing the long term goals in more detail +14:08 < ughabugha> wilde: Only positive emotions. +14:09 < jrandom> janonymous> agreed, the current roadmap is really just tech notes for tech tasks ;) +14:09 < jrandom> ok, 5) ?? +14:09 < jrandom> anything y'all want to bring up? +14:10 < wilde> itoopie isn't really in line with simple and secure +14:10 < wilde> it's more of a cartoon feeling +14:10 < wilde> that's why i asked +14:10 < ughabugha> IIP <Janonymous> yea, might want to build some more anticipation +14:10 < ughabugha> IIP <Janonymous> for the users to get involved +14:10 -!- kaji [~booky5@localhost] has joined #i2p +--- Log closed Tue Mar 02 14:11:08 2004 +--- Log opened Tue Mar 02 14:12:12 2004 +14:12 -!- jrandom_ [~jrandom@localhost] has joined #i2p +14:12 -!- Irssi: #i2p: Total of 6 nicks [0 ops, 0 halfops, 0 voices, 6 normal] +14:12 < jrandom_> back +14:12 < ughabugha> IIP <Janonymous> like, it should work for them without them even knowing its there +14:12 < jrandom_> wilde> I'm open to suggestions +14:12 < ughabugha> * jrandom_ (~jrandom@localhost) has joined #i2p +14:12 < jrandom_> <Janonymous> yea, might want to build some more anticipation +14:12 < jrandom_> hmm? +14:14 < ughabugha> You missed these: +14:14 < ughabugha> [00:11 43] <ughabugha> IIP <Janonymous> I'd just like to reemphasize.. I just think all multi-tunneling methods should be transparent and available to all client apps +14:14 < ughabugha> [00:12 07] <ughabugha> IIP <Janonymous> like, it should work for them without them even knowing its there +14:14 < jrandom_> janonymous> already implemented. +14:14 < jrandom_> i2p already transparently balances end to end communication over multiple tunnels +14:15 * jrandom_ kicks jrandom +14:15 -!- jrandom [~jrandom@localhost] has quit [Ping timeout] +14:15 -!- Irssi: Join to #i2p was synced in 231 secs +14:15 < wilde> participation? +14:15 < ughabugha> IIP <Janonymous> even if we profile the fastest most stable tunnels.. we can still use the other slow tunnels for extra throughput if we need it +14:15 < kaji> is iip up? +14:15 -!- kaji [~booky5@localhost] has quit [Client closed connection] +14:15 < ughabugha> IIP <Janonymous> And we may want to distribute the load anyway.. and that should all be transparent to the client apps +14:15 -!- You're now known as jrandom +14:16 -!- protocol [~iip@localhost] has joined #i2p +14:16 < ughabugha> IIP <Janonymous> ok +14:16 < ughabugha> IIP <Janonymous> cool +14:16 < jrandom> :) +14:17 < ughabugha> jrandom: Don't use ACTION, it's not relayed ;) +14:17 < jrandom> hah ok sorry +14:17 * jrandom says something they cant see +14:17 < jrandom> ;) +14:17 < jrandom> ok, anyone else have anything else? +14:18 < jrandom> i think after the current netDb bugs are fixed we may want to try the i2psnark tests again +14:20 -!- kaji [~booky5@localhost] has joined #i2p +14:20 -!- wilde [~anon@localhost] has quit [Ping timeout] +14:20 < ughabugha> But does the 15-second wait really distribute the load? +14:20 < ughabugha> That's not how I see it. +14:20 * protocol says iip is for lusers +14:20 < ughabugha> The way I see it, it should be 100% simultaneous, the node should put packets through the tunnel as fast as the destination can handle them. +14:20 < ughabugha> Through all the tunnels, I mean. +14:20 -!- nick [~Janonym@localhost] has joined #i2p +14:20 -!- kaji [~booky5@localhost] has quit [Client closed connection] +14:21 < jrandom> ughabugha: each message is ideally only sent over one tunnel, but each individual message is balanced over all of them +14:21 < ughabugha> IIP <Janonymous> me and duck ran a test over I2PSnark +14:21 < ughabugha> IIP <Janonymous> earlier today. +14:21 < jrandom> ughabugha: if we sent it over all tunnels always, that'd be a significant amount of wasted traffic +14:21 -!- nick [~Janonym@localhost] has quit [Client closed connection] +14:21 < ughabugha> IIP <Janonymous> Is everyone happy with the "I2P" name? +14:21 -!- kaji [~booky5@localhost] has joined #i2p +14:21 -!- wilde [~anon@localhost] has joined #i2p +14:22 < jrandom> janonymous> i2p is the name. +14:22 < jrandom> you can call it betty, but i2p is the name ;) +14:22 < ughabugha> kaji: Why are you blinking like this? +14:22 < jrandom> ughabugha: kaji likes messing with us +14:22 < ughabugha> jrandom: Yeah, I understand that. I guess it works just as I imagine it. +14:23 < kaji> i dont know +14:23 < kaji> is iip up? +14:23 < ughabugha> IIP <Janonymous> cool +14:23 < ughabugha> IIP <Janonymous> is for me +14:23 < ughabugha> It is for some people, and it's not for others. +14:23 < ughabugha> So I'm running a relay. +14:24 < jrandom> ughabugha++ +14:24 < ughabugha> To connect the networks. +14:24 < kaji> cool +14:24 < jrandom> the details of the parallel/serial sending is in net.invisiblenet.i2p.router.message.OutboundClientMessageJob +14:24 < ughabugha> :) +14:24 < jrandom> (for anyone who wants to know more details of how it works) +14:25 < jrandom> ok, anything else people want to bring up? +14:25 < kaji> so how is i2p dev? :) (Mirc sez 'lag=30 seconds') +14:25 < jrandom> kaji> we're making progress ;) +14:26 < jrandom> irssi here has bounced between 80s and 1s lag +14:26 < jrandom> (two disconnects in the last 90 minutes) +14:26 < ughabugha> IIP <Janonymous> is there any more ideas on content for the new site? +14:27 < ughabugha> IIP <kaji> sweet +14:27 < jrandom> beyond http://i2p.net/pipermail/i2p/2004-February/000133.html I think we'll want to go with one of drupal's forum modules +14:27 < ughabugha> No disconnects for me for 80 minutes. +14:27 < jrandom> nice ughabugha +14:27 < kaji> hmm now the lag is down to a few seconds +14:27 < jrandom> yeah, it varies kaji +14:28 < ughabugha> IIP <Janonymous> oh, me and ugha talked on my chat room over eep today :) +14:28 < jrandom> nice1! +14:28 < ughabugha> Janonymous: I wouldn't call that talking. ;) +14:28 < ughabugha> It was more like shouting over a distance of a few kilometers. +14:28 < jrandom> wait, y'all did voice? +14:29 < ughabugha> IIP <Janonymous> :) it was one message +14:29 < ughabugha> :) +14:29 < ughabugha> Well, I caused all the lag. +14:30 < ughabugha> Anyway, if somebody has a proposition for discussion, do it now, because I have to go. +14:30 < jrandom> word, 90m is a good meeting length to end at too... +14:30 < jrandom> anything else can be taken up on the mailing list +14:30 < jrandom> (and/or iip/i2p later) +14:31 * jrandom winds up the *baf*er... +14:31 * jrandom *baf*s the meeting closed +\ No newline at end of file diff --git a/pages/meeting81.html b/pages/meeting81.html new file mode 100644 index 00000000..f0774ffa --- /dev/null +++ b/pages/meeting81.html @@ -0,0 +1,404 @@ +
+
+13:12 < jrandom> agenda:
+13:12 < jrandom> 0) hi
+13:12 < jrandom> 1) administravia
+13:13 < jrandom> 2) 0.3 status
+13:13 < jrandom> 3) peer profiling / selection
+13:13 < jrandom> 4) web architecture
+13:13 < jrandom> 5) ???
+13:13 < jrandom> 0) hi
+13:13 * jrandom waves to the gang
+13:14 < deer> * jrandom_ waves from i2p
+13:14 < deer> * wilde hi5s
+13:15 < deer> <ughabugha> Hi!
+13:15 < deer> * duck is reading
+13:15 < deer> <human> yo!
+13:16 < jrandom> w0rd, sorry for the delay getting those status notes up at (http://i2p.net/pipermail/i2p/2004-March/000165.html)
+13:18 < jrandom> 1) administravia
+13:19 < jrandom> for simplicity, and to avoid the trouble we had last week w/ the various networks being bitchy, some magic has been worked out and this meeting is being run off three irc networks
+13:19 < deer> <duck> (amazing!)
+13:19 < jrandom> iip's #i2p, the duck/baffled i2p irc network's #i2p, and freenode's #i2p
+13:19 < jrandom> :)
+13:19 < deer> <baffled> who's paranoid?
+13:20 < deer> <ughabugha> Ok, done reading the status notes.
+13:20 < deer> <ughabugha> jrandom: What about it?
+13:20 < deer> <ughabugha> Or them?
+13:21 < jrandom> just mentioning it, so people who have trouble with one can use another
+13:21 < deer> <mihi> fine. done with status notes as well
+13:21 < jrandom> also, the drupal box should be back online this weekend (crossing fingers)
+13:22 < deer> <ughabugha> Oh, ok. Is there anything to discuss on 1)?
+13:22 < deer> <ughabugha> Or are we waiting for people to finish reading?
+13:22 < deer> <ughabugha> jrandom: Good. :)
+13:22 < jrandom> nope, unless anyone has any administravia they'd like to bring up?
+13:23 < deer> * mihi wants to set a flag at point 3
+13:23 < jrandom> flag set ;)
+13:23 < deer> * duck at point 2
+13:23 < deer> <duck> err, what index do we use?
+13:24 * jrandom supposes we can move on to agenda item 2) 0.3 status
+13:25 < jrandom> i ended up typing a lot more than usual for the 0.3 status notes, so rather than repeat them here, does anyone have any questions / concerns they'd like to bring up?
+13:25 < deer> <ughabugha> Go on.
+13:26 < deer> <duck> why do the ElGamal/AES+SessionTag decryptions fail too often?
+13:26 < jrandom> duck> due to overload and lag. if a garlic routed message is delayed beyond that sessionTag's lifetime, the decryption will fail
+13:27 < deer> <duck> k
+13:27 < jrandom> in addition, if the garlic routed message is decrypted fine, but the content was delayed so much that the cloves expire, its a wasted decryption, as well
+13:28 < deer> <duck> somehow that sentence made me believe that there was a cause besided the overload/lag
+13:28 < deer> <tro|l> ce zi e azi?
+13:28 < jrandom> well, there have been some troubles with source routed reply blocks failing decryption, though since they're going away in 0.3.1, its not really worth debugging them too much
+13:29 < deer> <kaji> wow it works!
+13:29 < jrandom> (and a failed ElG is probably the most CPU intensive thing i2p does)
+13:30 < deer> <jrandom_> heh welcome to i2p #i2p :)
+13:30 < deer> * kaji praises 0.2.5.1
+13:30 < deer> <jrandom_> 0.2.5.1? sheeit, get thee 0.2.5.4 :)
+13:30 < jrandom> ok, anything else for 0.3 status?
+13:31 < deer> <kaji> ..
+13:31 < deer> <duck> .
+13:31 < deer> <kaji> ping?
+13:31 < jrandom> p0ng
+13:31 < mihi> pung
+13:31 < deer> <mihi_backup> pung2
+13:32 < deer> <Pellinore> prawn
+13:32 < jrandom> ok, moving on to 3) peer profiling / selection
+13:32 * mihi moves the flag to the other number 3 ;)
+13:32 < jrandom> (man, its kind of funny that there isn't any vegetarian seafood substitutes...)
+13:32 < deer> * kaji praises 0.2.5.4.1
+13:32 < deer> <duck> the whole peer profiling thing looks at magic, how do you plan to debug that?
+13:32 < deer> <Pellinore> There is vegetarian crabmeat.
+13:32 < jrandom> ah, true pellinore.
+13:32 < deer> <wilde> jrandom: and veg sushi
+13:33 < jrandom> duck> what part of it looks like magic?
+13:33 < deer> <duck> the whole classification etc
+13:33 < deer> <Pellinore> And I could have sworn that I had seen some chik-type fish fillet substitute, but I could be wrong.
+13:33 < deer> <duck> I mean, how do you know that you are doing optimal things?
+13:33 < jrandom> the peer organizer (which moves profiles into the different groups) is a very simple and seperable component
+13:33 < jrandom> oh, thats a good point.
+13:34 < jrandom> i was doing some benchmarking the other day, running the organizer with 10,000 profiles, and it was organizing them all un ~50ms
+13:34 < jrandom> (organizing == runningthe calculators and moving them between groups)
+13:34 < jrandom> profiles also consume only ~3-4KB for a full profile, and a minimal profile takes ~200 bytes
+13:35 < deer> <duck> yeah, but how do you know that you are right with '0.597s reply' for group 1
+13:35 < deer> <duck> and that it shouldnt be 0.603s
+13:35 < jrandom> (so we'll keep a full profile of the best 1000 peers, and minimal of the next 10,000)
+13:35 < jrandom> ah, ok, good question.
+13:36 < jrandom> thats the Rate component
+13:36 < jrandom> there will obviously be some flutter, and we won't be very exact. the goal ois to get ballpark and organize them accordingly
+13:37 < deer> <duck> I did see it using averages
+13:37 < jrandom> e.g. find the routers on T3s with quad procs, and keep them seperate from routers on 386s with 2400 bps modems
+13:37 < deer> <duck> so if you throw in 100 shitty nodes, you heavily influence the average
+13:37 < jrandom> agreed - there are two different aspects of that that we can tune
+13:38 < jrandom> first, we can make the threshold use the top 10% to determine the "fast" vs "not fast"
+13:38 < jrandom> (or top 90%, whichever)
+13:38 < jrandom> second, we can adjust the Rate component to keep various statistics - rather than a simple average, it can ignore skew, find stddev, etc
+13:39 < jrandom> the rate component currently is quite remedial, and I'd love if someone good with stats could take a look at it and fix it up
+13:39 < jrandom> (one of the key goals of it however is to keep it scale free - so if we get 100,000 events, it doesnt have to keep all those data points in memory, etc)
+13:40 < deer> <duck> ok, so what prevents another NGRouting disaster from happening?
+13:40 < jrandom> but you're absolutely right - the calculators and the peer selection algorithms are going to be a major focus of future network improvements
+13:40 < jrandom> ngrouting tried to do two different things - find particular data, and find available peers.
+13:40 < jrandom> we only need to find available peers
+13:41 < deer> <duck> good
+13:41 < jrandom> (and place our tunnels there)
+13:41 < deer> * duck removes breakpoint
+13:41 < jrandom> :)
+13:41 < mihi> but we have to find tunnels as well.
+13:41 < jrandom> right mihi - the netDb is an important point
+13:42 < deer> <Pellinore> I'm good with the math of statistics, but terrible with the tech aspects of translating the data into computer-useful data.
+13:42 < deer> <Pellinore> But I would happily partner up with someone and contribute if I can.
+13:42 < jrandom> awesome pellinore!
+13:43 < jrandom> the main rate class is up at http://i2p.net/cgi-bin/cvsweb.cgi/i2p/code/core/java/src/net/invisiblenet/i2p/stat/Rate.java?rev=1.3&content-type=text/x-cvsweb-markup and we can talk later to discuss it :)
+13:43 < deer> <Pellinore> k
+13:43 < jrandom> (i know, i don't expect you to read the code, just mentioning it)
+13:44 < deer> <Pellinore> I'll read it, but it will be about like my dog reading Kierkegaard.
+13:44 < jrandom> hehe
+13:45 < deer> <Pellinore> But I am learning.
+13:45 < deer> <Pellinore> Anyway, please proceed -- I don't mean to bog things down.
+13:45 < jrandom> (volunteering to help isn't bogging things down ;)
+13:46 < jrandom> one point i forgot to mention about the peer profiling / selection code is that the 'integration' rank is only used in the network database for 'exploration', not for search/store
+13:46 < jrandom> we still do (fairly) traditional kademlia search/store with all non-failing peers
+13:46 < jrandom> also, within each peer group, we always choose *randomly*
+13:46 < jrandom> (aka we don't always choose the fastest of the fast group, etc)
+13:47 < jrandom> thats for both security and load balancing reasons
+13:48 < jrandom> (security, so that an attacker can't just create a really fast router and watch everyone make use of them - they have to create a large number of really fast routers, skew the entire distribution in their favor, etc)
+13:49 < jrandom> ok, do we have anything else for 3) peer profiling / selection?
+13:49 < deer> <duck> .
+13:50 < deer> <ughabugha> Doesn't look like it.
+13:50 < jrandom> ok, moving on to 4) web architecture
+13:52 < jrandom> mihi's new streaming lib gives us a lot of flexibility, plus he's mentioned a few times the desire to factor out the httpclient code into something more robust. in addition, human has started updating things to allow transparent squid(or tor-www) proxying and eepsite proxying within the same client
+13:52 < jrandom> given all of these different factors, and the likelyhood that web like functionality will be important for i2p's user base, i think we should take a step back and try to envision how it should all fit together
+13:53 * mihi has some code flying around on my hd for that httptunnel code. but it's far from being finished
+13:53 < mihi> for me httptunnel == httpclient + some filters
+13:53 < mihi> of course using my naming and streaming api.
+13:54 < mihi> the code atm only allows different "anonymity profiles".
+13:54 < jrandom> any thoughts on human's style of failing over to outproxies like squid/etc?
+13:54 < mihi> i.e. send all requests over one destination, mux them up to 10, mux them up to one dest per hostname, etc.
+13:54 < jrandom> ah, interesting
+13:55 < mihi> but these dests are not used yet ;)
+13:55 < jrandom> w3rd. yeah, there *is* the big caveat that having lots of destinations on one router does increase CPU load nontrivially
+13:55 < jrandom> (since any garlic fail will need to fail once per dest before failing completely)
+13:56 < jrandom> there is some magic left that can be used to minimize that though, i think
+13:56 < deer> <ughabugha> Are you sure the transparent squid proxying is a good idea in the performance point of view? I mean, people might get too lazy and not take their eepproxy off after browsing I2P sites or using I2P squid, therefore wasting I2P bandwidth for things that don't require anonymity.
+13:56 < jrandom> ughabugha> all things require anonymity :)
+13:57 < jrandom> (and if they can't tell the difference, well, sheeit...)
+13:57 < mihi> my intention for httptunnel is that http links will be rewritten (similarly to fproxy) so that you don't need a proxy but only a servlet.
+13:57 < deer> <ughabugha> jrandom: Heh. That way, I2P was born dead. There isn't going to be enough available bandwidth on the network, that all the endnodes would likely consume.
+13:58 < mihi> on that info page one might add a feature to browse the site throufh e.g. squid.
+13:58 < jrandom> not quite sure i follow. i do understand and agree with the DNS issues involved (though i think we can get around them a few ways)
+13:58 < jrandom> ah, ok mihi
+13:58 < deer> <aum> morning all
+13:58 < jrandom> mihi> so like a much much more advanced "Unable to reach peer" page?
+13:59 < mihi> more like a "anonymity warning" page like in freenet ;)
+13:59 < jrandom> ughabugha> if we cant handle web browsing, how are we going to handle BT/filesharing?
+13:59 < jrandom> hmm mihi, but do we want that, for people who want to browse the web anonymously? or would httpclient not be the app they'd use?
+14:00 < jrandom> 'mornin aum, just in time for the dev meeting :)
+14:00 < mihi> jrandom: if someone just wants to browse the web anonymously, he
+14:00 < deer> <ughabugha> jrandom: Hmm... Good point. Are we going to at all? ;)
+14:00 < deer> <aum> jrandom: you're not on iip, you're not on irc.duck.i2p ?!?
+14:00 < jrandom> ughabugha> we must.
+14:01 < mihi> might configure httptunnel to so so (httptunnel will still work as a proxy, so it's quite trivial to add that)
+14:01 < mihi> and most likely someone browsing the web "anonymously" will like some content filters, i guess ;)
+14:01 < jrandom> mihi> i think human already did :)
+14:01 < jrandom> agreed mihih
+14:01 < jrandom> /hih/hi/
+14:02 < mihi> when i say httptunnel, i don't mean httpclient ;)
+14:02 < jrandom> ah ok
+14:02 < deer> <jrandom_> i'm here aum ;)
+14:02 < mihi> but we *really* should move i2ptunnel to use the streaming api ASAP, which will reduce the number of files we must maintain
+14:03 < jrandom> agreed
+14:03 < mihi> human only patched the old version, i patched the new version myself
+14:03 < jrandom> we ran into some bugs this afternoon, not sure if human bounced you logs yet
+14:03 < deer> <wilde> another thing for the list: outproxy was taken, but more like i2p2i
+14:04 < mihi> i did not get logs yet from anyone...
+14:04 < jrandom> mihi> we'll get on to the streaming code asap, we can talk about it after the meeting if you've got a moment, or over email?
+14:04 < deer> * aum spent part of yesterday looking at p2p apps with a view to running them on i2p
+14:04 < jrandom> wilde> hmm?
+14:04 < jrandom> wikked aum, anything promising?
+14:04 < deer> * aum is presently inclined to favour 'push'-type filesharing, eg konspire2b
+14:05 < jrandom> i2psnark could be modified to use the new i2ptunnel streaming api fairly easily too
+14:05 < deer> <human> mihi: sending the logs (mihi@i2p.net, right?)
+14:06 < mihi> dunno if mihi made a redirect for me
+14:06 < deer> <mihi> s/mihi/jrandom
+14:06 < jrandom> hmm aum, do you think that freenet/insert model really would work most effectively?
+14:06 < deer> <wilde> jrandom: i was thinking of using a i2p webserver -> proxy -> internet, so people can browse a i2p site, but maybe an ordinary tunnel can manage the traffic
+14:06 < jrandom> mihi> want me to set that to for ward to you?
+14:06 < mihi> jrandom: nothing against it ;)
+14:07 < deer> <ughabugha> aum: 'Push'-type? What's that?
+14:07 < deer> <aum> what i like about konspire2b is it takes away the expectation for instant/prompt delivery, and reduces bandwidth requirement, by only broadcasting content announcements, then letting people 'subscribe' to 'content feeds'
+14:07 < jrandom> mihi> done.
+14:08 < deer> <aum> so instead of requesting a file, sitting and twiddling your thumbs, getting pissed off waiting for it to come in, you just 'subscribe' to the source's 'channel', then get on with other stuff
+14:08 < deer> <aum> konspire2b.sf.net
+14:08 < jrandom> aum> but isn't that incredibly innefficient, since you've got to manage an overlay network (broadcast) for list of things available, then you've got to relay them?
+14:09 < jrandom> wouldn't a direct swarming system be much more useful / efficient?
+14:09 < deer> <ughabugha> Heh. That sounds promising for I2P.
+14:09 < deer> <aum> jrandom: any examples of direct swarming?
+14:09 < jrandom> wilde> oh, so like the cgiproxy on duck and janonymous's site?
+14:09 < jrandom> aum> bittorrent
+14:10 < deer> <ughabugha> aum: Did you mean http://konspire.sourceforge.net/?
+14:10 < jrandom> where you get the torrent somewhere, and get content blocks directly from peers who have it
+14:10 < deer> <aum> ughabugha: guess so :)
+14:10 < mihi> argl... $me->brother removed the port forward for i2p...
+14:10 < jrandom> d'oh
+14:10 < deer> <aum> jrandom: is anyone currently trying bt/i2p?
+14:11 < deer> <baffled> aum, have you had a close look at mnet?
+14:11 < jrandom> aum> eco made some headway with i2psnark
+14:11 < deer> <aum> i've had a look, but not a close look
+14:11 < jrandom> (though he's mia at the moment)
+14:12 < jrandom> hmm, mnet with eepsite metatrackers and human's i2p/twisted transport might work
+14:12 < deer> <duck> heavy testing by janonymous and me seem to show that the current i2psnark problems are 50% caused by i2p and 50% by snark
+14:12 < jrandom> duck> how recently were those tests?
+14:12 < deer> <duck> last week
+14:12 < jrandom> though i've got no qualms with potentially exploring other bt implementations
+14:12 < jrandom> ah ok
+14:13 < deer> <duck> about mnet, I _think_ that you'd first to fix mnet itself before you could make that working
+14:13 < deer> <duck> so you might as wel fix freenet and use that
+14:13 < jrandom> heh
+14:13 < deer> <aum> fix freenet, ok! right after we bring in world peace ;p
+14:13 < deer> <duck> but ask in #mnet @ freenode
+14:13 < deer> <Pellinore> mnet=?
+14:13 < deer> <Pellinore> Mute?
+14:14 < jrandom> in that sense, perhaps an azureus mod for i2p might work?
+14:14 < deer> <wilde> no, a market based p2p approach
+14:14 < jrandom> pellinore - mnet.sf.net, a distributed data store without anonymity
+14:14 < deer> <baffled> Actually, I'm using mnet quite reliably on about five machines.
+14:14 < jrandom> right, the mojonation followon
+14:14 < deer> <baffled> I can't use freenet reliably on one machine.
+14:14 < deer> <duck> baffled: 0.6 or 0.7?
+14:14 < deer> <duck> (0.7 is with twisted iirc)
+14:16 < deer> <Pellinore> jrandom -- thanks.
+14:16 < deer> <Pellinore> You can't use Freenet reliably on any machine.
+14:17 < deer> <baffled> 0.6.[23].
+14:17 < deer> <Pellinore> That is, among other reasons, why we are here. :)
+14:17 < deer> <aum> i find that entropy works well... eventually!
+14:17 < jrandom> i don't know, i still think freenet might be a good base to work from for the i2p DHT (when we can cut out most of the code and keep the data store / SSK/CHK stuff)
+14:18 < jrandom> for file sharing, we should learn from the filesharing crowd what works best
+14:18 < deer> <aum> but since my linuxworld article on entropy, there's gazillions of entropy nodes now, and the net has taken on some freenet performance characteristics
+14:18 < deer> <Pellinore> I like the basic layout and features of Freenet, it's just that the fucker doesn't work, especially if one is using a dialup connection.
+14:18 < jrandom> e.g. DC clones, BT, [or what else do those crazy filesharing people use?]
+14:19 < jrandom> heh aum, damn you ;)
+14:19 < deer> <duck> plus there are the things that Newsbyte did identify about entropy...
+14:19 < deer> <aum> it's weaker anonymity, for example?
+14:19 < deer> <baffled> Right but there are instability issues with 0.7.
+14:19 < deer> <baffled> I think this connection has gotten flakey again.
+14:19 < jrandom> and security issues. i think we can unfortunately pass on using entropy
+14:21 < jrandom> but, erm, we're on discussion point 4, *web* architecture so for the moment lets jump back to that ;)
+14:21 < deer> <aum> another mad-assed file-sharing idea - what about using nntp, with n people running linked nntpds, and just use one of those libs that breaks down files into b64 chunks and posts them, and libs to retrieve them?
+14:22 < jrandom> NNTP would be really interesting - its reliable as fuck and time tested
+14:22 < deer> <duck> linking the servers?
+14:22 * jrandom would love to have an innd running with i2p ;)
+14:23 < deer> <aum> and since i2p does the anonymity, there's no need for nntp to have it
+14:23 < jrandom> right, the innd feed line could point at a local i2ptunnel proxy
+14:23 < deer> <aum> and people with different servers can config the servers to cache their own choice of groups
+14:23 < mihi> depending on how often they peer it would be possible to censor articles by creating message id collisions
+14:23 < deer> <duck> (ever tried configuring innd?)
+14:24 < jrandom> many times duck, but a loooong time ago
+14:24 < deer> <aum> is innd hard to setup?
+14:24 < deer> <duck> oh well, you are god
+14:24 < jrandom> mihi> agreed - thats not a censorship proof distribution medium
+14:24 < jrandom> aum> its a bitch
+14:25 < jrandom> just like squid - its good at what it does, but we likely need something dirt simple (one click, hopefully) to bundle
+14:25 * jrandom drags us back on topic
+14:26 < deer> <aum> and yet another p2p/filesharing approach - i seem to recall seeing a p2p app that works via http, chaining http servers
+14:26 * mihi guesses most users don't know how to set up a proxy in their brwoser...
+14:26 < deer> <aum> sorry, what's the topic?
+14:26 < jrandom> agenda item 4) web architecture ;)
+14:26 < aum> as in, web servers within i2p?
+14:26 < mihi> aum: yep
+14:26 < jrandom> thats a good point mihi - a web system will want the basics (.bat, .sh scripts) for startup/shutdown
+14:27 < jrandom> hmm, doesn't mozilla include a javascript url you can do to set the proxy?
+14:27 < jrandom> e.g. could we have a config page on httptunnel to click "on"/"off"?
+14:28 < jrandom> i realize we're not going to come to any decisions today about how the web functionality should work, but we should get some directions down
+14:28 < aum> what's the problem with the current eepproxy setup?
+14:29 < jrandom> e.g. filtering, inbound proxies (eeproxies), outbound servers (normal i2ptunnel server), outbound proxies (outproxies ala squid or tor-www)
+14:29 < mihi> aum: it requires quite some skill both to provide and to request eepsites
+14:29 < jrandom> also, the existing outproxy system sucks.
+14:29 < jrandom> its wholely unscalable
+14:29 < jrandom> we need something to allow/force distributing the outbound web request load across multiple outproxies
+14:30 < mihi> how can users get these outproxies. config file (like in hosts.txt?)
+14:30 < jrandom> and one reason why normal people would want to run outproxies is for plausible deniability - even if THEY are requesting "bad stuff", they can say "i2p did it"
+14:31 < jrandom> thats one option mihhi
+14:31 < mihi> jrandom: hehe
+14:31 < jrandom> s/hh/h/
+14:31 < aum> but doesn't eepproxy make 'direct' http connection to the requested server, ie as 'direct' as i2p connections are?
+14:31 < deer> <wilde> . /castvote DHT ala Freenet
+14:31 < mihi> aum: the problem are "normal" web urls.
+14:31 < jrandom> ./castvote 3 developers x 1 month x 12h / day
+14:32 < deer> * human added httptunnel support to the TunnelManager, btw
+14:32 < deer> <human> s/httptunnel/httpclient/
+14:32 < deer> <aum> what's that?
+14:32 < deer> <aum> oh, http client support?
+14:32 < deer> <human> aum: yes
+14:32 < jrandom> right, we need to find a way to let people browse slashdot.org via i2p
+14:32 < deer> <aum> so tunnelmgr now talks http?
+14:32 < jrandom> nice1 human!
+14:32 < jrandom> aum> remember the squid proxy?
+14:33 < deer> <aum> yep
+14:33 < deer> <wilde> jrandom: so 4 man-months roughly for a DHT?
+14:33 < deer> <human> aum: yup: openhttpclient <port> [<outbound WWW proxy>]
+14:33 < jrandom> wilde> i think thats reasonable, yes.
+14:34 < deer> <aum> human: have you written it up anywhere?
+14:35 < jrandom> aum> all it does is say "if !eepsite { send through $outboundWWWproxy } else {send to eepsite}"
+14:35 < deer> <human> aum: i was going to commit, then i got stuck with a StreamingI2PTunnelServer bug...
+14:36 < jrandom> a good short term solution would be a "outproxies.txt", ala hosts.txt
+14:36 < deer> <aum> human: and what exactly does 'openhttpclient <port> [<outbound WWW proxy>]' do?
+14:36 < jrandom> though we should start thinking about medium and long term solutions
+14:37 < deer> <human> human: will open a proxy listening for connections, that will redirect to WWW-proxy all the stuff that goes to URLS not ending with .i2p
+14:38 < deer> <Pellinore> Now that's interesting.
+14:38 < deer> <aum> human: ahh, nice, so you split off a thread within tunnelmgr?
+14:38 < deer> <human> human: i.e. you can use it to browse both eepsite and the normal web
+14:38 < deer> <human> human: yes
+14:38 < deer> <human> s/human/aum/ :-)
+14:39 < deer> <aum> slightly outside the 'brief' of tunnelmgr, but hey, there's no other place more appropriate in the i2p code - good job d00d
+14:39 < deer> <aum> human: so you talk python *and* java? is that damaging your brain?
+14:39 < deer> <human> aum: i did it to avoid launching yet another JVM for the EepProxy
+14:40 < jrandom> (well, the code is implement in i2ptunnel's httpclient, human just recently exposed it through tunnelmanager as well)
+14:40 < deer> <aum> yes, always good to keep the jvm instances down to a minimum
+14:40 < jrandom> ((and imho httpclient is exactly where it should go ;)
+14:40 < jrandom> (((until mihi's NextGen httpclient [httptunnel] is out)))
+14:41 < deer> <aum> is httpclient in cvs, such that it'll build for me as part of i2p update/build?
+14:41 < jrandom> yes, eepProxy uses httpclient
+14:42 < deer> <aum> *man this is so schizophrenic - i've got 3 xchat sessions open (irc.duck.i2p,iip,freenode))
+14:42 < jrandom> :)
+14:42 < deer> <aum> wicked latency on irc.duck.i2p
+14:42 < jrandom> ok, so no closure on the web architecture today, obviously, but worthwhile discussion
+14:43 < jrandom> yeah aum, 15s or so for me
+14:43 < jrandom> anything else on the web architecture for now, or should we move on to the 5) ??? open discussion section?
+14:43 < deer> * human is thinking about an I2PSocksTunnel
+14:44 < jrandom> yikes, now that'd be cool
+14:44 < deer> <human> (well, maybe it belongs to 5)
+14:44 < deer> <aum> socks? is there a way to 'shim' non-socks-enabled clients through to a socks interface?
+14:44 < deer> <human> aum: apt-get install tsocks :-)
+14:45 < aum> web discussion - one last thing - what about possibly forking /patching an existing web client
+14:45 < mihi> aum: sockscap for windwos
+14:45 < jrandom> aum> scary. very powerful, but scary.
+14:45 < jrandom> [i'd hate to have to maintain that]
+14:45 < aum> even for now, a brain-dead browser like dillo
+14:46 < jrandom> [[though it could be made 'uber secure', etc. but still, very, very scary]]
+14:46 < aum> or better, the browser control in wxwindows, it's multiplatform
+14:46 * jrandom reminices about the orignial flinks, when it had a built in freesite browser
+14:47 < aum> but then again, n00bs will whinge if they can't surf their usual m$-specific-javascript-infested sites
+14:47 < jrandom> right aum, and so will hackers if it doesnt support the latest standards compliant code
+14:47 < aum> hey, we should ask Microsoft for the source to IE6, then patch it ;p
+14:47 < jrandom> building a browser == good way to waste thousands of man-hours
+14:47 < jrandom> heh
+14:47 < deer> * human is quite happy using privoxy
+14:48 < aum> maybe they might toos in ie6 source as part of the European punitive settlement
+14:48 < deer> <human> (http://www.privoxy.org/)
+14:48 < aum> s/toos/toss/
+14:48 < jrandom> human> how would that fly for both sides of the proxy?
+14:48 < jrandom> e.g. we'll want the content filtered locally, not at the outbound endpoint
+14:49 < deer> <human> jrandom: users could be encouraged to install it
+14:49 < jrandom> (but the outbound endpoint will want to filter some content to avoid abuse, etc)
+14:49 < deer> <human> jrandom: or it may be part of the default I2P installation
+14:49 < aum> what if a DWP (distrib web proxy) was using a DHT for its cache?
+14:49 < jrandom> encourage == only geeks. bundle :)
+14:49 < jrandom> that'd be Good aum
+14:49 < deer> <human> jrandom: eheheh, agreed :-)
+14:49 < deer> <human> jrandom: privoxy also runs on windogs, btw
+14:50 < jrandom> word. yeah, we need some sort of content filtering - privoxy, muffin, whatever.
+14:50 < deer> <wilde> long meeting...
+14:50 * jrandom takes the hint..
+14:51 < deer> <Pellinore> wilde: Much to be said.
+14:51 < jrandom> anyone else have anything they want to bring up? we always have the mailing list for further things
+14:51 < deer> <Pellinore> And much to be done of course.
+14:51 < deer> <Pellinore> I have a couple of small questions.
+14:51 < aum> could we fork privoxy and 1) make it work over i2p, 2) make it use DHT for caching?
+14:51 < deer> <Pellinore> But they are as easily taken up privately.
+14:51 < jrandom> pellinore> whats up?
+14:51 < deer> <Pellinore> Nada, sorry I said anything.
+14:51 < jrandom> aum> most likely we wouldnt need to fork
+14:52 < deer> <Pellinore> I'll talk to you about it privately, or duck, at another time.
+14:52 < deer> <Pellinore> Not really dev-specific stuff.
+14:52 < deer> <duck> 10+16+7=33 manhours wasted on this one-hour overtime :)
+14:52 < jrandom> but building a DHT is a lot of effort. wholely incredibly worthwhile
+14:52 -!- Irssi: #i2p: Total of 10 nicks [0 ops, 0 halfops, 0 voices, 10 normal]
+14:52 * aum goes again to visit infoanarchy.org wiki pages on DHTs
+14:52 < jrandom> there are 16 people on iip?
+14:53 < deer> <human> aum: no need to fork, just: web browser <-> privoxy <-> httpclient <-> i2p <-> outbound proxy <-> www.pr0n.com
+14:53 < deer> <wilde> a generic DHT that would work outside I2P too, and that allows other binding than http
+14:53 < jrandom> aum> check out the link duck added to the i2p wiki, listing various ones
+14:54 < deer> <human> aum: you can configure privoxy to make it connect to another HTTP/socks proxy (that's how my I2P-to-tor privoxy works)
+14:54 < deer> <duck> (http://www.bamboo-dht.org/)
+14:54 < aum> not sure i like the idea of a dht working outside i2p - the best dht is one without anonymity (and the anonymity overhead) that can work most optimally within i2p
+14:54 < jrandom> hrm duck, what happened to that list of 'em?
+14:54 < deer> <duck> aum: easier to test
+14:55 < deer> <duck> jrandom: some commie did remove it I guess
+14:55 < jrandom> heh
+14:56 < jrandom> google++ : http://www.etse.urv.es/~cpairot/dhts.html
+14:56 < jrandom> (not the same page, but interesting)
+14:56 < jrandom> oh, here's the page - http://himalia.it.jyu.fi/ffdoc/storm/pegboard/available_overlays--hemppah/peg.gen.html
+14:57 < jrandom> but yes, a DHT that doesnt try to implement anonymity, plus a DHT that supports both CHK-style and SSK style content would be best
+14:58 < jrandom> (SSK style not being strictly necessary, but damn it would be really useful)
+14:58 < jrandom> but, anyway
+14:58 < jrandom> anyone got anything else they want to bring up?
+14:59 < deer> <duck> tomorrow is St. Patrick's Day
+14:59 < deer> <wilde> topic 5) ?
+14:59 < deer> <duck> so all drink irish beer
+14:59 < jrandom> good point
+14:59 < deer> <Pellinore> TOmorrow is both the anniversary of my current relationship, and of my second marriage.
+14:59 * jrandom takes note to avoid irish pubs tomorrow
+15:00 < jrandom> oh, congrats pellinore :)
+15:00 < jrandom> wilde> we're on 5) ???
+15:01 < jrandom> (and about to be on 6) [baf])
+15:01 * jrandom will be coming to iip momentarily [if i can]
+15:01 * jrandom winds up
+15:01 * jrandom *baf*s the meeting closed
+
\ No newline at end of file
diff --git a/pages/meeting82.html b/pages/meeting82.html
new file mode 100644
index 00000000..9e7935aa
--- /dev/null
+++ b/pages/meeting82.html
@@ -0,0 +1,468 @@
+
+[22:01:22] <jrand0m> agenda:
+[22:01:22] <jrand0m> 0) Hi
+[22:01:22] <jrand0m> 1) Network status
+[22:01:28] <jrand0m> 2) 0.3.1 plan
+[22:01:28] <jrand0m> 3) Web architecture
+[22:01:28] <jrand0m> 4) Administravia
+[22:01:34] <jrand0m> 5) ???
+[22:01:38] <jrand0m> 0) hi
+[22:01:39] <no_dammagE> of yourse
+[22:01:43] <ughabugha> Oh, cool, the meeting. :)
+[22:01:51] <jrand0m> hi, welcome to the weekly dev meeting, number $something
+[22:01:56] <ughabugha> Hi.
+[22:02:02] <jrand0m> weekly status notes up at http://i2p.net/pipermail/i2p/2004-March/000180.html
+[22:02:09] * mihi has joined #i2p
+[22:02:13] <fidd> howdy
+[22:02:32] <jrand0m> we'll see if we can avoid a 2 hour session today ;)
+[22:02:39] <jrand0m> ok, jumping to 1) network status
+[22:02:43] <Masterboy> :P
+[22:02:56] <jrand0m> we got 0.3.0 out on sunday, and its generally functional
+[22:03:12] <Masterboy> yes it is:)
+[22:03:23] <ox> * jrandom waves from i2p#i2p to prove it ;)
+[22:03:43] <jrand0m> there are still some bugs to fix, and a new set of things to be addressed, but ever onwards we go
+[22:04:21] * ion has joined #i2p
+[22:04:22] * ughabugha is reading the status notes.
+[22:04:27] * mrflibble has quit IRC (r eboot time)
+[22:04:35] <jrand0m> in the email i mention a new network monitoring tool duck put together - http://duck.i2p/dot/dot.png (or a snapshot at http://i2p.net/~jrandom/profiles.png)
+[22:05:05] <jrand0m> it basically gives us a view into how the network is doing - how many people are out there, and how well they're finding out about reliable and fast resources
+[22:05:22] <jrand0m> (basically it visualizes the result of the 0.3 peer profiling and selection process)
+[22:05:50] <ox> <duck> nice!
+[22:06:22] <jrand0m> yeah, its nice to see the visual feedback on the algorithms, rather than manually going through the networkDb
+[22:06:37] <ox> <Masterboy> there's a need of cpu usage decreasing..
+[22:06:38] <fidd> :)
+[22:06:48] * jrand0m gives the eepSiteAppOfTheWeek award to duck for dot.png
+[22:06:54] <ughabugha> Yeah, I wonder what would we be doing without duck?
+[22:07:08] <ox> <duck> maybe we can make an audio version too
+[22:07:17] <fidd> haha
+[22:07:20] <jrand0m> :)
+[22:07:22] <human> heheh
+[22:07:34] <fidd> or a smell-one
+[22:07:47] <ughabugha> Yeah, and stream it over jnon's icecast every hour.
+[22:07:51] <no_dammagE> how do I understand the speed column in #transport?
+[22:08:00] <no_dammagE> I mean peer profiles
+[22:08:25] <jrand0m> no_dammagE> good question. if you read the bottom text below, it explains that the numbers have no correlation with anything - they're strictly relative values.
+[22:08:50] <no_dammagE> ok :)
+[22:09:15] <jrand0m> if you want the *real* answer, see http://i2p.net/cgi-bin/cvsweb.cgi/i2p/code/router/java/src/net/invisiblenet/i2p/router/peermanager/SpeedCalculator.java?rev=1.3&content-type=text/x-cvsweb-markup
+[22:10:07] <jrand0m> the network has also grown to a steady 18-22 routers, which is a good size for the moment
+[22:10:31] <jrand0m> we'll want to grow a bit more once some of the existing bugs are dealt with, and the 0.3.1 phttp code is in place
+[22:10:36] <KyroxX> re
+[22:10:45] <jrand0m> wb KyroxX
+[22:11:03] <jrand0m> ok, that leads us into 2) 0.3.1 plan
+[22:11:16] <no_dammagE> mine will go off in 30 minutes and will go on in ~ 20 hours (or ill make it on the autostart so that it will be started with the PC)
+[22:11:29] <jrand0m> cool no_dammagE, thats fine
+[22:11:33] * fR has quit IRC (Ping timeout)
+[22:12:01] <jrand0m> rather than get the phttp code, the bandwidth limiter, and the new collusion deterrent all in one 0.3.1 release, i'm pushing the collusion deterrent into 0.3.2
+[22:12:19] <jrand0m> roadmap hasn't yet been updated, but things are pretty much the same
+[22:12:45] * fR has joined #i2p
+[22:13:17] <ughabugha> Are you going to release 0.3.0.1?
+[22:13:18] <jrand0m> there's going to be some complex stuff in the phttp revamp, dealing with throttling the connections, but we'll see how it goes
+[22:13:36] * KyroxX has quit IRC (Verlassend)
+[22:13:47] <jrand0m> perhaps, though currently the roadmap lists 0.3.1 as next week
+[22:13:54] <jrand0m> sunday, even.
+[22:14:01] <ox> <baffled> I knew you was in collusion with somebody.
+[22:14:02] <jrand0m> so i'm not sure
+[22:14:03] * Rom|Away|3h has quit IRC (Ping timeout)
+[22:14:04] <Masterboy> how can i limit the cpu usageof my router? why not make : "low" - "normal" - "high" - so you could choose?
+[22:14:10] <jrand0m> heh baff
+[22:14:11] <no_dammagE> why is that critical?:
+[22:14:11] <no_dammagE> 21:55:36.249 CRIT [I2CP Reader ] et.invisiblenet.i2p.util.Clock: Updating clock
+[22:14:12] <no_dammagE> offset to 105791ms from 0ms
+[22:14:16] * Romster has joined #i2p
+[22:14:24] * jar has quit IRC (Ping timeout)
+[22:14:38] <jrand0m> Masterboy> the code to work along those lines is planned for the 1.0rc1 release
+[22:14:43] <jrand0m> (router throttling)
+[22:14:48] * KyroxX has joined #i2p
+[22:14:50] <jrand0m> we've got some basics, but its not ready yet.
+[22:15:08] <KyroxX> re
+[22:15:13] <jrand0m> no_dammagE> because it should only occur at most once - if you see it happening a lot, its an issue
+[22:15:14] <Masterboy> oki
+[22:15:21] <jrand0m> (a critical issue)
+[22:15:48] <jrand0m> any other questions / concerns on the 0.3.1 release?
+[22:15:55] <mihi> then it should be debug the first time and then crit...
+[22:16:06] <jrand0m> you're right
+[22:16:09] <KyroxX> whats the topic?
+[22:16:17] <ughabugha> jrand0m: Err.. How can this occur on I2P? Closing Link: [unknown@192.168.0.2] (Ping timeout)
+[22:16:31] <jrand0m> KyroxX> the weekly dev meeting, item 2) 2) 0.3.1 plan
+[22:16:35] <ughabugha> Ah, never mind.
+[22:16:40] <jrand0m> ughabugha> ircd patch
+[22:16:49] <KyroxX> ah
+[22:17:02] <ox> <duck> my ircd is running on nsa.localdomain
+[22:17:06] <jrand0m> hmm
+[22:17:08] <ox> <duck> which has 192.168.0.2 as IP
+[22:17:12] <jrand0m> ah
+[22:17:30] * Romster has quit IRC (Ping timeout)
+[22:17:32] <jrand0m> ok, moving on to 3) Web architecture
+[22:17:49] * ion has quit IRC (Ping timeout)
+[22:17:58] <jrand0m> i know we discussed this last week a bit, and there's been some discussion on the mailing list about it too
+[22:18:02] <mihi> how can i make an account on drupal.i2p.net?
+[22:18:15] * mihi is too stupid for that...
+[22:18:16] <jrand0m> wilde> can you add one for mihi?
+[22:18:31] <jrand0m> (there's no way to register normally)
+[22:18:35] <mihi> jrand0m: you could simply say no, then i know i can stop trying ;)
+[22:18:42] <jrand0m> if wilde isn't around, i'll add one for you momentarily :)
+[22:18:51] * Romster has joined #i2p
+[22:19:04] * Romster is now known as Rom|Away|3h
+[22:19:18] <fidd> i'd like one too if its ok :)
+[22:21:05] <ox> <jmand> /ping jmand
+[22:21:12] <jrand0m> ok, back to the web arch stuff
+[22:22:06] <jrand0m> there are several different aspects of "how we use the web" in i2p, and we can either treat them all as OneBigWebThingy, or we can talk about specializing the components, making things that do their OneThingWell
+[22:22:34] * ion has joined #i2p
+[22:22:44] <jrand0m> mihi brought up some good points that I hadn't been looking at, some valuable features that we'll certainly want
+[22:23:03] <ughabugha> jrand0m: Are you talking about the separation of Squid and I2P web?
+[22:23:11] <ughabugha> Or something deeper?
+[22:23:24] <duck> the 'HTTPTunnel vs. {privoxy,muffin} + HTTPClient' thread
+[22:23:30] <duck> (http://i2p.dnsalias.net/pipermail/i2p/2004-March/)
+[22:23:48] <jrand0m> the seperation of squid and eepsites, as well as the seperation of browser proxies vs. (essentially) cgis
+[22:23:49] <ughabugha> Right.
+[22:24:00] <jrand0m> and, of course, the filters
+[22:24:48] <jrand0m> since we all work in the open source world here, there's no real need to have OneBigThing that deals with all of the different use cases - we can build one to address a need, then reuse its code for another to address another need
+[22:24:56] * jar has joined #i2p
+[22:25:04] <duck> I tend to agree with human's latest post
+[22:25:13] <jrand0m> plus, with mihi's new streaming I2PTunnel api, its fairly easy to build off
+[22:26:42] <jrand0m> as do i, though i don't have the time to work on httptunnel, so its really up to mihi as to what use case he's most interested in addressing first
+[22:26:48] * lucky has joined #i2p
+[22:27:45] * jar has quit IRC (EOF From client)
+[22:27:52] <jrand0m> mihi> any thoughts?
+[22:28:26] <jrand0m> ok or anyone else? :)
+[22:28:47] <duck> http://i2p.i2p/ looks ugly to me
+[22:28:55] <duck> but even that could be survived
+[22:28:59] <jrand0m> i2p.i2p?
+[22:29:05] <human> ?
+[22:29:27] * ion has quit IRC (Ping timeout)
+[22:29:28] <jrand0m> i could add in a dns entry for eep.i2p.net pointing to 127.0.0.1 for machines that do bad dns things
+[22:30:01] * fR has quit IRC (EOF From client)
+[22:30:20] * human didn't get the latest proposal :-)
+[22:30:27] <duck> I think I did see i2p.i2p mentioned somewhere as replacement for the current http://i2p/keybla
+[22:30:35] <jrand0m> yours was the latest human
+[22:30:54] <jrand0m> oh, right, yeah on irc last night i think jnano was discussing it
+[22:30:55] <human> jrand0m: i mean: "i could add in a dns entry for eep.i2p.net pointing to 127.0.0.1 for machines that do bad dns things"
+[22:31:03] <mihi> duck: you have good eyes. i did this to prevent netbios lookups in Opera.
+[22:31:21] <duck> ah yeah "code/apps/i2ptunnel/java/src/net/invisiblenet/i2p/httptunnel/handler/RootHandler.java"
+[22:31:21] <jrand0m> ah sorry human, i meant that with regards to what mihi just said :)
+[22:31:23] * lucky has quit IRC (Ping timeout)
+[22:31:49] <duck> it is a shame that some browsers need such workarounds
+[22:31:55] <human> wew
+[22:32:15] <jrand0m> human mentioned something about socks4 not requiring that?
+[22:32:15] * KyroxX is now known as wbk
+[22:32:23] <duck> socks4a
+[22:32:29] <jrand0m> ah ok
+[22:32:39] <duck> (socks4 does DNS)
+[22:32:49] <jrand0m> do all browsers support socks4a?
+[22:32:59] <human> jrand0m: socks4 is Evil(TM), but socks4a and socks5 delegate name resolution to the server
+[22:33:00] <duck> s/socks4 does DNS/with socks4 the client does DNS/
+[22:33:06] <mihi> some browsers don't even support socks proxies...
+[22:33:08] <human> jrand0m: yes, AFAIK
+[22:33:27] <jrand0m> right, plus the kiosk issue mihi, certainly
+[22:33:52] <duck> it could be an alternative
+[22:34:04] <duck> httpclient + socksclient + etc
+[22:34:29] <human> jrand0m, mihi: programs that don's support socks could be tsocks'ed
+[22:34:53] <jrand0m> human> unless its a kiosk, where people can't run apps
+[22:35:00] <jrand0m> (or change settings, etc)
+[22:35:19] <human> jrand0m: yes, of course socks tunnels aren't suited for these tasks
+[22:35:31] <duck> (human: though then they'd still call gethostbyname)
+[22:35:39] <jrand0m> would they duck?
+[22:35:55] <human> duck: no, tsocks even inhibits them and forwards them to the proxy server
+[22:36:16] <human> duck: (dunno what happens in the windows world, though)
+[22:36:30] <jrand0m> they BSOD
+[22:36:32] <jrand0m> er..
+[22:36:57] <duck> (not according to /usr/share/doc/tor-0.0.2_pre27/CLIENTS.gz)
+[22:36:57] <human> heheheh
+[22:37:07] <jrand0m> heh duck
+[22:37:18] <human> socks tunnels, however, will not replace www proxies :-)
+[22:37:24] <duck> (( </tortechnotalk> ))
+[22:38:25] <jrand0m> mihi> whats your take on the highest priority use case for httptunnel? if there's something we can help with?
+[22:38:31] <mihi> http://home.arcor.de/mschierlm/test/nosocks.png (which browser is that?)
+[22:38:31] <human> it's just an add-on to do some neat stuff with tunnelling, chaining etc.
+[22:38:31] <wbk> I2P is the ircd of iip right?
+[22:38:31] <duck> anyway, all solutions need a clientside filter
+[22:38:47] <human> duck: yes, according to man 8 tsocks :-)
+[22:39:14] <jrand0m> dunno mihi, opera?
+[22:39:19] * fR has joined #i2p
+[22:39:19] <duck> wbk: no private msg
+[22:39:19] <jrand0m> wbk> no
+[22:39:30] <mihi_backup> jrand0m: make it work perfectly with post requests && make it do everything httpclient does
+[22:39:45] <jrand0m> word
+[22:40:08] <ughabugha> mihi: That's Opera.
+[22:40:14] <human> mihi: dunno, but as i wrote above: socks tunnels, however, will not replace www proxies :-)
+[22:40:18] <ughabugha> If you ment that as a question. :)
+[22:41:13] <jrand0m> ok, cool, anyone have anything else to bring up for web stuff, or are we ready for 4) Administravia?
+[22:42:23] <jrand0m> ok, just some notes -
+[22:42:24] * Rom|Away|3h is now known as Rom|Away|4h
+[22:42:51] <jrand0m> the drupal site is back online, so anyone who wants to help out with that, or see the latest progress, please hit drupal.i2p.net :)
+[22:44:02] <jrand0m> on it, you'll find the other two administravia points - the team roster [http://drupal.i2p.net/team] and the draft of a new license policy [http://drupal.i2p.net/node/view/85]
+[22:44:26] <duck> I was looking at the license policy...
+[22:44:35] <duck> AFAIK Cryptix == BSD
+[22:44:43] <jrand0m> right
+[22:44:52] <duck> (but with Cryptix team as copyrightor instead of regents of massachusets or something)
+[22:44:52] <jrand0m> but, strictly, its the Cryptix license ;)
+[22:45:05] <duck> what is MIT?
+[22:45:13] <jrand0m> mit is == bsd 2 clause
+[22:45:16] <jrand0m> == x
+[22:45:19] <duck> what code is MIT I mean
+[22:45:25] <jrand0m> nothing
+[22:45:29] <human> == x < 4.4.0
+[22:45:36] <jrand0m> i just list it as "if you want to use MIT, great"
+[22:45:42] <jrand0m> right human :/
+[22:45:49] <duck> the amount of licenses is already quite a few
+[22:45:56] <duck> I was wondering if that could be restricted
+[22:46:07] <duck> for example changing the GPL code into BSD or even pubdomain
+[22:46:31] <duck> was wondering what the author(s) of that part(s) did think about that
+[22:46:32] <ox> <no_dammagE> so, chatroom, ill go sleep now. Good code @ Devteam, good time of day to all others. Till tomorrow.
+[22:46:40] <duck> bye no_dammagE
+[22:46:41] <jrand0m> i would love if the i2ptunnel streaming lib / naming lib or even the full i2ptunnel were licensed under a bsd-like license
+[22:46:51] <jrand0m> later no_dammagE
+[22:46:55] <no_dammagE> cu
+[22:46:58] * no_dammagE has quit IRC
+[22:47:19] * jar_backup has joined #i2p
+[22:47:50] <jrand0m> but, of course, GPL is fine, t'is mihi's right :)
+[22:48:06] <mihi> for streaming/naming lib that would be okay for me (or BSD or LGPL). but I'd like to keep GPL for the core I2PTunnel
+[22:48:07] <ughabugha> Well, whatever the license is, it should be GPL-compatible.
+[22:48:36] <ughabugha> (Ie, it shouldn't be more restrictive than GPL)
+[22:48:42] <human> i'm a GNU GPL advocate, but i think that the best license to disseminate new protocols and formats is something BSD-style (e.g. see how the OGG Vorbis guys relicensed everything from LGPL do MIT-X11)
+[22:49:05] <jrand0m> mihi> the streaming and naming lib are funcional without dependency upon i2ptunnel itself, right?
+[22:49:14] <ughabugha> Yeah, reference implementation shouldn't be GPL.
+[22:49:25] <mihi> they should be. if not, it's a bug.
+[22:49:30] <jrand0m> BSD 2 clause on those would be fantastic
+[22:49:40] <human> yup!
+[22:49:45] <mihi> you can have naming lib public domain if you include it into core ;)
+[22:50:02] * ion has joined #i2p
+[22:50:03] <jrand0m> absolutely, I'd love to include them in the core sdk
+[22:50:42] <mihi> them? ;) (including streaming lib into core would be a bad idea imho, since it is too less open for other impls)
+[22:51:09] <jrand0m> well, the sdk impl itself makes some nontrivial design assumptions - its just a ref impl
+[22:51:22] <jrand0m> i'd love if people could take i2p.jar and write a streaming app
+[22:51:28] <human> mihi: regarding I2PTunnels & GPL: i'd suggest to add an explicit GNU GPL exception that allows people to link your app with proprietary JVMs (see my comment on http://drupal.i2p.net/node/view/85)
+[22:51:28] * Masterboy has quit IRC (Ping timeout)
+[22:51:59] <duck> human: that brings up the "have to hire a lawyer before I can use it"-problem
+[22:52:01] <jrand0m> (perhaps we can split the current i2ptunnel into i2ptunnel and i2pstreaming, if you'd prefer?)
+[22:52:32] <mihi> jrand0m: that would be okay for me. just change the ant task to build 2 jars ;)
+[22:52:35] <human> duck: i suggest to add the exception just to avoid it
+[22:52:39] <jrand0m> duck> if mihi is willing to BSD the streaming and naming libs, i don't think that'd be too much trouble
+[22:53:30] <mihi> and better make i2pministreaming instead of i2pstreaming
+[22:53:41] <duck> mihistreaming :)
+[22:53:48] <mihi> (note the n in mi4ni)
+[22:54:02] <mihi> duck: that was exactly what i thought ;)
+[22:54:03] <jrand0m> word mihi, so perhaps we can revise the table on http://drupal.i2p.net/node/view/85 to list the I2PTunnel core as GPL (perhaps with the exception human mentions?), plus a seperate I2PMiniStreaming line as BSD?
+[22:54:04] <jrand0m> hehe
+[22:54:10] <jrand0m> i2pmihistreaming is good too :)
+[22:55:25] <duck> ok
+[22:55:40] <duck> next week I'll try to convince you all to move totally to publicdomain
+[22:55:45] <duck> but this is enough for now :)
+[22:55:48] <jrand0m> :)
+[22:55:50] <human> hehe
+[22:56:06] <jrand0m> mihi*=5
+[22:56:14] <mihi> jrandom**=5;
+[22:56:21] <duck> wbk did just offer to help with the webdesign
+[22:56:36] <jrand0m> oh awesome duck
+[22:56:45] <jrand0m> well, briefly before we jump to 5)
+[22:56:58] <jrand0m> do any devs have any qualms with the /policy/ in http://drupal.i2p.net/node/view/85?
+[22:57:05] <duck> so I did do a bureaucratic team-table lookup and delegate him to wilde
+[22:57:25] <human> before jumping... what about the GPL + exception suggestion?
+[22:57:29] <jrand0m> aka "implicitly under $primaryLicense" or "explicitly under $alternate"?
+[22:57:47] <jrand0m> duck++ :)
+[22:58:02] <mihi> human: I'm adding it atm
+[22:58:07] * human agrees with jrand0m's policy
+[22:58:25] <duck> what about copyright owner
+[22:58:28] <human> mihi: ok, thanks
+[22:58:30] * duck did see human adding some new files as GPL
+[22:58:36] <duck> and putting mihi's name on that
+[22:58:45] <ughabugha> Err... I don't think drupal likes passwords which are 32 characters long.
+[22:58:51] <human> duck: i just cut'n'pasted existing files
+[22:59:18] <duck> ok, but what if we have 50 ppl working on it and each putting their own name on the copyrights
+[22:59:20] <jrand0m> for people that add public domain code, there's no copyright, but for people who use copyright, people should copyright it themselves
+[22:59:22] <human> duck: (well, even if i'm forgetting to put copyrights into files...)
+[22:59:25] <duck> then you cant switch license at a later point
+[22:59:29] <jrand0m> thats fine duck, in my opinion
+[22:59:53] <jrand0m> e.g. thecrypto should be the copyright owner of his encryption and SHA routines
+[23:00:03] <human> (i was still observing jrand0m's policy to stick with module licenses, btw)
+[23:00:05] <jrand0m> though since he's released it under BSD 2 clause, we will use it
+[23:00:38] <jrand0m> oh, maybe i'm missing the point - you want to make sure everyone puts their own name on it?
+[23:00:44] <duck> no
+[23:00:49] * jrand0m assigns copyright to richard nixon
+[23:00:56] <human> heheh
+[23:01:34] <human> btw: in my country, "public domain" is just another kind of copyright
+[23:01:46] <jrand0m> hmm. i2p doesn't have any legal entity to receive copyright (and *never* will)
+[23:02:02] <human> i.e. you (the author) distribute your works without any restrictions
+[23:02:18] <jrand0m> right, a lot of countries have fucked up IP laws
+[23:02:59] <human> jrand0m: just to say that maybe it's better to put something like "i've created this file, and you can use it without any restriction" in each file
+[23:03:13] <jrand0m> that i think is a good idea
+[23:03:47] <human> jrand0m: (it's still happening, of course, but i think it should be a requirement :-)
+[23:03:55] <jrand0m> thats why i included the "jrandom wrote this in $year and releases it into the public domain" ;)
+[23:04:08] <human> jrand0m: yeah :-)
+[23:04:27] <jrand0m> so i'm missing ducks point
+[23:04:37] <fidd> and that thing abouth eating children
+[23:04:37] <duck> I lost it too
+[23:04:43] <jrand0m> :)
+[23:04:44] <human> heheh
+[23:04:47] <duck> lets forget it
+[23:04:58] * lucky has joined #i2p
+[23:05:13] <jrand0m> ok, so I'll add to the commit priv section the suggestion that people make note of their authorship of what they write
+[23:05:22] <jrand0m> (even if they dont copyright it?)
+[23:05:24] <lucky> hi
+[23:05:25] <lucky> :D
+[23:05:39] <jrand0m> s/suggestion/<i>suggestion</i>/
+[23:05:42] <jrand0m> hi lucky
+[23:05:50] <jrand0m> [damn i borked my regexp]
+[23:05:57] <duck> want me to PGP sign a statement?
+[23:06:09] <jrand0m> i'm going to, yes
+[23:06:30] <jrand0m> once the policy is ready and revised, i'll be contacting all prior committers for PGP/GPG auth
+[23:06:33] <human> jrand0m: yes (in my country it's impossible to refuse copyright, it's seen as an inalienable author's right)
+[23:06:52] <duck> yes, your country is fucked
+[23:06:53] <duck> NEXT
+[23:06:56] <duck> (oops)
+[23:06:58] <jrand0m> :)
+[23:07:19] <fidd> human, what country?
+[23:07:39] <human> jrand0m: so, "this file is not copyrighted" just doesn't make sense - you should *always* explicitly say that you're the author, and that you put no restrictions on your work
+[23:07:47] <human> fidd: somewhere near Europe :-)
+[23:07:54] <fidd> heh, ok
+[23:07:59] <lucky> human: you can later say you don't want the copyright
+[23:08:03] <lucky> and put it in the public domain.
+[23:08:19] <jrand0m> human> with the "implicit release under $primaryLicense", that should address the issue though, right?
+[23:08:24] <duck> human means that that doesnt mean anything in $fuckedcountry
+[23:08:42] <jrand0m> human> since that implicitly means commit == release as $primaryLicense
+[23:08:50] <human> duck: yup, exactly
+[23:09:07] <jrand0m> (so no comment == implicit license by $author, per `cvs log`)
+[23:09:28] <jrand0m> (ah, legalese in code ;)
+[23:09:36] <human> jrand0m: well, i'm not a lawyer... but i think it should work
+[23:09:43] * kaji has joined #i2p
+[23:09:48] <ox> * wilde agrees with the last proposal
+[23:09:57] <jrand0m> w3rd.
+[23:10:05] <jrand0m> ok, i'll see if i can get the eff to review
+[23:10:19] <jrand0m> moving on to 5) ???
+[23:10:21] <human> jrand0m: maybe it's better to have some sort of agreement when ppl are given CVS access
+[23:10:46] <ox> <wilde> when will we see, net.i2p.legal.LicenseManager?
+[23:10:47] <jrand0m> agreed human> explicit agreement with $policy will be a prerequisit for getting commit privs
+[23:10:50] <jrand0m> heh
+[23:10:52] <human> jrand0m: (for example, GPG signing the your policy, and hosting it on the I2P site?)
+[23:11:00] <human> heheh
+[23:11:04] <jrand0m> reasonable enough human.
+[23:11:13] <mihi> jrand0m prefers PGP8 ;)
+[23:11:23] <jrand0m> damn straight. pgpdisk++
+[23:12:06] * wilde has joined #i2p
+[23:12:14] <duck> hi wilde
+[23:12:36] <jrand0m> ok, does anyone have anything they want to bring up for 5) ???
+[23:13:27] <wilde> just an invitation one more time for people to visit drupal and comment, modify, etc
+[23:13:37] <jrand0m> word, yes, thats a good point
+[23:13:41] <duck> http://drupal.i2p.net/
+[23:13:41] <wilde> so we can have good docs for 1.0
+[23:13:41] <mihi> human, jrand0m: is the license in CVS okay now? ;)
+[23:13:55] <jrand0m> on http://drupal.i2p.net/team there are a lot of [vacant] roles. volunteer!
+[23:14:02] <fidd> i cant get drupal thru squuid :/
+[23:14:17] * mihi volunteers for QS guy cuz of echo server ;)
+[23:14:29] <mihi> s/QS/QA/
+[23:14:33] <jrand0m> woot!
+[23:15:01] <wilde> unit tests for echo server
+[23:15:12] <mihi> wilde rofl no
+[23:15:17] <human> mihi: maybe you should s/XXXX/mihi/ in the GPL exception :-)
+[23:15:20] <ughabugha> jrand0m: Heh, what do you mean by stress testing? :)
+[23:15:34] <mihi> echo server is system test for i2p ;)
+[23:15:38] <mihi> human: oops ;)
+[23:15:56] * Rom|Away|4h has quit IRC (Ping timeout)
+[23:16:08] <jrand0m> ughabugha> it means you smash (aka use) the router and have patience with me to debug it, submitting reports and logs
+[23:16:35] <ox> <wilde> thus stress testing poor jrandom...
+[23:16:40] <ughabugha> jrand0m: Oh, okay. :)
+[23:16:44] <duck> wow, mihi is fast
+[23:16:47] <ughabugha> Hehe.
+[23:17:30] * Romster has joined #i2p
+[23:17:40] <mihi> duck: editor still open and the CVS comment was fast to type as well ;)
+[23:17:40] <jrand0m> mihi> licenses look great - just to be explicit, you're idented here, and you intend to release under the bsd 2 clause [per http://opensource.org/licenses/bsd-license.php], correct?
+[23:17:41] * Romster is now known as Rom|Away|4h
+[23:18:02] <jrand0m> (or you can just add that copyright text into the source)
+[23:19:24] <mihi> hmm, what does idented mean? (yes to your second subclause)
+[23:19:42] <jrand0m> means you've proven to trent that you're mihi :)
+[23:19:50] <duck> authenticated
+[23:19:54] <mihi> ok, identified ;)
+[23:20:01] <jrand0m> w3rd
+[23:20:06] <human> let's try identicated
+[23:20:14] <mihi> it looked to me like "indented" and i thought that my white space was incorrect ;)
+[23:20:20] <jrand0m> hehe
+[23:20:43] <ox> * wilde thinks launches word for find yet another synonym
+[23:21:07] <human> authentified?
+[23:21:22] <duck> anyway...
+[23:21:28] <jrand0m> ok, r0x0r, anyone have anything else to bring up?
+[23:21:44] <ox> <wilde> yeah
+[23:21:50] <ox> <wilde> eep naming
+[23:22:00] <jrand0m> heh you don't like my pronounciation?
+[23:22:12] * kaji has quit IRC (Ping timeout)
+[23:22:14] <ox> <wilde> of i2p -> eep
+[23:22:14] * Rom|Away|4h has quit IRC (Ping timeout)
+[23:22:21] <jrand0m> oh
+[23:22:30] <jrand0m> you want to rename the whole project "eep" ?
+[23:22:39] <human> lol
+[23:22:48] <ox> * wilde mutters
+[23:22:48] <mihi> envisible enternet project ;)
+[23:23:08] <lucky> envisible
+[23:23:09] <jrand0m> extrordinarily excellent people
+[23:23:15] <lucky> connotates something for me.
+[23:23:46] <mihi> even easier publishing ;)
+[23:23:51] <jrand0m> ooOOoo
+[23:23:51] <lucky> As in its going to be visable, therefore possible. envision maybe?
+[23:23:53] <ughabugha> Come on, stop picking on wilde. :)
+[23:23:54] <ox> <wilde> seriously, do you like the name then it's fun?
+[23:24:06] <ox> <wilde> fine i mean, getting tired
+[23:24:44] <ox> <wilde> new users will not have it easy
+[23:25:03] <jrand0m> oh, i'm not a marketeer. we went under "eep" because its all i could think of
+[23:25:23] <human> i think it should be forbidden to explain that eep ~= i2p, or users will *really* screw up
+[23:25:25] * ion has quit IRC (Ping timeout)
+[23:25:26] <jrand0m> what should we call websites that people both host and access through i2p?
+[23:25:38] <jrand0m> hehe
+[23:25:42] <duck> i2psites?
+[23:25:44] <ox> <wilde> i2p site?
+[23:25:57] * human likes eepsites without explanations :-)
+[23:26:09] * kaji has joined #i2p
+[23:26:25] * jrand0m asks the http://drupal.i2p.net/team user advocate for their opinion
+[23:26:35] <duck> we got one?
+[23:26:38] <jrand0m> no
+[23:26:43] <jrand0m> ;)
+[23:26:52] <duck> heh
+[23:26:55] <human> anyway... you can change all the naming, as long as the "Shitlist" keeps its current name
+[23:26:56] <ox> * wilde rushes to the browser
+[23:27:01] <jrand0m> heh
+[23:27:06] <mihi> lol human
+[23:27:07] <jrand0m> oh, shitlist is going to stay, for sure ;)
+[23:27:21] <ox> <wilde> i take the role, it should be i2p sites, i resign
+[23:27:21] <duck> I bet that shitlist is a proper english word
+[23:27:24] <jrand0m> i mean, "blacklist" just isn't as fun
+[23:27:26] <jrand0m> hah wilde
+[23:27:29] <human> jrand0m: cool!
+[23:27:56] <ughabugha> But why not stick to the current names?
+[23:28:05] * human was worried that the shitlist was going to be the first victim when I2P goes corporate
+[23:28:06] <jrand0m> ok, i don't really care either way, i2psite is fine, eepsite is fine
+[23:28:09] <ughabugha> I mean we have enough time to consider it on the mailing list until 1.0.
+[23:28:09] <mihi> jrand0m: and the elephants on the moon have to stay too ;)
+[23:28:22] <kaji> so is kaji.i2p up for anyone. i kinda just started it up without testing anything and left it running
+[23:28:31] <jrand0m> human> i think we don't have to worry about that one ;)
+[23:28:35] <ughabugha> kaji: It worked for me.
+[23:28:48] <jrand0m> we have to keep moving the easter eggs mihi :)
+[23:28:48] <ox> <wilde> i don't really care, eepsite is just as boring as i2psite
+[23:29:05] <jrand0m> we can consider them synonyms
+[23:29:23] <ox> <wilde> that the worst decision ;)
+[23:29:44] <duck> wbk: ok, I have to leave for a bit. The meeting is almost over so people can help you in #i2p
+[23:29:44] * jrand0m supposes that now that i've taken on the title of PM i've got to make a decision
+[23:29:48] * ion has joined #i2p
+[23:29:55] * jrand0m kicks self
+[23:30:09] <human> heheh
+[23:30:12] * mihi guesses jrand0m needs some support for that
+[23:30:19] * Trent@anon.iip sets mode: +o mihi
+[23:30:27] * mihi sets mode: +o jrand0m
+[23:30:30] <@jrand0m> ooOOoo
+[23:30:32] * mihi sets mode: -o mihi
+[23:30:49] <ox> <wilde> ok no more questions from me
+[23:30:55] * human sacrifices his pet to the PM
+[23:31:38] * mihi still waits for jrand0m kicking himself...
+[23:31:44] <@jrand0m> i think there's benefit to discussion, as well as some quirkiness. i also lean in human's direction - there's no need to confuse people by explaining "eep != i2p"
+[23:31:59] * @jrand0m Offically Decides "eepsite"
+[23:32:23] * You were kicked by jrand0m (bastard!)
+Session Close: Tue Mar 23 23:32:23 2004
+Session Start: Tue Mar 23 23:32:30 2004
+[23:32:32] <human> lol
+[23:32:37] <duck> lets quickly baff the meeting closed
+[23:32:40] <duck> oh, too late
+[23:32:42] <jrand0m> heh
+[23:32:48] <human> heheh
+[23:32:56] <jrand0m> ok anything else? we're at the 92 minute mark
+[23:33:05] * jrand0m winds up...
+[23:33:20] * jrand0m *baf*s the meeting closed
+
\ No newline at end of file
diff --git a/pages/meetings.html b/pages/meetings.html
index d122fe50..4752b020 100644
--- a/pages/meetings.html
+++ b/pages/meetings.html
@@ -2,10 +2,43 @@