I2P Entwicklertreffen - 18. Januar 2005

13:04 <jrandom> 0) hi 13:04 <jrandom> 1) Netzstatus 13:04 <jrandom> 2) 0.5 13:04 <jrandom> 3) i2pmail.v2 13:04 <jrandom> 4) azneti2p_0.2 13:04 <jrandom> 5) ??? 13:04 <ant> <duck> (das Geräusch, wie der Krypto-Talk an meinen Ohren vorbeifliegt) 13:04 <jrandom> :) 13:04 * jrandom winkt 13:04 <cervantes> 'lo 13:04 <jrandom> auch du kannst dem Geräusch lauschen, wie der Krypto-Talk an deinen Ohren vorbeifliegt! Wöchentliche Statusnotiz veröffentlicht @ http://dev.i2p.net/pipermail/i2p/2005-January/000559.html 13:05 <bla> hi 13:05 <jrandom> springen wir gleich rein, da wir sowieso in eine interessante Diskussion reinplatzen... 1) Netzstatus 13:05 <jrandom> ich habe wirklich nichts hinzuzufügen über das hinaus, was in der Mail steht – hat jemand etwas, das er zum Netzstatus anbringen möchte? 13:06 <bla> Außer, dass wir zum ersten Mal Knoten auf *allen* Kontinenten außer der Antarktis gesehen haben, nein. 13:06 <jrandom> w00t! 13:07 <jrandom> ok, weiter zu 2) 0.5‑Kram 13:07 <mule> hey, mein Vater ist gerade auf dem Weg in die Antarktis, hätte ihm einen Knoten mitgeben sollen 13:07 <ant> <duck> verdammte Antarktikaner 13:07 <Xan> keine Antarktikaner? :( 13:07 <jrandom> hah, nice 13:07 <jrandom> obwohl ich nicht glaube, dass es dort oben viel Anonymitätsmenge gibt 13:07 <Frooze> gib der Antarktis die Schuld 13:08 * cervantes richtet eine Ölplattform in der Antarktis ein, damit er dort einen Knoten finanzieren kann 13:09 <jrandom> ok ok, es gibt eine Menge 0.5‑Kram, also können wir es stückweise angehen 13:09 <jrandom> zuerst: Danke an die Leute, die einen Tag lang Stats gesammelt haben – viele interessante Daten @ http://dev.i2p.net/~jrandom/messageSizes/ 13:09 <postman> war mir ein Vergnügen :) 13:10 <cervantes> bzgl. Netzstatus... habe in letzter Zeit einige Leute gesehen, die Probleme haben, I2P zum Laufen zu bringen (im Forum usw.) – ich weiß nicht, ob das nur am gestiegenen Nutzeraufkommen liegt oder vielleicht an mehr I2P‑basierten Apps, bei denen mehr schiefgehen kann 13:10 <+protokol> jrandom: LÜGNER! Du hast gesagt, die Daten wären interessant! 13:10 * jrandom wirft Schlamm auf protokol 13:11 <ant> <duck> cervantes: Ich habe auch Berichte gesehen, dass Leute es innerhalb weniger Minuten ans Laufen bekommen 13:11 <ant> <duck> Ich denke, NAT verursacht die meisten Probleme 13:11 <cervantes> duck: stimmt... 13:11 <ant> <dmdm> wer ist NAT? 13:11 <jrandom> cervantes: Es gibt noch einige unschöne Probleme, klar. Das NAT‑Problem und OS X waren zuletzt etwas nervig, aber Jhors Hilfe beim Letzteren sollte das Letztere verbessern 13:12 <cervantes> aye 13:12 <cervantes> *hust* also... 0.5 13:13 <Xan> dmdm: network address translation 13:13 <jrandom> heh, ok. Im Grunde dient die Erhebung dieser Nachrichten‑Größenstatistiken dazu, die Padding‑Probleme zu untersuchen 13:14 <jrandom> leider war die Strategie, die ich mir durch Rosinenpicken von Zahlen gebaut habe, Mist und führte allein durch Padding‑Daten zu 25% Overhead 13:14 <jrandom> wenn wir einem der Vorschläge für die 0.5‑Verschlüsselung folgen (tunnels-alt.html), haben wir dieses Problem nicht 13:15 <jrandom> (da es kleine feste Größen mit Fragmentierung erzwingt) 13:15 <mule> welche Art von Nachrichten willst du padden, die ein router sieht oder die ein externer Beobachter sieht? 13:15 <jrandom> mule: wichtige Frage 13:15 <jrandom> wenn wir uns nur um den externen Beobachter sorgen, können wir die Nachrichten ungepaddet lassen und etwaige Füllverkehr (Chaff)‑Generierung auf der Transportebene machen 13:16 <Teal`c> http://microsoft.i2p/david_hasselhoff_05_christmas_album__silent_night.mp3 13:16 <jrandom> andererseits, wenn wir uns Sorgen um tunnel‑Teilnehmer machen, die Verkehrsanalyse betreiben, müssen wir auch um Padding im tunnel kümmern 13:16 <@duck> wie groß ist die Gefahr, dass ein router bei 5–6 Hops eine Verkehrsanalyse macht? 13:16 <cervantes> Teal`c: Meeting gerade... kannst du #i2p-chat für MP3‑Ankündigungen nutzen ;-) 13:17 <Teal`c> sorry 13:17 <cervantes> :) für David Hasselhoff? 13:18 <jrandom> kommt darauf an, auf welches Niveau der Analyse, duck. Wenn sie irgendwie herausgefunden haben, in welchem tunnel sie sind (z. B. sie sind das Inbound tunnel Gateway und haben die netDb geharvestet und das mit einer Destination korreliert), ist das nichttriviale Information. Andererseits ist es keine direkte Enttarnung, gibt aber schon Hinweise 13:18 <jrandom> noch wichtiger als das tunnel‑Padding ist jedoch End‑to‑End‑Padding, um Nachrichtenflussdaten vor Gateways und Endpunkten zu verbergen. 13:19 <jrandom> wenn wir verrückt/dumm sind, könnten wir bis zu einem Pipenet gehen und überall konstante Bitrate verwenden 13:19 <+polecat> Hab’s! 13:19 <jrandom> (und am Ende hat niemand mehr i2p am Laufen) 13:19 <+polecat> Was wir tun müssen, ist i2p über E‑Mail zu tunneln! 13:19 <cervantes> wie wahrscheinlich ist es, dass kolludierende router im selben tunnel auf einem hinreichend großen Netzwerk landen? 13:19 <+polecat> Kein ISP wäre so dumm, E‑Mail zu stoppen! 13:20 * jrandom wartet auf die net.i2p.router.transport.gmail Implementierung 13:20 <postman> polecat: oh mann, das ist albern 13:20 <postman> :) 13:20 <bla> cervantes: N^(-h) (N ist # der schnellen Knoten, h = # Hops). So scheint es 13:20 <+polecat> =3 Ich weiß. 13:21 <cervantes> ist das viel? :) 13:21 <jrandom> nicht die # der schnellen Knoten, da Externe deine Profile nicht kennen 13:21 <+polecat> Im Ernst, in schamloser Zweckentfremdung bestehender IP‑Dienste könnten wir i2p auf vielfältige, geniale Weise tunneln. 13:21 <jrandom> c^2/N^h, um zwei Peers in denselben tunnel zu bekommen 13:21 <jrandom> einverstanden, polecat. Das ist einer der Gründe, warum wir keine bidirektionalen tunnels haben 13:22 <jrandom> manche Transporte (z. B. E‑Mail) taugen schlecht für bidirektionale Kommunikation 13:22 <bla> jrandom: c = ? 13:22 <jrandom> c==# kolludierende Peers 13:23 <+polecat> Hm, interessanter Punkt. 13:23 <ant> <duck> Mit Blick auf die Roadmap: Welche Auswirkungen hätte es, wenn i2p in die falsche Richtung geht und eine falsche Krypto‑Lösung wählt? 13:23 <+polecat> Oder Brieftauben‑Protokoll, überhaupt nicht bidirektional. 13:23 <+polecat> Krypto ist doch modular, oder? 13:23 <jrandom> duck: Das ist nur ein Aufzählungspunkt von 0.5 und ein Unterabschnitt des tunnels*.html‑Dokuments. Es gibt beim tunnel routing viel mehr als nur die Frage, wie wir die Daten verpacken 13:24 <bla> jrandom: Andererseits ist das das Problem dafür, sie *jetzt* in den tunnel zu bekommen. Über T Tunnel‑Auffrischungen (alle soundso viele Minuten) ergibt sich P = 1 - (1 - c^2/N^h)^T 13:24 <jrandom> andererseits hat der Unterschied zwischen "fixed 1KB blocks" und "0-40KB blocks" erhebliche Auswirkungen 13:24 <+polecat> Ich würde nur ungern sehen, dass dieses Netzwerk wie Entropy endet, in McEliece feststeckend. 13:24 <jrandom> polecat: lies http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt.html?rev=HEAD 13:24 <bla> jrandom: Und damit gegen Null für hinreichend große Zeit. D. h.: Für hinreichend große Zeit werden die Angreifer wenigstens einmal im selben tunnel sein 13:25 <jrandom> der Plan ist Standard AES256/CBC 13:25 <+protokol> ich höre, DNS ist gut zum Tunneln, die meisten Leute blocken es nicht 13:25 <jrandom> sicher, bla, allerdings nicht ganz so direkt (für exploratory tunnels schon, aber nicht für client tunnels) 13:26 <+polecat> Und wenn irgendwie sogar AES geknackt wird, dann eben eine gleichwertige symmetrische Chiffre. 13:27 <jrandom> bla: Ich glaube nicht, dass das in der Praxis groß genug als Sorge ist, aber wenn man es als Teil eines Predecessor‑Angriffs einsetzt, ist die Frage weitgehend hinfällig 13:28 <jrandom> (wegen der Art, wie wir den Rest des tunnel routing machen) 13:28 <bla> jrandom: k 13:28 <jrandom> genau, polecat 13:29 <jrandom> duck: Wenn wir die zweite Option nehmen, wird der Wechsel zu einer anderen später wahrscheinlich leicht. 13:29 <jrandom> andererseits erfordert die zweite Option ordentlich Performance‑Tuning, damit es nicht Mist ist 13:29 <jrandom> aber ich bin sicher, dass wir das hinkriegen 13:31 <jrandom> jedenfalls denke ich, das oben deckt ab, wo wir gerade bzgl. 0.5‑Arbeit stehen 13:31 <jrandom> hat noch jemand Fragen/Kommentare/Bedenken? 13:31 <bla> jrandom: Eines 13:32 <bla> jrandom: Ich denke, wir sollten Anon. im Moment etwas höher bewerten als Performance; also ja, die PRNG (Pseudozufallszahlgenerator)‑Option klingt gut 13:33 <jrandom> einverstanden. Performance kann man später tunen, "hinterher" bessere Anonymität hinzufügen ist jedoch viel schwerer 13:33 <jrandom> (aber natürlich ist Performance /ein/ Sicherheitsparameter. Wenn sie mies ist, nutzt es keiner) 13:33 <bla> Ja. 13:33 <bla> jrandom: 13:33 <bla> sorry 13:33 <@duck> richtig, /me flips the magical Freenet-performance bit 13:33 <cervantes> vielleicht hält das all die mit Torrents wedelnden Leecher noch eine Weile fern ;-) 13:34 <jrandom> heh 13:34 <cervantes> <-- Verbindung zurückgesetzt 13:34 <bla> cervantes: Nein, ich nicht! :) 13:34 <cervantes> :) 13:35 <jrandom> ich glaube schon, dass wir ein paar wirklich coole Optimierungen hinbekommen, und es scheint, dass viel von unserem Flaschenhals nicht mit der Peer‑Auswahl zusammenhängt, sondern (heh) schlicht Bugs in der jobqueue sind 13:36 <jrandom> aber, anyway, noch etwas zu 2) 0.5? 13:36 <ant> <BS314159> könntest du eine Erklärung für diesen Loop‑Angriff posten? 13:37 <ant> <BS314159> klingt gefährlicher, als deine Behandlung vermuten lässt 13:37 <jrandom> Loop: Baue einen tunnel mit A-->B-->C-->D-->C, schicke 10 Nachrichten hinein. 13:37 <jrandom> ohne die PRNGs kannst du so viele Nachrichten zu dieser C<-->D‑Schleife hinzufügen, wie du willst 13:38 <ant> <BS314159> ok 13:38 <jrandom> damit legst du effektiv mit nur wenigen Nachrichten jeden router per DoS lahm 13:38 <ant> <BS314159> aber nur A kann das 13:38 <jrandom> mit den PRNGs wird die Anzahl der Nachrichten begrenzt, die in die Schleife gehen können 13:38 <ant> <BS314159> es besteht also keine Gefahr, dass ein Angreifer meine tunnels verkürzt, indem er Schleifen einführt 13:38 <jrandom> nein, niemand kann deine tunnels verkürzen 13:39 <jrandom> das Einzige, wofür das nützlich ist, ist ein DoS 13:39 <jrandom> (ein sehr billiger DoS) 13:39 <jrandom> (aber wenn man selektiv Peers ohne große Kosten per DoS angreifen kann, kann man gaaaanz üble Sachen machen) 13:40 <ant> <BS314159> comprendo 13:40 <+protokol> und Hashcash‑Zertifikate helfen dabei? 13:40 <jrandom> protokol: Hashcash adressiert das Problem, dass ein Peer zu viele tunnels baut und vielleicht zu viele Hops 13:41 <jrandom> protokol: bei Schleifen hilft es nicht. Die beiden Wege, die ich finden konnte, die /wirklich/ helfen, sind die PRNGs (tunnel-alt.html) oder die Verifizierung bei jedem Schritt (tunnel.html) 13:42 <jrandom> die Verifizierung bei jedem Schritt hat Risiken, daher tendieren wir derzeit zu den PRNGs 13:42 <+Ragnarok> wie effektiv wird die PRNG‑Methode sein? 13:42 <Xan> A-->B-->C-->D-->C – sollte nicht jeder Hop eine andere ID bekommen oder so, sodass Nachrichten den tunnel beim zweiten Mal, wenn sie C erreichen, verlassen statt zu loopen? 13:43 <jrandom> Xan: Tun sie, aber ohne Verifizierung bei jedem Schritt kannst du nicht sagen, ob es schlecht ist oder nicht 13:44 <jrandom> Ragnarok: ich glaube, sie wird sehr effektiv darin sein, den angerichteten Schaden zu minimieren 13:45 <jrandom> zumindest soweit ich bis jetzt sehe 13:45 <jrandom> wenn jemand Probleme/Fragen damit sieht oder Vorschläge zur Verbesserung hat, bitte melden :) 13:46 <Xan> oder ich verstehe das Thema nicht 13:46 <Xan> bbl 13:46 <jrandom> 'k l8r, ich aktualisiere das Dokument, um es klarer zu machen 13:47 <jrandom> ok, wenn es nichts Weiteres gibt, gehen wir zu 3) i2pmail.v2? 13:47 <jrandom> postman: bist du da? 13:48 <postman> ja 13:49 <postman> :) 13:49 <jrandom> noch etwas zu deinem Beitrag im Forum hinzuzufügen? klingt ziemlich cool 13:49 <postman> nun, einige von euch haben den Entwurf für i2pmail.v2 vielleicht schon gelesen 13:50 <bla> wtf passiert? Massenhafte Disconnects. Ich habe auch Probleme, Sites zu erreichen (z. B. orion, library) 13:50 <postman> es zielt langfristig auf eine vollständig dezentralisierte Mail‑Infrastruktur ab 13:50 <postman> braucht aber Proxysoftware auf den Knoten sowie eine Reihe dedizierter Relays 13:51 <postman> alle sind eingeladen, Ideen/Konzepte/Rants beizusteuern 13:51 <postman> Entwicklung hat bereits begonnen – erwartet aber nichts vor Spätfrühling :) 13:51 <jrandom> w00t 13:51 <kaji> hmm, die Cops sind gerade bei mir vor der Tür aufgetaucht 13:52 <bla> kaji: ? 13:52 <jrandom> schnell, spreng deine Festplatte 13:52 <postman> jrandom: nun, das ist alles, was ich fürs Erste zu sagen habe :) 13:52 <cervantes> Versteck den Blackjack‑Tisch! 13:52 <jrandom> wikked, danke postman 13:52 <kaji> sie sagten, ich hätte 911 gewählt, aber ich bin mir ziemlich sicher, weder ich noch mein Bruder haben das getan 13:53 <+protokol> kaji: die überprüfen nur i2p 13:53 <jrandom> ok, wenn es sonst nichts zu 3) i2pmail gibt, gehen wir weiter zu 4) azneti2p_0.2 13:53 <+protokol> <gruselige Musik> 13:53 <jrandom> wie in der E‑Mail erwähnt, gab es in letzter Zeit wichtige Fortschritte 13:53 <kaji> dann sagten sie, schnurlose Telefone können spinnen, wenn sie daneben liegen, aber alle meine Schnurlosen stehen in der Ladestation -> #i2p-chat 13:55 <jrandom> die Azureus‑Leute waren sehr reaktionsschnell, ein Update vorzubereiten (yay!), aber die Leute sollten auch auf Probleme achten 13:55 <jrandom> (wenn ihr die i2p‑Mailingliste nicht lest und azneti2p nutzt, lest die i2p‑Mailingliste) 13:55 <jrandom> ((oder selbst wenn ihr azneti2p nicht nutzt, lest die Liste, dort kündigen wir wichtige Dinge an ;) 13:56 <jrandom> duck und orion haben ebenfalls viele Updates gemacht, um den neuen BT‑Client und das Format zu berücksichtigen 13:56 <jrandom> (yay!) 13:56 * orion lächelt 13:57 <orion> da ist noch ein Stück Weg, aber fürs Erste funktioniert es. 13:57 <jrandom> (so weit, wie i2p es zulässt ;) 13:58 <orion> hehe, ja. ;) 13:58 <jrandom> hat sonst noch jemand etwas bzgl. azneti2p oder i2p‑bt einzubringen? 13:58 <jrandom> (oder bytemonsoon2p ;) 14:00 <jrandom> ok, wenn nicht, weiter zu 5) ??? 14:00 <jrandom> offene Runde – hat sonst noch jemand etwas einzubringen? 14:00 <postman> jrandom: warum veröffentlicht das Adressbuch userhosts‑Einträge? 14:01 <jrandom> postman: Bug. 14:01 <postman> das war also kein geplantes Verhalten und wird geändert? 14:01 <cervantes> nur eine Sache... 14:01 <jrandom> postman: korrekt, und wird geändert 14:02 <jrandom> (richtig, Ragnarok? :) 14:02 <+Ragnarok> hängt genau davon ab, was postman meint... 14:03 <jrandom> Ragnarok: Neue Einträge, die der lokale Nutzer zu seinen eigenen privaten hosts hinzufügt, sollten nicht in die veröffentlichten hosts propagiert werden 14:03 <jrandom> (z. B. userhosts.txt ist privat, hosts.txt wird mit anderen synchronisiert und ist öffentlich) 14:03 <cervantes> Im Rahmen eines halbwegs regelmäßigen Slots im Forum wird es Anerkennung und Auszeichnungen für diejenigen geben, die I2P entweder kürzlich oder über die Lebensdauer des Projekts hinweg gute Dinge beigetragen haben 14:03 <postman> Ragnarok: nach dem Update auf 0.4.2.6 fand ich Einträge aus meiner userhosts.txt im veröffentlichten Adressbuch in meinem eepsite‑Ordner 14:03 <ant> <BS314159> hmm 14:04 <postman> Ragnarok: das waren manuell hinzugefügte Keys, die nicht hätten veröffentlicht werden sollen 14:04 <cervantes> diese Woche zeichnen wir duck aus, für allgemeine Exzellenz als Service‑Provider für die Community und als rundum großartigen Idler: http://forum.i2p/viewtopic.php?t=275 14:04 <jrandom> w00t! 14:04 <jrandom> (go duck go, go duck go) 14:05 <Teal`c> wie sieht’s mit Domain‑Name‑Hijacking aus? 14:05 * brachtus applaudiert 14:05 * orion macht einen Entenwatschelgang als Zeichen des Respekts. 14:05 <cervantes> ein wichtiger Punkt für die Zukunft... du musst kein kryptographisches Genie sein, um Lob zu bekommen! 14:06 <+Ragnarok> nein, das ist erwartetes Verhalten. Ich kann es ändern, aber zuerst muss ich File Locking implementieren, damit du hosts.txt direkt ändern kannst 14:06 <orion> (aber es hilft) 14:06 <cervantes> du könntest einfach eine geniale eepsite beigesteuert haben oder so... 14:06 <cervantes> oder ein hilfreicher Mensch im Forum gewesen sein usw. 14:07 <ant> <BS314159> hmm 14:07 <cervantes> (ansonsten, seien wir ehrlich, würde jrandom jede Woche gewinnen) 14:07 <jrandom> hey, ihr bezahlt ja meinen Bierfonds, der Kram ist nicht umsonst ;) 14:07 <ant> <BS314159> könntest du nicht einfach eine neue Datei "publichosts.txt" machen? 14:07 <ant> <BS314159> dann das Adressbuch userhosts.txt ignorieren lassen, aber den Nutzern erlauben, ihre eigene publichosts.txt zu abonnieren? 14:08 <jrandom> Teal`c: Es gibt keinen Weg, einen Domainnamen zu hijacken, keine Einträge werden überschrieben, und userhosts überschreibt hosts immer 14:09 <jrandom> Ragnarok: Vielleicht kann die Weboberfläche das Locking‑Problem adressieren, da Nutzer die Dateien nicht manuell bearbeiten werden 14:09 <+Ragnarok> sobald das Locking erledigt ist, gibt es keinen echten Grund mehr, Adressen aus userhosts.txt zu ziehen (es ist derzeit der einzige Weg, ein Race zu umgehen), daher gibt es keinen wirklichen Sinn, eine dritte Datei hinzuzufügen 14:10 <+Ragnarok> jrandom: nun, ich hatte vor, die Java File‑Locking‑API zu verwenden 14:10 <jrandom> wenn du meinst, dass es nötig ist, bist du der Boss :) 14:10 <ant> <BS314159> es würde dir erlauben, alle von anderen erhaltenen Namen zu entfernen, während du die behältst, die du selbst erstellt hast 14:10 <ant> <BS314159> einfach indem du hosts.txt leerst und dein Abonnement änderst 14:11 <ant> <BS314159> aber ich denke, das kann bis zum Name‑Signing warten 14:11 <orion> Metadaten werden dieses Problem lösen. Gibt es schon einen Spez‑Entwurf? 14:11 <jrandom> mit nur zwei Dateien sollte es gehen – eine wird vom Adressbuch verwaltet, eine nicht 14:12 <jrandom> (du könntest sogar das Adressbuch userhosts.txt komplett ignorieren lassen – userhosts.txt überschreibt hosts.txt sowieso) 14:12 <+Ragnarok> jrandom: das wäre der Plan, sobald Locking fertig ist (sollte wirklich nicht viel Arbeit sein, ich bin nur noch nicht dazu gekommen :) 14:13 <+Ragnarok> und ich arbeite gerade daran, genug XML Schema zu lernen, um eines für die Namenseinträge zu schreiben 14:13 <ant> <dr_kavra> ist dies der Kanal für Kenosis? Ein anderer Kanal hat mich hergeschickt :D 14:13 <jrandom> lol 14:13 <jrandom> nee, sorry, das ist i2p 14:14 <jrandom> (es sei denn, du suchst eine anonyme Kommunikationsschicht) 14:14 <jrandom> wikked, Ragnarok 14:14 <ant> <BS314159> Ich finde immer noch, dass XML hierfür zu geschwätzig und nicht menschenlesbar ist, verglichen mit YAML, aber ich schreibe den Code nicht 14:14 <jrandom> Ragnarok: Der schwierige Teil wird sein, die Krypto mit XML zu machen, ohne auf hässliches CDATA zurückzugreifen 14:14 <orion> hat schon jemand einen Arbeitsentwurf für die Metadata‑Spez geschrieben? 14:15 <jrandom> (ich persönlich finde, XML ist Mist, aber ich bin nur ein Nörgler) 14:15 <jrandom> orion: http://dev.i2p.net/pipermail/i2p/2004-February/000135.html hat ein grundlegendes Setup 14:15 <orion> (Name/Key‑Metadaten) 14:15 <dox> wurde das Adressbuch und seine Features irgendwo angekündigt? Ich wusste nicht, dass meine hosts.txt veröffentlicht wird 14:15 <jrandom> (siehe NameReference‑ und LocalEntry‑Elemente) 14:16 <jrandom> dox: es wird an den Ort geschrieben, der in addressbook/config.txt angegeben ist 14:16 <jrandom> (standardmäßig ./eepsite/docroot/hosts.txt) 14:17 <orion> es fehlt ein Public/Private‑Flag (d. h. verteilen, nicht). 14:17 <ant> <cervantes> das Einzige Gute an XML (und das ist ein großer Pluspunkt) ist, dass es ein weithin akzeptierter Standard ist 14:17 <jrandom> stimmt, cervantes: gilt auch für EDI 14:17 <orion> gibt es einen Ort, um das zu bündeln? also Bereich im Forum? 14:18 <orion> oder vielleicht eine Wiki‑Seite? 14:18 <jrandom> orion: susis oder ughas Wiki 14:18 <orion> Ich werde Wikis für bytemonsoon und orion.i2p aufsetzen, um zu einer Community‑Meinung über die zukünftigen Entwicklungsziele zu kommen. 14:18 <BrockSamson> xml + Krypto ohne CDATA = mime, oder? 14:19 <jrandom> wikked, orion 14:19 <jrandom> BrockSamson: smime, mit anderen Parsern ;) 14:19 <orion> (auch eines für Namens‑Metadaten) 14:21 <jrandom> es gibt viele Wege, die Metadaten zu machen, wichtig sind Flexibilität und "Korrektheit", damit es über die Zeit wachsen oder sich ändern kann 14:21 * jrandom ist sicher, dass Ragnarok et al. mit gutem Zeug aufwarten werden :) 14:21 <orion> deshalb denke ich, dass ein öffentlicher Entwurf sinnvoll ist. 14:22 <ant> <cervantes> i2p‑Konsortium :P 14:22 <jrandom> nun, seit den letzten Meetings sagen die Leute "jemand sollte seine Ideen ins Wiki stellen", aber die Wiki‑Seiten wachsen nicht besonders ;) was ok ist, wir gehen das Tempo, das wir gehen 14:23 * orion verspricht, innerhalb eines Tages drei Wikis aufzusetzen und allen ihre Adressen zu mailen 14:23 <BrockSamson> nenn mich faul, aber vergleiche eine ANSI 850 Purchase Order EDI mit fast jeder anderen XML‑basierten Purchase Order, und ich würde lieber die XML‑Version decodieren, coden und debuggen. Selbst wenn sie 5x die EDI‑Größe hat 14:23 <jrandom> w00t 14:23 <jrandom> heh, BrockSamson 14:24 <BrockSamson> Position 10 ist ST? oh, dann sollte Position 310 Name sein 14:24 <BrockSamson> ich Dussel 14:24 <jrandom> BrockSamson: glaube nicht, dass die XML‑Schemas für POs viel besser sind ;) 14:24 <jrandom> (aber ja, das Zeug ist eine einzige blutige Katastrophe) 14:25 <BrockSamson> um 4:30 morgens sind sie es 14:25 <BrockSamson> außer... 14:25 <jrandom> heh 14:25 <BrockSamson> es ist von einem Ex‑EDI‑Programmierer geschrieben 14:25 <BrockSamson> und das xml sieht so aus: <p1><po><q>1</q></po></p1> 14:26 <BrockSamson> ich wette, wenn man die Stunden zusammenzählt, die Open‑Source‑Projekte damit verbringen, darüber zu reden, 'XML' oder nicht 'XML', könnte man Linux zehnmal neu schreiben. 14:26 <BrockSamson> jedes Projekt, an dem ich jemals beteiligt war, hatte massive Debatten darüber 14:27 <orion> Debatten sind gut für ein Projekt, je nachdem, wer debattiert. ;) 14:27 <jrandom> eh, es tut, was es tut, aber es ist kein Allheilmittel. Es könnte für die Namenssachen gut funktionieren 14:28 <BrockSamson> viele Leute sind nur zum Debattieren in Projekten. 14:28 <jrandom> nicht hier. ich bin hier wegen des freien Biers 14:28 <ant> <cervantes> das ist diskutabel 14:28 <orion> die Implementierungsdetails werden klarer, wenn der Entwurf greifbarer ist. 14:28 <orion> daher der Bedarf an Wiki/Peer‑Review. 14:29 <BrockSamson> Ich habe gehört, dieses Projekt verschenkt kostenlosen Garlic 14:29 <jrandom> jede Menge davon 14:30 <jrandom> ok, hat noch jemand etwas fürs Meeting? 14:30 <ant> * cervantes rollt die zeremonielle call with bell heraus 14:30 <ant> <cervantes> call =cow 14:30 * jrandom nimmt Schwung 14:31 * jrandom *baf*t die Kuhglocke und schließt das Meeting