IIP 1.2 roadmap meeting log

**** BEGIN LOGGING AT Fri Mar 28 21:16:06 2003

[2003/03/28 21:16:06]-->    You are now talking on #iip-future
[2003/03/28 21:16:08]<nop>  hehe
[2003/03/28 21:16:10]<hezekiah> UserX! :)
[2003/03/28 21:16:15]<UserX>    hi
[2003/03/28 21:16:26]<hezekiah> We were just coming up with consipircy theories on why you weren't here yet. :)
[2003/03/28 21:16:40]---    hezekiah gives channel operator status to UserX
[2003/03/28 21:16:52]<hezekiah> There. :) (Who knows what good that does, but it does something I guess!) :)
[2003/03/28 21:17:12]<hezekiah> OK ... nop? Do you want to start since you have a good idea of what's going on?
[2003/03/28 21:17:26]<hezekiah> (Oh, and we need the logger thing too.)
[2003/03/28 21:18:08]<nop>  well
[2003/03/28 21:18:09]<nop>  actually
[2003/03/28 21:18:19]<nop>  I thing UserX has an offer of what he likes for decentralization
[2003/03/28 21:18:26]<nop>  and I'd like for him to review what he thinks
[2003/03/28 21:18:29]<nop>  and then discuss node discovery
[2003/03/28 21:18:36]<hezekiah> OK.
[2003/03/28 21:18:37]<nop>  and channel key encryption
[2003/03/28 21:18:53]<hezekiah> I no almost nothing about p2p theory, so I won't have much good to say. :)
[2003/03/28 21:19:06]<nop>  well, we're learning too
[2003/03/28 21:19:07]<nop>  :)
[2003/03/28 21:19:09]<hezekiah> lol
[2003/03/28 21:19:24]<nop>  a few links though I'm gonna post
[2003/03/28 21:19:52]<nop>  http://cgi.cs.duke.edu/~priya/HyperNews/get.cgi/eval7/7.html?nogifs
[2003/03/28 21:20:12]<nop>  http://www.onion-router.net/
[2003/03/28 21:21:45]<nop>  http://216.239.57.100/search?q=cache:HSJ8UiXJEEYC:www.pdos.lcs.mit.edu/asrg/02-22-2000.ps+garlic,+routing&hl=en&ie=UTF-8
[2003/03/28 21:21:51]<nop>  look up the word garlic
[2003/03/28 21:22:23]<hezekiah> Concerning the first link. Are we supposed to find and read that paper, or just read this person's description of it?
[2003/03/28 21:23:16]<nop>  well, all this can be read later
[2003/03/28 21:23:23]<nop>  but it's just stuff we might want to consider at different points
[2003/03/28 21:23:28]<nop>  at least certain methods
[2003/03/28 21:23:30]<nop>  from these articles
[2003/03/28 21:23:57]<hezekiah> OK. But when I read it later, do you want me to find the paper, or just read the guy's comments? :)
[2003/03/28 21:24:17]<nop>  read the paper if possible
[2003/03/28 21:24:23]<hezekiah> OK. :)
[2003/03/28 21:24:33]<nop>  UserX are you here
[2003/03/28 21:24:37]<UserX>    i'm here
[2003/03/28 21:24:56]<nop>  can you start where we left off a long time ago about the most plausible routing system to start
[2003/03/28 21:25:04]<nop>  and the scalable factors of that routing method
[2003/03/28 21:25:48]---    nop is now known as noP
[2003/03/28 21:26:36]*  noP sits back and listens 
[2003/03/28 21:26:36]<noP>  ;)
[2003/03/28 21:27:52]---    Disconnected (Remote host closed socket).
**** ENDING LOGGING AT Fri Mar 28 21:27:52 2003

**** BEGIN LOGGING AT Fri Mar 28 21:30:01 2003

[2003/03/28 21:30:01]-->    You are now talking on #iip-future
[2003/03/28 21:30:08]<--    UserX has quit (Ping timeout)
[2003/03/28 21:30:09]<noP>  hmmhehe
[2003/03/28 21:30:11]<noP>  ok
[2003/03/28 21:30:14]<noP>  that could be the issue
[2003/03/28 21:30:18]<noP>  no wonder he wasn't saying much
[2003/03/28 21:30:23]<hezekiah> lol
[2003/03/28 21:30:44]---    You are now known as UserX
[2003/03/28 21:31:04]<UserX>    the two possible methods for doing the first versions of decentralized IIP would either be: dumb broadcast or listening server routing
[2003/03/28 21:32:23]<UserX>    dumb broadcast has the obvious problem of scalability and if it is done would only be a stepping stone to something better and probably only be in developer release
[2003/03/28 21:33:12]<noP>  right
[2003/03/28 21:33:21]<hezekiah> Dumb broadcast is just sending a message out into the network, and let it bounce from node to node until it hits the right one, correct?
[2003/03/28 21:33:24]<noP>  I think we discussed broadcast is kind of dumb
[2003/03/28 21:33:25]<noP>  ;)
[2003/03/28 21:33:51]<noP>  can you go a bit of detail on listener server routing
[2003/03/28 21:34:36]<UserX>    hezekiah: basicly yes.
[2003/03/28 21:34:53]<hezekiah> Thanks. Continue ... :)
[2003/03/28 21:36:38]<noP>  he might have pinged out
[2003/03/28 21:36:39]<noP>  :)
[2003/03/28 21:36:44]<hezekiah> Maybe.
[2003/03/28 21:36:57]<hezekiah> I've noticed that the developer version of IIP has become less stable recently.
[2003/03/28 21:37:05]<hezekiah> Rigt now I'm using the HEAD version.
[2003/03/28 21:37:14]<noP>  right
[2003/03/28 21:38:24]<UserX>    basicly with listening routing you have three layers in the network. broadcast, relay, and user
[2003/03/28 21:38:59]<UserX>    user nodes connect to relay nodes. relay nodes connect broadcast nodes (possibly via other relay nodes)
[2003/03/28 21:41:02]<UserX>    broadcast nodes every so often send out a broadcast message which act as a way for other broadcast nodes to know how to find that node
[2003/03/28 21:43:40]<UserX>    a basic description of it is in: IIP-Routing.txt
[2003/03/28 21:44:16]<noP>  listener routes are part of broadcast layer
[2003/03/28 21:44:54]<noP>  ?
[2003/03/28 21:46:18]<UserX>    yes
[2003/03/28 21:46:55]<noP>  ok
[2003/03/28 21:47:06]<noP>  can you demonstrate the math on the scalability theory we have for this?
[2003/03/28 21:47:25]<noP>  and
[2003/03/28 21:47:26]<noP>  also
[2003/03/28 21:47:49]<noP>  before we even get decentralization
[2003/03/28 21:47:52]<noP>  we need to look at VIRC
[2003/03/28 21:47:53]<UserX>    I did some math on the scalability in: IIP-Traffic.txt
[2003/03/28 21:47:56]<noP>  ok
[2003/03/28 21:48:08]<noP>  we are planning to rid the ircd server
[2003/03/28 21:48:09]<noP>  correct
[2003/03/28 21:48:12]<noP>  so
[2003/03/28 21:48:21]<noP>  we're gonna have to study the crap out of irc
[2003/03/28 21:48:23]<UserX>    basicly listening routing won't scale far past 1000 servers
[2003/03/28 21:50:31]<noP>  ok
[2003/03/28 21:50:38]<noP>  1000 servers as in all nodes
[2003/03/28 21:50:41]<noP>  or just broadcast servers?
[2003/03/28 21:50:49]<UserX>    broadcast servers
[2003/03/28 21:51:43]<noP>  yea
[2003/03/28 21:51:46]<noP>  I see in traffic.txt
[2003/03/28 21:52:37]<noP>  ok
[2003/03/28 21:52:47]<noP>  so let's start with hezekiah's idea and start mapping out certain things
[2003/03/28 21:52:57]<hezekiah> My idea?
[2003/03/28 21:52:58]<noP>  what needs to be done before we can even realistically look at routing
[2003/03/28 21:52:59]<noP>  yes
[2003/03/28 21:53:05]<noP>  you wanted to have goals, deadlines etc
[2003/03/28 21:53:08]<noP>  organization
[2003/03/28 21:53:10]<hezekiah> Oh! That idea! :)
[2003/03/28 21:53:16]<noP>  so
[2003/03/28 21:53:40]<hezekiah> What level 1 goals that will make "development" IIP 1.2?
[2003/03/28 21:53:55]<noP>  well
[2003/03/28 21:53:56]<hezekiah> Level 1 should be pretty abstract big stuff.
[2003/03/28 21:54:03]<noP>  let's break down the routing and decentralization
[2003/03/28 21:54:05]<noP>  with that to work
[2003/03/28 21:54:09]<noP>  we need to eliminate the ircd servers
[2003/03/28 21:54:20]<noP>  thus building our own protocol to work with irc clients
[2003/03/28 21:54:27]<noP>  simulating a normal ircd server environment
[2003/03/28 21:54:32]<noP>  give or take a few features
[2003/03/28 21:54:52]<noP>  so we need a Virc, (Virtual IRC) interpreter
[2003/03/28 21:54:58]<noP>  so that the client can talk to IIP
[2003/03/28 21:55:04]<noP>  that's done locally on the IIP node
[2003/03/28 21:55:17]<noP>  each node has this
[2003/03/28 21:55:33]<hezekiah> virc interprets IRC commands to IIP commands?
[2003/03/28 21:55:53]<noP>  yes, it's the middle, IRCCLIENT -> VIRC -> IIP_PROTO
[2003/03/28 21:55:59]<hezekiah> OK.
[2003/03/28 21:56:00]<UserX>    hezekiah: correct
[2003/03/28 21:56:17]<hezekiah> BTW, your previous list for big features was: <hezekiah> What are the major features/changes you plan for 1.2?
[2003/03/28 21:56:18]<hezekiah> <nop> what
[2003/03/28 21:56:18]<hezekiah> <nop> decentralization
[2003/03/28 21:56:18]<hezekiah> <nop> and channel encryption
[2003/03/28 21:56:18]<hezekiah> <nop> as well as client to client encryption
[2003/03/28 21:56:19]<hezekiah> <nop> channel trust
[2003/03/28 21:56:22]<noP>  yes
[2003/03/28 21:56:25]<noP>  let me get to that
[2003/03/28 21:56:26]<hezekiah> <nop> using RSA keyring
[2003/03/28 21:56:29]<noP>  ok
[2003/03/28 21:56:32]<hezekiah> Sorry. :)
[2003/03/28 21:56:34]<noP>  you've used PGP hezekiah 
[2003/03/28 21:56:35]<noP>  so
[2003/03/28 21:56:40]<hezekiah> Yeah.
[2003/03/28 21:56:42]<noP>  you understand that you can encrypt to many users
[2003/03/28 21:56:46]<noP>  from your key ring
[2003/03/28 21:56:51]<noP>  and those users can each decrypt the message
[2003/03/28 21:56:53]<noP>  but it's one message
[2003/03/28 21:56:57]<noP>  one ciphertext
[2003/03/28 21:57:01]<noP>  for all users
[2003/03/28 21:57:39]<hezekiah> I assumed one symmetric key was copied and each copy was encrypted with the public key of a receiving user.
[2003/03/28 21:57:48]<noP>  yes
[2003/03/28 21:57:52]<hezekiah> Good. :)
[2003/03/28 21:58:12]<noP>  ok
[2003/03/28 21:58:12]<noP>  so
[2003/03/28 21:58:18]<noP>  a channel encryption system
[2003/03/28 21:58:23]<noP>  each user has a pubkeyid
[2003/03/28 21:58:26]<noP>  like user@pubkey
[2003/03/28 21:58:38]<noP>  when we do an /invite to a channel
[2003/03/28 21:58:53]<noP>  you add the user to the keyring
[2003/03/28 21:59:04]<noP>  and send him the symmetric key for that session
[2003/03/28 21:59:08]<noP>  via his pubkey
[2003/03/28 21:59:13]<noP>  if the user isn't invited
[2003/03/28 21:59:20]<noP>  the symmetric key won't be sent to him
[2003/03/28 21:59:24]<noP>  thus
[2003/03/28 21:59:27]<noP>  he'll get garbage
[2003/03/28 21:59:32]<noP>  and not understand the channel
[2003/03/28 21:59:36]<noP>  this is for private channel modes
[2003/03/28 21:59:42]<noP>  aka encrypted channels
[2003/03/28 22:00:00]<hezekiah> What happens if a nasty user gives the symmetric key to someone else?
[2003/03/28 22:00:15]<noP>  the symmetric key is done internally
[2003/03/28 22:00:20]<noP>  and signed
[2003/03/28 22:00:24]<noP>  so if the user isn't on the keyring
[2003/03/28 22:00:27]<noP>  with signature
[2003/03/28 22:00:30]<noP>  for his pubkeyid
[2003/03/28 22:01:01]<noP>  let me think
[2003/03/28 22:01:10]<hezekiah> OK. :)
[2003/03/28 22:01:48]<noP>  we can do a challenge response method for each key given out
[2003/03/28 22:01:54]<noP>  signature +key
[2003/03/28 22:02:00]<noP>  so if that is not what expected
[2003/03/28 22:02:05]<noP>  than he still can't have access
[2003/03/28 22:03:09]<hezekiah> I'm assuming the signature is done by someone with authority to let a person join the channel?
[2003/03/28 22:03:13]<noP>  yes
[2003/03/28 22:03:18]<noP>  Operator or channel mode holder
[2003/03/28 22:03:45]<noP>  signature will prevent spoofed authentication
[2003/03/28 22:03:57]<noP>  so key is useless without signature
[2003/03/28 22:04:18]<noP>  or expected answer that would be calculated
[2003/03/28 22:04:29]<hezekiah> So the only thing you have to worry about now is having someone get into a good routing position and eaves drop on the channel. Since Bad Bob gave Evil Eve the symmetric key, she can still decrypt the conversation even though she can't join the channel.
[2003/03/28 22:04:36]<noP>  symmetric key will also be different for each person is another way
[2003/03/28 22:04:46]<hezekiah> Assuming the routing encryption is link-to-link.
[2003/03/28 22:05:08]<noP>  no
[2003/03/28 22:05:15]<noP>  each session key is different
[2003/03/28 22:05:18]<noP>  for each person
[2003/03/28 22:05:25]<noP>  since the key is signature+key
[2003/03/28 22:05:42]<noP>  we can even have a dynamic key
[2003/03/28 22:05:47]<noP>  for each user
[2003/03/28 22:05:49]<hezekiah> So there is more than one symmetric key used in the secure channel?
[2003/03/28 22:05:56]<noP>  yes there can be
[2003/03/28 22:06:13]<noP>  in a sense
[2003/03/28 22:06:23]<noP>  the use of S+K is a different key
[2003/03/28 22:06:27]<noP>  it's the KEY signed
[2003/03/28 22:06:32]<noP>  thus the outcome is not the normal key
[2003/03/28 22:06:45]<noP>  so all you have is random key, or don't even look at key as key
[2003/03/28 22:06:50]<hezekiah> But if the signature is removed, then it's the normal key, isn't it?
[2003/03/28 22:06:51]<noP>  but a hash 
[2003/03/28 22:06:54]<noP>  no
[2003/03/28 22:07:12]<noP>  look at the key as completely different for every user in the channel
[2003/03/28 22:07:25]<noP>  for instance
[2003/03/28 22:07:25]<hezekiah> OK ...
[2003/03/28 22:07:25]<noP>  diffie-hellman
[2003/03/28 22:07:25]<noP>  is different than how RSA works
[2003/03/28 22:07:32]<noP>  or el-gamal actually
[2003/03/28 22:07:32]<noP>  better example
[2003/03/28 22:07:40]<hezekiah> Right. Discrete log versus factoring.
[2003/03/28 22:07:41]<noP>  with the different users we can generate our own session
[2003/03/28 22:07:55]<noP>  that and RSA encrypts session key inside ciphertext message
[2003/03/28 22:08:02]<noP>  where as DH you calculate the session key
[2003/03/28 22:08:09]<noP>  as well as El Gamal
[2003/03/28 22:08:33]<noP>  RSA in some cases does that, which isn't always good
[2003/03/28 22:09:18]<hezekiah> You know ... why don't we discuss the details of channel encryption when we are ready to start writing it.
[2003/03/28 22:09:50]<noP>  yes
[2003/03/28 22:09:51]<noP>  that's why
[2003/03/28 22:09:54]<noP>  I wasn't rushing to that
[2003/03/28 22:09:56]<hezekiah> Actually that was part of the roadmap idea. :)
[2003/03/28 22:09:57]<noP>  but it's possible
[2003/03/28 22:10:06]<noP>  so just wanted to get it out there
[2003/03/28 22:10:12]<noP>  to have trust channels
[2003/03/28 22:10:12]<hezekiah> If you say it's possible, then I believe you! :)
[2003/03/28 22:11:10]<noP>  ok
[2003/03/28 22:11:15]<noP>  next
[2003/03/28 22:11:31]<hezekiah> I think we're still trying to come up with a list of level 1 features.
[2003/03/28 22:11:44]<noP>  yes
[2003/03/28 22:11:45]<noP>  ok
[2003/03/28 22:11:50]<noP>  UserX may help with this
[2003/03/28 22:11:53]<noP>  I'm thinking to broad
[2003/03/28 22:11:54]<noP>  sorry
[2003/03/28 22:12:01]<UserX>    One thing I want to do is relases of the development version
[2003/03/28 22:12:08]<hezekiah> Level 1 is supposed to be broad. :)
[2003/03/28 22:12:12]<hezekiah> mids will like that!
[2003/03/28 22:12:19]<noP>  haha
[2003/03/28 22:12:58]<noP>  still there UserX 
[2003/03/28 22:13:07]<noP>  your insight on development for level 1 would be good
[2003/03/28 22:17:15]<hezekiah> UserX? Are you there?
[2003/03/28 22:17:17]<noP>  ...
[2003/03/28 22:17:59]<noP>  here's here, but I dunno, he's gone silent :)
[2003/03/28 22:18:14]<hezekiah> conspiricy theory round 2!
[2003/03/28 22:18:24]<hezekiah> ... the dog needed to be taken out
[2003/03/28 22:18:30]<hezekiah> ... the babies diaper needed to be changed
[2003/03/28 22:18:37]<UserX>    the major things that will be needed for 1.2:  virc, network routing protocol, node to node protocol, channel protocol
[2003/03/28 22:18:42]<hezekiah> Ah!
[2003/03/28 22:19:52]<hezekiah> Anything to add, nop?
[2003/03/28 22:20:04]<noP>  no
[2003/03/28 22:20:07]<noP>  that's the nail on the head
[2003/03/28 22:20:13]<noP>  see, this is why UserX rocks
[2003/03/28 22:20:16]<noP>  man of few words
[2003/03/28 22:20:19]<noP>  but when he says stuff
[2003/03/28 22:20:21]<noP>  tada
[2003/03/28 22:20:22]<noP>  :)
[2003/03/28 22:20:22]<hezekiah> Would "channel trust" be under the "channel protocol" section.
[2003/03/28 22:20:26]<noP>  I believe so
[2003/03/28 22:20:28]<hezekiah> Well put!
[2003/03/28 22:20:52]<UserX>    channel trust and encryption would go under channel protocol
[2003/03/28 22:21:01]<hezekiah> OK.
[2003/03/28 22:21:18]<hezekiah> So level 1 is: virc, network routing protocol, node to node protocol, channel protocol
[2003/03/28 22:21:35]<noP>  yes
[2003/03/28 22:21:44]<hezekiah> Are we doing them in that order?
[2003/03/28 22:21:59]<noP>  good question
[2003/03/28 22:22:07]<noP>  it really depends on dependencies of protocols
[2003/03/28 22:22:14]<hezekiah> The only thing I don't know about would  be virc.
[2003/03/28 22:22:22]<hezekiah> Everything else looks in perfect order.
[2003/03/28 22:23:32]<UserX>    virc, channel protocol, network routing protocol, node to node protocol  would be the rough order things would need to be done in
[2003/03/28 22:23:53]<hezekiah> OK. :)
[2003/03/28 22:24:33]<hezekiah> Since the channel protocol probably won't need IIP to be fully decentralized, that would seem to make sense. (At least that's how it looks to me.) :)
[2003/03/28 22:25:28]<hezekiah> So ... what are "Level 2" the steps that need to be done to write up virc?
[2003/03/28 22:25:58]<noP>  well
[2003/03/28 22:26:01]<noP>  study rfc1459
[2003/03/28 22:26:03]<noP>  ;)
[2003/03/28 22:26:07]<noP>  that's your irc protocol for ya
[2003/03/28 22:26:25]<hezekiah> After that maybe Level 3 could be a 2-3 months worth chunk, and Level 4 could be what part to get done in the next 1 1/2 weeks.
[2003/03/28 22:26:34]<hezekiah> 1459. That's the RFC for IRC?
[2003/03/28 22:26:49]<noP>  I believe so
[2003/03/28 22:26:56]<UserX>    virc: interface between IRC client, network and channel protocols. would also be used to manage user identities and channels
[2003/03/28 22:27:49]<hezekiah> Uh, www.rfc.org == "Rosenburg Fund for Children"
[2003/03/28 22:27:58]<hezekiah> Where do I look up an RFC?
[2003/03/28 22:27:58]<noP>  www.ietf.org
[2003/03/28 22:28:02]<hezekiah> Thanks. :)
[2003/03/28 22:29:20]<hezekiah> Yup. 1459 is IRC.
[2003/03/28 22:29:28]<noP>  I think there is an updated one
[2003/03/28 22:29:31]<noP>  but I don't know the number
[2003/03/28 22:29:38]<noP>  that one is standard though
[2003/03/28 22:30:40]<noP>  ok
[2003/03/28 22:30:42]<noP>  next
[2003/03/28 22:30:56]<hezekiah> level 2 steps for writting virc?
[2003/03/28 22:32:30]<noP>  oh
[2003/03/28 22:32:37]<noP>  that probably is gonna require getting familiar with rfc 1459
[2003/03/28 22:32:44]<noP>  so that we understand the underlying concepts of irc
[2003/03/28 22:32:51]<noP>  because we are imitating an irc server
[2003/03/28 22:32:52]<noP>  locally
[2003/03/28 22:33:17]<hezekiah> step 1: read and understand rfc 1459
[2003/03/28 22:33:33]<hezekiah> Are you including the updates in 2810-2812?
[2003/03/28 22:33:35]<noP>  step 2: take a look at our ircd code
[2003/03/28 22:33:44]<noP>  I would suggest taking a look yes
[2003/03/28 22:33:50]<noP>  I am not familiar with the specs on the updates
[2003/03/28 22:33:59]<noP>  our ircd code is in cvs
[2003/03/28 22:34:04]<noP>  it's not ours
[2003/03/28 22:34:08]<noP>  but it's what we use
[2003/03/28 22:34:09]<noP>  and modify
[2003/03/28 22:34:12]<noP>  for ircd server now 
[2003/03/28 22:34:27]<noP>  this will probably give us shortcuts and we just borrow from that code
[2003/03/28 22:34:30]<noP>  although'
[2003/03/28 22:34:39]<noP>  robustness will be a formality and requirement
[2003/03/28 22:35:03]<noP>  so probably quite a bit of mods for our environment
[2003/03/28 22:35:11]<hezekiah> One thing we will need to know is what IIP commands the IRC commands are getting interpreted to.
[2003/03/28 22:35:35]<noP>  yes
[2003/03/28 22:35:41]<noP>  I think the best thing to do before writing code
[2003/03/28 22:35:56]<noP>  is come up with protocol specs for virc -> IIP_PROTO
[2003/03/28 22:36:17]<hezekiah> An excellent idea. ;)
[2003/03/28 22:36:31]<hezekiah> So now it looks more like:
[2003/03/28 22:36:44]<hezekiah> step 1: read rfc 1459 and look at 2810-2812
[2003/03/28 22:37:01]<hezekiah> step 2: write protocol specs for virc -> IIP_PROTO
[2003/03/28 22:38:35]<hezekiah> One thing I just thought of again ...
[2003/03/28 22:39:04]<hezekiah> Before we start working on the virc, are there still things on the "TODO" list that need to be finished first?
[2003/03/28 22:39:13]<hezekiah> UserX? You're the one who would know best. :)
[2003/03/28 22:39:27]<hezekiah> Mainly, has the "core" stuff been completed yet?
[2003/03/28 22:39:41]<UserX>    memory/object management:  memory manager needs to be made aware of ObjectDescriptors
[2003/03/28 22:40:31]<UserX>    core:  system for tracking per core listen refs and node refs
[2003/03/28 22:42:24]<UserX>    core:  move relevant configuration options to the core
[2003/03/28 22:42:44]<UserX>    i think those are the big ones that need to be done
[2003/03/28 22:42:50]<hezekiah> OK.
[2003/03/28 22:44:03]<hezekiah> So perhaps we should prepend "finish loose ends" before virc.
[2003/03/28 22:44:39]<hezekiah> Prepend to the level 1 list I mean. :)
[2003/03/28 22:45:15]<UserX>    yes
[2003/03/28 22:45:47]<hezekiah> So, if the three item list you just sent were made level 2, then what order does it get done in?
[2003/03/28 22:47:22]<hezekiah> Would the order you listed it in be OK?
[2003/03/28 22:48:11]<UserX>    irc and channel protocol stuff would be done first. network routing protocol stuff would be done as the network routing takes shape. managing user and channel identities would be done as we implement the appropriate crypto stuff
[2003/03/28 22:50:21]<hezekiah> Uh, oops. I was refering to the memory management and core stuff, when I asked what order it should be done in. My misscommunication. :)
[2003/03/28 22:51:51]<UserX>    in the order that they are listed.
[2003/03/28 22:51:57]<hezekiah> OK. :)
[2003/03/28 22:52:36]<hezekiah> That list really doesn't need a level 3 or 4 in my opinion.
[2003/03/28 22:53:30]<noP>  back
[2003/03/28 22:53:31]<noP>  sorry
[2003/03/28 22:53:39]<hezekiah> UserX: If you can send me a description of what needs to be done for the memory manager via email, then I'll work on that. :)
[2003/03/28 22:53:55]<noP>  mail.invisiblenet.net is down right now
[2003/03/28 22:53:57]<noP>  just for info
[2003/03/28 22:54:00]<noP>  dns issues
[2003/03/28 22:54:07]<hezekiah> Ah.
[2003/03/28 22:54:09]<noP>  I've moved over to more reliable dns service
[2003/03/28 22:54:13]<hezekiah> OK.
[2003/03/28 22:54:35]<hezekiah> Well, you can just email it to [email protected] , UserX. :)
[2003/03/28 22:54:48]<UserX>    ok
[2003/03/28 22:55:00]<hezekiah> OK.
[2003/03/28 22:55:08]<hezekiah> So Level 1 looks like this, right now:
[2003/03/28 22:55:27]<hezekiah> A. Finish loose ends with memory management and "core".
[2003/03/28 22:55:32]<hezekiah> B. VIRC
[2003/03/28 22:55:39]<hezekiah> C. network routing protocol
[2003/03/28 22:55:45]<hezekiah> D. node to node protocol
[2003/03/28 22:56:00]<hezekiah> E. channel protocol
[2003/03/28 22:56:01]<hezekiah> .
[2003/03/28 22:56:03]<noP>  email works now
[2003/03/28 22:56:05]<noP>  nevermind
[2003/03/28 22:56:07]<hezekiah> OK. :)
[2003/03/28 22:57:08]<hezekiah> Level 2 for A is:
[2003/03/28 22:57:14]<hezekiah> <UserX> memory/object management:  memory manager needs to be made aware of ObjectDescriptors
[2003/03/28 22:57:15]<hezekiah> <UserX> core:  system for tracking per core listen refs and node refs
[2003/03/28 22:57:15]<hezekiah> <UserX> core:  move relevant configuration options to the core
[2003/03/28 22:57:26]<hezekiah> And the partial begining list of level 2 for B is:
[2003/03/28 22:57:55]<hezekiah> <hezekiah> step 1: read rfc 1459 and look at 2810-2812
[2003/03/28 22:57:56]<hezekiah> <hezekiah> step 2: write protocol specs for virc -> IIP_PROTO
[2003/03/28 22:58:30]<hezekiah> Anyway, I suggest that we work on A (finishing the loose ends), then read over the RFC's for IRC.
[2003/03/28 22:59:12]<hezekiah> After that we can have another meeting and figure out how we are going to procede with VIRC (i.e. come up with Level's 2, (maybe 3), and 4).
[2003/03/28 22:59:27]<hezekiah> What do both of you think?
[2003/03/28 22:59:29]<hezekiah> :)
[2003/03/28 23:00:34]<noP>  should we have weekly meetings
[2003/03/28 23:00:36]<noP>  for this
[2003/03/28 23:00:38]<noP>  same time
[2003/03/28 23:00:39]<noP>  same channel
[2003/03/28 23:00:51]<noP>  then at least we will have something to announce at iip-dev
[2003/03/28 23:00:53]<noP>  ;)
[2003/03/28 23:00:56]<hezekiah> lol
[2003/03/28 23:01:24]<hezekiah> Well, I don't think we would really need them each week.
[2003/03/28 23:02:08]<hezekiah> Usually, when we are coding, I write code and then grab UserX or you (nop) when I have a question.
[2003/03/28 23:03:17]<hezekiah> If we have a problem in between, we could call for another meeting.
[2003/03/28 23:03:17]<UserX>    I would think the next step for VIRC after that is to implemtent with some minimal functionality
[2003/03/28 23:03:25]<noP>  userx
[2003/03/28 23:03:30]<noP>  do you still have that isproxy2.c file
[2003/03/28 23:03:33]<noP>  we had a while back
[2003/03/28 23:03:56]<noP>  because that was a mimimal start on the local virc
[2003/03/28 23:04:00]<hezekiah> It might have been a good idea to have a meeting when we dealt with that entropy bug. It would have been a LOT faster than going back and forth with all those emails. :)
[2003/03/28 23:04:08]<noP>  true
[2003/03/28 23:04:10]<UserX>    noP: probably
[2003/03/28 23:04:16]<noP>  if you can find it
[2003/03/28 23:04:19]<noP>  that might help
[2003/03/28 23:04:23]<noP>  it doesn't follow good code structure
[2003/03/28 23:04:25]<noP>  like we have set now
[2003/03/28 23:04:27]<noP>  but it's a start
[2003/03/28 23:04:28]<noP>  ;)
[2003/03/28 23:04:36]<hezekiah> We can always reformat. ;)
[2003/03/28 23:04:40]<noP>  yes
[2003/03/28 23:06:11]<hezekiah> OK ... so I move that the meeting adjurnes, we go work on finishing up the memory management and "core" stuff, then we read the IRC RFC's, and then we have another meeting after that.
[2003/03/28 23:06:25]<noP>  ok
[2003/03/28 23:06:27]<hezekiah> What say ye to my motion? Ayes? Nays? ;-)
[2003/03/28 23:06:29]<noP>  all in favor say I
[2003/03/28 23:06:37]<hezekiah> Aye/I
[2003/03/28 23:06:43]<noP>  Aye
[2003/03/28 23:07:05]<UserX>    aye
[2003/03/28 23:07:08]<noP>  ok
[2003/03/28 23:07:12]<noP>  see ya guys later
[2003/03/28 23:07:14]<hezekiah> Motion passed!
[2003/03/28 23:07:17]<hezekiah> Meeting adjurned!
[2003/03/28 23:07:22]<--    noP ([email protected]) has left #iip-future (noP)
[2003/03/28 23:07:26]*  hezekiah *baf*'s the 'baf'er!
[2003/03/28 23:07:30]<hezekiah> *baf*!
[2003/03/28 23:07:50]<hezekiah> It was nice to do this! I think it will at least help me get my bearings on development! :)
[2003/03/28 23:08:10]<hezekiah> I'll await your email on the memory management stuff, UserX. :)
[2003/03/28 23:08:33]<UserX>    hezekiah: ok
[2003/03/28 23:08:39]<hezekiah> It's not a major rush, because I still need to port over the entropy gather fix we made in head to development. ;)
[2003/03/28 23:08:43]<hezekiah> See you around. :)
[2003/03/28 23:08:53]<--    hezekiah ([email protected]) has left #iip-future (Bye!)
[2003/03/28 23:08:53]<UserX>    see ya
**** ENDING LOGGING AT Fri Mar 28 22:16:00 2003