[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.