I2P setkání vývojářů - 4. března 2016

15:00:05 <zzz> 0) ahoj 15:00:23 <zzz> 1) struktura těchto schůzek 15:00:32 <zzz> 2) diskuse o roadmapě 15:00:37 <zzz> 0) ahoj 15:00:41 <zzz> ahoj 15:00:54 <str4d> ahoj 15:01:02 <xcps_> ahoj! 15:01:27 <orignal_> co se děje? 15:02:18 <zzz> prosím zkontrolujte vlákno na http://zzz.i2p/topics/2021 a aktuální roadmapu na http://i2p-projekt.i2p/en/get-involved/roadmap 15:02:27 <zzz> 1) struktura těchto schůzek 15:03:22 <zzz> máme jít rovnou na roadmapu, nebo bychom měli nejdřív mluvit o prioritách na vysoké úrovni? 15:03:53 <str4d> Volil bych nejdřív to druhé 15:04:41 <zzz> ok, takže ve vlákně jsem nastínil dvě priority – rozšiřovat síť a zvyšovat bezpečnost 15:04:55 <zzz> jak to zní jako principy na vysoké úrovni? 15:05:25 <zzz> nejprve si rozhodněme, co je důležité 15:05:32 <EinMByte> Zní to, jak by se dalo čekat, myslím 15:05:48 <EinMByte> „rozšiřovat síť“ by mělo být v širokém smyslu 15:05:57 <str4d> Myslím, že to jsou skvělá zastřešující témata 15:06:03 <zzz> anonimal ve vlákně nadhodil spoustu dalších, ale o to mi úplně nešlo 15:06:13 <xcps_> zvyšování bezpečnosti by mělo být vždy nejdůležitější, imho 15:06:28 <zzz> nějaké další principy, které bychom měli zvážit při revizi roadmapy? 15:06:28 <str4d> Co IMHO musíme udělat, je zjistit, co to konkrétně znamená v termínech možných výstupů 15:06:40 <EinMByte> Takže „rozšiřovat síť“ by mělo také znamenat „zvýšit pozornost výzkumu“ 15:07:00 <zzz> rozšiřovat síť znamená spoustu různých věcí – viz vlákno 15:07:09 <str4d> EinMByte, jo, myslím, že jsem to ve vlákně zmiňoval 15:07:36 <zzz> brzy si ujasníme, co to znamená. Teď se shodněme na tom, co je důležité. 15:07:58 <str4d> Použitelnost je pro mě hodně důležitá a IMHO přispívá k výše uvedeným dvěma oblastem 15:07:58 <zzz> Všechno je možné, když budeme dál růst. Jakmile přestaneme růst, jsme mrtví 15:08:05 <zzz> souhlas, str4d 15:08:41 <str4d> Krátkodobě pokud jde o zvýšení naší uživatelské základny, a dlouhodobě pokud jde o větší veřejnou známost, snadnost použití pro výzkumníky atd. 15:09:11 <EinMByte> Poznamenejme také, že růst je jediný způsob, jak přilákat výzkumníky 15:09:25 <zzz> více uživatelů přináší více vývojářů a více výzkumníků a více obsahu a a a 15:09:37 <EinMByte> Velké sítě jsou obecně zajímavější ke studiu 15:10:05 <EinMByte> Takže myslím, že se můžeme všichni shodnout na těch 2 prioritách 15:10:16 <zzz> většina našeho růstu za poslední rok byla díky Vuze. Což je skvělé, ale rád bych viděl i více ‚přirozeného‘ růstu 15:10:43 <zzz> ale možná je růst v integrovaných (embedded) aplikacích, nebo obecně zaměření na aplikace, nejsnazší cesta k růstu 15:10:48 <str4d> Jo 15:11:04 <EinMByte> zzz: Pro spoustu lidí je jednodušší používat aplikaci, která I2P spouští na pozadí a stará se za ně o konfiguraci 15:11:12 <sadie> ahoj – trochu pozdě na večírek 15:11:20 <zzz> ahoj sadie, jsem rád, že jsi dorazila 15:11:23 <str4d> To IMHO přijde ze zlepšení použitelnosti jak v UI, tak v API 15:11:42 <str4d> Na tom druhém už pracujeme v různých vláknech 15:11:48 <zzz> svým způsobem jsou to aplikace, kdo jsou experti na UI – nechme je bundlovat i2p a vystavit (nebo skrýt) ho, jak uznají za vhodné 15:11:58 <str4d> Mmm 15:12:08 <EinMByte> str4d: To je jiné řešení téhož problému, ano. A líbí se mi víc, protože bundlovat I2P se vším IMHO neškáluje 15:12:30 <str4d> To je tak trochu přístup, který jsem volil na Androidu 15:13:04 <EinMByte> Musí existovat způsob, jak zajistit, aby neměli jednu instanci I2P pro každou aplikaci 15:13:12 <zzz> ok, ještě něco k 1), nebo se přesuneme k samotné roadmapě? 15:14:00 <str4d> Myslím, že tu panuje hrubá shoda 15:14:08 <str4d> (alespoň žádný nesouhlas :P) 15:14:14 <zzz> dovolte mi zkopírovat řádky z vlákna. Ne jako dogma, jen pro referenci 15:14:25 <zzz> Rozšiřovat síť 15:14:25 <zzz> Zahrnuje: Marketing, společné projekty, bundlovat víc věcí, pomáhat ostatním bundlovat i2p, použitelnost, vylepšení webu, více překladů, přednášky a prezentace, články a příběhy, UI, Android, Android apps, lepší obcházení GFW, orchid, více knihoven a nástrojů pro vývojáře klientů, lepší podpora pro obří weby, podporovat vývoj alternativního routeru, aliance, zrychlení a efektivita, kapacita, zvyšování limitů, getting in 15:14:25 <zzz> do Debianu, ... 15:14:25 <zzz> Zvyšovat bezpečnost 15:14:25 <zzz> Zahrnuje: migrace kryptografie, subscription protocol, nové transportní protokoly, pluggable transports, LS2, NTCP2, nové DH, revokace klíčů, uložení klíčů, code review, Sybil, opravy chyb, pojmenovávání, SSL, ... 15:14:46 <zzz> ok, pojďme na 2) samotnou roadmapu 15:15:10 <zzz> url je http://i2p-projekt.i2p/en/get-involved/roadmap 15:15:50 <zzz> .25 je v podstatě hotová, vydání za cca 10 dní, takže se podívejme na další 4 vydání 26–29 pro tento rok 15:16:00 <zzz> která by nás měla dovést až k CCC 15:16:15 <EinMByte> Když je něco pod 2017, např., znamená to, že se na to začneme dívat až tehdy, nebo že s implementací začneme až tehdy? 15:16:41 <str4d> Co se týče věcí, které musíme udělat, dal bych migraci kryptografie a práci na Sybil hodně vysoko 15:16:42 <zzz> 1mb, určitě chceme začít už teď s velkými věcmi na 2017, jako je nová kryptografie/DH, NTCP2 atd 15:17:04 <EinMByte> Také eclipse útoky jsou teď problém, IMHO 15:17:05 <zzz> takže roadmapa by mohla zahrnout přípravné práce pro tyhle věci 15:17:23 <str4d> EinMByte, jo, bral jsem to pod Sybil 15:17:36 <EinMByte> Celý nápad s půlnoční rotací nefunguje a měly by existovat lepší alternativy, předpokládám 15:17:52 <zzz> souhlas 15:18:05 <EinMByte> str4d: Jasně, je rozumné je klasifikovat jako stejný typ útoku 15:18:44 <str4d> EinMByte, o tomhle jsem mluvil s pár lidmi na RWC 15:18:48 <str4d> Mám nějaké myšlenky, ale těžko se to probírá právě tady 15:18:51 <EinMByte> zzz: Takže pokud chceme do 2017 začít s NTCP2/... musíme naplánovat předběžné práce 15:18:58 <zzz> správně, 1mb 15:19:02 <str4d> Jo 15:19:20 <str4d> Chtěl bych mít plánování a research v roadmapě :) 15:19:28 <zzz> tady je problém. Měl bych teď pracovat na 26 a nevím, co v ní je 15:19:39 <orignal_> je možné přidat náhodný padding k existujícímu NTCP? 15:20:01 <str4d> orignal_, pokud si pamatuju, ne, ale podívej se na vlákno NTCP2 15:20:02 <zzz> tak pojďme strávit 10 minut plánováním 26, pak se můžeme přesunout k delšímu horizontu 15:20:13 <str4d> k 15:20:14 <zzz> řekněte mi, co mám dělat dnes 15:20:30 <EinMByte> Pravda, nejdřív se soustřeďme na to 15:20:34 <zzz> ok, podívejme se, co je v seznamu pro 25, co se nestalo 15:20:50 <zzz> wrapper se nestal, kytv je AWOL 15:20:54 <EinMByte> „crypto enhancements“ je dost široké 15:21:12 <zzz> co se ve skutečnosti stalo v rámci crypto enhancements, byly nějaké zrychlení 25519 15:21:34 <zzz> takže seznam .25 je tam vlastně celý, kromě wrapperu 15:22:00 <zzz> ale na Sybil je ještě práce, tak to nechme v seznamu pro 26 15:22:08 <str4d> Skvělé 15:22:25 <str4d> GMP 6 jsme posunuli na .26 kvůli potřebě více testování 15:22:35 <zzz> co dalšího v seznamu pro 26 by tam mělo být, nebo se přesunout 15:23:05 <EinMByte> Prevence Sybil nakonec asi bude spousta práce, takže mi to přijde jako dlouhodobá věc 15:23:10 <EinMByte> (ve smyslu, že nejdřív potřebujeme dobrý přehled literatury) 15:23:15 <zzz> orignal, jo, NTCP s paddingem je NTCP2 15:23:21 <str4d> EinMByte, nástroj na detekci Sybil se zatím k ničemu nepoužívá, tam je potřeba víc plánování :) 15:23:49 <zzz> hottuna4 je měsíc nedostupný, nejsem si jist, kdy ten měsíc skončí, takže gmp6 se do 26 možná dostane a možná ne 15:24:02 <str4d> K 15:24:37 <str4d> Vylepšení subscription protocolu pro addressbook: to by bylo velmi dobré přidat ASAP, aby mohli vlastníci starých Dest (Destination) migrovat na Ed25519 15:24:37 <EinMByte> Myslím, že CRLs nepotřebují otazník 15:24:47 <str4d> Ale jak dlouho to ve skutečnosti potrvá? 15:25:14 <zzz> brzy budeme potřebovat status update od tuna, očekávám, že deadline pro naskládání velkých věcí do 26 bude konec března / první týden v dubnu 15:26:10 * str4d pořád úplně nerozumí věci kolem CRL, mohl by zzz rozvést? 15:26:14 <zzz> 25 bude mít schopnost číst CRL z disku, takže je můžeme zahrnout do update 15:26:35 <zzz> ale to není tak užitečné, protože v update můžeme prostě odstranit cert a má to stejný efekt 15:26:56 <zzz> takže abychom dostali CRL k lidem bez nutnosti dělat update, dali bychom je do feedu 15:26:57 <str4d> Jen se snažím přijít na use case 15:27:09 <zzz> use case je, že někdo bude kompromitován 15:27:20 <str4d> Pořád neděláme cert pinning? 15:27:30 <zzz> ne 15:27:56 <zzz> takže mám hotovo 90 % a jen musím strčit CRL do namespace 15:28:46 <zzz> pinning je záludný a nebezpečný 15:29:05 <zzz> crypto cat udělali ‚pinning suicide‘ 15:29:17 <zzz> kde byli připinnovaní, ale změnil se intermediate 15:30:49 <zzz> nemyslím, že pinning nahrazuje cls 15:30:51 <zzz> crls 15:31:21 <zzz> CRL nejsou jen pro SSL, jsou tu reseed a update keys 15:31:58 <zzz> můžeme tedy nechat CRL v seznamu pro 26? je to skoro hotové 15:32:20 <str4d> Co mě znepokojuje ohledně pinningu je, že někdo může udělat např. něco jako Quantum Insert, přesměrovat doménové jméno reseedu a prostě nasadit libovolný platný SSL cert splňující požadavek na doménové jméno a routers to přijmou 15:33:05 <str4d> A co se týče CRL, pokud tím zakážeme konkrétní certifikát, čím se ten certifikát nahradí? 15:33:25 <zzz> ničím. v příštím vydání by pravděpodobně byla náhrada 15:33:45 <str4d> Začínáme zacházet do detailů 15:34:07 <str4d> Myslím, že kam jsem mířil je, že to musíme ještě promyslet 15:34:24 <zzz> ok, takže CRL nechme pro 26, ale detaily si k tomu proberme během příštího týdne nebo dvou 15:34:30 <zzz> protože to není 100% jasné 15:34:38 <zzz> posuňme se dál 15:34:42 <zzz> co ještě je v seznamu pro 26 15:34:43 <str4d> mmk 15:34:50 <EinMByte> ok 15:35:08 <zzz> subscription protocol 15:35:28 <zzz> tohle je klíč pro migraci kryptografie u webů 15:35:40 <EinMByte> náhrada hosts.txt, nebo co tím myslíš? 15:36:22 <zzz> ano, je to hosts.txt jako feed, něco jako foo.i2p=b64#sig=b64#cmd=alt ... 15:36:26 <str4d> EinMByte, doplnění subscription protocolu addressbooku o podepsaná key-value metadata 15:36:49 <zzz> návrh je docela daný, ale je pozastavený asi 18 měsíců 15:37:07 <EinMByte> Jasně, ale nevyrostla by velikost souboru hosts příliš? 15:38:02 <EinMByte> Možná přidat parametr since, aby se vyloučily všechny hosty vložené před daným časem 15:38:07 <EinMByte> (aby se předešlo stahování celého seznamu, když to není potřeba) 15:38:22 <zzz> původně to bylo součástí plánu migrace kryptografie, ale bylo to těžké a nebyla to nejdůležitější část 15:38:49 <zzz> ale je to hlavní věc, která zbývá u migrace podpisů 15:39:26 <str4d> EinMByte, tohle už tak trochu máme přes etag 15:39:28 <zzz> tohle je další z věcí, která je navržená s řadou detailů, ale nemáme úplně shodu, takže jsme nezačali 15:39:42 <EinMByte> str4d: Používá se to ale? 15:39:46 <str4d> EinMByte, ano 15:40:00 <EinMByte> Aha, neřeš. V tom případě 15:40:03 <str4d> To by se nelišilo od současného nastavení 15:40:20 <zzz> takže to dáme na seznam pro 26 a začneme na tom ASAP. nejsem si jistý, jestli se dostaneme dost daleko už pro 26, ale zkusím to. potřebujeme zrevidovat vlákno na zzz.i2p 15:40:22 <str4d> ale místo toho, aby se položky s doménovými jmény nikdy neopakovaly, by se teď opakovaly ve „streamu“ 15:40:42 <EinMByte> Je nějaký konkrétní důvod, proč musíme zachovat ten divný formát? 15:41:05 <EinMByte> Přišlo by mi jednodušší použít něco standardního 15:41:06 <zzz> možná. kompatibilita se starými klienty. ale měli bychom to zrevidovat a určitě rozhodnout, zda je to důležité 15:41:20 <zzz> nikdo z nás se na to už možná rok nepodíval 15:41:28 <zzz> takže to oprášíme a podíváme se 15:41:32 <EinMByte> zzz: Kompatibilitu lze řešit i tím, že nějakou dobu budeme poskytovat starý soubor hosts.txt 15:41:41 <str4d> Je tu také širší otázka, co dělat např. se všemi „ztracenými“ jmény 15:41:53 <str4d> Ale to je mimo současnou diskusi 15:41:57 <zzz> jo. potřebovali bychom také zapojit ostatní implementace 15:42:18 <EinMByte> str4d: Myslím, že to je něco, o čem rozhodneme, až budeme mít nový naming systém (pokud ho někdy mít budeme) 15:42:26 <str4d> Prozatím chci nějaký způsob, jak aby si aktuálně aktivní domény mohly aktualizovat své dests 15:42:26 <zzz> ok, zatím to zůstává v seznamu pro 26. další na seznamu – věci kolem Sybil 15:42:45 <zzz> můžeme udělat Sybil automatickou? Doufám, že jste všichni četli ten článek od Philipa Wintera???? 15:42:50 <str4d> A čím dřív dostaneme core kód dovnitř, tím dřív to budeme moct za rok či tak zapnout 15:43:50 <EinMByte> zzz: Jaký článek? Zjevně mi něco uniklo 15:44:27 <zzz> pro odkaz se koukněte na @__phw na Twitteru 15:45:02 <zzz> spolupracujeme s ním díky sadie, která nás seznámila na CCC 15:45:03 <EinMByte> zzz: tohle: http://arxiv.org/pdf/1602.07787v1.pdf? 15:45:27 <zzz> pokud to vyšlo v posledních pár týdnech, tak to je ono 15:45:59 <EinMByte> No, je to eprint z letošního února 15:46:09 <zzz> nemyslím, že jsme připraveni na automatiku. oni vlastně taky ne 15:46:22 <zzz> oni jen jednou denně pošlou e-mail dirauths 15:46:36 <zzz> je to celé heuristika a magie na obou stranách 15:46:49 <EinMByte> Takže ten eprint asi dal online poté, co to vyšlo 15:46:57 <zzz> takže bych rád automatické věci odsunul na později během roku 15:47:07 <str4d> EinMByte, verzi mám z 25. února 15:47:14 <EinMByte> zzz: Tak jak by to přesně fungovalo v decentralizovaném prostředí? 15:47:44 <str4d> Potřebujeme postupovat zdola nahoru, ne shora dolů 15:48:06 <str4d> tj. každý router by musel v peer profilech zahrnovat „potenciální kandidáty na Sybil“ 15:48:13 <zzz> EinMByte, nevím. je to těžké 15:48:20 <str4d> na základě např. časů online atd. 15:48:30 <EinMByte> Detekovat Sybil útoky je podle mě proveditelné, zabránit jim na základě té detekce je v decentralizované síti velmi těžké 15:48:30 <EinMByte> Ale ta výzva se mi líbí 15:48:34 <zzz> také potřebujeme gravyho, který pracuje na centralizovaném předělání svého setupu 15:48:43 <str4d> Je také možnost mít nějaké více centralizované řešení 15:48:45 <str4d> Jo, to 15:48:45 <EinMByte> str4d: V tom bodě musíš začít přidělovat důvěru každému routeru 15:48:52 <EinMByte> což samo o sobě bude celý anti-Sybil systém 15:49:07 <str4d> A nechat routery odebírat seznam potenciálních sybilů 15:49:07 <zzz> něco jako dagon proposals 15:49:09 <str4d> EinMByte, to je v zásadě to, co peer profiles teď jsou 15:49:31 <str4d> kde je „důvěra“ aktuálně definovaná jako „v minulosti pro mě spolehlivě dobře routoval“ 15:49:42 <EinMByte> str4d: Ano, a už to způsobilo pár útoků :) 15:50:15 <str4d> Jo 15:50:23 <EinMByte> Peer profiles také opravdu neumožňují vyloučit peer ze sítě 15:50:31 <EinMByte> Sybil prevence by to do určité míry umožnila 15:50:35 <str4d> Peer profiling a peer selection je další z věcí, které podle mě potřebují prioritu 15:50:46 <str4d> Můžou 15:51:01 <zzz> tak navrhuju změnit položku Sybil u 26 na ‚continued improvement‘, ale část ‚automatic‘ přesunout na později 15:51:01 <str4d> Teď ne 15:51:11 <str4d> Jen říkám, že to je místo, kam bychom to dali 15:51:34 <EinMByte> str4d: Ano, to je možné. 15:51:37 <str4d> (pokud jde o začlenění detekce Sybil a pokročilejších technik do lexikonu a architektury I2P) 15:51:53 <EinMByte> Každopádně bych neshazoval decentralizaci. Je to nejhezčí část I2P, imho 15:52:14 <str4d> Jo 15:52:27 <EinMByte> (a centralizace stejně vede k různým praktickým útokům) 15:52:43 <zzz> pojďme dál. streaming improvements? nejsem si jistý, co to je, možná jen věčně se opakující položka ‚udělat to lepší‘ 15:52:49 <str4d> zzz, jo, můžeme pokračovat v práci na té stránce routerconsole a pak to napojit na peer profiles a výběr, jakmile se rozhodneme pro strategii 15:53:00 <zzz> nenapadá mě, co konkrétně je na streamingu k udělání. někdo? 15:53:01 <EinMByte> Někdy přidání centrální autority usnadní důkaz bezpečnosti, ale v praxi způsobí selhání bezpečnosti 15:53:20 <str4d> Výzkum a optimalizace by byly fajn 15:53:28 <EinMByte> zzz: Nějaká zřejmá zlepšení, která bychom tam mohli udělat? 15:53:30 <str4d> To by byl dobrý kandidát pro externí výzkum 15:53:46 <zzz> opravdu potřebujeme lepší testovací setup 15:53:51 <EinMByte> str4d: Souhlasím. 15:53:55 <zzz> přidat zpoždění / dropy, přeuspořádání atd. 15:54:04 <EinMByte> Asi bychom měli rozšířit naši stránku „open research questions“ o tohle a další věci 15:54:40 <zzz> nemám moc „blue sky“ věcí v seznamu kolem streamingu. potřebuje to být řízené výsledky testů 15:54:50 <EinMByte> Možná je víc prostoru pro zlepšení v alokaci tunnels? 15:55:05 <str4d> zzz, je nějaký GH projekt, který simuluje „Internet“ pomocí kontejnerů, které to umí, pokud si dobře pamatuju 15:55:08 <zzz> co kdybychom z té položky udělali ‚streaming test harness‘ 15:55:17 <str4d> Nevím, jak snadné by to bylo, potřebovali bychom novou JVM na každý kontejner :P 15:55:25 <str4d> EinMByte, mmm 15:55:48 <EinMByte> str4d: shadow by šel použít, myslím. Nevím, jestli by to šlo integrovat s Javou, ale je to na kovri TODO listu 15:55:52 <str4d> To ale není úplně streaming, to je na úrovni datagramů 15:56:22 <zzz> ta věc s alokací tunnels je psiho nápad, aby client vybíral tunnels 15:56:34 <EinMByte> str4d: Ano, mám podezření, že je tu víc co optimalizovat 15:56:46 <EinMByte> zzz: Nemyslím si, že uživatelé jsou nejlepší optimalizační algoritmy, ale možná 15:57:10 <zzz> je to brutální porušení našeho vrstvení a nevidím, jak to udělat. ale to je to, co psi navrhuje 15:57:19 <EinMByte> ... anebo „client“ nejspíš neznamená uživatele 15:57:32 <zzz> client == client-side I2CP 15:57:44 <str4d> Jde o to, že 15:57:54 <str4d> Tor to poskytuje přes jejich Control Socket 15:57:58 <EinMByte> Ok, takže to znamená to 15:57:59 <str4d> A je to velmi užitečné pro výzkumníky 15:58:10 <str4d> Ale oni také mají mnohem plošší architekturu 15:58:19 <str4d> Zatímco my přes I2CP oddělujeme různé klienty od sebe 15:58:31 <EinMByte> zzz: Očekával bych, že router bude mít relevantnější informace. Client by mohl předat jakékoli dodatečné požadavky 15:58:41 <zzz> máme také psiho Lua hooks pro výzkumníky, které se nikdy nesloučily (ani v Javě, ani v kovri), ale pořád je to možnost 15:59:14 <zzz> viz teď client strana ani neví o tunnels, takže rozhodně nemá možnost je vybírat 15:59:16 <str4d> Když jsem mluvil s nickm na RWC, říkal, že pro Tor je mnohem snazší udržovat rozhraní Control Socket než plugin systém 15:59:17 <EinMByte> Vím, že shadow se v praxi používá výzkumníky 15:59:22 <EinMByte> Lua, to nevím 15:59:55 <EinMByte> zzz: Takže asi stejného lze dosáhnout předáváním relevantních informací přes I2CP? 16:00:17 <zzz> 1mb, ano, ale bylo by to fakt ošklivé 16:00:44 <str4d> Vždycky to můžeme omezit pomocí flagu -research nebo tak něco 16:00:54 <str4d> (v router.config) 16:01:06 <str4d> Tím pádem se většina uživatelů nepotká s tou ošklivostí 16:01:13 <zzz> kovri/i2pd zatím nemají ty rigidní API bariéry mezi client/router, je to pro 16:01:20 <zzz> *je 16:01:28 <str4d> A můžeme od začátku definovat „.research“ jako „Vyhrazujeme si právo tyto API změnit“ 16:01:44 <str4d> tj. výzkumníci by museli používat flag .research společně s konkrétní verzí 16:01:57 <str4d> Zpět k vlastnímu tématu diskuse: 16:01:59 <EinMByte> zzz: K tunnels. Záleží. Myslím, že by dávalo smysl předávat informace o zamýšleném použití tunnel. 16:02:20 <zzz> (FYI, tahle schůzka poběží max. ještě 25 minut, bude pokračovat v neděli) 16:02:33 <EinMByte> zzz: Je to hlavně snazší pro nás, protože shadow je napsaný v C, myslím 16:02:42 <str4d> Myslím, že by to mělo být přesunuto do kategorie „needs more research“ 16:02:44 <zzz> problém je, že není potřeba vybrat jen tvoje tunnels, ale i tunnels na vzdáleném konci 16:02:48 <EinMByte> Dobře. Pojďme dál. 16:03:08 <zzz> ok, to je teď všechno, co je v seznamu pro 26. Co by se mělo přidat? 16:03:11 <EinMByte> zzz: Neřeší to vzdálený konec 16:03:36 <zzz> ne, source-routujeme (tj. vybereme vzdálený lease z jeho leaseSetu pro jeho inbound) 16:04:08 <zzz> podívejte se na seznam 27–29. co by se mělo stáhnout do 26, pokud vůbec něco? 16:04:44 <str4d> Chci začít dělat přípravy pro nové LSs a netDb 16:04:46 <zzz> tady je všechno to ‚předběžné práce na xxx pro 2017‘, ale také spousta věcí pro 2016 16:05:23 <EinMByte> zzz: Špatně jsem pochopil, co jsi myslel vzdáleným koncem, nevadí 16:05:31 <str4d> Čím dřív to ustálíme a dostaneme do codebase, tím dřív na to bude mít síť širokou podporu 16:06:42 <EinMByte> Všimněte si, že my (kovri) chceme specifikace 16:06:52 <EinMByte> Jinak bude těžké držet krok s implementací 16:07:31 <zzz> jasně. cokoliv, co je nová specifikace, na tom musíme pracovat společně 16:07:36 <EinMByte> str4d: Začněme výčtem, co by LS2 mělo vlastně podporovat 16:07:53 <EinMByte> (pokud to už nebylo uděláno) 16:09:40 <zzz> v zásadě je LS2 jen pár věcí 16:09:59 <zzz> přidat nějaký prostor pro flags 16:10:09 <zzz> a umožnit budoucí crypto 16:10:52 <zzz> ale mám všechny ty návrhy na lepší multihoming, plus vyhledávání služeb ve stylu Grothoffa 16:11:00 <zzz> anycast 16:11:01 <EinMByte> Máme někde konkrétní seznam pro referenci? 16:11:11 <zzz> je to poskládané na zzz, moment 16:11:23 <str4d> Pomalu pracuju na tom, dát to všechno dohromady na webu 16:11:41 <zzz> můžeme to zrychlit, str4d? třeba příští týden nebo dva? 16:11:47 <str4d> To by mělo jít do seznamu .26 16:11:50 <str4d> Hmm 16:11:53 <str4d> Možná 16:11:59 <str4d> Potřebuju na to moar očí 16:11:59 <zzz> bez návrhů na jednoduchém seznamu je to strašně složité 16:12:08 <EinMByte> str4d: Skvělé. Vlastně by se u některých z těchto věcí hodila wiki-funkcionalita 16:12:24 <EinMByte> (myšlenka je, že by to šlo rychleji) 16:12:48 <zzz> pro začátek potřebujeme seznam 16:12:50 <str4d> EinMByte, přesně 16:12:56 <zzz> nevařme tady oceán 16:13:11 <str4d> Snažím se přejít od požadovaného backend HTML k (aktuálně) rST 16:13:31 <str4d> Potřebuju, aby se lidi podívali na to, co mám, a zkontrolovali, že a) je to použitelné a b) nepřijdeme o nic, co teď máme 16:13:39 <str4d> Aktuálně je to použito jen na spec docs 16:13:40 <zzz> dejme tu věc s návrhy na seznam pro 26 a později si řekneme, co to znamená. Ale potřebujeme v tom co nejdřív pokrok. 16:13:55 <str4d> Ale jakmile to zpevní, rozšířit to na proposals je triviální 16:13:56 <zzz> chci je na webu. je mi jedno, v jaké formě. 16:14:46 <EinMByte> Jsem ochoten návrhy revidovat, ale občas se stane, že prostě žádný text nenajdu 16:15:10 <EinMByte> (některé věci jsou na webu tak nějak schované, myslím) 16:15:37 <zzz> přesně tak 16:16:05 <zzz> musíme přesunout věci ze zzz.i2p na web, nějak je zorganizovat 16:16:13 <EinMByte> str4d: Přechod z HTML na něco, co lze snadno převádět do různých formátů, je dobrá věc 16:16:28 <EinMByte> zzz: Ano, rozhodně 16:16:35 <str4d> EinMByte, co potřebuju zrevidovat, je v i2p.www.str4d 16:16:36 <EinMByte> Možná pevně daný proces pro všechny návrhy 16:16:57 <zzz> ok. je to na seznamu pro 26. detaily budou následovat. str4d, pusť se do práce. neočekával bych moc zpětné vazby. Prostě přijď s novým systémem a my se přizpůsobíme 16:17:02 <str4d> a na http://vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p/ 16:17:04 <str4d> EinMByte, pokud na tom se mnou chceš pracovat a dotáhnout to, mohl bych to stihnout možná do .25 16:17:23 <zzz> co ještě pro 26? musíme to uzavřít 16:17:36 <str4d> ( EinMByte, konkrétně http://vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p/spec ) 16:18:14 <zzz> tohle jsou věci v hodně krátkém horizontu. Potřebuju vědět, co mám dělat v pondělí 16:18:27 <zzz> poslední výzva pro 26 16:18:41 <str4d> Myslím, že věci kolem subscriptions potrvají nějakou dobu 16:18:49 <str4d> Takže budu rád, když to bude hlavní věc 16:18:52 <zzz> souhlas. 16:19:54 <zzz> ok. schůzka v neděli ve stejný čas. začneme s vrp/h1. prosím předem zrevidujte ticket 1119. potom budeme mluvit o 27–29, pokud to čas dovolí. 16:20:06 <EinMByte> str4d: Něco z toho, co podle tebe vyžaduje největší pozornost? 16:20:27 <zzz> v neděli se můžeme krátce vrátit k 26, pokud bude potřeba 16:20:43 <str4d> EinMByte, v zásadě rozhodnout, zda je formát pro psaní návrhů použitelný a zda neomezuje to, co skončí na webu (ať už ve formátu HTML nebo TXT) 16:20:45 <zzz> takže agenda na neděli bude 1) vrp/h1/1119; 2) 26; 3) 27–29 16:20:57 <zzz> díky všem 16:21:25 * zzz *bafs* schůzka ukončena 16:27:50 <EinMByte> str4d: Asi je to OK, pokud to lze převést do většiny ostatních formátů :)