I2P Entwicklertreffen - 24. Oktober 2006

16:03 <jrandom> 0) hi 16:03 <jrandom> 1) Netzstatus 16:03 <jrandom> 2) Syndie-Entwicklungsstatus 16:03 <jrandom> 3) ??? 16:03 <jrandom> 0) hi 16:03 * jrandom winkt 16:03 * Complication stolpert dorthin, wo die Tastatur in Reichweite ist (der Wochenanfang war die Hölle, aber jetzt ist es vorbei) 16:04 <jrandom> (Hurra auf höllische Anfänge!) 16:04 <jrandom> Wöchentliche Statusnotizen unter http://dev.i2p.net/pipermail/i2p/2006-October/001315.html 16:04 <+Complication> Hallo 16:05 <jrandom> während ihr die (kurzen) Notizen lest, springen wir zu 1) Netzstatus 16:05 * jrandom ist jetzt seit 3 Tagen ohne Disconnect mit freshcoffee verbunden, und es sieht so aus, als hätten beide irc-Server eine gute Zahl an Nutzern 16:06 <jrandom> stats.i2p ist auch wieder da, und die tunnel-Erfolgsrate macht ein paar merkwürdige Sprünge, ist aber insgesamt auch in guter Verfassung 16:06 <jrandom> (wenn auch immer noch im Bereich 20–30) 16:06 <jrandom> ((was viel besser ist als 5–10, aber viel schlechter als 60–80)) 16:07 <jrandom> ok, hat jemand etwas zu 1) Netzstatus? 16:08 <+Complication> Ähnlich hier, aber keine extra-persistenten Verbindungen 16:08 <+tethra> außer Applaus nichts von mir! 16:08 <+Complication> Ich wollte nur kurz etwas zu NTP-Problemen anmerken 16:09 <+Complication> Kurz gesagt: Am Sonntag, 29. Okt., stellen einige Zeitzonen von Sommerzeit auf Normalzeit um 16:09 <jrandom> (das wird nerven) 16:10 <+Complication> Ich hoffe persönlich, dass das niemandem Probleme bereitet, aber ich kenne mich mit NTP nicht gut genug aus, um sicher zu sein 16:10 <+Complication> Also, falls die jüngste NTP-Server-Sanity-Prüfung (hinzugefügt mit Version .26) in dieser Nacht jemanden stören sollte... 16:11 <+Complication> ...dachte ich, es wäre besser, den Konfigurationsschlüssel zu erwähnen, mit dem man sie deaktivieren kann (falls Bedarf besteht) 16:11 <+Complication> (damit Leute, die die Statusnotizen lesen, Bescheid wissen) 16:12 <+Complication> Deaktivieren kann man sie, indem man die Zeile "router.clockOffsetSanityCheck=false" in http://localhost:7657/configadvanced.jsp einträgt 16:12 <+Complication> Aber wie gesagt, ich hoffe, dass das niemand braucht 16:13 <+Complication> Es wird jedoch interessant zu beobachten sein, wie sich das Netzwerk in dieser Nacht verhält, wenn unterschiedliche Zeitzonen umschalten 16:13 <+Complication> Ich werde auf jeden Fall beobachten, in der Hoffnung, dass man etwaige Anomalien bis zum Frühjahr beheben kann :D 16:14 <jrandom> die Umschaltminute wird wahrscheinlich ziemlich holprig sein, sollte sich aber kurz darauf wieder einrenken 16:14 <+Complication> ... und das war's von mir. :) 16:14 <jrandom> aber hoffentlich klappt's, und wenn nicht, wie du sagst, gibt's den Frühling :) 16:14 <bar> und falls es doch b0rkt, sind neulich im Chat zwei mögliche Vorschläge für zukünftige Verbesserungen aufgetaucht: 16:15 <bar> "verhindern, dass routers mit Zeitabweichung Subnetze bilden, indem die Kontrolle an NTP übergeben wird, falls Peers <some number" 16:15 <bar> ... und "floodfill-Peer-router-Infos nicht aus dem netdb löschen, wenn es zu wenige davon gibt" 16:15 <jrandom> aye 16:16 <+Complication> In der Tat, das Anpassen der erforderlichen Anzahl an Datenpunkten (verfügbare Peer-Uhrabweichungen), die nötig sind, um Peer-Zeitabweichungsmessungen als verlässlich zu erachten 16:16 <+Complication> (ups, etwas Redundanz in meinem letzten Satz) 16:17 <+Complication> ... und ja, die floodfill-Prüfung. Ich nehme an, dass es derzeit keine ähnliche Prüfung gibt? 16:18 <jrandom> richtig 16:18 <+Complication> Scheint so, als ob es manchen Leuten mit etwas Glück oder Magie gelegentlich gelingt, floodfill-Peers aus den Augen zu verlieren 16:19 <jrandom> das sollte auf jeden Fall behoben werden 16:19 <jrandom> (hat neulich einige erwischt, als einer davon per Nullroute blockiert wurde) 16:20 <jrandom> (if #floodfill == 0, vielleicht ein paar zufällig als floodfill behandeln) 16:20 <+Complication> Wenn das machbar ist, dann auch möglich 16:21 <+Complication> Allerdings wäre es vielleicht doppelt sicher, das zusätzlich dazu zu tun, dass man mindestens 2 (oder so) floodfill-Peers behält 16:22 <jrandom> aye 16:25 <jrandom> ok, hat noch jemand etwas zu 1) Netzstatus? oder sollen wir zu 2) Syndie-Entwicklungsstatus übergehen? 16:25 <badger> zur irc-Stabilität: sehe serverseitig viel, viel, viel weniger Reconnects. 16:25 <badger> man könnte es fast einen Service nennen :) 16:26 <jrandom> :) 16:28 <jrandom> ok, springen wir zu 2) Syndie-Entwicklungsstatus 16:28 <jrandom> viel Fortschritt hier, wie in den Statusnotizen erwähnt 16:28 <jrandom> es gab dazu hier in den letzten Tagen auch eine Menge Diskussion 16:28 <jrandom> möchte jemand dazu etwas einbringen? 16:30 <@cervantes> installier etwas anderes als mspaint 16:30 <jrandom> heh 16:30 <jrandom> nun, es hat seinen Wert, zum Skizzieren *hässliche* Dinge zu verwenden – das dämpft die Erwartungen 16:31 <+fox> <HotTuna> die Links im Forenbeitrag scheinen down zu sein ... einige jedenfalls.. 16:31 <@cervantes> Ich glaube, das wird in den Beiträgen erwähnt 16:31 <+fox> <HotTuna> oh. . sorry 16:31 <jrandom> hottuna: sie sind gespiegelt @ dev.i2p.net/~jrandom/mockup/ 16:31 <@cervantes> einige sollten weiter unten gespiegelt sein 16:32 <+Complication> Eine Frage: Denkst du, es ist einfacher, begrenztes HTML (sicher) von Grund auf zu implementieren, ohne einen Webbrowser auseinanderzunehmen? 16:33 * jrandom hat gerade zwei weitere Bilder hochgeladen: dev.i2p.net/~jrandom/mockup/forum.webp und blog.webp (zeigen die Diskussion der letzten Tage über verschiedene Arten, ein Forum anzuzeigen) 16:33 <@cervantes> definitiv am einfachsten, das sicher zu machen 16:33 <+Complication> (bin nur neugierig, was auf der GUI-Seite passiert, da ich das etwas verpasst habe) 16:33 <jrandom> Complication: Ich habe für allgemeine Formatierungszwecke schon fast alles fertig 16:33 <@cervantes> zumal syndie nur einen begrenzten html-Subset unterstützen wird 16:34 <+Complication> Aha 16:34 <jrandom> (Schriften, Ausrichtung, Größen, Farben, Bilder, Links, Listen (inklusive verschachtelter), Überschriften, Absätze, html-Entities) 16:35 <jrandom> divs für Layout oder Tabellen zu machen, erfordert hingegen erheblich mehr Arbeit, aber das gehe ich jetzt nicht an 16:35 <+Complication> Klingt gut genug 16:36 <@cervantes> und natürlich der <blink>-Tag 16:36 * jrandom bewirft cervantes mit † 16:37 <@cervantes> aua, von einer Entity aufgespießt 16:37 <jrandom> wir werden sehen. wie es ausgerollt und genutzt wird, ist es vielleicht nötig, auf eine vollwertige html-Rendering-Engine umzusteigen 16:38 * jrandom möchte den Code-Bestand allerdings so klein wie möglich halten, damit es weniger zu debuggen und zu prüfen gibt, was Sicherheit und Anonymität angeht 16:39 <+Complication> In der Tat, es gibt zweifellos Vorteile, text/plain zu verwenden 16:40 <+Complication> (was hoffentlich nur Angriffe in natürlicher Sprache unterstützt ;P ) 16:41 <+Complication> Was haltet ihr von der Möglichkeit von hashcash-Antispam-Maßnahmen? Noch zu früh, um das zu sagen? Glaubst du, man könnte das später leicht nachrüsten? 16:42 <@cervantes> nun, ich denke, die Verwendung von bbcode oder Wiki-Syntax würde das Risiko von Markup-Injection in einer vollwertigen html-Engine reduzieren 16:42 <@cervantes> *Rendering-Engine 16:43 <jrandom> ziemlich leicht nachzurüsten, Complication – einfach ein neuer öffentlicher Header (hashcalc'ed gegen die kanonische syndie-uri, beim Import verifiziert, beim Signieren erzeugt) 16:44 * Complication hat vor ein paar Tagen kurz darüber nachgedacht, aber nur oberflächlich 16:44 <jrandom> hashcash kann auch auf mehreren Ebenen erfolgen – pro neuem Channel (meta.syndie), pro aktualisiertem Channel oder pro Post (vielleicht sogar abgestuft nach sizeof(post) oder #msgs/day) 16:44 <+Complication> Wenn man hashcash als Proof of Work implementieren wollte, frage ich mich, worauf der Absender am besten Kollisionen berechnen sollte? 16:45 <+Complication> Aha, die uri... könnte es tatsächlich sein 16:45 <+Complication> Oh, in der Tat 16:45 <+Complication> Das sind Dinge, an die ich nicht gedacht hatte 16:48 <jrandom> cervantes: stimmt schon 16:48 <jrandom> ok, hat noch jemand etwas zu 2) Syndie-Entwicklungsstatus? 16:51 <jrandom> ok, wenn nicht, springen wir zu 3) ??? 16:51 <jrandom> möchte jemand noch etwas ansprechen? 16:54 <jrandom> ok, wenn nicht... 16:54 * jrandom holt aus 16:54 * jrandom *baf*t das Meeting