I2P Entwicklertreffen - 30. Dezember 2003

<jrandom> 0) hi <jrandom> 1) Router-Status <jrandom> 2) i2ptunnel <jrandom> 3) IM <jrandom> 4) 0.3-Pläne <jrandom> 5) Zeitsynchronisation <jrandom> 6) ??? <jrandom> hallo mihi, polo <polo> hallo! <mihi> hi jrandom <jrandom> 0) hi <jrandom> :) <rsk> hi <i2p> <duck> hi <jrandom> 1) Router-Status <jrandom> 0.2.3.3 ist draußen und scheint zu funktionieren <jrandom> natürlich gibt es noch viel zu tun <jrandom> aber dies sollte das letzte 0.2-Release sein <jrandom> 0.3 wird Peer-Profiling hinzufügen, damit router schlechte router vermeiden können <jrandom> (und 0.3.1 ist eine Überarbeitung der Transports) <jrandom> hola Ophite1 <Ophite1> Heya. <rsk> also mehr Overhead für 0.3? <jrandom> ja und nein <jrandom> es wird Peer-Tests geben, aber sie werden zielgerichteter sein <rsk> sehen wir eine Beschleunigung bei der Pfadauswahl? <jrandom> ja <jrandom> es gibt diese ‚Liveliness‘-Kalkulatoren, und es werden neue Latenz- und Durchsatz-Kalkulatoren hinzugefügt <jrandom> außerdem können Leute ihre eigenen Präferenzen für bestimmte Peers anpassen <jrandom> z. B., wenn du weißt, dass du Peer X gegenüber Peer Y bevorzugen willst, kannst du ihnen einen Gewichtungsbonus von einigen zufälligen Punkten geben <mihi> wird es einen sauberen Shutdown geben? *g* <jrandom> das ist tatsächlich eine gute Frage, mihi <jrandom> I2P kommt an den Punkt, an dem es eine Admin-Oberfläche braucht. <jrandom> Der längste Job, der den Betrieb aufhält, ist der GenerateStatusConsoleJob <jrandom> der inzwischen bis zu 4–6 Sekunden dauern kann <jrandom> (und alles andere aufhält) <jrandom> das muss asynchron und bei Bedarf laufen. <jrandom> aber ich will keinen Web-Listener / etc. schreiben. <jrandom> vielleicht umgekehrt – ein Servlet, das den router startet und mit ihm kommuniziert <mihi> du brauchst keinen vollständigen Webserver. Wenn du GET siehst, gibst du einfach deine Daten zurück. <jrandom> genau <jrandom> du hast recht, das Zeug sollte auch in 0.3 rein. <mihi> und wenn du etwas anderes siehst (wie SHUTDOWN), mach, was nötig ist. Natürlich nur von localhost ;) <jrandom> ach komm <mihi> dann kann jemand ein schönes Admin-Programm bauen <jrandom> genau <mihi> du hattest Trigger über Dateien, oder? Sind die irgendwo dokumentiert? >>> mihi [~mihi@ags9-d9ba536a.pool.mediaWays.net] hat PING 1072820995 von jrandom angefordert <jrandom> die waren in IDN, nicht im router selbst <jrandom> aber das könnte ein guter Weg sein <jrandom> das ist ein trivial einfaches System <jrandom> gute Idee, gehen wir so vor <jrandom> (und ich kann diesen Code einfach wiederverwenden :) <i2p> <duck> dieses magische Datei-Zeugs fängt an, wie plan9 auszusehen <jrandom> lol <mihi> aber Datei-Trigger erfordern Polling <jrandom> stimmt, mihi, ein Verzeichnis alle 30 s zu lesen ist nicht so schlimm <mihi> aber ein ServerSocket#accept ist günstiger. <mihi> da es keine Zeit frisst. (vorausgesetzt ein gutes OS) <mihi> okay, Datei-Trigger sind besser als nichts, klar. <jrandom> ein Server-Socket würde Remote-Admin erlauben <jrandom> (wo angebracht) <jrandom> k. A. <jrandom> muss ausgearbeitet werden. <jrandom> (oder wenn jemand aufspringen und es coden will... :) <mihi> und ein Server-Socket könnte auch die routerConsole ausliefern. <jrandom> genau <jrandom> ok, 2) i2ptunnel <jrandom> :) <jrandom> i2ptunnel rockt immer noch, und es sieht so aus, als wollten wir eine socketbasierte API hinzufügen, um es zu steuern <i2p> <anon> sind aums ic2cp2pc-Pläne vorerst vom Tisch? <jrandom> ja, ci2cp liegt auf Eis und wird durch die socketbasierte API ersetzt, um I2PTunnel zu steuern <jrandom> ich glaube, ich kann diese API in den nächsten Tagen draufpacken, damit er mit der Implementierung loslegen kann <mihi> verwende einfach einen Socket, mach in.readLine() und gib diese Zeile an runCommand() ;) <rsk> was bringt die API I2P? <jrandom> ziemlich genau das, mihi (außer dass sie die Ergebnisse formatiert und in standardisierter Form zurücksendet) <mihi> mit einem passenden „Logger“, um die Ergebnisse zurückzusenden. <mihi> s/commands/results/ <jrandom> rsk> damit können Anwendungsentwickler Client- und Server-Sockets über I2P bauen, ohne sich um die Verschlüsselungsanforderungen von I2CP kümmern zu müssen <jrandom> genau, genau <jrandom> i2ptunnel hat /tatsächlich/ Overhead in Situationen, in denen es viele i2ptunnels gibt <jrandom> unabhängig von der JVM <jrandom> i2ptunnel-Clients erstellen pro kontaktiertem Client eine neue Destination, und der router wird deutlich schlechter performen, je mehr lokale Destinations es gibt. <rsk> ah <jrandom> das liegt an den Anonymitätsanforderungen des Netzwerks in Verbindung mit unserer Verschlüsselung <jrandom> für Anwendungen, die nur ein oder zwei tunnel zu einem Peer öffnen wollen, wird diese neue API der HAMMER sein <jrandom> aber für Anwendungen, die mit vielen anderen Peers sprechen müssen, ist I2CP der richtige Weg. <jrandom> (da das eine einzelne Destination ist, multiplexed durch I2CP) <jrandom> ich schätze, es ist auf eine Weise die alte TCP-gegen-UDP-Abwägung <jrandom> mihi> hast du irgendwelche Gedanken oder Ideen zur Zukunft von i2ptunnel? <rsk> rsk> wie läuft die Arbeit an IP over I2P bzw. dem VPN-Kram? <mihi> jrandom: jemand soll eine gute Streaming-API schreiben und i2ptunnel sie benutzen lassen. <mihi> gleiches für den Naming-Server. <mihi> vielleicht ein paar Sequenznummern hinzufügen, falls niemand das Obige macht. <mihi> was eine inkompatible Änderung bedeuten wird. <jrandom> inkompatible Änderungen sind nicht schlecht, wir sind noch früh in der Entwicklung <jrandom> (wenn wir auch die Größe der IDs auf zwei oder vier Bytes pro Seite erhöhen könnten?) <mihi> die Streaming-API wird dennoch eine inkompatible Änderung sein. und wenn I2P funktioniert, brauchen wir keine Sequenznummern. <jrandom> rsk> auf Eis, bis jemand Zeit hat, es aufzunehmen? ≡ rsk/#i2p findet, dass inkompatible Änderungen die besten sind <jrandom> genau, mihi <mihi> ID sollte derzeit 3 Byte sein, warum also auf 2 Bytes *erhöhen*? <jrandom> mihi> eigentlich würde ich mode=GUARANTEED gerne langsam ausmustern und das in der Streaming-API implementieren ≡ mihi/#i2p auch <jrandom> wobei I2P = IP bleibt, nicht TCP oder UDP <jrandom> verdammt, ich wünschte, ich hätte noch 14 Stunden am Tag. <mihi> nur 14? ;) <jrandom> ;) <jrandom> werden die 3-Byte-IDs nicht von beiden Seiten der Verbindung abgeleitet? Oder bin ich nur verwirrt <mihi> jede Seite hat eine ID von 3 Bytes, allerdings muss jeweils nur eine gesendet werden. <jrandom> vielleicht implementiere ich die Streaming-API, reiße GUARANTEED raus und füge als Nächstes diesen Socket-Controller hinzu. <jrandom> ah ok <mihi> siehe /apps/i2p/i2ptunnel/java/src/protocol.txt <jrandom> genau, genau <mihi> btw, wer hat diese Datei *dort* falsch abgelegt? ≡ jrandom gibt eco die Schuld ;) <jrandom> warte, nee, du hast sie dorthin gelegt <jrandom> oder? <jrandom> oh warte, nein, ich habe sie importiert ≡ jrandom gibt sich selbst die Schuld, dumm zu sein. <jrandom> (la la la) <jrandom> verdammt. ok, ja, an der Streaming-API und dem Socket-Controller zu arbeiten, ermöglicht es mir, über das Peer-Testing/Profiling/Selection-Manifest nachzudenken <jrandom> ich poste das in ein paar Tagen zur Kommentierung <jrandom> (und es holt meinen Kopf aus dem router raus. variety++) <jrandom> mihi> noch etwas zu i2ptunnel? <mihi> nicht, dass ich wüsste <jrandom> cool <jrandom> (danke nochmal, dass du dir Zeit nimmst, dich hier einzubringen, ich weiß, du bist mit fiw und dem Rest beschäftigt) <jrandom> ok, thecrypto ist nicht hier, aber er macht Fortschritte an der IM-App. <jrandom> (das ist Tagesordnungspunkt 3) <jrandom> 4) 0.3-Pläne <jrandom> 0.3.0 ~= Peer-Profiling-Kram, und jetzt wird es auch die Streaming-API und diesen Socket-Controller für i2ptunnel enthalten <jrandom> aber, wenn man es nicht erraten konnte, es wird nicht am 1. Januar veröffentlicht <jrandom> der 15. Januar ist eine Außenseiter-Option. Wir werden sehen, wie es läuft. <jrandom> 0.3.1 ist kein voller Monat Arbeit, daher muss es vielleicht nicht verschoben werden. <jrandom> abgesehen davon ist die Roadmap noch weitgehend im Plan und repräsentativ dafür, wohin wir uns bewegen <jrandom> 5) Zeitsynchronisation <jrandom> eine neue FAQ ist unter http://wiki.invisiblenet.net/iip-wiki?I2PTiming veröffentlicht <jrandom> mihi, du hattest einen Vorschlag zur vierten Option dort (eine eigene Zeitbestimmung innerhalb von I2P bauen)? <jrandom> hi brawl <mihi> jep. ∙φ∙ brawl heißt jetzt eco_ <eco_> hi Leute <jrandom> oh heya eco <mihi> wir haben gerade die Streaming-API / tunnel-API diskutiert <mihi> und dann hackst du dir ein eigenes getTimeMillis zusammen, das das korrigiert. <Ophite1> mihi: Nein, das solltest du nicht. <jrandom> mihi> wenn ein Angreifer 1000 Nodes mit falscher Zeit erstellt, werden alle in die Bredouille gebracht <jrandom> (da sich der Durchschnitt irgendwohin verschiebt) <mihi> wenn ein Angreifer 1000 Nodes erstellt, sind doch sowieso alle geliefert...? <rsk> wäre das nicht selbstkorrigierend? <Ophite1> mihi: OK, 3. <jrandom> nein, das sollten wir handhaben können, mihi. <mihi> okay, dann nutze den Durchschnitt nur, wenn die Standardabweichung kleiner als 1 s ist oder so. <rsk> wenn alle die gleiche Zeit haben, ist es okay, selbst wenn diese Zeit falsch ist, oder? <jrandom> rsk> wenn alle 1000 Nodes synchron wären – aber was, wenn sie alle zufällig verteilt sind <mihi> verwende nur Zeiten, die nah genug beieinander liegen. Wenn nicht, nimm 3 neue Nodes. <jrandom> mihi> richtig, wir könnten NTP implementieren (was im Grunde tut, was du sagst, indem es eine Reihe von Kandidaten-Durchschnitten nutzt, um iterativ an die korrekte Zeit heranzukommen <mihi> aber wir müssen uns nicht um alles kümmern (wie Ping-Latenzen), wie NTP es tut. <Ophite1> wenn wir das nicht täten, mihi, würde die Zeit langsam rückwärts kriechen. ≡ mihi/#i2p findet, das ist besser, als die Nutzer ihre Zeit individuell einstellen zu lassen. <jrandom> also landet jeder, der zufällig 3 dieser verschobenen Nodes wählt, in seinem eigenen privaten Netzwerk? <jrandom> was ist mit der dritten Option - <jrandom> I2P hat eine Komponente, die bei einem echten NTP-Server via NTP oder SNTP nachfragt <mihi> wenn du nur verschobene Notes in deiner netDB hast, bist du ebenfalls in diesem privaten Netz... <jrandom> anstatt das Rad neu zu erfinden <Ophite1> obwohl mir das teilweise gefällt... <Ophite1> NTP ist nicht signiert, es ist anfällig für einen MITM-Angriff. <Ophite1> oder DNS-Cache-Poisoning für z. B. time.nist.gov <jrandom> stimmt, Ophite1, aber mit 200.000+ SNTP- oder NTP-Hosts ist das eine große Angriffsfläche. <jrandom> wir würden definitiv nicht gegen time.nist.gov synchronisieren. <Ophite1> Verbindungen von I2P zum Zeitserver der NSA könnten ein paar Augenbrauen heben, ne? :) <jrandom> und wenn ein Angreifer time.nist.gov angreift, sind überall alle betroffen <jrandom> heh <mihi> dann kombinieren wir beides. Frag einen „echten“ NTP-Server und deinen Nachbarn. Wenn beide das Gleiche sagen, ist es okay. <jrandom> also noch /mehr/ Code ;) <jrandom> aber ja, das ist vernünftig. <Ophite1> Das ist interessant. Und wenn nicht? <Ophite1> einen anderen NTP-Server wählen? <jrandom> den Peer ablehnen. <mihi> anderen NTP-Server und einen anderen Peer versuchen. <mihi> bis du eine Übereinstimmung hast. Dann alle bisherigen Peers ablehnen. ≡ mihi/#i2p tippt langsamer als jrandom :( <Ophite1> Übereinstimmung innerhalb eines bestimmten Schwellenwerts, sagen wir 1 s? <jrandom> 1 s wäre gut. <jrandom> Peers bis zu etwa 30 s akzeptieren (um mit Lag umzugehen) <Ophite1> ist 1 Sekunde auf STARK BELASTETEN Verbindungen okay? <jrandom> 1 s fürs Syncen, 30 s für die Kommunikation. <Ophite1> ich habe gesehen, dass die Latenz bei DSL auf 5 Sekunden steigt, wenn man böse Dinge damit anstellt. <jrandom> mit TCP oder UDP? <Ophite1> aber dann ist dieser Host in dem Fall vermutlich ohnehin nicht der, zu dem du die Zeit synchronisieren willst ;) <jrandom> stimmt <Ophite1> UDP. <jrandom> hmm 'k <Ophite1> man hätte gedacht, es würde gedroppt :) <i2p> <duck> ich denke, das Problem ist eher, den Nutzer wissen zu lassen, dass es ein Problem gibt <jrandom> duck> das stimmt. <i2p> <duck> erst nach dem Durchgehen großer Logs sehen sie, dass ihre Uhr falsch geht (wenn sie es finden) <Ophite1> Vielleicht. So ungefähr. <i2p> <duck> oder dass der Port bereits belegt ist <jrandom> eine Admin-Oberfläche wäre schön. <i2p> <duck> die Welt ist besser, wenn alle NTP verwenden, verbunden mit ihrem lokalen stantrum (sp) 2-Server CTCP Cloaking ist jetzt [An] <jrandom> vielleicht bringen wir ein 0.4-Release mit einer Menge Aufräumarbeiten und Endnutzer-Dingen, bevor wir auf 1.0 gehen? <jrandom> genau (stratum) <i2p> <duck> nur Windows-Clients haben das wahrscheinlich nicht <i2p> <duck> aber sie sind auch nicht unbedingt stabil <jrandom> Windows hat NTP <i2p> <duck> also wen kümmert's <Ophite1> duck: Windows XP und Windows Server 2003 enthalten NTP. <jrandom> eine ganze Ecke einfacher als unter Unix auch <Ophite1> standardmäßig zu time.windows.com synchronisiert, iirc. <jrandom> mit Dropdown-Optionen für andere <Ophite1> Es ist ein wesentlicher Bestandteil der Windows-Produktaktivierung. <Ophite1> kann nicht ablaufen, wenn man die Zeit nicht kennt :) <jrandom> heh <mihi> keine Option an meiner Uni... alle Uhren gehen 1 bis 5 Stunden falsch. aber ich darf I2P dort vielleicht ohnehin nicht laufen lassen... <Ophite1> mihi: I2P sollte sich besonders bemühen, in so einer Situation zu funktionieren... <jrandom> mihi> großartig! Du kannst helfen, den Hidden-Operation-Modus zu testen :) <jrandom> nebenbei: Ich werde diesen Sommer etwas reisen <jrandom> ich werde wahrscheinlich offline sein, ohne meinen Laptop. <i2p> <duck> Nebenbei-Gedanke: ntp.duck.i2p :) <Ophite1> Sieh es so: Brianna Kazaa lädt einen coolen neuen anonymen Filesharing-Client herunter, von dem ihre beste Freundin sagte, er sei echt cool und man könne heimlich mit Leuten chatten und so. Wollen wir ihr sagen, dass sie ihre Uhr auf 30 Sekunden genau stellen muss (woher soll sie die bekommen)? Oder wollen wir, dass es einfach funktioniert? <jrandom> aber ich werde dafür sorgen, dass ich mit nur öffentlichen Terminals weiterhin auf I2P sein kann. CTCP Cloaking ist jetzt [Aus] <jrandom> keine Frage, Ophite1. Einfach funktionieren (mit Doku für Geeks) <jrandom> duck> Bootstrap ;) <jrandom> und I2P wird /keine/ Root-Rechte benötigen. <Ophite1> Genau das ist mein Punkt. <Ophite1> jrandom: Würdest du einen router auf einer Maschine laufen lassen, auf der du keine Root-Rechte hast? <jrandom> also ja, ein Mix aus Option 3 und 4 <Ophite1> Option 3,5 klingt für mich cool ;) <jrandom> Ophite1> ich würde hundert davon laufen lassen :) <mihi> Option 3,1415926... <jrandom> (und weiter ins nächste Labor, noch hundert laufen lassen) <Ophite1> Ooh. Pie. Lecker.;) <Ophite1> jrandom: Ich sagte, du hättest dort keine Root-Rechte. Amateur. :) <jrandom> lol <jrandom> so, das ist im Wesentlichen, worauf wir hinauswollen. <jrandom> bis die Zeit-Sachen implementiert sind, sollten alle Option 1 oder 2 verwenden. <jrandom> für Option 2: Wenn jemand etwas Doku schreiben könnte, würde ich das schätzen <Ophite1> das ist für den Moment akzeptabel, da wir für Brianna Kazaa & Co. Noch Nicht Bereit sind ;) <mihi> zur Info: Ich werde „hidden operation“ nicht testen. mein Uni-Account wurde schon einmal deaktiviert und ich möchte ihn nicht noch einmal blockiert bekommen... <Ophite1> mihi: Du bist der beste Test, den wir überhaupt haben könnten. <jrandom> Ophite1 > nicht zum Testen. <jrandom> 'k mihi, wir finden einen Weg, und sobald es bereit ist, wirst du es nutzen können. <Ophite1> OK, vielleicht nicht testen. Manche Unis werden so biestig, dass sie dich rauswerfen, statt dich nur zu blocken. <Ophite1> Ich kenne jemanden an der in den USA am stärksten Anti-Filesharing, pro-RIAA eingestellten Universität. Er betreibt einen 2-Gbit-Dumpsite. <jrandom> lol nice <Ophite1> mir ist klar, dass sehr, sehr wenige Leute so mutig sind. <jrandom> ok, das war's zur Zeitsynchronisation. <jrandom> eco_> hi. Irgendwelche BT-Sachen, über die du sprechen willst? {oder bis nächste Woche aufheben} <Ophite1> aber bedenke, dass der Großteil des Internets in Zukunft wahrscheinlich universitär/unternehmensgetrieben sein wird. I2P könnte verboten werden. I2P könnte SEHR WOHL von großen ISPs als Missbrauch angesehen werden. I2P muss trotzdem funktionieren. <Ophite1> Ich habe ein paar interessante Ideen in dieser Richtung, die ich zu einem späteren Zeitpunkt vorstellen werde. <jrandom> word <Ophite1> (Transport) <rsk> I2P wird von großen ISPs als Missbrauch betrachtet, lies deinen Vertrag <Ophite1> rsk: einen verteilten Proxy-Cache betreiben? <rsk> irgendeinen ‚Server‘ betreiben <Ophite1> rsk: Nicht, solange es nicht zu SMTP oder WWW weiterleitet. <jrandom> Services jeglicher Art betreiben <jrandom> genau <Ophite1> rsk: Hehe, ich habe dafür eine Lösung ;) <eco_> jrandom: kann ein kurzes Update geben <jrandom> die Bühne gehört dir :) <eco_> ich porte den Java-basierten BitTorrent-Client Snark (www.klomp.org/snark), um mich mit I2P vertraut zu machen <eco_> der erste Port läuft auf i2ptunnel, ruft direkt die Java-Klassen auf <eco_> aktueller Stand: funktioniert mit 2 Peers, bei > 2 geht's durcheinander, tunnels werden nicht aufgeräumt, daher ist Neustarten schmerzhaft <eco_> ETA: dieses Wochenende ≡ eco_/#i2p merkt, dass dies als > 2003 angesehen werden könnte <jrandom> w00t! ≡ jrandom hackt time.nist.gov <eco_> ein „echter“ Port würde den Overhead der tunnels wahrscheinlich reduzieren, aber das ist der nächste Schritt <jrandom> cool ≡ eco_/#i2p gibt die Bühne zurück an MC jrandom <jrandom> 'k, ich glaube, das war's <jrandom> 6) ??? <jrandom> hat noch jemand etwas? ≡ eco_/#i2p möchte seinen Dank für die bisher von jrandom cs gut gemachte Arbeit aussprechen <eco_> und dass Schlaf für Homo sapiens irgendeinen Nutzen hat, obwohl jrandom das Gegenteil zu beweisen scheint <jrandom> ;) <jrandom> was haltet ihr davon, uns vorerst hier statt auf IIP zu treffen, bis I2P zuverlässig genug ist? <jrandom> ich persönlich habe es satt, dass die Meetings jede Woche zerrissen werden. <i2p> <anon> lilo ist Mist! <eco_> wir könnten dadurch, dass wir hierher gehen, Leute ausschließen <jrandom> tun wir, ich weiß. <jrandom> wenn wir eine iip<-->hier-Bridge <i2p> <duck> IIP schließt jeden Tag Leute aus <jrandom> wäre das gut. <jrandom> genau. <jrandom> IIP ist leider unbrauchbar für eine zuverlässige Entwickler-Community. <i2p> <duck> http://banaan.zeelandnet.nl/open/changate.html <i2p> <duck> das ist der Code, auf dem eyeKon etc. basiert <jrandom> und obwohl ich gerne alleine vor mich hin codiere, kommt ihr mit wirklich guten Ideen und macht essentielle gute Sachen, die wichtig sind ≡ rsk/#i2p schreibt ein Windows-Update-Skript <i2p> <duck> theoretisch könnte es sich mit 3 Servern verbinden und jeden von ihnen spiegeln <jrandom> word, duck, vielleicht versuche ich, eines auf i2p.dnsalias.net zum Laufen zu bringen <jrandom> Ping-Flood aus der Hölle ;) <eco_> IRC auf duck.i2p war heute ziemlich gut, besser als IIP <jrandom> einverstanden <jrandom> hat mich aber ein paar Mal rausgeworfen. <jrandom> vielleicht wird es nächste Woche zuverlässiger <eco_> es liegt in deinen Händen :-) <jrandom> die Zuverlässigkeit wird sich wahrscheinlich erst mit 0.3 verbessern, das in ~2 Wochen ansteht <jrandom> (1 Woche für den tunnel/Streaming-Kram, 1 Woche für Peer-Profiling/Tests) <jrandom> dann kommen die Bugs, die das mitbringt :) <jrandom> allerdings sollte ich sagen, dass ich gestern Abend ziemlich begeistert war, Audio von aum zu streamen <jrandom> und ardvark konnte 42 Minuten ohne Buffering streamen! <jrandom> also sind wir vielleicht zuverlässig genug <jrandom> (mein lokaler router kann nur phttp, was vermutlich ein kleiner Grund ist) <jrandom> ok, hat noch jemand etwas? <i2p> <duck> kann an nichts denken ≡ eco_/#i2p ich auch nicht ≡ jrandom holt aus... ≡ jrandom *baf*t das Meeting zu