I2P Entwicklertreffen - 25. November 2014

20:04:39 <str4d> Yo 20:04:44 <str4d> Es ist Zeit für das Meeting 20:06:47 <str4d> zzz, psi, kytv, Meeh, dg 20:07:30 <psi> ist es das? 20:07:39 <psi> ah Dienstag 20:09:03 <zzz> anwesend 20:09:48 <orignal> Meeting? 20:10:11 <str4d> orignal: Besprechung der To-do-Liste von Java I2P 20:10:35 <str4d> Während wir warten, dass die anderen auftauchen: http://trac.i2p2.i2p/wiki/Roadmaps/1.0 20:10:41 <kytv> Auch anwesend, obwohl ich bei solchen Dingen normalerweise nutzlos bin. 20:11:37 <str4d> Ich habe das Gantt-Diagramm auf der obigen Seite (das ich für den 0.9.13-0.9.16-Entwicklungszyklus erstellt habe) angepasst, um zu zeigen, was wir meiner Meinung nach getan haben. 20:13:30 <zzz> interessant 20:14:06 <zzz> mehrere Destinations pro tunnel <-- ist nicht passiert 20:14:22 <str4d> Nicht? Okay, mein Fehler. 20:14:27 <zzz> findbugs-Durchlauf <-- ist passiert, kann man aber immer wieder machen 20:14:56 <str4d> Mehrere Sessions pro I2CP – das ist auch nicht passiert *derp* 20:14:56 * str4d korrigiert 20:15:48 <zzz> wow, wir hatten ein gutes Jahr (imho) 20:16:38 <eche|on> ja, das hatten wir 20:17:14 <str4d> zzz: ja, ich habe es ausdrücklich als Teil der Audit-Vorbereitung bezeichnet, aber du hast recht. 20:17:39 <zzz> neues DH untersuchen <---- ich würde sagen nur halb erledigt, jedenfalls bzgl. NTCP2 20:20:26 <str4d> Gantt zeigt halb fertig nicht so leicht an :P 20:20:34 <str4d> Seite neu laden, behoben 20:21:36 <str4d> Okay, das ist also, was wir im letzten Zyklus geschafft haben. 20:21:36 <zzz> dann nicht erledigt 20:23:45 <str4d> Zweck dieses Meetings ist es, mit der Planung für den nächsten Zyklus zu beginnen. 20:23:46 <zzz> Ich möchte wiederholen, dass ein Planungszyklus über 3–5 Releases sehr hilfreich zu sein scheint, um unseren Fokus und unsere Ressourcen zu bündeln 20:23:47 <str4d> (Wenn ich das Gantt-Diagramm aktualisiere, lasse ich die halb erledigten drin und schiebe sie nach vorne) 20:23:47 <str4d> Bei der vorherigen Sitzung habe ich die Teilnehmer gebeten, jeweils ein paar Punkte zusammenzustellen, was sie in I2P und rund um I2P erledigt sehen möchten 20:23:47 <str4d> Können wir die bitte jetzt einfügen? 20:24:21 <str4d> +1 20:24:36 <str4d> Und jetzt haben wir dafür einen Beleg! 20:26:15 <zzz> ohne darauf einzugehen, was wichtiger ist, denke ich, dass fast alles, was im Gantt-Diagramm angezeigt und noch unfertig ist, weiterhin wichtig ist 20:27:01 <str4d> Ich stimme zu. 20:27:07 <str4d> Ich möchte dennoch sehen, welche Ideen die Leute in der letzten Woche hatten, falls welche. 20:27:45 <str4d> Hier sind meine: http://pastethis.i2p/show/jF2RkHwrIPkCb0yOpI7l/ 20:27:46 <iRelay> Titel: Paste #jF2RkHwrIPkCb0yOpI7l | LodgeIt! (at pastethis.i2p) 20:28:07 <eche|on> Mir gehen die Optionen aus, ich sehe, I2P nach außen zu bringen, mit Hilfe von Bote Android, i2p messenger ist eine Option, ein XMPP-Server und Syndie. Sorry, ich halte Syndie immer noch für wichtig. 20:28:27 <str4d> eche|on: super, danke! 20:28:43 <str4d> Weiter so, her mit mehr :) 20:28:53 <eche|on> und mit der Android-App kommen restricted routes (eingeschränkte Routen) 20:28:54 <zzz> meine Liste neuer Dinge: das Red-Hat-ECDSA-Problem lösen, auf EdDSA migrieren, Jetty 9 / Java 7, die Vuze-Nutzerbasis ausbauen und mehr Marketing / Outreach / Partnerschaften / Einbettung 20:29:36 <str4d> Für die Nachwelt schreibe ich meine Ideen auch hier auf: 20:30:11 <str4d> Todo in I2P: Routerconsole-UX-Analyse und Redesign; Ideen aus Tors HS-2.0-Design übernehmen und auf I2P-Destinations anwenden; Bandbreitenplanung. Todo rund um I2P: Verbesserungen am Website-Theme; I2P-Bote Fetching-Relays implementieren; Forschung 20:30:23 <zzz> noch eins: orchid: reparieren oder abschaffen 20:30:32 <str4d> +100 20:31:13 <kytv> Bezüglich des RedHat/Gentoo-ECDSDA-Problems, vielleicht könnten/sollten wir eine Nachricht in der Seitenleiste (oder den Logs) mit einem Download-Link anzeigen. Oder den Benutzer fragen, ob ‚wir‘ es in ./lib herunterladen sollen 20:31:35 <zzz> noch eins: Test-Verbesserungen, Test-Hardware, Windows-Tests 20:31:58 <str4d> kytv: gute Ideen (aber die Diskussion kann bis zu einem anderen Meeting warten :) 20:32:03 <zzz> noch eins: mehr Geld ausgeben 20:32:36 <zzz> noch eins: China 20:32:58 <str4d> Zwischen diesen Ideen und der nicht erledigten Liste auf der obigen Seite haben wir einen guten Pool potenzieller Projekte. 20:33:34 <str4d> Mein Ziel ist es, diese Projekte aufzubereiten, zu formalisieren und auf der To-do-Seite der Website zu veröffentlichen 20:34:11 <str4d> Nachdem ich mir die To-do-Seiten anderer Projekte angesehen habe, ist dies das Format, das ich vorschlage: 20:34:11 <str4d> http://pastethis.i2p/show/nvexU3ZvSFOI6L5DrrqM/ 20:34:12 <iRelay> Titel: Paste #nvexU3ZvSFOI6L5DrrqM | LodgeIt! (at pastethis.i2p) 20:34:54 <eche|on> gute Idee 20:35:10 <kytv> dito zu Orchid 20:35:10 <kytv> Mein wichtigstes „TODO rund um I2P“ betrifft das Testen. Nicht automatisierte Softwaretests per se, sondern dass irgendeiner unserer Dienste live geht, ohne irgendeine Art von Test … einfach [puff], „es ist live … keine Ahnung, ob es funktioniert.“ 20:35:12 <kytv> In I2P: Den Installer so machen, dass er unter Windows ins Benutzerverzeichnis installiert, um jegliche Berechtigungsprobleme zu vermeiden. Sollte einfach sein, aber ich weiß nicht wie. 20:35:16 <kytv> Chrome hat das so gemacht (macht es vielleicht immer noch?) 20:35:41 <str4d> Mein ideales Endergebnis: Nutzer können zur To-do-Seite gehen und eine Liste all unserer Projektideen in und rund um I2P finden. 20:36:11 <zzz> noch eins: GSoC 20:36:14 <str4d> Oben wird es eine Tag-Cloud geben, auf die sie klicken können, um Projekte zu filtern, die bestimmte skils erfordern 20:36:17 <str4d> Skills 20:36:21 <zzz> noch eins: Sommertreffen 20:37:54 <zzz> noch eins: GNS-Untersuchung, zweiter Durchgang? 20:38:28 <str4d> mmm 20:38:54 <zzz> oder vielleicht reicht einfach noch eine Diskussion mit den Leuten 20:39:09 <str4d> Ich werde jetzt im Gantt die erledigten Aufgaben herausnehmen. 20:39:27 <zzz> kannst du es speichern und ein neues starten? 20:39:29 <str4d> zzz: welche der unteren paar wurden erledigt (SSU-Replay-Erkennung etc.)? 20:39:38 <str4d> Klar, kann ich. 20:39:49 <zzz> es ist irgendwie schön zu zeigen, dass wir tatsächlich Dinge schaffen 20:40:19 <eche|on> zzz: das meiste wurde IMHO von dir erledigt 20:40:35 <EinMByte> habe ich das Meeting verpasst? 20:40:37 <zzz> Ich glaube, ich habe alles gemeldet, was fälschlich als erledigt oder nicht erledigt stand. 20:42:39 <str4d> Neues Diagramm ist online 20:43:55 <str4d> zzz: Welche der drei ganz unten sollten nach vorne geschoben werden? Ich glaube, Client-Locking ist noch ein Thema? 20:43:59 <str4d> (client tunnel locking) 20:44:18 <str4d> zzz: Ich stimme zu. 20:44:34 <str4d> Das wird IMHO dadurch unterstützt, dass wir an der To-do-Seite arbeiten. 20:44:56 <str4d> Wenn wir die Nicht-Coding-Projekte so erklären können, dass Neulinge sie verstehen und erledigen können, hilft uns das ebenfalls. 20:44:59 <zzz> nicht 100% sicher im Moment, was dieser Client-Locking-Punkt ist, aber ich denke, er ist noch nicht fertig 20:45:08 <str4d> (Ebenso für Coding-Projekte) 20:45:32 <zzz> jup 20:45:53 * str4d schiebt auch Streaming-Verbesserungen nach vorne 20:46:03 <str4d> Kann ich SSU-Session-Replay-Erkennung dann streichen? 20:46:04 <dg> Meinst du die Duplikat-Probleme? 20:46:18 <dg> So wie wir tunnels bekommen, die sich nicht aus I2PTunnel deregistrieren und keine neuen zulassen? So etwas? 20:46:30 <zzz> str4d, ich komme wegen SSU-Replay nochmal auf dich zurück, bin mir im Moment nicht sicher 20:46:45 <dg> Ich würde lieber weniger tunnel death (Tunnelabbrüche) sehen als mehr Durchsatz 20:46:59 <str4d> dg: das könnte es sein. Es gibt auch das separate Problem, dass der I2PTunnel-Start die UI blockiert 20:47:29 <zzz> setz ‚tunnel death‘ als neuen Punkt drauf, warum nicht 20:48:01 <dg> str4d: Ganz vergessen! 20:48:03 <str4d> k 20:48:39 <zzz> Für das Locking-Ding habe ich, glaube ich, etwas Unabgehaktes im Code, das sich seit etwa 18 Monaten mitschleppt, ist aber immer noch nicht richtig 20:48:40 <str4d> Als Nächstes: die obigen Ideen durchgehen. Welche sollten auf *unsere* 6-Monats-Liste (d. h. welche soll ich ins Gantt aufnehmen)? 20:50:16 <psi> EinMByte: Meeting läuft 20:50:21 <psi> (nein) 20:51:51 <zzz> Ich schlage vor, erstmal alles dort aufzunehmen, dann sprechen wir später über Prioritäten, oder lassen die Gantt-Abhängigkeiten uns sagen, was als Nächstes zu tun ist? 20:52:52 <str4d> mmk 20:53:04 * str4d zieht die obige Liste heraus und räumt sie jetzt auf 20:53:08 <EinMByte> psi: oh großartig. 20:54:08 <psi> potenzieller Punkt: Durchsatz von tunnels und Nachrichten-Drop-Raten benchmarken 20:54:26 <str4d> EinMByte: hast du irgendwelche Ideen für unsere To-do-Liste? 20:55:15 <EinMByte> NTCP2, möglicherweise. Allerdings langfristig 20:56:39 <str4d> EinMByte: zur Referenz: http://trac.i2p2.i2p/wiki/Roadmaps/1.0 20:56:53 <EinMByte> danke 20:57:04 <EinMByte> (wollte gerade fragen) 21:00:23 <str4d> Hier ist die Liste der Ideen von allen: 21:00:24 <str4d> http://pastethis.i2p/show/K0fGRb2708ADbCTZ9u9K/ 21:00:25 <iRelay> Titel: Paste #K0fGRb2708ADbCTZ9u9K | LodgeIt! (at pastethis.i2p) 21:01:01 <str4d> Fast alle davon lassen sich in Projekte für die To-do-Seite der Website umwandeln. 21:01:36 <str4d> Nächstes Diskussionsthema: Welche davon (und die derzeit im Gantt) sind für uns in den nächsten sechs Monaten wichtiger? 21:02:48 <psi> restricted routes ist wahrscheinlich der wichtigste Punkt, IMO 21:02:50 <EinMByte> bezüglich Syndie vielleicht: Ich habe an diesem Plugin gearbeitet – im Moment aber keine Zeit). Das könnte eine der Sachen sein, die Syndie mehr Aufmerksamkeit verschaffen (kann?). 21:03:20 <dg> str4d: tunnel death fehlt und ich finde, das ist ziemlich wichtig 21:03:37 <EinMByte> Wenn jemand Interesse an Firefox-/Icedove-Plugin-Entwicklung hat: ihr wisst, was zu tun ist 21:03:37 <str4d> dg: ist drin (tunnel thread locking) 21:03:41 <str4d> Ich dachte, das sei es 21:03:49 <dg> oh, sorry str4d, ich meinte, wenn Verbindungen abrupt beendet werden 21:03:54 <dg> mein Fehler 21:04:04 <str4d> Ah, k 21:04:55 <EinMByte> psi: Ich stimme zu, restricted routes sind wichtig. Aber ich denke auch, wir sollten sehen, dass die Implementierung ziemlich viel Zeit in Anspruch nehmen wird 21:05:21 <EinMByte> (nicht sicher, wie viel vom Design / Konzept schon gemacht ist) 21:05:35 <dg> In I2P: restricted routes, RedHats ECDSA-Probleme, Tors HS 2.0, dann der Rest. Rund um I2P: Vuze-Nutzerbasis, GSoC, Forschung, Benchmark, dann der Rest. 21:06:04 <dg> Ich stimme EinMByte zu.. das Routerconsole-Redesign ist wichtig, aber das könnte eine unbestimmte Zeit dauern. 21:07:15 <EinMByte> str4d: noch eine Sache, möglicherweise. Ich kenne einige Forscher, die ein neues Konzept für eine DWSE (distributed web search engine, verteilte Websuchmaschine) entwickelt haben; sie könnten daran interessiert sein, das als I2P-Anwendung zu entwickeln 21:07:42 <str4d> EinMByte: schön! 21:07:49 <EinMByte> Da die meisten DWSEs derzeit nicht wirklich gut funktionieren, wäre das IMHO sehr interessant 21:08:01 <zzz> nein, mit ‚tunnel death‘ meinte ich 3-Minuten-Tunnelabbrüche, den Datagramm-Test vom Vuze-Typen usw. Unterschiedlich zu lokalen i2ptunnel-Locking-Problemen. 21:08:07 <EinMByte> Das ist auch etwas, das ich in Betracht ziehen würde zu implementieren 21:08:20 <dg> Ich dachte nicht genau an 3 Minuten, aber das war mit enthalten. 21:08:34 <EinMByte> (mit Hilfe, hoffentlich) 21:09:03 <str4d> k, Gantt-Seite neu laden 21:10:34 <EinMByte> str4d: Verlass dich darauf trotzdem nicht zu sehr, es hängt davon ab, ob I2P-Nutzer an so etwas überhaupt interessiert sind. 21:11:14 <EinMByte> Außerdem bin ich mir beim GNS-Kram nicht sicher. Auf jeden Fall sollte es keine hohe Priorität haben. 21:11:56 <str4d> Aktualisierte neue Ideen: http://pastethis.i2p/show/1qxHbkWjD27N7SdzNJZL/ 21:11:57 <iRelay> Titel: Paste #1qxHbkWjD27N7SdzNJZL | LodgeIt! (at pastethis.i2p) 21:12:35 <zzz> ich würde sagen, 4 breite Kategorien haben höchste Priorität: 1) kurzfristige Crypto-Migration fortsetzen (addressbook, muiltidest, etc.) 2) langfristigere Crypto-Planung/Forschung (DH, LS2, NTCP2) 3) alles rund ums Testen 4) alles Nicht-Coding 21:13:48 <EinMByte> zzz: ist das in der Reihenfolge der Wichtigkeit? 21:14:05 <str4d> ECDSA-Probleme fallen in die erste Kategorie; Tor HS 2.0 fällt in die zweite Kategorie. 21:14:21 <zzz> nein. ungefähr gleich wichtig 21:14:44 <str4d> Also ist der einzige Punkt, der in diesen Kategorien nicht vertreten ist, restricted routes 21:15:28 <jenkins@kyirc> Starting build #556 für Job i2pd (previous build: SUCCESS) 21:15:30 <jenkins@kyirc> Projekt i2pd Build #556: SUCCESS in 8.2 s: http://jenkins.killyourtv.i2p/job/i2pd/556/ 21:15:31 <jenkins@kyirc> * orignal: NTCPServerConnection entfernt 21:15:32 <jenkins@kyirc> * orignal: NTCP-Clientcode nach Transports verschoben 21:16:34 <EinMByte> vielleicht ist NTCP2 nicht *so* wichtig 21:16:50 <zzz> und der Grund, warum ich sie so gruppiert habe und gleiche Priorität sage, ist, dass es wahrscheinlich 4 getrennte Gruppen von Leuten für diese 4 Kategorien sind, die jeweils Fortschritte machen könnten 21:17:08 <EinMByte> oder zumindest, bevor wir richtig mit dem NTCP2 anfangen können, müssen wir viel recherchieren und auch ein paar sehr wichtige Fragen beantworten 21:17:33 <jenkins@kyirc> Projekt i2pd (Linux x86) Build #33: SUCCESS in 1 min 47 s: http://jenkins.killyourtv.i2p/job/i2pd%20(Linux%20x86)/33/ 21:17:44 <EinMByte> zzz: in der Tat 21:17:51 <JekabsR> es ist interessant, dass das i2p-Netzwerk dazu neigt, alle schnellen router zusammenzubringen 21:17:58 <jenkins@kyirc> Starting build #33 für Job i2pd (Linux x64) 21:18:03 <zzz> genau. „NTCP2“ ist nur eine Abkürzung für eine Menge Dinge, die möglicherweise oder möglicherweise nicht in etwas resultieren, das „NTCP2“ genannt wird 21:18:34 <JekabsR> und sie bevorzugen keine langsamen router 21:18:40 <EinMByte> Ja. Wenn wir die Transport-Layer ändern, ist es auf jeden Fall extrem wichtig, keine Fehler zu machen, da das vermutlich I2P komplett kaputtmachen würde. 21:19:19 <psi> JekabsR: langsamere router werden immer noch genutzt, nur nicht so sehr 21:19:43 <jenkins@kyirc> Projekt i2pd (Linux x64) Build #33: SUCCESS in 1 min 52 s: http://jenkins.killyourtv.i2p/job/i2pd%20(Linux%20x64)/33/ 21:20:05 <EinMByte> zzz: wenn 2 „Forschung“ ist, dann hast du allerdings recht 21:20:33 <EinMByte> das kann gleichzeitig gemacht werden 21:21:52 * str4d arbeitet das Gantt in diese vier Kategorien um (plus eine „Sonstiges“-Kategorie) 21:22:12 <JekabsR> aber es gibt ein Problem – Client-ähnliche Destinations bekommen selten schnelle router-Verbindungen 21:22:40 <eche|on> nein? 21:22:46 <psi> JekabsR: nicht ganz sicher, ob das zutrifft 21:23:46 <zzz> str4d, haben wir Android vergessen, oder ist das eine separate Roadmap? 21:23:59 <str4d> zzz: wir haben es vergessen 21:24:01 <eche|on> JekabsR: Hidden-Mode-router haben einige Probleme, aber andere bekommen schnelle Verbindungen, da genügend schnelle router verfügbar sind und freie Kapazität haben 21:24:26 <str4d> Technisch fällt I2P Android in die Kategorie „in I2P“ 21:24:35 <psi> oh, noch eine Forschungsfrage: wie viel Kapazität hat i2p gerade eigentlich? 21:25:14 <zzz> vielleicht ergibt eine 5. Kategorie für Android mehr Sinn 21:25:46 <zzz> aber ich hänge nicht an Kategorien. Ich habe die 4 nur als schnelle Art erwähnt, zu kommunizieren, was ich wichtig finde 21:25:54 <JekabsR> weil sie dazu neigen, eine kleine Zahl wirklich schneller Verbindungen und eine große Zahl langsamer Verbindungen zu erzeugen 21:26:11 <dg> [citation needed] 21:26:15 <JekabsR> mein router hat angefangen, langsame tunnels zu droppen 21:26:24 <str4d> zzz: Ich finde, das war eine gute Idee 21:26:56 <str4d> Gantt-Seite jetzt aktualisieren 21:27:07 <eche|on> JekabsR: https://geti2p.net/_static/pdf/I2P-PET-CON-2009.1.pdf 21:30:12 <eche|on> JekabsR: tunnels werden nur am Ende der tunnel-Lebensdauer gedroppt und wenn eigene tunnels die Kapazität brauchen. 21:30:29 <str4d> Wenn ihr http://trac.i2p2.i2p/wiki/Roadmaps/1.0 aktualisiert, seht ihr jetzt die Überschriften, jeweils mit einem Sechsmonatsbalken. Das gibt einen Hinweis darauf, wie viel Zeit es gibt, um alles unterzubringen. 21:32:43 <str4d> Jetzt, da wir einige Ideen für die nächsten sechs Monate haben, müssen wir mit der Zeitplanung beginnen. 21:33:18 <str4d> Und wer was angeht. 21:33:52 <JekabsR> meine Konsole meldet häufig, dass sie zu viele eingehende Verbindungen hat und tunnels teilweise abgewiesen werden. Wie entscheidet i2p, welche abgewiesen werden? 21:34:08 <dg> ‚zu viele eingehende Verbindungen‘? 21:34:21 <dg> JekabsR: Es läuft gerade ein Meeting, du solltest vielleicht warten, bis es vorbei ist 21:35:00 <str4d> Ich hätte auch gern ein paar Freiwillige, die helfen, die Ideensammlung in eine funktionierende Projektseite auf der Website-To-do zu verwandeln 21:35:12 <JekabsR> NTCP-Verbindungen: 425. Limit: 425. Timeout: 2 min. 21:35:30 <JekabsR> UDP-Verbindungen: 1149. Limit: 1275. Timeout: 4 min. 21:36:14 <JekabsR> Limits werden erreicht 21:37:42 <JekabsR> router nutzt 80% der CPU-Leistung 21:38:23 <str4d> Jemand? 21:39:36 <kytv> JekabsR: 1) Meeting im Gange, du willst vielleicht warten; 2) schau auf http://127.0.0.1:7657/peers#help 21:41:16 <JekabsR> kytv: werde ich mir ansehen 21:41:44 <zzz> str4d, ich glaube, du hast nach 1 Stunde 45 alle verloren. Vielleicht fürs Erste den Sieg erklären und wir machen ein andermal weiter? 21:41:45 <str4d> Versuchen wir ein paar spezifischere Fragen. 21:41:52 <str4d> Oder das./ 21:41:55 <JekabsR> 330,0 / 342,4 KBps meine aktuelle Last 21:42:06 <str4d> Ja, wir haben definitiv gute Fortschritte gemacht. 21:42:30 <JekabsR> und Torrent-Uploads mit 2–5 kb Geschwindigkeit :( 21:44:17 <str4d> Danke für die Diskussionen, alle zusammen! 21:44:20 * str4d wärmt den baffer auf 21:44:20 * str4d ***bafs das Meeting geschlossen