I2P_Website/i2p2www/meetings/logs/244.log

15:00:05 <zzz> 0) hi
15:00:23 <zzz> 1) structure for these meetings
15:00:32 <zzz> 2) roadmap discussion
15:00:37 <zzz> 0) hi
15:00:41 <zzz> hi
15:00:54 <str4d> hi
15:01:02 <xcps_> hi!
15:01:27 <orignal_> what's up?
15:02:18 <zzz> please review the thread at http://zzz.i2p/topics/2021 and the current roadmap at http://i2p-projekt.i2p/en/get-involved/roadmap
15:02:27 <zzz> 1) structure for these meetings
15:03:22 <zzz> should we go straight into the roadmap or should we talk about high-level priorities first?
15:03:53 <str4d> I'd go with the latter first
15:04:41 <zzz> ok, so in the thread, I threw out two priorities - grow the network, and increase security
15:04:55 <zzz> how do those sound as high-level principles?
15:05:25 <zzz> let's first decide what's important
15:05:32 <EinMByte> They sound as expected, I think
15:05:48 <EinMByte> "grow the network" should be in the broad meaning, though
15:05:57 <str4d> I think those are great as broad themes
15:06:03 <zzz> anonimal threw out a whole bunch more in the thread, but that wasn't really what I was going for
15:06:13 <xcps_> increasing security should be always the most important imho
15:06:28 <zzz> other principles we should consider as we review the roadmap?
15:06:28 <str4d> What IMHO we need to do here is figure out what those actually mean in terms of potential deliverables
15:06:40 <EinMByte> So "grow the network" should also mean "increase research attention"
15:07:00 <zzz> grow the network means a huge variety of stuff - see the thread
15:07:09 <str4d> EinMByte, yah, I think I might have mentioned that in the thread
15:07:36 <zzz> we'll figure out what these mean shortly. at this minute let's agree on whats important.
15:07:58 <str4d> Usability is of big importance to me, and IMHO feeds into the above two areas
15:07:58 <zzz> everything is possible if we keep growing. once we stop growing we are dead
15:08:05 <zzz> agreed str4d 
15:08:41 <str4d> More immediately in terms of increasing our userbase, and more long-term in terms of increasing our public exposure, ease of use by researchers etc.
15:09:11 <EinMByte> Note also that growing is the only way to attract researchers
15:09:25 <zzz> more users bring more devs and more researchers and more content and and and
15:09:37 <EinMByte> Large networks are generally more interesting to study
15:10:05 <EinMByte> So I think we call all agree on those 2 priorities
15:10:16 <zzz> the bulk of our growth in the last year has been from vuze. Which is great but I'd love to have more 'native' growth also
15:10:43 <zzz> but maybe growth in embedded apps, or focusing on applications in general, is the easiest path to growth
15:10:48 <str4d> Yep
15:11:04 <EinMByte> zzz: For a lot of people, it's easier to use an application that runs I2P in the background and handles the configuration for them
15:11:12 <sadie> hi - a little late to the party
15:11:20 <zzz> hi sadie glad you made it
15:11:23 <str4d> That IMHO will come from usability improvements for both the UI and APIs
15:11:42 <str4d> The latter we have already been working on in various threads
15:11:48 <zzz> in some ways, it's the apps that are the UI experts, let them bundle i2p and expose (or hide) it as they see best
15:11:58 <str4d> Mmm
15:12:08 <EinMByte> str4d: That's a different solution to the same problem, yes. And I like it more because bundling I2P with everything doesn't scale IMHO
15:12:30 <str4d> That is kinda the approach I was taking with Android
15:13:04 <EinMByte> There needs to be a way to ensure that people don't have an I2P instance for every application
15:13:12 <zzz> ok, anything else on 1) or should we move on to looking at the roadmap itself?
15:14:00 <str4d> I think everyone here appears to be in rough agreement
15:14:08 <str4d> (no dissent at least :P)
15:14:14 <zzz> let me copy in the lines from the thread. Not as gospel, just for reference
15:14:25 <zzz> Grow the Network
15:14:25 <zzz> Includes: Marketing, joint projects, bundling more stuff, helping others bundle i2p, usability, website improvements, more translations, talks and presentations, articles and stories, UI, Android, Android apps, better GFW evasion, orchid, more libs and tools for client devs, better support for huge websites, supporting alternative router dev, alliances, speedups and efficiency, capacity, increasing limits, getting in
15:14:25 <zzz> to Debian, ...
15:14:25 <zzz> Increase security
15:14:25 <zzz> Includes: Crypto migration, subscription protocol, new transport protocols, pluggable transports, LS2, NTCP2, new DH, key revocation, key storage, code review, sybil, bug fixes, naming, SSL, ...
15:14:46 <zzz> ok, let's move on to 2) the roadmap itself
15:15:10 <zzz> url is http://i2p-projekt.i2p/en/get-involved/roadmap
15:15:50 <zzz> .25 is pretty much done, release in about 10 days, so let's look at the next 4 releases 26-29 for this year
15:16:00 <zzz> which should carry us thru to ccc
15:16:15 <EinMByte> If something is under 2017, e.g., does that mean we start looking into it only then, or does that mean we start the implementation at that point?
15:16:41 <str4d> In terms of things we *need* to do, I'd rank the crypto migration and sybil work as high up there
15:16:42 <zzz> 1mb, we certainly do want to get started on big 2017 things now, like new crypto/dh, ntcp2, etc
15:17:04 <EinMByte> Also, eclipse attacks are a problem right now, IMHO
15:17:05 <zzz> so the roadmap could include prepatory work for those
15:17:23 <str4d> EinMByte, yah, I was bundling that under Sybil
15:17:36 <EinMByte> The whole midnight rotation idea doesn't work and there should be better alternatives, I suppose
15:17:52 <zzz> agreed
15:18:05 <EinMByte> str4d: Sure, it's reasonable to classify them as the same type of attack
15:18:44 <str4d> EinMByte, I discussed this with a few people at RWC
15:18:48 <str4d> Got some thoughts, but hard to discuss right here
15:18:51 <EinMByte> zzz: So if we want to get started on NTCP2/... by 2017 we will need to plan preliminary work
15:18:58 <zzz> right 1mb
15:19:02 <str4d> Yep
15:19:20 <str4d> I want to have planning and research on the roadmap :)
15:19:28 <zzz> here's the issue. I should be working on 26 right now and I don't know what's in it
15:19:39 <orignal_> is it possible to add random padding to existsing NTCP?
15:20:01 <str4d> orignal_, not that I recall, but check the NTCP2 thread
15:20:02 <zzz> so let's spend 10 minutes planning 26, then we can move to the longer term
15:20:13 <str4d> k
15:20:14 <zzz> tell me what I should be doing today
15:20:30 <EinMByte> True, let's focus on that first
15:20:34 <zzz> ok let's see what's on the 25 list that didnt happen
15:20:50 <zzz> wrapper didnt happen, kytv is awol
15:20:54 <EinMByte> "crypto enhancements" is pretty broad
15:21:12 <zzz> what actually happened on crytpo enhancements were some 25519 speedups
15:21:34 <zzz> so the .25 list all actually is in there except wrapper
15:22:00 <zzz> but there's more to do on sybil so lets keep that on the 26 list
15:22:08 <str4d> Great
15:22:25 <str4d> We bumped GMP 6 to .26 because of the need for more testing
15:22:35 <zzz> what else on the 26 list now should be in there or moved
15:23:05 <EinMByte> Eventually preventing sybil will probably be a lot of work, so it seems long-term to me
15:23:10 <EinMByte> (in the sense that we need a good literature review first)
15:23:15 <zzz> orignal, yeah, ntcp w/ padding is ntcp2
15:23:21 <str4d> EinMByte, the Sybil detection tool isn't used for anything yet, that is where more planning is needed :)
15:23:49 <zzz> hottuna4 is unavailable for a month, not sure when that month is up, so gmp6 may or not make it into 26
15:24:02 <str4d> K
15:24:37 <str4d> Subscription protocol improvements for addressbook: that is something that would be very good to add in ASAP, so old Dest owners can migrate to Ed25519
15:24:37 <EinMByte> I think CRLs don't really need a question mark
15:24:47 <str4d> But how long will that actually take to do?
15:25:14 <zzz> we'll need some status update from tuna soon, I expect the deadline for propping big stuff for 26 would be late march / 1st week of april
15:26:10 * str4d still doesn't quite understand the CRL stuff, could zzz expand?
15:26:14 <zzz> 25 will have ability to read crls from disk, so we can include in the update
15:26:35 <zzz> but thats not so helpful because in an update we can just remove the cert and that does the same thign
15:26:56 <zzz> so to get crls out to ppl w/o having to do an update, we would put them in the feed
15:26:57 <str4d> I'm just trying to figure out the use case
15:27:09 <zzz> use case is somebody gets compromised
15:27:20 <str4d> Do we still not do cert pinning?
15:27:30 <zzz> no
15:27:56 <zzz> so i've done 90 % of it and just need to stick the crl into the namespace
15:28:46 <zzz> pinning is tricky and dangerous
15:29:05 <zzz> crypto cat did the 'pinning suicide'
15:29:17 <zzz> where they were pinned but an intermediate changed
15:30:49 <zzz> i don't think pinning replaces cls
15:30:51 <zzz> crls
15:31:21 <zzz> crls not just for ssl, there's reseed and update keys
15:31:58 <zzz> can we keep crls on the list for 26 then? it's almost done
15:32:20 <str4d> What I'm concerned re: pinning is that someone could do e.g. a Quantum Insert-like thing to redirect a reseed domain name, and just put up any valid SSL cert satisfying the domain name requirement, and the routers will accept it
15:33:05 <str4d> And re: CRLs, if we use that to disable a particular certificate, what does that certificate get replaced with?
15:33:25 <zzz> nothing. in the next release there would presumably be  a replacement
15:33:45 <str4d> This is getting a bit far into the weeds
15:34:07 <str4d> I think where I was going is we need to think this over a bit more
15:34:24 <zzz> ok so let's keep crls for 26 but let's discuss the details on it in the next week or two
15:34:30 <zzz> as it's not 100% clear
15:34:38 <zzz> moving on
15:34:42 <zzz> what else ont he 26 list
15:34:43 <str4d> mmk
15:34:50 <EinMByte> ok
15:35:08 <zzz> subscription protocol
15:35:28 <zzz> this is the key for crypto migration of sites
15:35:40 <EinMByte> hosts.txt replacement or what do you mean?
15:36:22 <zzz> yes this is the hosts.txt as a feed thing, with like foo.i2p=b64#sig=b64#cmd=alt ...
15:36:26 <str4d> EinMByte, amending the addressbook subscription protocol with signed key-value metadata
15:36:49 <zzz> proposal is pretty set, but on hold for 18 months or so
15:37:07 <EinMByte> Sure, although wouldn't the size of the hosts file grow too large
15:38:02 <EinMByte> Maybe add a since parameter, to exclude all hosts inserted before some given time
15:38:07 <EinMByte> (to avoid downloading the whole list even if it's not required)
15:38:22 <zzz> this was originally part of the crypto migration plan but it was hard and wasn't the most important part
15:38:49 <zzz> but it's the main thing remaining on crypto migration of signatures
15:39:26 <str4d> EinMByte, we kinda have that already with etag
15:39:28 <zzz> this is another one of those things that's proposed with a lot of specifics, but haven't quite got agreeement and so havent started
15:39:42 <EinMByte> str4d: Is it used, though?
15:39:46 <str4d> EinMByte, yes
15:40:00 <EinMByte> Oh, nvm. in that case
15:40:03 <str4d> This would be no different to the current setup
15:40:20 <zzz> so we'll on the 26 list and start on it asap. not sure if we can get far enough into it for 26 but I'll try. we need to review the thread on zzz.i2p
15:40:22 <str4d> but instead of domain name entries never repeating, they would now repeat in the "stream"
15:40:42 <EinMByte> Is there a particular reason why we need to keep the weird format, though?
15:41:05 <EinMByte> It would seem easier to me if we just used something standard
15:41:06 <zzz> maybe. compatibility with old clients. but we should review and decide for sure if that's important
15:41:20 <zzz> none have us have looked at this in maybe a year
15:41:28 <zzz> so we'll dust it off and take a looko
15:41:32 <EinMByte> zzz: Compatibily could be handled by also providing the old hosts.txt file for a while
15:41:41 <str4d> There's also the broader issue of what to do with e.g. all the "lost" names
15:41:53 <str4d> But that is outside the current discussion
15:41:57 <zzz> yup. we would also need to get the other impls involved
15:42:18 <EinMByte> str4d: I think that's something to decide on when we get a new naming system (if we ever do)
15:42:26 <str4d> For now, I want some way for currently-active domains to update their dests
15:42:26 <zzz> ok, it's staying on the list for 26 for now. next on the list - sybil stuff
15:42:45 <zzz> can we make sybil be automatic? Have you all read the philip winter paper I hope????
15:42:50 <str4d> And the sooner we get the core code in, the sooner we can turn it on in a year or so
15:43:50 <EinMByte> zzz: What paper? I missed something clearly
15:44:27 <zzz> check @__phw on twitter for link
15:45:02 <zzz> we are working with him thanks to a sadie introduction at ccc
15:45:03 <EinMByte> zzz: this: http://arxiv.org/pdf/1602.07787v1.pdf?
15:45:27 <zzz> if it was published in the last coulple weeks, thats it
15:45:59 <EinMByte> Well, it's an eprint from February this year
15:46:09 <zzz> i don't think we're ready for automatic. they arent really either
15:46:22 <zzz> they just spit out an email once a day to the dirauths
15:46:36 <zzz> it's all heuristic and magic on both sides
15:46:49 <EinMByte> So he probably put the eprint online after it got published
15:46:57 <zzz> so I'd like to push automatic stuff out to later in the year
15:47:07 <str4d> EinMByte, 25 Feb is the version I have
15:47:14 <EinMByte> zzz: So how exactly would that work in a decentralized setting?
15:47:44 <str4d> We need to do things from the bottom-up instead of the top-down
15:48:06 <str4d> ie. each router would need to include "potential Sybil candidates" in the peer profiles
15:48:13 <zzz> EinMByte, I don't know. it's hard
15:48:20 <str4d> based on e.g. online times etc.
15:48:30 <EinMByte> Detecting sybil attacks is doable I think, preventing them based on that detection is very hard in a decentralized network
15:48:30 <EinMByte> But I like the challenge
15:48:34 <zzz> we also need gravy who is working on a centralized redo of his setup
15:48:43 <str4d> There is also the possibility of having some kind of more centralized setup
15:48:45 <str4d> Yah, that
15:48:45 <EinMByte> str4d: At that point you need to start assigning trust to each router
15:48:52 <EinMByte> which itself would be a whole anti-sybil system
15:49:07 <str4d> And having routers subscribe to a list of potential sybils
15:49:07 <zzz> kinda like the dagon proposals
15:49:09 <str4d> EinMByte, that is basically what peer profiles are now though
15:49:31 <str4d> where "trust" is currently defined as "reliably routed well for me in the past"
15:49:42 <EinMByte> str4d: Yes, and they've caused a few attacks so far :)
15:50:15 <str4d> Yep
15:50:23 <EinMByte> Also, peer profiles don't really allow you exclude a peer from the network
15:50:31 <EinMByte> Sybil prevention would sort of allow that
15:50:35 <str4d> Peer profiling and peer selection is another of the things I think needs prioritisation
15:50:46 <str4d> EinMByte, they *can*
15:51:01 <zzz> so i propose to change the 26 sybil item to 'continued improvement' but move the 'automatic' part to later
15:51:01 <str4d> Not right now
15:51:11 <str4d> I'm just saying that is where we would put it
15:51:34 <EinMByte> str4d: Yes, that's possible.
15:51:37 <str4d> (in terms of putting Sybil detection and more advanced techniques into I2P's lexicon and architecture)
15:51:53 <EinMByte> In any case, I would not drop the decentralization. It's the nicest part of I2P imho
15:52:14 <str4d> Yep
15:52:27 <EinMByte> (and centralization also leads to various practical attacks anyway)
15:52:43 <zzz> lets move on. streaming improvements? not sure what that is, maybe just perennial 'make it better' item
15:52:49 <str4d> zzz, yep, we can continue to work on that routerconsole page, and then hook it into the peer profiles and selection once we decide on a strategy
15:53:00 <zzz> i can't think of what there is to do specifically on streaming. anybody?
15:53:01 <EinMByte> Sometimes adding a central authority can make your security proof easy, but cause security failure in practice
15:53:20 <str4d> Research and optimizations would be nice
15:53:28 <EinMByte> zzz: Any obvious improvements we could make there?
15:53:30 <str4d> That would be a good candidate for external research
15:53:46 <zzz> we really need a better test setup
15:53:51 <EinMByte> str4d: I agree.
15:53:55 <zzz> add delays / drops, reorder, etc
15:54:04 <EinMByte> We should probably extend our "open research questions" page with that and other stuff
15:54:40 <zzz> i don't have much blue sky things on my list of streaming stuff. it needs to to be test-result-driven
15:54:50 <EinMByte> There may be more improvement in the allocation of tunnels?
15:55:05 <str4d> zzz, there's some GH project that simulates "The Internet" with containers that can do that IIRC
15:55:08 <zzz> so how about we make this item be 'streaming test harness'
15:55:17 <str4d> Dunno how easy it would be tho, we would need a new JVM per container :P
15:55:25 <str4d> EinMByte, mmm
15:55:48 <EinMByte> str4d: shadow could be used, I think. Not sure if it could be integrated with Java but it's on the kovri TODO list
15:55:52 <str4d> That's not really streaming tho, that is at the datagram level
15:56:22 <zzz> the tunnel allocation thing is psi's idea to have the client pick tunnels
15:56:34 <EinMByte> str4d: Yes, I suspect there's more to optimize this
15:56:46 <EinMByte> zzz: I don't really think users are the best optimization algorithms, but maybe
15:57:10 <zzz> it's a violent corruption of our layering, and I don't see any way to do it. but that's what psi is proposing
15:57:19 <EinMByte> ... or probably "client" does not mean user
15:57:32 <zzz> client == client-side of i2cp
15:57:44 <str4d> The thing there is
15:57:54 <str4d> Tor does provide this ability via their Control Socket
15:57:58 <EinMByte> Ok so it does mean that
15:57:59 <str4d> And it is very useful for researchers
15:58:10 <str4d> But they also have a much flatter architecture
15:58:19 <str4d> Whereas we silo different clients from each other via I2CP
15:58:31 <EinMByte> zzz: I'd expect the router to have more relevant information. The client could pass any additional requirements
15:58:41 <zzz> we also have psi's lua hooks for researchers, that never got merged (either in java or kovri), but is still an option
15:59:14 <zzz> see right now the client side doesn't even know about tunnels, so it certainly doesn't have any ability to pick them
15:59:16 <str4d> Speaking to nickm at RWC, he said it was much easier for Tor to maintain a Control Socket interface than a plugin system
15:59:17 <EinMByte> I know that shadow is being used in practice by researchers
15:59:22 <EinMByte> Lua, I don't know
15:59:55 <EinMByte> zzz: So probably the same thing can be achieved by passing the relevant information over I2CP?
16:00:17 <zzz> 1mb, yes, but it would be really fugly
16:00:44 <str4d> We could always restrict it with a -research flag or something
16:00:54 <str4d> (in router.config)
16:01:06 <str4d> That way most users are not exposed to the fugly
16:01:13 <zzz> kovri/i2pd don't have those rigid API barriers between client/router yet, it's easier for the
16:01:20 <zzz> *them
16:01:28 <str4d> And we can define ".research" from the start to mean "We reserve the right to change these APIs"
16:01:44 <str4d> ie. researchers would need to use the .research flag along with a particular version
16:01:57 <str4d> Back to the actual topic of discussion:
16:01:59 <EinMByte> zzz: Re: tunnels. It depends. I think it would make sense to pass information about the intended usage of the tunnel.
16:02:20 <zzz> (FYI this meeting will go 25 more minutes max, to be continued sunday)
16:02:33 <EinMByte> zzz: It's mainly easier for us because shadow is written in C, I think
16:02:42 <str4d> I think this should be pushed into the "needs more research" category
16:02:44 <zzz> the trouble is its not just your tunnels that need to be picked but the far-end's tunnels
16:02:48 <EinMByte> Ok. Let's move on then.
16:03:08 <zzz> ok that's all that's on the 26 list now. What should be added?
16:03:11 <EinMByte> zzz: Doesn't the far-end handle that
16:03:36 <zzz> no, we source-route (i.e. pick the far-end lease out of it's leaseset for his inbound)
16:04:08 <zzz> look at the 27-29 list. what should be pulled in to 26 if anything?
16:04:44 <str4d> I want to start getting the prep work done for new LSs and the netdb
16:04:46 <zzz> here is where all the 'initial work on xxx for 2017' is, but also lots of 2016 stuff
16:05:23 <EinMByte> zzz: I misunderstood what you meant with far-end, nvm
16:05:31 <str4d> The sooner we get that settled down and into the codebase, the sooner the network will have broad support for it
16:06:42 <EinMByte> Note that we (kovri) want specifications
16:06:52 <EinMByte> Otherwise it will be hard to keep up with the implementation
16:07:31 <zzz> sure. anything that's a new specification, we need to all work on together
16:07:36 <EinMByte> str4d: Let's start by listing what LS2 should actually support
16:07:53 <EinMByte> (if that hasn't already been done)
16:09:40 <zzz> basically ls2 is only a couple of things
16:09:59 <zzz> add some space for flags 
16:10:09 <zzz> and enable future crypto
16:10:52 <zzz> but i have all those proposals about better multihoming, plus grothoff-like service lookup
16:11:00 <zzz> anycast
16:11:01 <EinMByte> Do we have specific list somewhere for reference?
16:11:11 <zzz> it's pulled together on zzz, sec
16:11:23 <str4d> EinMByte, I'm slowly working on pulling all that together on the website
16:11:41 <zzz> can we make that faster str4d ? like next week or two?
16:11:47 <str4d> That should go into the .26 list
16:11:50 <str4d> Hmm
16:11:53 <str4d> Possibly
16:11:59 <str4d> I need moar eyes on it
16:11:59 <zzz> without the proposals on a simple list this is way too hard
16:12:08 <EinMByte> str4d: Great. Actually for some of these things a wiki-functionality would be useful
16:12:24 <EinMByte> (idea is that it would go faster)
16:12:48 <zzz> for starters we need a list
16:12:50 <str4d> EinMByte, exactly
16:12:56 <zzz> lets not boil the ocean here
16:13:11 <str4d> I'm trying to move from requiring backend HTML to (currently) rST
16:13:31 <str4d> I need people to look over what I have to check that a) it is usable and b) it doesn't lose anything we currently have
16:13:39 <str4d> Currently it is applied to the spec docs only
16:13:40 <zzz> let's put the proposal thing on the list for 26 and we'll talk later about what that means. But we need forward progress on it asap.
16:13:55 <str4d> But the moment that is solidified, extending it to proposals is trivial
16:13:56 <zzz> i want them on the website. i don't care what form.
16:14:46 <EinMByte> I'm willing to review proposals, but it happens sometimes that I just don't find any text
16:15:10 <EinMByte> (some things on the website are sort of hidden, I think)
16:15:37 <zzz> right
16:16:05 <zzz> we need to move stuff from zzz.i2p to the website in some sort of organization
16:16:13 <EinMByte> str4d: Moving from HTML to something which can be easility converted to various formats is a good thing
16:16:28 <EinMByte> zzz: Yes, absolutely
16:16:35 <str4d> EinMByte, what I need reviewed is in i2p.www.str4d
16:16:36 <EinMByte> Maybe a fixed process for all proposals
16:16:57 <zzz> ok. it's on the list for 26. details to follow. str4d get to work. i wouldn't expect a lot of feedback. Just come up with a new system and we will all fall in line
16:17:02 <str4d> and on http://vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p/
16:17:04 <str4d> EinMByte, if you want to work with me on nailing that down, I could get that finished maybe by .25
16:17:23 <zzz> what else for 26? we gotta wrap this up
16:17:36 <str4d> ( EinMByte, http://vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p/spec specifically)
16:18:14 <zzz> this is very short term stuff. I need to know what to do on monday
16:18:27 <zzz> last call for 26
16:18:41 <str4d> I think the subscriptions stuff will take a while
16:18:49 <str4d> So I'd be happy with that being the main thing
16:18:52 <zzz> agreed. 
16:19:54 <zzz> ok. meeting on sunday same time. we will start with vrp/h1. please review ticket 1119 in advance. after that we will talk about 27-29, time permitting.
16:20:06 <EinMByte> str4d: Any of those that you think require most attention?
16:20:27 <zzz> we can also briefly circle back to 26 on sunday if necessary
16:20:43 <str4d> EinMByte, basically deciding whether the format for writing proposals is usable, and whether it limits what ends up on the website (in either HTML or TXT format)
16:20:45 <zzz> so agenda on sunday will be 1) vrp/h1/1119; 2) 26; 3) 27-29
16:20:57 <zzz> thanks everybody
16:21:25 * zzz *bafs* the meeting closed
16:27:50 <EinMByte> str4d: It is probably OK as long as it can be coverted to most other formats :)