Setkání vývojářů I2P - 18. října 2005

16:10 <jrandom> 0) ahoj 16:10 <jrandom> 1) 0.6.1.3 16:10 <jrandom> 2) Freenet, I2P a darknety (ó jé) 16:10 <jrandom> 3) Tunnel bootstrap attacks 16:10 <jrandom> 4) I2Phex 16:10 <jrandom> 5) Syndie/Sucker 16:10 <jrandom> 6) ??? 16:10 <jrandom> 0) ahoj 16:10 * jrandom mává 16:10 <jrandom> týdenní poznámky o stavu jsou na http://dev.i2p.net/pipermail/i2p/2005-October/001017.html 16:10 <dust> jupí, už to funguje. díky, Gregore 16:10 <cervantes> čauky 16:11 <+fox> <blx> heloa 16:11 <jrandom> ok, pojďme na 1) 0.6.1.3 16:11 <jrandom> všichni jste aktualizovali docela svižně, díky! 16:12 <jrandom> věci vypadají v rozumném stavu, ale nemám moc co dodat nad to, co je v poznámkách o stavu 16:12 <jrandom> má někdo dotazy/připomínky/obavy ohledně 0.6.1.3? 16:13 <jrandom> dobře, pokud ne, skočme na 2) Freenet, I2P a darknety (ó jé) 16:13 <cervantes> 609 známých peerů! 16:14 <cervantes> (w00t) 16:14 <jrandom> jo, síť roste 16:14 <+fox> <blx> ó jé! 16:14 * cervantes pořádá tipovačku, za jak dlouho padne tisícovka 16:14 <jrandom> heh 16:14 <tethra> heheh 16:15 <tethra> sázíme digitální hotovostí? ;) 16:15 <cervantes> ale ukazuje to, jak je jádro I2P poslední dobou pevné, když adopce uživatelů zrychluje 16:16 <cervantes> kdepak...jrandom už nevědomky věnoval všechny své letošní pivní peníze 16:16 <jrandom> hehe 16:16 <jrandom> ok, k bodu 2), nejsem si jistý, že mám ještě co dodat (myslím, že jsme toho koně už zmlátili). Má někdo dotazy/připomínky/obavy? 16:18 <cervantes> jak jsi řekl, když nic jiného, vyprovokovalo to pár zajímavých, částečně souvisejících debat o bezpečnosti, tj. 3) 16:18 <jrandom> pokud ne, můžeme svižně přejít k 3) Tunnel bootstrap attacks 16:18 <jrandom> jo, to ano 16:19 <jrandom> problém, který Michael nastolil, kvantifikuje obecný názor, který jsem měl, a je fajn to udělat explicitně 16:20 <jrandom> později večer bude další diskuse o novějším útoku (až stihnu sepsat odpověď), ale ten první nevypadá jako velký problém 16:21 <jrandom> dává to lidem smysl, nebo máte k tomu dotazy či obavy? 16:22 <cervantes> heh... to buď znamená, že s tím všichni v pohodě souhlasí, nebo se v tom vůbec nevyznají 16:23 <cervantes> zařadím se do kategorie „nevědomost je blaženost“ 16:23 <jrandom> heh, v podstatě je to útok, kdy zlí hoši náhodou jsou odchozím koncovým bodem každého tunnel, který jsi kdy postavil 16:23 <jrandom> když ale teprve startuješ, „každý tunnel, který jsi kdy postavil“ je velmi malé číslo (např. 0, 1, 2) 16:24 <jrandom> ale po pár sekundách to číslo naroste dost na to, aby se (c/n)^t změnilo v opravdu hodně malé číslo 16:25 <tethra> (c/n)^t je... 16:25 <jrandom> (tohle je jeden z důvodů, proč nespouštíme i2cp listener – a tedy i i2ptunnel/apod. – hned, ale až chvíli po startu) 16:25 <jrandom> c == počet spolupracujících peerů (zlí hoši), n == počet peerů v síti, t == počet tunnels, které jsi postavil. 16:25 <cervantes> jasně... 16:25 <tethra> ah 16:26 <jrandom> takže jak t roste, pravděpodobnost úspěšného útoku hodně klesá 16:26 <cervantes> takže aby to vůbec bylo reálné, musel bys začít používat svůj router pro citlivé úlohy během pár minut po startu? 16:26 <jrandom> (nebo v každém případě menší než pravděpodobnost ovládnutí všech hopů v jednom tunnel) 16:26 <tethra> ahh, chápu 16:27 <jrandom> cervantes: hned, než se postaví 3. tunnel 16:27 <jrandom> (za předpokladu, že používáš 3-hop tunnels) 16:27 <cervantes> to je dost nepravděpodobné 16:28 <cervantes> už jen z pohledu způsobu použití 16:28 <jrandom> přesně tak. 16:28 <jrandom> a jelikož při startu stavíme víc než 3 tunnels, než pustíme jakékoliv klienty, není to jen otázka pravděpodobnosti 16:28 <jrandom> ale i tak je dobré ten útok kvantifikovat 16:29 <cervantes> stojí za to nechat router šlapat o něco déle, abychom se pojistili proti jakékoliv pravděpodobnosti? 16:30 <cervantes> nebo šlapat ještě víc... 16:30 <jrandom> možná. pokud budeme ignorovat čas navázání spojení i nenáhodný výběr peerů, pravděpodobnost je nulová 16:31 <tethra> to je důvod k „woot!“ chápu to správně? 16:32 <jrandom> jo, ale z inženýrského pohledu bychom ty vlastnosti ignorovat neměli ;) 16:32 <jrandom> takže pro 0.6.2 se na to možná podíváme během předělané implementace výběru/řazení peers pro tunnel, abychom se ujistili, že se to chová Rozumně 16:34 <jrandom> OK, pokud nic dalšího k 3), přesuňme se k 4) I2Phex 16:34 <jrandom> sirup tu není a striker(a) jsem na IRC neviděl – redzara, jsi tu? 16:36 <+redzara> ano 16:36 <+redzara> První průchod je téměř hotový: port Sirupova modu na nejnovější Phex CVS. 16:36 <jrandom> paráda! 16:36 <+redzara> dál: Druhý průchod: diff mezi Sirupovým kódem a základním Phex kódem použitým v počátečním vydání, abych si byl jistý, že na nic nezapomenu :) 16:37 <+redzara> možná hotovo o tomhle víkendu 16:37 <jrandom> wow, to by bylo skvělé 16:37 <+redzara> Třetí průchod: refaktor komunikační vrstvy s GregorK 16:37 <+fox> <GregorK> doufám, že víš, že v posledním Phex CVS není download kód stabilní a soubor stahování není kompatibilní s předchozími vydáními 16:38 <jrandom> tady je I2P, na nestabilitu jsme zvyklí :) 16:38 <+fox> <GregorK> :) 16:38 <+redzara> Poslední průchod bude dost těžký, protože teď nemám kontakt na GregorK :( 16:38 <jrandom> GregorK: co bys doporučil pro integraci? 16:39 <+fox> <GregorK> no, teď kontakt na mě máš ;) 16:39 <jrandom> ah jo, redzara, ty první dva jsou beztak dost velké :) 16:39 <+redzara> GregorK: čau chlape 16:40 <+redzara> GregorK: pečlivě jsem si přečetl všechny kódy 16:40 <+fox> <GregorK> mám nápad, jak postavit vrstvu... můžu se to pokusit připravit co nejlépe a pak uvidíme, jak to sedí a co je třeba změnit 16:40 <+fox> <GregorK> všechny?? páni... 16:40 <+redzara> Gregork: ano, všechny!! 16:41 <cervantes> on dokonce zná velikost tvého spodního prádla 16:41 <Rawn> :D 16:41 <+fox> <GregorK> skvělé... příště při nákupu se prostě zeptám tebe... 16:43 <+fox> <GregorK> bylo by fajn, kdyby někdo z týmu I2Phex mohl být i v týmu Phex.. 16:43 <jrandom> redzara: myslíš, že budeme mít vydání I2Phex 0.1.2 s výsledky tvého druhého průchodu ještě předtím, než všechno sloučíme do plugin vrstvy v mainline Phexu? Nebo to bude najednou? 16:43 <+redzara> Promiň, ale anglicky dostatečně nerozumím/nemluvím/nečtu/nepíšu, abych se zasmál tomu, co jsi napsal 16:43 <+fox> <GregorK> to by také pomohlo řešit chyby, které jsou na obou stranách 16:44 <jrandom> GregorK: doufejme ale, že najdeme způsob, jak mít I2P část jen jako tenký plugin v Phexu, že? 16:44 <jrandom> nebo myslíš, že by měly zůstat oddělené? 16:44 <+redzara> jrandom: myslím, že bychom mohli mít Phex 2.6.4 přes I2P, pro mě je I2Phex u konce 16:45 <jrandom> u konce? 16:45 <+fox> <GregorK> nejsem si jistý, že to takhle zvládneme hned od začátku, ale myslím, že většinu lze oddělit do pluginu. 16:45 <jrandom> super, jo, je to spousta práce, to určitě 16:46 <jrandom> zvlášť když se podíváš na věci jako java.net.URL (která při vytvoření objektu uniká DNS dotazy atd.) 16:46 <+redzara> jrandom: u konce, skončeno 16:46 <+Ragnarok> grr 16:47 <jrandom> ok, jasně, redzara, jakmile všechno rozběháme v Phex 2.6.4 přes I2P, souhlasím, že pro I2Phex nebude moc důvod 16:47 <+fox> <GregorK> správně... myslím, že Phex na některých místech používá Apache URI třídu jako workaround... ale jen když je to nutné 16:48 <jrandom> aha, jo, vzpomínám, že jsem si s tou knihovnou hrál, vypadá dobře 16:49 <jrandom> určitě pomůžeme s auditem anonymita/bezpečnost, než to doporučíme koncovým uživatelům přes i2p 16:49 <jrandom> (ne že bych tím naznačoval problémy v Phexu, jen problémy jsou v každé appce a snad pomůžeme je vychytat) 16:50 <+fox> <GregorK> u některých věcí jako použití Socket a podobně mám nápad, jak to hladce integrovat... ale jinde, u různých UDP feature a tak... ještě nevím, jak to nejlépe vyřešit 16:50 <+fox> <GregorK> o, jsem si jistý, že v Phexu je spousta problémů. :) 16:50 <jrandom> aha, jo, sockets budou snadné, ale možná budeme muset jiné věci vypnout. Na co se používá UDP – rychlé dotazy? 16:51 <+fox> <GregorK> aktuálně jen bootstrapping 16:51 <+fox> <GregorK> UDP Host Cache... náhrada za GWebCache 16:52 <jrandom> ahhh, ok. 16:52 <+redzara> Takže to nepotřebujeme, pokud máme slušný GWebCache? 16:53 <+fox> <GregorK> ano... ale standardní GWebCache má taky své bezpečnostní problémy... 16:53 <+redzara> GregorK: v rámci I2P myslím ne 16:54 <jrandom> aha, tohle lze obejít – I2PSocket je autentizovaný – znáš ‚destination‘ peeru na druhém konci, takže nemůžou říct „Já jsem, ehm... whitehouse.gov.. jasně!“ 16:54 <jrandom> ale máš pravdu, je to něco, co je třeba ověřit 16:54 <+fox> <GregorK> také firewall‑to‑firewall přenosy by byly UDP téma, které bychom rádi implementovali, jakmile se najde dobrovolník :) 16:54 <jrandom> aha, no, I2P nepotřebuje firewall‑to‑firewall přenosy – I2P vystavuje plně otevřený end‑to‑end adresní prostor :) 16:55 <jrandom> ale... ooh, to by mohlo být užitečné 16:55 <jrandom> kdyby měli uživatelé Phexu „0 hop tunnels“, dostali by NAT traversal/firewall‑to‑firewall přenosy zdarma, a to docela rychle 16:55 <+fox> <GregorK> další by byly LAN broadcasty dotazů a podobně... pro snadnější sdílení obsahu v privátních sítích 16:56 <jrandom> (0 hop tunnels nabízejí jistou míru věrohodné popiratelnosti, aniž by bylo nutné, aby provoz nesli prostřední peers) 16:57 <jrandom> hmm, LAN broadcast je fajn, ale nejsem si jistý, že by to I2P opravdu potřebovalo (je to riziko pro anonymitu vědět, kde ten druhý peer je :), takže tuhle funkci by možná šlo při použití I2P pluginu vypnout? 16:58 <cervantes> *ve výchozím stavu vypnuto 16:58 <+fox> <GregorK> no, zatím to není k dispozici... ale v tomhle případě se uživatelé obvykle stejně znají, aby si tu privátní síť vybudovali.. 16:58 <jrandom> jo, jasně, cervantesi 16:58 <jrandom> jasně jasně, GregorK 16:59 <+fox> <GregorK> jsou nějaké změny týkající se uživatelského rozhraní?? 17:00 <+bar> no, nebudeme potřebovat vlajky :) 17:00 <jrandom> minimálně by se hodila možnost pár konfiguračních voleb souvisejících s I2P. 17:01 <jrandom> myslím, že sirup dokázal přepnout část zobrazení tak, aby používala I2P ‚destinations‘ místo zobrazení IP + portu, takže myslím, že to bylo v pohodě 17:01 <+redzara> A co bitzy—Zatím nic, ale vlajky a země se nepoužívají 17:01 <jrandom> bitzy? 17:01 <+redzara> sorry, špatné copy/paste :( 17:02 <+fox> <GregorK> můžeš poskytnout seznam konfiguračních voleb a volitelných funkcí, které potřebujete? 17:03 <jrandom> jsem si jistý, že ti to dodáme. host+port, na kterém běží I2P, a pár rolet pro nastavení výkon/anonymita by mělo stačit 17:03 <jrandom> pošleme ti podrobnosti 17:02 <cervantes> [x] Super rychlý režim přenosu 17:02 <+fox> <GregorK> no, Bitzi se používá k identifikaci souborů... je to problém pro anonymitu? 17:03 <vulpine> <redzara> GregorK: připravuju to, ale v zásadě nejsou žádné změny 17:03 <+fox> <GregorK> :) zeptej se svého providera, cervantesi... 17:03 <redzara> GregorK: možná, pracuju na tom 17:04 <cervantes> GregorK: heh, obyvatel UK... bez šance ;-) 17:04 <+fox> <GregorK> když přenášíš soubory mezi 2 instancemi Phexu na tom samém PC... přenosy jsou bleskové ;) 17:05 <cervantes> super... mám spoustu skvělých filmů, o které se můžu podělit sám se sebou :) 17:05 <cervantes> * vyškrtněte to ze zápisu ze schůzky * 17:06 <bar> jrandom už to nakousl, ale tady je ten bláznivý nápad znovu: 17:06 <+bar> co takhle integrovat I2P přímo do Phexu, aby běžní uživatelé měli 0‑hop tunnels? 17:07 <+fox> <GregorK> myslím, že zobrazení vlajek a IP+port pochází z objektu HostAddress... který by nová vrstva skryla... takže můžeš zobrazit něco jiného 17:07 <+bar> (kvůli věrohodné popiratelnosti a UDP firewall hole punching) 17:08 <+fox> <GregorK> nejsem si jistý, jestli tomu opravdu rozumím ;) 17:08 <+bar> asi ani já ne ;) 17:09 <jrandom> GregorK: v podstatě to znamená, že uživatelé Phexu by spolu mluvili přímo, ale měli by věrohodnou popiratelnost, protože by mohli mluvit nepřímo 17:09 <+bar> jrandom, myslím, že chápeš, co tím myslím, mohl bys to rozvést? 17:09 <jrandom> také by k tomu zdarma dostali NAT traversal I2P, plus bezpečnost dat a ochranu před sniffingem od ISP atd. 17:09 <+redzara> GregorK: takže musíš odstranit veškerý kód související s host+port + IsLocalIP + IsPrivateIP + ... 17:10 <jrandom> na druhou stranu (VELKOU druhou stranu) by to neumělo mluvit s gnutella klienty, kteří neběží nad I2P 17:10 <jrandom> (i když nakonec budou všichni ;) 17:10 <+fox> <GregorK> Myslím, že prvním krokem – a ten je už sám o sobě dost velký – je přiblížit I2P a Phex k sobě. 17:10 <jrandom> souhlas 17:10 <+bar> (sakra, to mě nenapadlo) 17:11 <+bar> jo, rozhodně. 17:11 <jrandom> tohle je „létající poník“. Pojďme nejdřív na praktické věci 17:11 <+fox> <GregorK> a až uvidíme, jak to fungovalo, můžeme rozhodnout, jak dál.. 17:11 <jrandom> přesně tak 17:12 <+fox> <GregorK> redzara: rád bych měl dvě implementace HostAddress, jednu pro I2P a jednu jako je ta současná. 17:14 <+redzara> Gregork: žádný problém, v mém modu jsem okomentoval všechen kód, takže můžeš snadno udělat dvě implementace. Jen mě prosím nech dodělat úvodní práci 17:14 <+fox> <GregorK> jasně.. žádný problém.. 17:14 <jrandom> :) OK, takže redzara, myslíš, že bychom mohli mít alfa test nové verze založené na Phex‑2.4.2 někdy příští týden? 17:15 <jrandom> (pro část fáze 2. tvoje fáze 3 si vyžádá víc práce při integraci do mainline) 17:15 <+redzara> jrandom: příští se mi zdá OK 17:16 <jrandom> OK, skvělé 17:16 <+redzara> s/next/next week/ 17:16 <jrandom> OK, tohle je docela vzrušující, bude skvělé, když to rozběhne hladce 17:17 <jrandom> má někdo ještě něco k 4) I2Phex, nebo se krátce posuneme k 5) Syndie/Sucker? 17:17 <cervantes> I2P určitě získá z takových killer apps 17:18 <+fox> <GregorK> mimochodem existuje Phex CVS mailing list pro všechny CVS změny v Phexu... jestli to pomůže 17:18 <jnymo> *ehm*... sakra jo 17:18 <jrandom> OK, super, díky, GregorK 17:18 <jrandom> rozhodně, cervantesi 17:19 <jrandom> OK, k bodu 5), nemám moc co dodat nad to, co už je 17:19 <jrandom> dust: jsi nablízku? 17:19 <+redzara> GregorK: Díky, ale spravovat jednu verzi je pro mě až až :) 17:19 <jrandom> hehe, redzara 17:19 <dust> Poslední dobou jsem neměl moc volného času, ale když bude, zkusím se pustit do té věci addresses.jsp, přidat tam do rozbalovačky protokolů ‚RSS‘ a pak postavit trasu přes Updater, Sucker do BlogManageru. 17:20 <dust> pokud tedy někdo nemá lepší nápad 17:20 <jrandom> boží 17:20 <jrandom> to zní perfektně. 17:21 <jrandom> ale hmm, možná by to chtělo ještě další pole („do kterého blogu to posílat“ a „jaký prefix tagu“)... 17:21 <jrandom> možná by dával smysl samostatný formulář/tabulka, i když možná ne 17:22 <dust> aha, myslel jsem, že addresses.jsp je jen pro jeden blog (když se tam musíš přihlásit?) 17:22 <jrandom> ah, pravda, dobrý point 17:23 <jrandom> část s updaterem je trochu nejasná, ale máš pravdu 17:23 <dust> (vyřešíme to, až na to dojde) 17:23 <jrandom> jo 17:24 * jnymo si myslí, že www.i2p.net by mohlo spustit něco jako ‚merchandise café‘ 17:24 <jnymo> s tričky eyetoopie s nápisem „I am Jrandom“ ;) 17:24 * mrflibble pořád dohání „flamewar“, která se očividně točí do pořádného flamewaru :) 17:24 <jrandom> heh, jnymo 17:25 <jrandom> jo, v tom vlákně je spousta materiálu 17:25 <jrandom> OK, možná se tím dostaneme k 6) ??? 17:25 <jrandom> má někdo ještě něco k projednání na schůzku? 17:25 <+bar> jo, jen krátká poznámka k problému symetrických NATů (trochu jsem slídivě pátral): 17:25 <+nickless_head> jrandom: znám pravdu! 17:25 <+fox> <blx> kaffe? 17:25 <mrflibble> ups, promiň jr 17:26 <jnymo> ale vážně... každý open‑source projekt nějaké velikosti má vlastní sekci s merchem 17:26 <+nickless_head> jrandom: mám jasný důkaz, že jsi hacknul homepage last.fm! 17:26 <+nickless_head> (v sekci „co dostanete po registraci“ bylo uvedeno ‚a pony‘) 17:26 <jrandom> jnymo: myslím, že máš pravdu, tu cestu chceme prozkoumat, může to být i dobrý způsob fundraisingu 17:27 <jnymo> jrandom: přesně 17:27 * mrflibble by si to tričko koupil 17:27 <+bar> dobře, k symetrickým NATům, 17:27 <+bar> pokud to něco znamená, myslím, že na rozdíl od už podporovaných NATů tady není žádné kouzlo. Jediný správný způsob je nastudovat a prozkoumat chování každého jednotlivého symetrického NATu a použít introducery pro sondování. 17:28 <jrandom> blx: poslední kaffe CVS je úplně b0rked. crypto balíčky nejsou ve zdroji, PRNG selže při inicializaci a URL handlery si neporadí s file:// :( 17:28 <jnymo> Pravděpodobně bys to nechtěl nosit na veřejnosti, dokud nebude mít I2P pár tisíc uživatelů ;) 17:28 <+bar> (myslím, že takhle dělají UDP hole punching třeba Hamachi a Skype zevnitř symetrických NATů) 17:28 <+nickless_head> jnymo: hrnky by byly boží :) 17:28 <+bar> podle toho, co jsem zatím četl na netu, algoritmy predikce symetrických NATů jsou dost mizerné. 17:28 <jrandom> hmm, bar 17:28 <mrflibble> hehe, svoje jméno bych si na to nedal. jo, a jsem pořád naživu/nezatčený, i když mám IIP tričko 17:28 <jrandom> jo, to jsem četl taky 17:29 <+bar> zkusím k tomu posbírat další dobré, relevantní čtení. 17:29 <+redzara> Drobná otázka: jaké bylo obvyklé průměrné procento retransmitovaných bajtů v 0.6.1.3? 17:29 <jrandom> díky, bar 17:29 <+fox> <jme___> bar, jsou ty jejich predikce konzistentní? 17:29 <+fox> <jme___> bar, přeformuluju to :) 17:29 <+fox> <blx> jrandom, to mě mrzí 17:30 <jrandom> redzara: bohužel jsem to zapomněl dát do netDb. Ale teď vidím 2.6 a 3.8 17:30 <jrandom> blx: mě taky :( 17:30 <+fox> <jme___> bar, když zanalyzuješ chování NAT krabice a najdeš vzorec, jak ho předpovídat – funguje to vždy pro tuhle krabici? Nebo jednou funguje a jindy selže? 17:30 <jrandom> blx: vím, že teď něco mergují s classpath, takže snad až to vyřeší 17:30 <+fox> <blx> pravděpodobně to znamená, že se k party nepřidám 17:30 <jrandom> blx: jsi vázaný specificky na kaffe, nebo na OSS/DFSG? 17:31 <+fox> <blx> svobodný software 17:31 <+fox> <blx> řekněme DFSG 17:31 <jnymo> kdyby chtěl uživatel I2P použít hosted server pro I2P, jaká by byla liberální, levná hostingová společnost, do které jít? 17:31 <+bar> jme___: prý se Hamachi daří zprostředkovat 97 % všech pokusů o spojení. Asi jsou tam nějaké NATy, které při přidělování portů vykazují skoro náhodné chování 17:32 <jrandom> OK, určitě něco vymyslíme, blx. kaffe dřív fungovalo a nejsme závislí na ničem specificky od Sunu 17:32 <jrandom> jnymo: používám sagonet.net, ale zvedli ceny z 65/měs na 99/měs (ale na rychlé lince s 1250 GB/měs) 17:32 <jrandom> vím, že v Německu jsou taky nějaké levné 17:33 <+fox> <jme___> bar, 97 % by bylo skvělé 17:33 <jrandom> redzara: jakou vidíš míru retransmisí? 17:33 <+bar> jme___: jo, takže hádám, že většina symetrických NATů je předvídatelná 17:33 <+fox> <blx> jrandom, to teda doufám. tohle mě fakt zajímá :) 17:33 <+fox> <jme___> bar, co bys dělal? relay, UDP hole punching, obrácení spojení... jsou i jiné tech? 17:33 <jnymo> je 99 v průměru drahé? 17:34 <+redzara> jrandom mezi 3;8 a 4.2 17:34 <jrandom> jme___: jsme UDP, není třeba obracet spojení :) 17:35 <+bar> jme___: nejsem expert, možná budu mít víc informací na příští meeting (ale rozhodně to smrdí profilováním + UDP hole punching ;) 17:35 <jrandom> jnymo: pro 1250 GB ani ne. viděl jsem 60–120 USD/měs za 50–100 GB/měs 17:35 <jrandom> bar: možná by byl lepší UPnP? 17:35 <+fox> <jme___> jrandom, i s UDP je to užitečné :) 17:35 <+redzara> jrandom: ale jen některé uzly dělají větší paseku, možná nějaké starší 17:35 <+fox> <jme___> vulpine: ok 17:35 <jrandom> i když to pomůže jen lidem, kteří mohou svůj NAT ovládat 17:36 <+fox> <jme___> UPnP by mělo být podporované, ale není exkluzivní vůči jiným způsobům 17:36 <jrandom> no, všechno, co teď děláme, funguje bez jakéhokoli UPnP 17:36 <+fox> <jme___> protože UPnP nepodporují všechny NATy, ani zdaleka 17:36 <jrandom> přesně tak, např. NAT od ISP 17:36 <+bar> jrandom: pokud s UPnP nejsou bezpečnostní problémy, asi to nemůže uškodit. i když Hamachi UPnP nepoužívá 17:36 <+fox> <jme___> tady ‚musí‘ = aby se zajistila co nejvyšší konektivita 17:37 <+fox> <jme___> ok, vracím se ke svému C++ :) 17:38 <jrandom> správně, jme___, ale pokud zvládneme kromě cone/restricted hole punchingu i symmetric hole punching, jsme na tom skvěle 17:38 <jrandom> l8s jme___ 17:38 <jrandom> jo, ideální by bylo, kdybychom to nepotřebovali 17:39 <jrandom> OK, má někdo ještě něco k projednání na schůzku? 17:41 <jrandom> pokud ne... 17:41 * jrandom se připravuje 17:41 * jrandom *baf* ukončuje schůzku