336 lines
22 KiB
HTML
336 lines
22 KiB
HTML
{% extends "_layout.html" %}
|
|
{% block title %}I2P Development Meeting 71{% endblock %}
|
|
{% block content %}<h3>Tuesday, December 30, 2003 22:00:00 CET</h3>
|
|
<div class="irclog">
|
|
<p><jrandom> 0) hi</p>
|
|
<p><jrandom> 1) router status</p>
|
|
<p><jrandom> 2) i2ptunnel</p>
|
|
<p><jrandom> 3) im</p>
|
|
<p><jrandom> 4) 0.3 plans</p>
|
|
<p><jrandom> 5) time synchronization</p>
|
|
<p><jrandom> 6) ???</p>
|
|
<p><jrandom> hello mihi, polo</p>
|
|
<p><polo> hello !</p>
|
|
<p><mihi> hi jrandom</p>
|
|
<p><jrandom> 0) hi</p>
|
|
<p><jrandom> :)</p>
|
|
<p><rsk> hi</p>
|
|
<p><i2p> <duck> hi</p>
|
|
<p><jrandom> 1) router status</p>
|
|
<p><jrandom> 0.2.3.3 is out, and it seems to be working</p>
|
|
<p><jrandom> still lots to do, of course</p>
|
|
<p><jrandom> but this should be the last 0.2 release</p>
|
|
<p><jrandom> 0.3 is going to add the peer profiling to allow routers to avoid bad routers</p>
|
|
<p><jrandom> (and 0.3.1 is a revamp of the transports)</p>
|
|
<p><jrandom> hola Ophite1</p>
|
|
<p><Ophite1> Heya.</p>
|
|
<p><rsk> so more overhead for 0.3?</p>
|
|
<p><jrandom> yes and no</p>
|
|
<p><jrandom> it will have peer testing, but its going to be more focused</p>
|
|
<p><rsk> will we see a speed up with path selection?</p>
|
|
<p><jrandom> yes</p>
|
|
<p><jrandom> there are those 'liveliness' calculators, and there will be new latency and throughput calculators added</p>
|
|
<p><jrandom> plus people will be able to tweak their own preferences for particular peers</p>
|
|
<p><jrandom> e.g. if you know you want to prefer peer X over peer Y, you will be able to give them a weighting bonus of</p>
|
|
<p> some random points</p>
|
|
<p><mihi> will there be a clean shutdown? *g*</p>
|
|
<p><jrandom> thats actually a good question mihi</p>
|
|
<p><jrandom> i2p is getting to the point where it needs an admin interface.</p>
|
|
<p><jrandom> the longest Job thats holding up its operation is the GenerateStatusConsoleJob</p>
|
|
<p><jrandom> which can now take up to 4-6 seconds</p>
|
|
<p><jrandom> (holding everything else up)</p>
|
|
<p><jrandom> that needs to go async and on demand.</p>
|
|
<p><jrandom> but i dont want to write a web listener / etc.</p>
|
|
<p><jrandom> perhaps the reverse - a servlet that starts the router and communicates with it</p>
|
|
<p><mihi> you don't need a full web server. just when you see GET, return your data.</p>
|
|
<p><jrandom> right</p>
|
|
<p><jrandom> you're right, that stuff should be in 0.3 as well.</p>
|
|
<p><mihi> and when you see something else (like SHUTDOWN), do as you please. of course only from localhost ;)</p>
|
|
<p><jrandom> aww c'mon</p>
|
|
<p><mihi> then someone can make a nice admin program</p>
|
|
<p><jrandom> right</p>
|
|
<p><mihi> you had some triggers by files, didn't you? are they documented somewhere?</p>
|
|
<p>>>> mihi [~mihi@ags9-d9ba536a.pool.mediaWays.net] requested PING 1072820995 from jrandom</p>
|
|
<p><jrandom> those were in IDN, not the router itself</p>
|
|
<p><jrandom> but that might be a good way to go</p>
|
|
<p><jrandom> its a trivially easy system</p>
|
|
<p><jrandom> good idea, lets go that way</p>
|
|
<p><jrandom> (and i can just reuse that code :)</p>
|
|
<p><i2p> <duck> this magical filestuff starts to look like plan9</p>
|
|
<p><jrandom> lol</p>
|
|
<p><mihi> but file triggers require polling</p>
|
|
<p><jrandom> right mihi, reading a directory every 30s aint that bad</p>
|
|
<p><mihi> but a ServerSocket#accept is cheaper.</p>
|
|
<p><mihi> as it won't eat any time. (provided a good OS)</p>
|
|
<p><mihi> okay, file triggers are better than nothing, sure.</p>
|
|
<p><jrandom> server socket would allow remote admin</p>
|
|
<p><jrandom> (when appropriate)</p>
|
|
<p><jrandom> dunno.</p>
|
|
<p><jrandom> something to be worked out.</p>
|
|
<p><jrandom> (or if someone wants to jump on it and code... :)</p>
|
|
<p><mihi> and server socket could deliver the routerConsole as well.</p>
|
|
<p><jrandom> right</p>
|
|
<p><jrandom> ok, 2) i2ptunnel</p>
|
|
<p><jrandom> :)</p>
|
|
<p><jrandom> i2ptunnel still rules, and its looking like we want to add a socket based API to control it</p>
|
|
<p><i2p> <anon> aum's ic2cp2pc plans are off for now?</p>
|
|
<p><jrandom> yes, ci2cp is dead in the water, replaced with the socket based API to control I2PTunnel</p>
|
|
<p><jrandom> I think I may be able to throw on that API in the next few days, so he can get churning on the impl</p>
|
|
<p><mihi> just use a socket, make in.readLine() and feed that line to runCommand() ;)</p>
|
|
<p><rsk> what does the api give i2p?</p>
|
|
<p><jrandom> pretty much mihi (except it formats the results and send them back in a standard way)</p>
|
|
<p><mihi> with an appropriate "logger" to send the commands back.</p>
|
|
<p><mihi> s/commands/results/</p>
|
|
<p><jrandom> rsk> it lets application developers build client and server sockets over i2p without dealing with I2CP's</p>
|
|
<p> encryption needs</p>
|
|
<p><jrandom> right right</p>
|
|
<p><jrandom> i2ptunnel /does/ have an overhead for situations where there are lots of i2ptunnels</p>
|
|
<p><jrandom> regardless of the JVM</p>
|
|
<p><jrandom> i2ptunnel clients create a new destination per client contacted, and the router will perform much worse as</p>
|
|
<p> the number of local destinations grows.</p>
|
|
<p><rsk> ah</p>
|
|
<p><jrandom> this is due to the anonymity needs of the network tied to how our encryption works</p>
|
|
<p><jrandom> for applications who just want to open a tunnel or two to a peer, this new api will RULE</p>
|
|
<p><jrandom> but for applications that need to talk to lots of other peers, I2CP is the way to go.</p>
|
|
<p><jrandom> (since that is a single destination, multiplexed by i2cp)</p>
|
|
<p><jrandom> I suppose its the old TCP vs UDP balance, in a way</p>
|
|
<p><jrandom> mihi> do you have any thoughts, or some ideas for the future of i2ptunnel?</p>
|
|
<p><rsk> hows the work on the ip over i2p, or the vpn stuff going?</p>
|
|
<p><mihi> jrandom: someone write a good streaming api, and then lets i2ptunnel use it.</p>
|
|
<p><mihi> same for naming server.</p>
|
|
<p><mihi> perhaps add some sequence numbers if no one does the things above.</p>
|
|
<p><mihi> which will mean an incompatible change.</p>
|
|
<p><jrandom> incompatible changes aren't bad, we're early in dev</p>
|
|
<p><jrandom> (if we could increase the size of of the IDs too to two or four bytes per side as well?)</p>
|
|
<p><mihi> the streaming api will be an incompatible change nevertheless. and if i2p worked, we don't need sequence</p>
|
|
<p> numbers.</p>
|
|
<p><jrandom> rsk> on hold, until someone has time to run with it?</p>
|
|
<p>≡ rsk/#i2p thinks incompatible chages are the best kind</p>
|
|
<p><jrandom> right mihi</p>
|
|
<p><mihi> ID should be 3 byte atm, so why *increase* to 2 bytes?</p>
|
|
<p><jrandom> mihi> actually, I'd like to slowly deprecate mode=GUARANTEED and implement that in the streaming api</p>
|
|
<p>≡ mihi/#i2p too</p>
|
|
<p><jrandom> leaving i2p = IP, not TCP or UDP</p>
|
|
<p><jrandom> damnit I wish I had another 14 hours in the day.</p>
|
|
<p><mihi> only 14? ;)</p>
|
|
<p><jrandom> ;)</p>
|
|
<p><jrandom> aren't the 3 byte ids derived by both sides of the con? or maybe i'm just confused</p>
|
|
<p><mihi> each side has an ID of 3 bytes, hovever, only one must be sent at a time.</p>
|
|
<p><jrandom> perhaps I'll implement the streaming API, rip out GUARANTEED, and add that socket controller next.</p>
|
|
<p><jrandom> ah ok</p>
|
|
<p><mihi> see /apps/i2p/i2ptunnel/java/src/protocol.txt</p>
|
|
<p><jrandom> right right</p>
|
|
<p><mihi> btw, who misplaced that file *there*?</p>
|
|
<p>≡ jrandom blames eco ;)</p>
|
|
<p><jrandom> wait, naw, you put 'em there</p>
|
|
<p><jrandom> didnt you?</p>
|
|
<p><jrandom> oh wait, no I imported them</p>
|
|
<p>≡ jrandom blames self for being stupid.</p>
|
|
<p><jrandom> (la la la)</p>
|
|
<p><jrandom> damn. ok, yeah, working on the streaming API and the socket controller will allow me to mull over the peer</p>
|
|
<p> testing / profiling / selection manifesto</p>
|
|
<p><jrandom> I'll post that in a few days for comment</p>
|
|
<p><jrandom> (and it'll get my head out of the router. variety++)</p>
|
|
<p><jrandom> mihi> anything else on i2ptunnel?</p>
|
|
<p><mihi> not that i know</p>
|
|
<p><jrandom> coo'</p>
|
|
<p><jrandom> (thanks again for taking the time to chime in on this stuff, I know you're busy with fiw and the rest)</p>
|
|
<p><jrandom> ok, thecrypto isn't here, but he's making progress on the IM app.</p>
|
|
<p><jrandom> (thats agenda item 3)</p>
|
|
<p><jrandom> 4) 0.3 plans</p>
|
|
<p><jrandom> 0.3.0 ~= peer profiling stuff, and now it'll also include the streaming api and that socket controller for</p>
|
|
<p> i2ptunnel</p>
|
|
<p><jrandom> but, if you couldn't guess, its not going to be released on jan 1</p>
|
|
<p><jrandom> jan 15 is an outside possibility. we'll see how things go.</p>
|
|
<p><jrandom> 0.3.1 isn't a full month of work, so it may not need to get bumped.</p>
|
|
<p><jrandom> other than that, the roadmap is still pretty much on track and representative of where we're moving</p>
|
|
<p><jrandom> 5) time synchronization</p>
|
|
<p><jrandom> a new faq is posted at http://wiki.invisiblenet.net/iip-wiki?I2PTiming</p>
|
|
<p><jrandom> mihi, you had a suggestion about the fourth option there (building our own in-i2p timing)?</p>
|
|
<p><jrandom> hi brawl</p>
|
|
<p><mihi> yep.</p>
|
|
<p>∙φ∙ brawl is now known as eco_</p>
|
|
<p><eco_> hi guys</p>
|
|
<p><jrandom> oh heya eco</p>
|
|
<p><mihi> you should connect 3 random nodes and remember the diff between the avg time and local time.</p>
|
|
<p><jrandom> we just discussed the streaming API / tunnel api</p>
|
|
<p><mihi> and then hack up your own getTimeMillis that corrects that.</p>
|
|
<p><Ophite1> mihi: No, you shouldn't.</p>
|
|
<p><jrandom> mihi> so if an attacker creates 1000 nodes with the wrong time, everyone gets screwed</p>
|
|
<p><jrandom> (since avg would skew randomly in between)</p>
|
|
<p><mihi> if an attacker creates 1000 nodes, everyone gets screwed anyway...?</p>
|
|
<p><rsk> wouldnt that be self corecting?</p>
|
|
<p><Ophite1> mihi: OK, 3.</p>
|
|
<p><jrandom> no, we should be able to handle that mihi.</p>
|
|
<p><mihi> okay, then only use avg, if standard deviation is lower than 1sec or so.</p>
|
|
<p><rsk> if everyone has the same time your ok, even if that time is wrong, right?</p>
|
|
<p><jrandom> rsk> if all 1000 nodes were in sync, but what if they're all random</p>
|
|
<p><mihi> only use times that are close enough together. if not, take 3 new nodes.</p>
|
|
<p><jrandom> mihi> right, we could implement NTP (which basically does what you say, using a series of candidate averages</p>
|
|
<p> to iteratively close in on the correct time</p>
|
|
<p><mihi> but we need not care of everything (like ping latencies), as ntp does.</p>
|
|
<p><Ophite1> if we did not, mihi, time would slowly creep backwards.</p>
|
|
<p>≡ mihi/#i2p thinks that is better than let users set their time individually.</p>
|
|
<p><jrandom> so anyone who randomly picks 3 of those skewed nodes gets sent onto their own private network?</p>
|
|
<p><jrandom> what about that third option -</p>
|
|
<p><jrandom> i2p has a component that checks with a real NTP server via NTP or SNTP</p>
|
|
<p><mihi> if you have only skewed notes in your netDB, you are on that private net as well...</p>
|
|
<p><jrandom> rather than reimplementing the wheel</p>
|
|
<p><Ophite1> while I partially like that one...</p>
|
|
<p><Ophite1> NTP isn't signed, it's subject to an MITM attack.</p>
|
|
<p><Ophite1> or dns cache poisoning for, say, time.nist.gov</p>
|
|
<p><jrandom> right Ophite1, though with 200,000+ SNTP or NTP hosts, thats a large set to attack.</p>
|
|
<p><jrandom> we would definitely not sync of time.nist.gov.</p>
|
|
<p><Ophite1> connections from i2p to the NSA's time server might raise a few eyebrows, ne? :)</p>
|
|
<p><jrandom> and if an attacker goes after time.nist.gov, everyone everywhere is affected</p>
|
|
<p><jrandom> heh</p>
|
|
<p><mihi> then we combine both. ask a "real" ntp server and your neighbor. if both say the same, it's okay.</p>
|
|
<p><jrandom> so even /more/ code ;)</p>
|
|
<p><jrandom> but yeah, thats reasonable.</p>
|
|
<p><Ophite1> That's interesting. And if they don't?</p>
|
|
<p><Ophite1> pick another ntp server?</p>
|
|
<p><jrandom> refuse the peer.</p>
|
|
<p><mihi> try other ntp server and another peer.</p>
|
|
<p><mihi> until you have a match. then refuse all prev peers.</p>
|
|
<p>≡ mihi/#i2p types slower than jrandom :(</p>
|
|
<p><Ophite1> match within a certain threshold, say 1sec?</p>
|
|
<p><jrandom> 1s would be good.</p>
|
|
<p><jrandom> accepting peers up to 30s or so (to deal with lag)</p>
|
|
<p><Ophite1> is 1 sec okay on HEAVILY LADEN connections?</p>
|
|
<p><jrandom> 1s for syncing, 30s for comm.</p>
|
|
<p><Ophite1> I've seen latency on DSL get to 5 seconds when doing evil things to it.</p>
|
|
<p><jrandom> with tcp or udp?</p>
|
|
<p><Ophite1> but then, in that case, that host might not be the one you want to sync time to anyway ;)</p>
|
|
<p><jrandom> right</p>
|
|
<p><Ophite1> udp.</p>
|
|
<p><jrandom> hmm 'k</p>
|
|
<p><Ophite1> you'd have thought it'd get dropped :)</p>
|
|
<p><i2p> <duck> I think that the problem is more letting the user know that there is a problem</p>
|
|
<p><jrandom> duck> that is true.</p>
|
|
<p><i2p> <duck> only after walking through big logs they see that their clock is off (if they find it)</p>
|
|
<p><Ophite1> Maybe. Sort of.</p>
|
|
<p><i2p> <duck> or that the port is already bound</p>
|
|
<p><jrandom> an admin interface would be nice.</p>
|
|
<p><i2p> <duck> the world is better with everybody using NTP connected to their local stantrum (sp) 2 server</p>
|
|
<p>CTCP Cloaking is now [On]</p>
|
|
<p><jrandom> perhaps we'll have a 0.4 release with a bunch of cleanups and end user things, prior to going 1.0?</p>
|
|
<p><jrandom> right (stratum)</p>
|
|
<p><i2p> <duck> only windows clients are not likely to have that</p>
|
|
<p><i2p> <duck> but they are also not likely to be stable</p>
|
|
<p><jrandom> windows has NTP</p>
|
|
<p><i2p> <duck> so who cares</p>
|
|
<p><Ophite1> duck: Windows XP and Windows Server 2003 include NTP.</p>
|
|
<p><jrandom> a shitload easier than with unix too</p>
|
|
<p><Ophite1> sync'ed by default to time.windows.com iirc.</p>
|
|
<p><jrandom> with drop down options for others</p>
|
|
<p><Ophite1> It's an essential part of Windows Product Activation.</p>
|
|
<p><Ophite1> can't expire if you don't know the time :)</p>
|
|
<p><jrandom> heh</p>
|
|
<p><mihi> no option at my university... all clocks are 1 hour to 5 hours off. but i might not be allowed to run i2p there</p>
|
|
<p> anyway...</p>
|
|
<p><Ophite1> mihi: i2p should try especially hard to work in such a situation...</p>
|
|
<p><jrandom> mihi> awesome! you can help test out the hidden operation :)</p>
|
|
<p><jrandom> as an aside, I'm going to be doing some traveling this summer</p>
|
|
<p><jrandom> i'll likely be offline, without my laptop.</p>
|
|
<p><i2p> <duck> sidethought: ntp.duck.i2p :)</p>
|
|
<p><Ophite1> Look at it like this: Brianna Kazaa downloads cool new anonymous filesharing client which her best friend</p>
|
|
<p> told her was really cool and lets you chat to people secretly and stuff. Do we want to tell her that she</p>
|
|
<p> needs to set her clock within 30 seconds (how will she get some?)? Or do we want it to just work?</p>
|
|
<p><jrandom> but I'm going to make sure I can still be on I2P with just public terminals.</p>
|
|
<p>CTCP Cloaking is now [Off]</p>
|
|
<p><jrandom> no brainer Ophite1. just work (with docs for geeks)</p>
|
|
<p><jrandom> duck> bootstrap ;)</p>
|
|
<p><jrandom> and i2p will /not/ require root.</p>
|
|
<p><Ophite1> That's my point.</p>
|
|
<p><Ophite1> jrandom: would you run a router on a box you didn't have root to?</p>
|
|
<p><jrandom> so yeah, a mix between option 3 and 4</p>
|
|
<p><Ophite1> option 3.5 sounds cool to me ;)</p>
|
|
<p><jrandom> Ophite1> i'd run a hundred of them :)</p>
|
|
<p><mihi> option 3.1415926...</p>
|
|
<p><jrandom> (and move on to the next lab, run a hundred more)</p>
|
|
<p><Ophite1> Ooh. Pie. Tasty.;)</p>
|
|
<p><Ophite1> jrandom: I said you didn't have root on. Amateur. :)</p>
|
|
<p><jrandom> lol</p>
|
|
<p><jrandom> so thats basically where we're looking.</p>
|
|
<p><jrandom> until the time stuff is implemented, everyone should use option 1 or 2.</p>
|
|
<p><jrandom> for option 2, if someone could write up some docs, I'd appreciate it</p>
|
|
<p><Ophite1> that's acceptable for now as we are Not Yet Ready for Brianna Kazaa et al ;)</p>
|
|
<p><mihi> jftr: i won't test "hidden operation". my univ account has already been disabled once and i don't want it</p>
|
|
<p> another time blocked...</p>
|
|
<p><Ophite1> mihi: You are the best test we could possibly have.</p>
|
|
<p><jrandom> Ophite1 > not for test.</p>
|
|
<p><jrandom> 'k mihi, we'll find a way, and once its ready you'll be able to use it.</p>
|
|
<p><Ophite1> OK, maybe not test. Some unis get shirty enough to chuck you out rather than just block you.</p>
|
|
<p><Ophite1> I know someone at the most anti-filesharing pro-RIAA university in the USA. He runs a 2gbit dumpsite.</p>
|
|
<p><jrandom> lol nice</p>
|
|
<p><Ophite1> I appreciate that very, very few people are this ballsy.</p>
|
|
<p><jrandom> ok, thats it for time synchronization.</p>
|
|
<p><jrandom> eco_> hi. any bt stuff you want to talk about? {or save till next week}</p>
|
|
<p><Ophite1> but bear in mind the majority of the internet is in future probably going to become university/corporate.</p>
|
|
<p> i2p might be banned. i2p might WELL be considered abuse by major ISPs. i2p will have to work anyway.</p>
|
|
<p><Ophite1> I have a few interesting ideas along that angle I will present at a future date.</p>
|
|
<p><jrandom> word</p>
|
|
<p><Ophite1> (transport)</p>
|
|
<p><rsk> i2p is considered abuse by major ISPs, read your contract</p>
|
|
<p><Ophite1> rsk: running a distributed proxy cache?</p>
|
|
<p><rsk> running any 'server'</p>
|
|
<p><Ophite1> rsk: Not unless it relays to SMTP or WWW.</p>
|
|
<p><jrandom> running services of any time</p>
|
|
<p><jrandom> right</p>
|
|
<p><Ophite1> rsk: Hehe, I have a solution to that ;)</p>
|
|
<p><eco_> jrandom: can give a brief update</p>
|
|
<p><jrandom> floor is yours :)</p>
|
|
<p><eco_> i'm porting the java-based bittorrent client snark (www.klomp.org/snark) to get aquainted with i2p</p>
|
|
<p><eco_> first port runs on top of i2ptunnel, directly calling the java classes</p>
|
|
<p><eco_> current state: does work with 2 peers, things get messed up with > 2, tunnels aren't cleaned up, so restarting</p>
|
|
<p> is painful</p>
|
|
<p><eco_> eta: this weekend</p>
|
|
<p>≡ eco_/#i2p realises that this might be considered > 2003</p>
|
|
<p><jrandom> w00t!</p>
|
|
<p>≡ jrandom hacks time.nist.gov</p>
|
|
<p><eco_> a "real" port would probably cut the overhead of the tunnels, but that's a next step</p>
|
|
<p><jrandom> cool</p>
|
|
<p>≡ eco_/#i2p gives floor back to mc jrandom</p>
|
|
<p><jrandom> 'k, I think that was it</p>
|
|
<p><jrandom> 6) ???</p>
|
|
<p><jrandom> anyone have anything else?</p>
|
|
<p>≡ eco_/#i2p would like to express his thanks for the job well done by jrandom cs up to now</p>
|
|
<p><eco_> and that sleep has some use for home sapiens, though jrandom seems to prove this false</p>
|
|
<p><jrandom> ;)</p>
|
|
<p><jrandom> what are y'all's thoughts on meeting here as opposed to iip, until i2p is reliable enough?</p>
|
|
<p><jrandom> personally, I'm tired of meetings being cut to shreds every week.</p>
|
|
<p><i2p> <anon> lilo sucks!</p>
|
|
<p><eco_> we might be shutting people out by going here</p>
|
|
<p><jrandom> we are, I know.</p>
|
|
<p><jrandom> if we can get an iip<-->here bridge</p>
|
|
<p><i2p> <duck> IIP is shutting ppl out each day</p>
|
|
<p><jrandom> that'd be good.</p>
|
|
<p><jrandom> right.</p>
|
|
<p><jrandom> iip is, unfortunately, unusable for a reliable development community.</p>
|
|
<p><i2p> <duck> http://banaan.zeelandnet.nl/open/changate.html</p>
|
|
<p><i2p> <duck> that is the code where eyeKon etc is based on</p>
|
|
<p><jrandom> and while I like to go off coding on my own, y'all come up with really good ideas and do good stuff that is</p>
|
|
<p> essential</p>
|
|
<p>≡ rsk/#i2p is writing a windows update script</p>
|
|
<p><i2p> <duck> theoretically it could connect to 3 servers and mirror each of them</p>
|
|
<p><jrandom> word duck, perhaps I'll try to get one running on i2p.dnsalias.net</p>
|
|
<p><jrandom> ping flood from hell ;)</p>
|
|
<p><eco_> irc at duck.i2p was pretty good today, beat iip</p>
|
|
<p><jrandom> agreed</p>
|
|
<p><jrandom> dropped me a few times though.</p>
|
|
<p><jrandom> perhaps it'll be more reliable next week</p>
|
|
<p><eco_> it's in your hands :-)</p>
|
|
<p><jrandom> reliability probably won't improve until 0.3, which is ~2 weeks out</p>
|
|
<p><jrandom> (1 week to do the tunnel/streaming stuff, 1 week for peer profiling / testing)</p>
|
|
<p><jrandom> then there'll be whatever bugs that introduces :)</p>
|
|
<p><jrandom> though I should say I was really excited to stream audio from aum last night</p>
|
|
<p><jrandom> and ardvark was able to stream for 42 minutes without buffering!</p>
|
|
<p><jrandom> so perhaps we can be reliable enough</p>
|
|
<p><jrandom> (my local router is phttp only, which is probably a slight cause)</p>
|
|
<p><jrandom> ok, anyone have anything else?</p>
|
|
<p><i2p> <duck> cant thing of anything</p>
|
|
<p>≡ eco_/#i2p can't either</p>
|
|
<p>≡ jrandom winds up...</p>
|
|
<p>≡ jrandom *baf*s the meeting closed</p>
|
|
</div>
|
|
{% endblock %} |