--- 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: 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.webp. 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> Nunca lidei com isso antes. 18:54 <@hezekiah> Vou me preocupar com isso quando chegar lá. :) 18:54 < jrand0m> heh, verdade 18:55 < jrand0m> ok, as quatro coisas que eu queria que a gente cobrisse hoje: *router architecture, *modelo de desempenho, *análise de ataque, *psyc. Já fizemos a primeira, o thecrypto está offline então talvez a gente adie isso (a menos que você tenha opiniões sobre o modelo, nop?) 18:57 <@hezekiah> Hum … jrand0m. Tenho mais uma pergunta. 18:57 < jeremiah> jrand0m: onde está a versão mais recente da especificação da rede? é a que você enviou no dia 13? 18:57 < jrand0m> sim, senhor? 18:57 <@hezekiah> Bem, a arquitetura do router faz as APIs lidarem com chaves /enviadas a elas pelo Application/. 18:57 < jrand0m> jeremiah> sim 18:57 <@nop> Não neste momento 18:58 <@hezekiah> Agora … a única forma que vejo da API obter a chave é via createSession. 18:58 < jrand0m> hezekiah> o router recebe chaves públicas e assinaturas, não chaves privadas 18:58 < jrand0m> certo 18:58 <@hezekiah> Mas isso exige um arquivo. 18:58 < jrand0m> as chaves são armazenadas em um arquivo ou na memória da API 18:58 < jrand0m> sim 18:58 <@hezekiah> Agora, se a aplicação gerar uma chave, por que ela não pode simplesmente encaminhá-la para a API via um buffer? 18:59 <@hezekiah> Precisa mesmo armazená-la em um arquivo e depois fornecer o nome do arquivo? 18:59 < jrand0m> não, pode ficar em memória se você quiser 18:59 <@hezekiah> Não há função para fazer tudo isso na API, porém. 18:59 <@hezekiah> É só uma ideia. 19:00 <@hezekiah> Se a chave for para ser gerada apenas uma vez e usada muitas, muitas vezes (como chaves GPG), então um arquivo faz sentido. 19:00 -!- mihi [none@anon.iip] saiu [tchau pessoal, está ficando tarde…] 19:00 <@hezekiah> Mas se ela for gerada com mais frequência, então talvez alguma forma de enviá-la diretamente para a API por meio de uma estrutura ou algum tipo de buffer seria interessante 19:00 <@hezekiah> . 19:01 < jrand0m> sim, ela é gerada uma vez e apenas uma vez (a menos que você esteja usando um chapéu de alumínio) 19:02 < jrand0m> embora o createDestination(keyFileToSaveTo) permita criar essa chave 19:02 <@hezekiah> OK. 19:02 <@hezekiah> Então não há realmente necessidade de transferência direta do App para a API. Um arquivo será suficiente. 19:03 <@hezekiah> Então, onde estávamos antes de eu interromper tão rudemente? :) 19:06 < jeremiah> então, agora estamos trabalhando apenas na API do router, não na do cliente, certo? 19:06 < jrand0m> bem, vamos pular a análise de desempenho por enquanto (tomara que consigamos alguma conversa sobre isso na lista de discussão antes da próxima semana?). e provavelmente o mesmo com relação à análise de ataque (a menos que alguém tenha lido a nova spec e tenha comentários) 19:07 <@hezekiah> Então, já que estamos pulando isso, sobre o que devemos estar falando agora? 19:07 <@hezekiah> Psyc? 19:07 < jrand0m> a menos que mais alguém tenha outros comentários para trazer…? 19:08 <@hezekiah> Bem, pela primeira vez, meu buraco de comentários (também notoriamente conhecido como minha boca) está vazio. 19:08 < jrand0m> hehe 19:09 < jrand0m> ok, alguém tem alguma ideia de como o lado IRC das coisas vai funcionar e se o psyc pode ser relevante ou útil? 19:09 < jeremiah> observação (isso me irritou): a lista “Wired, Tired, Expired” da Wired colocou o Waste como “wired” 19:09 < jrand0m> heh 19:09 < jrand0m> você tem noção do quanto vamos deixar todo mundo de boca aberta? 19:09 < jeremiah> sim 19:09 <@hezekiah> jrand0m: Isso assume que a gente faça isso funcionar. 19:10 < jrand0m> Garanto que vai funcionar. 19:10 <@hezekiah> Há muitos outros esforços fracassados por aí. 19:10 < jrand0m> Eu larguei meu emprego para trabalhar nisso. 19:10 <@hezekiah> Então vamos deixar todo mundo de boca aberta. :) 19:10 <@hezekiah> É. Como você vai colocar comida na mesa fazendo isso? 19:10 <@hezekiah> Código GPL não paga bem. ;-) 19:10 < jrand0m> heh 19:11 <@hezekiah> Quanto ao psyc … deixe-me colocar desta forma: 19:11 <@hezekiah> A primeira vez que ouvi falar disso foi quando você nos enviou um e-mail sobre isso. 19:11 < jrand0m> merda, não fui eu que encontrei :) 19:11 <@hezekiah> No entanto, o IRC é provavelmente um dos (se não /o/ mais) protocolos de chat mais prolíficos por aí. 19:11 <@hezekiah> As pessoas vão querer apps de IRC MUITO antes mesmo de /saberem/ o que é psyc. 19:11 <@hezekiah> jrand0m: Opa. Desculpe. Esqueci desse detalhe. :) 19:12 < jrand0m> não de acordo com o psyc. a história deles remonta a 86, acho 19:12 <@hezekiah> A questão é que a superioridade do protocolo não é tão relevante quanto quem o usa. 19:12 <@hezekiah> A história deles pode ir tão longe. 19:12 <@hezekiah> Mas quantas pessoas usam Psyc? 19:12 < jeremiah> é, se eles existem desde um ano depois que eu nasci (aham) e ainda não são tão grandes assim 19:12 <@hezekiah> Meu ponto é que, mesmo que seja um protocolo melhor, a maioria das pessoas usa IRC. 19:13 <@hezekiah> Podemos fazer a melhor rede I2P do planeta … 19:13 -!- Ehud [logger@anon.iip] saiu [Ping timeout] 19:14 < jeremiah> alguém pode explicar rapidamente por que nos importamos? Eu achava que IRC seria apenas uma aplicação possível, mas que a rede é flexível para suportar psyc também, se quisesse 19:14 <@hezekiah> Certo. 19:14 <@hezekiah> Psyc pode ser feito … 19:14 <@hezekiah> … mas estou dizendo que deveríamos fazer IRC primeiro porque mais pessoas o usam.
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
parece que isso vai exigir muita largura de banda para um determinado usuário que pode estar num modem, e com a latência de enviar, digamos… 20 mensagens separadamente, isso acabaria com a conversa
19:21 < jeremiah> Não sei qual é a melhor solução, talvez essa fosse uma
19:22 < jeremiah> Acho que mensagens diretas seriam boas se você quisesse, mas há casos em que provavelmente não é tão importante
19:22 <@hezekiah> A mensagem precisaria ser assinada pela chave privada do autor para garantir a autenticidade.
19:22 <@hezekiah> Embora essa questão ainda não importe por bastante tempo, acho que o jeremiah tem um ponto
19:22 < jrand0m> hezekiah> isso exige usuários que queiram comunicação comprovável :)
19:23 < jrand0m> com certeza.
19:23 <@hezekiah> Se eu tivesse que enviar uma mensagem para 100 usuários em um canal …
19:23 < jeremiah> embora minha mensagem média tenha apenas algumas centenas de bytes, então enviá-la para centenas de usuários talvez não seja tão difícil
19:23 <@hezekiah> … bem, minha conversa seria /muito/ lenta.
19:23 < jeremiah> especialmente se você não esperasse por uma resposta
19:23 <@hezekiah> 20K para enviar uma mensagem.
19:23 <@hezekiah> Acho que não. :)
19:23 < jrand0m> bem, se há 100 usuários em um canal, alguém tem que enviar 100 mensagens
19:23 < jeremiah> são 20K?
19:23 < jeremiah> ah, é mesmo
19:23 <@hezekiah> 200 usuários
19:24 < jeremiah> hmm
19:24 < jeremiah> os routers não seriam bons nisso?
19:24 < jeremiah> podemos supor com alguma segurança que eles têm largura de banda decente, certo?
19:24 <@hezekiah> Eu pensei que cada pessoa tivesse uma ‘router implementation’
19:24 < jrand0m> Não exatamente. se houver retransmissores, o mecanismo de seleção precisa levar isso em consideração
19:24 < jrand0m> sim hezekiah
19:24 < jeremiah> eu não li a especificação
19:25 < jrand0m> um router é o seu router local
19:25 <@hezekiah> Ugh!
19:25 <@hezekiah> Ainda estou confundindo os seus nicks!
19:25 <@hezekiah> lol
19:25 < jrand0m> hehe
19:25 <@hezekiah> Hum … para onde foi o nop?
19:25 <@hezekiah> Ah.
19:26 <@hezekiah> Ele ainda está aqui.
19:26 <@hezekiah> Achei que ele tinha ido embora por um momento,
19:26 < jrand0m> mas o jeremiah está certo, o psyc tem algumas ideias que talvez queiramos considerar, embora talvez queiramos rejeitá-las
19:26 <@hezekiah> Vamos primeiro colocar a rede para funcionar.
19:26 * jrand0m brinda a isso
19:26 <@hezekiah> Se você esticar sua visão até a linha de chegada, vai tropeçar na pedra a 3 polegadas na sua frente.
19:27 * jeremiah se sente inspirado
19:27 <@hezekiah> lol
19:27 < jrand0m> Acho que seria realmente ótimo se pudéssemos mirar em revisar a especificação da rede até a próxima semana, enviando e-mails para iip-dev sempre que alguém tiver ideias ou comentários. estou fora de mim?
19:27 <@hezekiah> nop? Você tem mais alguma coisa para acrescentar à pauta, ou encerramos?
19:27 <@hezekiah> jrand0m: Bem, não sei se conseguiria ler tudo isso até a próxima semana, mas posso tentar. :)
19:27 < jrand0m> heh
19:28 < jrand0m> são extenuantes 15 páginas ;)
19:28 <@hezekiah> 15 páginas?
19:28 <@hezekiah> Parecia mais com 120!
19:29 < jrand0m> heh, bem, depende da sua resolução, eu acho ;)
19:29 < jeremiah> ele tem muitas âncoras lá, o que faz parecer que é enorme
19:29 < jrand0m> hehe
19:29 <@hezekiah> O lado esquerdo tem MUITO mais do que 15 links, cara!
19:29 <@hezekiah> Confessa!
19:29 <@hezekiah> É mais de 15. :)
19:29 <@hezekiah> Ah!
19:29 <@hezekiah> Aquelas não são páginas! São apenas âncoras!
19:29 <@hezekiah> Estou salvo!
19:30 * hezekiah se sente como um marinheiro recém-resgatado de um afogamento
19:30 < jeremiah> classe, virem para o volume 4 capítulo 2 Estrutura de Bytes da Mensagem
19:30 < jrand0m> lol
19:30 <@hezekiah> lol
19:30 <@nop> encerrar
19:30 <@hezekiah> baf!
19:30 <@hezekiah> Na próxima semana, 21:00 UTC, no mesmo lugar.
19:30 <@hezekiah> Vejo vocês lá. :)
19:30 < jeremiah> até mais — Registro encerrado Tue Jul 15 19:30:51 2003