Setkání vývojářů I2P - 20. prosince 2005

15:20 <jrandom> 0) ahoj 15:20 <jrandom> 1) Stav sítě 15:20 <jrandom> 2) I2PSnark aktualizace 15:20 <jrandom> 3) UI blogu Syndie 15:20 <jrandom> 4) ??? 15:20 <jrandom> 0) ahoj 15:20 * jrandom mává 15:20 <jrandom> týdenní poznámky o stavu jsou na http://dev.i2p.net/pipermail/i2p/2005-December/001240.html 15:22 <jrandom> ok, vrhneme se na 1) Stav sítě 15:22 <jrandom> Nemám moc co dodat nad to, co je v poznámkách o stavu. 15:22 <+Complication> Kdyby nebylo občasných OOM, troufl bych si tomu říkat docela dobré 15:22 <jrandom> zátěžové testy vypadají dost slibně, naznačují, že máme hodně prostoru pro zlepšení výkonu 15:23 <+Complication> A hádám, že ty OOM 15:23 <jrandom> heh, OOM související s i2psnark? nebo i předtím? 15:23 <+Complication> přispívají k nestabilitě, když buď instance i2p-bt, i2psnark nebo i2p-rufus dělají... věci. 15:24 <zzz> moje teorie je, že zvýšený torrentový provoz trochu poškozuje spolehlivost IRC 15:24 <+Complication> (možná bych tu zvláštnost se SAM neměl nazývat OOM, protože jsem se na to detailně nedíval, ale rozhodně je to jeden z faktorů) 15:24 <jrandom> hmm, nejsem si jistý, stav irc byl podobný jako před posledními aktualizacemi snarku 15:25 <+Complication> Šířka pásma byla stabilní, zčásti i tunnels stabilní taky... jen to občas spadne 15:26 <zzz> Každopádně jsem optimista, že opravy stavby tunnelů, které přijdou v 0.6.1.8, zlepší lidem zkušenost s IRC 15:26 <+Complication> Z dobře známých důvodů, které snad zmizí, až přijde jejich čas :) 15:26 <jrandom> jo, myslím si to taky, zzz, takže asi vydáme release během příštího dne či tak 15:26 <+legion> IRC může být prostě příliš citlivé, možná by bylo lepší použít něco jako Jabber? 15:26 <zzz> zejména pro lidi na pomalejších strojích a/nebo spojení 15:27 <jrandom> Jabber by na tom nic nezměnil 15:27 <+Complication> Zvlášť s redundancí tunnelů nastavenou na 2 15:28 <+bar> řekl bych, že irc je vynikající sračkoměr na určování počasí v síti 15:28 <+legion> Jo, stačí, aby trochu zafoukal vítr, a irc se hned vysere 15:28 <+bar> přesně :) 15:28 <+Complication> Všiml jsem si, že po opravě shitlistingu má "Recent" tendenci vždy převyšovat "Known" 15:29 <+Complication> Je to tím, že "Known" nezahrnuje peery na shitlistu, zatímco "Recent" ano? 15:29 <jrandom> jo, IRC je dobrý pohled na věc, protože ukazuje značné rozdíly u různých uživatelů (např. dreamtheaterfan má vždy potíže atd.) 15:30 <jrandom> hmm, to dává smysl, Complication 15:30 <+Complication> (nejsem si jistý, jen hádám) 15:30 <jrandom> (protože peery na shitlistu jsou z netDb vyřazeny, ale jejich profily se neodstraní) 15:32 <+Complication> Pak se indikátory zdají OK (jen jsem se chtěl zeptat pro případ, že by nebyly) 15:33 <jrandom> ok, ještě něco k 1) Stavu sítě? 15:33 <jrandom> pokud ne, přesuňme se k 2) I2PSnark aktualizace 15:33 <tealc_> jaké aktualizace jsou k dispozici? 15:34 <jrandom> viz http://dev.i2p.net/pipermail/i2p/2005-December/001240.html pro krátký výčet ;) 15:34 <jrandom> v zásadě I2PSnark nyní umí obsluhovat více torrentů najednou přes jedinou I2P destination, má webové rozhraní a je integrován do router konzole 15:35 <tealc_> pouštím nejnovější cvs buildy a i2psnark způsobuje spoustu chyb haldy paměti nebo tak něco 15:35 <+Complication> ...a také zvládá torrenty vytvořené Azureusem s podivnými meta-taggy. 15:35 <+Complication> Na kterých se dříve zasekl. 15:35 <jrandom> ah, jasně, pořád tam ještě něco ladím, tealc_ 15:35 <jrandom> (jak je zmíněno v týdenních poznámkách o stavu ;) 15:35 <jrandom> jo, správně, Complication 15:36 <jrandom> jo, a lidé z Azureusu opravili bug ve svém trackeru, který I2PSnarku bránil ho používat 15:36 <jrandom> (takže lidi, co provozují azureus trackery starší než B16, by měli co nejdřív upgradovat) 15:37 <+bar> chtěl bych mít možnost snadno vypnout autostart i2psnark (pro scénáře s nízkou šířkou pásma atd.) 15:38 <jrandom> to by mělo jít poměrně snadno přidat 15:38 <+bar> zní skvěle 15:39 <jrandom> ok, ještě něco k 2) I2PSnark aktualizace? 15:40 <jrandom> pokud ne, přejděme k 3) UI blogu Syndie 15:40 <zzz> palce nahoru za nový i2psnark - dobrá práce 15:41 <jrandom> gracias, těžkou práci odvedl mjw, díky čemuž je snark tak snadno rozšiřitelný 15:41 <jrandom> ok, jak je zmíněno v poznámkách o stavu, syndie teď má nové UI blogu 15:42 <jrandom> Myslím, že nabídne rovnováhu mezi whitelisty a blacklisty, aby se vypořádala s různými spamovými problémy, které lidé zažívají 15:43 <jrandom> nasadíme to v příštím release, takže se do toho budete moct za den či dva pustit 15:43 <+legion> Stane se spam opravdu brzy velkým problémem? 15:44 <+Complication> legion: jak nám někdo ochotně předvedl, klidně by mohl 15:44 <jrandom> ne, blacklisty se postarají o autory, kteří floodují, a whitelisty o spammery, kteří vytvářejí spoustu autorů 15:44 <dust> (anonymita v některých lidech probouzí to nejhorší) 15:44 <jrandom> (takže spamování není problém) 15:45 <+Complication> (Ačkoli si myslím, že dotyčný regeneroval klíče, aby se vyhnul trvalému blacklistu, což *je* určitým zpomalením.) 15:45 <+Complication> I když ne velkým zpomalením, a proto z celého srdce souhlasím, že whitelisty jsou také dobré. :) 15:46 <+bar> možná by do budoucna šlo použít nějaké řešení typu hashcash, pokud by bylo potřeba 15:46 <jrandom> pokud bude potřeba, ale nevidím důvod, proč by měla 15:46 <+bar> souhlasím, teď taky ne 15:46 <+Complication> bar: něco jako "nezobrazit, pokud si nedali práci něco spočítat"? 15:47 <+bar> ano, něco v tom smyslu 15:47 <+Complication> Zní to proveditelně, i když to pravděpodobně nebude třeba. 15:47 <+bar> asi ano. 15:47 <jrandom> kdyby nějaká skupina spammerů pořád zaplavovala s velkým množstvím nových autorů, lidé by pořád mohli ostatním říkat o nových autorech tím, že by zveřejňovali své záložky a odkazy na blogy ve svém vlastním blogu 15:47 <+Complication> Spíš doufejme, že zbytečné. 15:48 <+Complication> Možná by stálo za to zvážit, zda Syndie umí takovou funkci pojmout, kdyby někdy byla potřeba. 15:49 <jrandom> jo, umí, přes hlavičky v příspěvku na blogu nebo v samotné metainfo blogu 15:49 <jrandom> ehm, metadata (proklatý bt!) 15:51 <jrandom> ok, pokud není nic dalšího k 3) Syndie, skočme na 4) ??? 15:51 <jrandom> má někdo ještě něco, co chce na schůzce otevřít? 15:51 <+legion> ano, pár věcí 15:52 <+legion> nejdřív clunk 15:52 <jrandom> super, jo, clunk zní zajímavě 15:52 <+legion> Jak jsem dnes dříve zmiňoval na i2p-chat, pracuju na tom, aby se to dalo zkompilovat s Cygwinem a/nebo MinGW. 15:53 <+legion> Zatím je rozbitý jen klient, zbytek včetně serveru se kompiluje a vypadá, že funguje 15:53 <jrandom> paráda 15:54 <tealc_> i2p by se mohlo ukázat jako pořádný oříšek pro program neomezeného dohledu George Bushe. Uvidíme se v táborech smrti, vezměte karty, jo 15:54 <+legion> Snažím se nejen dohledat, proč je klient rozbitý, ale i to vyřešit. Momentálně jsem uvízl. 15:56 <+legion> Druhá věc, kterou jsem chtěl probrat: šel by do příští aktualizace přidat výchozí tunnel na můj jabber server? Jen aby to bylo jednodušší pro každého, kdo si chce jabber vyzkoušet. 15:57 <tethra> 20:34:37 <jrandom> if a set of spammers were flooding with lots of new authors all the time, people could still tell other people about new authors by posting their bookmarks and blog references in their own blog <--- možná by v tom mohl hrát roli polecatův způsob kombinování důvěry? (tj. zároveň blokovat spammery -a- propagovat populární autory.) 15:57 <tethra> </$0.02> 15:58 <+polecat> To by byl primitivní příklad mého nápadu na síť důvěry, s heuristikou 100% přenosu důvěry, ano. 15:58 <jrandom> legion: hmm, přidat vypnutou konfiguraci pro nové uživatele je docela snadné, ale moje obava se týká filtrování protokolu (a toho, jaké klienty co uniká). jaké máš zkušenosti s různými klienty? 15:59 <jrandom> jo, je tu hodně prostoru pro integraci metrik důvěry do syndie 16:01 <+legion> Pokud vím, jeti neuniká, kromě svého filetransferu, který mám v nastavení serveru stejně vypnutý. Možná to bude opraveno v příští verzi jeti. Jinak o ostatních klientech nevím. 16:02 <+legion> Jistě vím, že groupchat je solidní bez ohledu na klienty; jen kontakt mimo groupchat mohou některé klienty prozrazovat, ale nejsem si jistý. 16:03 <jrandom> hmm, únik není ve skutečnosti booleovský; jde o to, /jaké informace/ klienty unikají, ne zda uniká nějaká informace 16:04 <+legion> Jasně, myslel jsem samozřejmě jakékoli kritické informace jako ip adresy, i když dobré klienty by, pokud to uniká, měly uvádět jen 127.0.0.1 nebo localhost 16:06 <+legion> Takže bych doporučil používat jen známé klienty, které neunikají, jako je jeti. 16:07 <zzz> mohl bys do své tabulky klientů přidat sloupec "ověřeně neuniká"? 16:07 <jrandom> bylo by užitečné, kdybys zdokumentoval, co jeti uniká a neuniká (podobně jako co postman dal dohromady pro SMTP a POP proxy) 16:08 <+legion> Podle vývojáře jeti neuniká nic, co by ohrozilo anonymitu. To je jisté bez pochyb. Podíval jsem se i do zdrojáku a nenašel nic, co by mě vedlo si myslet opak. 16:09 <jrandom> to, že to říká vývojář, může být jisté, ale co vývojář chápe pod anonymitou, je jiná otázka ;) 16:09 <+legion> Jo, zzz, mohl bych přidat další takový sloupec 16:09 <jrandom> Nezpochybňuju možnost, že se jeti chová správně, ale potřebujeme vědět, co to znamená 16:10 <zzz> vypadá to, že neunikání lze ověřit jen trasováním protokolu 16:10 <zzz> ne pohledem do zdrojáku nebo dotazem na vývojáře 16:12 <jrandom> ok, má ještě někdo něco k dnešní schůzce? 16:12 <+bar> jen připomínka, abyste nezapomněli na amd64 jbigi 16:13 <+bar> (vsadím se, že je to na vašem to-do listu) 16:13 <jrandom> jo :) 16:13 <jrandom> (win amd64, tj. linux amd64 už funguje) 16:13 <jrandom> ale pokud už nic dalšího... 16:14 * jrandom uzavírá 16:14 <+bar> ano, win amd64. 16:14 * jrandom *baf* uzavírá schůzku