16:06 < jrandom> 0) hi
16:06 < jrandom> 1) 0.6.1.25 and net status
16:06 < jrandom> 2) I2PSnark
16:06 < jrandom> 3) Syndie (what/why/when)
16:06 < jrandom> 4) Syndie crypto questions
16:06 < jrandom> 5) ???
16:06 < jrandom> 0) hi
16:06  * jrandom waves
16:06 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-September/001307.html
16:07 < jrandom> since those notes came up hours and hours ago, y'all should have already read them and have notes ready, right? ;)
16:07 < jrandom> jumping forward to 1) 0.6.1.25 and net status
16:08 < vulpine> <Complication> Regarding 0.6.1.25 seems to have worked fine over here, only one previously unseen error
16:08 < jrandom> cool, whats the prob?
16:08 < vulpine> * Complication searches logs
16:09 < jrandom> the net size seems larger than before, though still same orer of magnitude
16:09 < vulpine> <Complication> "Unknown error reading the net.i2p.data.i2np.GarlicMessage: wtf, fromLong got a negative? -840"
16:10 < vulpine> <Complication> Started with "ERROR [NTCP read 1 ] .router.tunnel.FragmentHandler: Error receiving fragmented message (corrupt?)"
16:10 < jrandom> ah ok cool, that one has been around for a long time, safe to ignore
16:11 < vulpine> <Complication> Single occurrence
16:11 < vulpine> <frosk> i've gotten several of that last one
16:11 < vulpine> * jrandom pokes fox
16:12 < vulpine> <Complication> Oh, and one more: "router.tunnel.TunnelDispatcher: wtf, took 1121 to dispatch net.i2p.data.i2np.TunnelBuildMessage@XXXX out YYYYY in net.i2p.router.tunnel.PumpedTunnelGateway@ZZZZ"
16:12 < vulpine> <Complication> (seems non-significant too, maybe simple congestion)
16:12 < jrandom> aye, likely 
16:13 < jrandom> irc is, obviously, a bit rough at the moment still
16:13 < jrandom> (but, for once, its not i2p's fault :)
16:14 < jrandom> ok, anyone have anything else for 1) Net status and 0.6.1.25?
16:15 < kostya213> just want to add that .25 fixed all my problems i've been having the past few months
16:15 < jrandom> wikked!
16:16 < vulpine> <green> please, change status calcul when only using NTCP
16:16 < jrandom> 'k, but its not recommended to disable udp (i believe i've explicitly said that i won't tell people how to disable udp too)
16:17 < jrandom> but the status should be updated to take into consideration that udp is not the only transport
16:17 < jrandom> i'll get that fixed in the next rev, thanks
16:17 < vulpine> <green> jrandom : sure you don't tell, but i'm able to read code ;)
16:18 < jrandom> right, though when i don't recommend something, and tell people not even to try, don't be suprised if a display message comes up confusing ;)
16:19 < vulpine> <green> sure, i could also juste display "OK" in console :)
16:19 < jrandom> true 'nuff
16:21 < jrandom> ok, lets jump on over to 2) I2PSnark 
16:21 < jrandom> zzz doesn't seem to be over there atm
16:22 < jrandom> there are some changes zzz is working on to improve the scheduling in i2psnark
16:23 < jrandom> (its a bit.. simplistic atm iirc, though i'm not entirely certain of the mods zzz is hacking on)
16:23 < jrandom> ((but i look forward to the progress!))
16:25 < jrandom> ok, if there's nothing else on 2) I2PSnark, lets move forward to 3.*) Syndie stuff
16:26 < jrandom> lets jump in to 3.1) what is syndie first, since there's so much to cover
16:27 < jrandom> i got a few questions before the meeting regarding the encryption for posts
16:27 < jrandom> basically, posts are *symmetrically* encrypted - anyone with the symmetric key can read the post, as they're authorized
16:28 < jrandom> channel replies are asymmetrically encrypted to the public key associated with the channel/forum
16:28 < jrandom> some posts can use passphrase based encryption to generate the symmetric key for reading
16:29 < jrandom> and some posts can include the symmetric key in the post's readable headers (so that anyone can read it)
16:29 < modulus> what's the point of that last one?
16:29 < jrandom> and some forums themselves can include the symmetric key in the forum metadata, so that anyone can read the post but only if they have the channel metadata
16:29 < jrandom> modulus: so that everything is always encrypted, even publicly readable stuff
16:29 < jrandom> (so that trivial wiretapping is useless)
16:30 < modulus> right, i see.
16:31 < jrandom> ok, i think that covers the encryption questions that were asked before the meeting
16:31 < jrandom> does anyone have any questions on 3.1) what is syndie?
16:31 < jrandom> (I mean, more will be clarified as it is pushed out there, of course)
16:32 < vulpine> <void> hmm
16:33 < jrandom> que tal void?
16:33 < vulpine> <void> <void> i guess that the message (.zip) archive can also include other messages, possibly from other  people, such as the messages being quoted?
16:34 < jrandom> well, yes, you can include .snd files as attachments, but there is an explicit namespace, so you can do standard References: style links to previous messages
16:34 < jrandom> (aka you don't have to do frost-style "threading")
16:35 < vulpine> <void> ok, right
16:37 < vulpine> <Complication> About Syndie, I wondered how people would go about solving the problem of granting people access to some multiple-poster forum (like accounts on an ordinary message board) but not granting this irrevocably, and avoiding undesired mess when need to revoke access (for whatever reasons) occurs
16:38 < vulpine> <Complication> One solution, of course, seemed for the author to specify a recommendation of whose replies clients should display
16:38 < jrandom> Complication: create a new pub/private keypair, give the private key to (temporarily) authorized people, and include the public key as the list of "keys allowed to post"
16:38 < vulpine> <Complication> ..and for clients, unless they desire to research history, to follow this recommendation (or more specifically its latest version)
16:38 < jrandom> (and when they are no longer authorized, remove that key from the list of "keys allowed to post")
16:39 < kostya213> jrandom: you might want to use a different extension than .snd since it's a widely used extension for audio applications, mime will confuse it
16:39 < jrandom> ah, right - all forums have an "owner" (a signing private key) who can manage the list of who is allowed to post, etc
16:39 < vulpine> <Complication> "keys allowed to post" would be metadata attached to the author's latest post, or some other message, right?
16:39 < jrandom> good point kostya213, though we may be stuck with .dat then ;)
16:40 < jrandom> Complication: ah sorry, no, its like the current/old syndie- separate signed metadata posts for the forum/channel itself
16:40 < vulpine> * Complication believes that someone has even claimed .dat for something :)
16:40 < jrandom> yes, the application called "octet-stream" ;)
16:40 < vulpine> <void> it doesn't look like .syn is used for anything noteworthy
16:41 < vulpine> <Complication> Aha, special metadata posts... right, that could do it
16:41 < jrandom> oh neat, we get to syn!
16:41 < jrandom> (good eye void, thanks kostya213)
16:41 < vulpine> <void> hmm, "
16:41 < vulpine> <void> hmm, "Word Synonym File", Company: Microsoft
16:42 < jrandom> well, i'm sure we'll work 'er out
16:42 < kostya213> yes it's used by word
16:42 < vulpine> <void> but we might as well ignore that :)
16:42 < kostya213> don't lose hope, i think it's possible to find something that won't cause problems with widely used mimetypes
16:43 < jrandom> ok, anything else on 3.1) What is syndie?
16:43 < vulpine> <void> err, then again, why would we stick with three-letter extensions? it's a relic from the DOS ages
16:43 < kostya213> one thing that must be asked, why limit to a three-letter extension? nobody uses DOS anymore
16:44 < jrandom> heh
16:44 < kostya213> jinx on void
16:44 < kostya213> .syndie seems good to me
16:44 < vulpine> <void> .synd wouldn't conflict with any
16:44 < kostya213> good as well
16:45 < vulpine> <void> damn lag :(
16:48 < jrandom> ok, lets jump on over to 3.2) Why does Syndie matter?
16:48 < vulpine> <void> jrandom: wait
16:48 < cervantes> (because you say it does)
16:48  * jrandom waits
16:48 < jrandom> !thwap cervantes ;)
16:48 < vulpine> <void> the status notes post mentions that an avatar can be attached to a post, otherwise a default will be used
16:49 < vulpine> <void> but what if a person wants to have several predefined avatars instead of a single "default" one?
16:49 < jrandom> aye, the author can include a default avatar in their own channel's metadata
16:49 < vulpine> <void> attaching the other one every time isn't going to be efficient
16:49 < jrandom> good question void - lets jump to that script code in the notes
16:50 < jrandom>     listauthkeys --authorizedOnly true
16:50 < jrandom>     authenticate 0
16:50 < vulpine> <void> (?)
16:50 < jrandom> listauthkeys will display all of the identities you can sign the message saying that you are, while "authenticate 0" picks an identity to sign with
16:51 < jrandom> so, that identity has its own channel, and that channel has its own metadata, which may include an avatar
16:51 < vulpine> <void> hmm, a separate identity means a separate keypair?
16:51 < jrandom> yes
16:51 < vulpine> <void> what if a person wants to have several avatars on a single identity?
16:52 < jrandom> they have a default avatar on their channel metadata, and they can override it on a per-message basis
16:52 < kostya213> dubious value
16:52 < vulpine> <void> several "default" avatars he can choose from
16:52 < vulpine> <void> or am i splitting hair here? :)
16:53 < jrandom> ah, i understand what you're saying.  nah, not supported at first
16:53 < jrandom> maybe later
16:53 < vulpine> <void> true kostya213, never mind then
16:53 < vulpine> <void> :)
16:53 < jrandom> (but the avatars will be very limited in size, so shouldn't be much trouble to include)
16:53 < vulpine> * Complication thinks the adding of per-message ones could be coded to be easy enough
16:53 < vulpine> <void> so, 3.1) What is syndie?
16:53 < vulpine> <Complication> (eventually)
16:54 < vulpine> * cervantes glues the irc servers together
16:54 < vulpine> <void> Complication: jrandom just said he is going to do that already :)
16:54 < jrandom> (per message ones will be in the baseline complication, its the idea of having many 'defaults' to choose from, picking it by saying "use avatar 1" in a message rather than including the avatar itself)
16:54 < vulpine> <Complication> latency, latency...
16:54 < jrandom> ok, anything else for 3.1?
16:54 < jrandom> if not, lets jump to 3.2
16:55 < vulpine> <void> i think that's all
16:55 < jrandom> wr0d.
16:56 < jrandom> other than cervantes' snark, anyone have any questions/comments/concernts re "why"?
16:56 < jrandom> (er, "concerns")
16:58 < vulpine> <Complication> cervantes: did you clean the surface with alcohol before applying glue on the ircd? ;)
16:58 < kostya213> imo syndie doesn't need justification, its value should be self-evident to anyone who's already interested in anonymizing networks
16:58 < kostya213> and aware of the dangers of centralization of information
16:59 < vulpine> <Complication> (repost, please ignore if reached server)
16:59 < vulpine> * Complication thinks that Syndie matters because Joe Sixpack running phpBB would suffer pwnage too quickly, and Joe Sixpack running $random_blogging_tool would suffer it too
16:59 < vulpine> <Complication> (even if probability might vary)
16:59 < vulpine> <void> indeed
16:59 < jrandom> aye, plus anyone facing actual hostile adversaries (not even necessarily state level)
17:00 < jrandom> ok, cool, just wanted to run things by y'all
17:00 < jrandom> anything else on 3.2, or shall we move over to 3.3) when can we use syndie?
17:01 < vulpine> <void> well, essentially it's a forum/blogging/e-mail/communication tool based on cryptographic primitives and independent from a transport layer
17:01 < vulpine> <Complication> ...and in the far-out scenario that Joe Sixpack's adversary would mount intersection attacks, anyone running an eepsite of any kind would suffer pwnage eventually (except in an enormous network)
17:01 < kostya213> it might be a harder sell to those who don't see immediate value in privacy/anonymity
17:01 < jrandom> kostya213: aye, though we may be able to pull some tricks, like being able to safely browse offline
17:02 < vulpine> <Complication> They might appreciate security regardless
17:02 < jrandom> (e.g. an offline rss reader that also pulls in the full set of pages referenced, not just the rss summary)
17:02 < vulpine> <void> so yeah, i can't see why it needs justification :)
17:02 < vulpine> <void> kostya213: they needn't be anonymous to use syndie
17:02 < cervantes> when can we use syndie or when will syndie be useable?
17:02 < jrandom> word void :)
17:03 < cervantes> for the text interface I imagine there needs to be a fairly hefty amount of usage documentation
17:03 < jrandom> cervantes: right now, syndie is functional (you can create posts, manage channels, read posts, reply to posts, etc)
17:03 < kostya213> jrandom: how does syndie handle redundancy? how resilient is it against content disappearing?
17:03 < cervantes> (before it's useable)
17:03 < jrandom> cervantes: there's inline menus with each command doc'ed (at least minimaly)
17:04 < cervantes> cool, any plans on some use case examples?
17:04 < jrandom> kostya213: syndie works at the content layer - redundancy is handled by something else.  if you post to usenet, its replicated across usenet (for instance)
17:04 < cervantes> I think the trick will be learning how they all script together
17:04 < vulpine> <void> kostya213: that's out of the scope of syndie, it's dependant on the transport mechanism
17:04 < vulpine> <void> unfortunately
17:04 < jrandom> good idea cervantes
17:05 < jrandom> the first syndie release will include an http replication system like the old/existing syndie
17:05 < jrandom> cervantes: perhaps some of the beta users can put together  their favorite scripts for us to distribute :)
17:05 < modulus> mmm, is this a console app?
17:05 < jrandom> modulus: yes, the first text based app
17:06 < modulus> excellent!
17:06 < cervantes> jrandom: provided the beta users can work out how to use it ;-)
17:06 < jrandom> hehe
17:06  * jrandom considered curses/etc, as well as cli-only, but an interactive scriptable text interface is probably the simplest and most useful
17:07 < jrandom> (sans gui, that is)
17:07 < cervantes> modulus: see, jrandom listened to your relentless feedback :)
17:07 < vulpine> <Complication> If people want, they can probably build more interactive textual interfaces on top of it
17:07 < jrandom> aye, certainly
17:08 < jrandom> (the code is built to support easy integration with an irc client, like pircbot)
17:08 < modulus> cervantes: hehe
17:09 < modulus> i guess you could put a gui on top of it too for that matter, if it works roughly as i imagine
17:09 < modulus> although that'd be lots more work.
17:09  * kostya213 waits for the emacs plugin
17:09 < modulus> hahaha
17:09 < jrandom> heh
17:09 < modulus> actually an emacs mode isn't such a bad idea, maybe would attract more crazies to it.
17:10 < cervantes> press ctrl-alt-shift-break-uparrow-num7-b to choose your identity
17:10  * jrandom will leave that to elipsers to hack through ;)
17:10 < kostya213> no offense, but i'm not sure this project needs to attract more crazies
17:10 < vulpine> <Complication> would those sort of crazies code, too?
17:11 < jrandom> hopefuly complication
17:11 < jrandom> ok, hopefully 3.3) explains a it of whats coming down the line
17:11 < jrandom> as for *when*, well, we'll see, but i'm hoping "soon" ;)
17:12 < jrandom> ok, anyone have anything else for 3.3)?
17:12 < vulpine> * Complication would welcome a few hordes of those crazies then :D
17:12 < cervantes> well there's coding and then there's writing obfuscated perl interpreted tcl
17:12 < kostya213> a plugin for FUSE might be useful too
17:13 < jrandom> aye
17:13 < jrandom> ok, lets jump on over to 4) crypto for syndie
17:13 < jrandom> anyone have any comments on those issues?
17:14 < vulpine> <Complication> I wish I had, but I'm not competent to estimate the strength of those ciphers/hashes/key lengths
17:15 < vulpine> <void> how long are elgamal/rsa signatures? 4kbit for a 2kbit key?
17:15 < vulpine> * Complication leaves that talk entirely for others
17:15 < jrandom> dunno offhand
17:15 < vulpine> <void> vs dsa?
17:16 < jrandom> (though ecc looks nice'n'tiny)
17:16 < modulus> ElGamal signatures are hard and long. as gnupg's team found out.
17:16 < jrandom> aye, though some of those tricks were related to key reuse
17:16 < vulpine> <void> ah, ok
17:16 < vulpine> <void> yeah, it does
17:16 < tethra> modulus: if they're hard and long, there's a fetish site for it
17:17 < jrandom> ok, that point was really just a heads up and call for comments whenever y'all have thoughts
17:17 < cervantes> could it not be possible to implement some kind of pluggable ciphers - when a better method of creating keys is standardised we can add that to syndie and new posts will begin using them, but can still use obsolete methods for older posts
17:17 < tethra> (sorry)
17:17 < jrandom> cervantes: it includes a DSA: prefix, so an Elg: prefix would work
17:17 < modulus> are you using 1024-limited dsa or not?
17:18 < modulus> also what has? sha1 or higher order revs?
17:18 < cervantes> so really you are just concerned with getting syndie off to a good start
17:18 < jrandom> dsa is only 1024bit (there are dsa2 proposals for longer, but they aren't standardized yet)
17:18 < jrandom> and yes, dsa requires sha1
17:18 < modulus> hmm, my understanding is that they were quite strong pre-standards.
17:18 < kostya213> cervantes has a good point, having syndie content in fixed ciphers offers poor forward-secrecy, you never know when an algo will go titsup
17:18 < modulus> but i don't follow the process closely enough so you are probably right
17:19 < jrandom> kostya213: but choice is bad for crypto, so we should have fixed values when we can
17:19 < jrandom> (bad because of anonymity)
17:19 < vulpine> <void> do you know why aren't more people/protocols using ecc, anyway? are they afraid of the lack of research, or just worried about compatibility?
17:19 < modulus> patents.
17:20 < jrandom> patents and fud, yet some concerns in implementation
17:20 < vulpine> <void> ah, right modulus
17:20 < modulus> btw, is there are a good reason to go dsa vs rsa-sha512 for instance?
17:20 < tethra> patents and fud and the state (oh my)
17:20 < modulus> not trying to be annoying, just considering that gpg for instance has gone this way, among others.
17:20 < jrandom> haven't reviewed that option in years modulus
17:21 < modulus> obviously dsa is a standard, which speaks for it, but the keys are small and the hashes are weak. not that i think it's likely to end up being the weakest link ;-)
17:23 < cervantes> I wouldn't propose "choice" - but new versions of syndie would package increasingly secure (mandatory) ciphers
17:23 < vulpine> <Complication> Leaving some leeway in the structures for future change, seems reasonable regardless of which current crypto proves best, I'd think
17:23 < jrandom> aye, though that implies the fallback to weaker/older versions to interoperate
17:23 < jrandom> but, ok, we'll work through it
17:24 < jrandom> ok, lets jump on over to 5) ???
17:24 < jrandom> anyone have anything else to bring up for the meeting?
17:25 < cervantes> no being able to read the latest posts from your favourite source is a good incentive to make sure everyone stays upgraded
17:25 < jrandom> to a degree
17:26 < cervantes> no=not
17:26 < jrandom> (aye, its an incentive, but people are lazy/not interested in "upgrading software", etc)
17:27 < jrandom> s/people/some people/
17:27 < cervantes> I guess that's their issue though
17:27 < jrandom> true that
17:27 < kostya213> the i2p implementation at least can have painless upgrading
17:28 < jrandom> certainly
17:28 < cervantes> as for ??? - apologies for the irc connectivity - the ISP should be restoring one if it's major network carriers "as soon as possible"
17:29 < jrandom> w3wt
17:29 < vulpine> <Complication> To the ??? topic, I could perhaps add that the second (more extensive) part of NTP modifications is close to working, and I hope to have it committed for testing soonish
17:29  * cervantes pinches salt
17:29 < kostya213> what's the near-term plans for router development? is the roadmap accurate?
17:29 < jrandom> wikked complication
17:29 < vulpine> <Complication> It's goal is to second-guess NTP servers basing on peer clock skews
17:29 < jrandom> kostya213: stabilization until syndie is out
17:30 < jrandom> (from my perspective)
17:30 < vulpine> <Complication> (and avoid taking potentially connectivity-damaging action)
17:31 < cervantes> grand
17:32 < jrandom> ok, anything else for the meeting?
17:34  * jrandom winds up
17:34  * jrandom *baf*s the meeting closed