743 lines
37 KiB
HTML
743 lines
37 KiB
HTML
<pre>
|
|
--- 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
|
|
</pre> |