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