Overview and Logs for the tini2p Dev Meeting Held on 2019-02-07
Project design & goals, Current status, Timeline, Roadmap, Contributors outreach, and miscellaneous
dev diaries
i2p
crypto
el00ruobuob / oneiric
Logs
<oneiric_> 0. Greetings <oneiric_> hallo <Corklander> Hello! <oneiric_> 1. Project design + goals <oneiric_> the main (somewhat rough) design document is here: https://github.com/tini2p/tini2p/DESIGN.md <Corklander> I show this as the URL: https://github.com/tini2p/tini2p/blob/master/DESIGN.md <oneiric_> i2p components will be separated into (mostly) independent modules <oneiric_> thanks Corklander <oneiric_> only the minimal set of features for a functioning i2p router will be implemented <oneiric_> as new protocols come online (LS2, ECIES) old crypto will be deprecated and removed <oneiric_> any questions? <oneiric_> comments? <Corklander> Are there any specific architecture requirements? As in, need an AES-boosted CPU, etc.? <oneiric_> not that i can tell so far, but i haven't focused on multi-platform too much yet <oneiric_> need to get it working on a single platform first :) <Corklander> Yup. :) <oneiric_> that being said, i'm trying to keep portability in mind, to ease multi-platform suppoort <oneiric_> support* <Corklander> A super-slim router would have the distinct advantage of very high portability even to SoCs. <oneiric_> it would be amazing to run on a super slim board like that <oneiric_> that may require a port to c which is a potential path to go down once an mvp router is finished <oneiric_> ^ maybe <Corklander> Also good to hear. <oneiric_> a rust impl is also on the table, but we can revisit that in the roadmap section <oneiric_> are we good to move on? <kinghat> is there a non dev variant of #tini2p-dev? <oneiric_> kinghat: absolutely #tini2p <oneiric_> moving on <oneiric_> 2. Current project status <oneiric_> currently building out the ntcp2 transport, and will move to i2np, tunnels and netdb next. <oneiric_> client modules are completely open to independent, parallel dev <oneiric_> core components can be developed in parallel with some communication <oneiric_> the code is still in somewhat high flux, and am just rebasing on a single commit atm <oneiric_> fairly close to having the networking + session management for the ntcp2 transport <oneiric_> after that, ntcp2 will be more-or-less finished <oneiric_> any comments questions? <Corklander> This is more architectural/design: what license do you plan to release? <oneiric_> current license is BSD-3 (to be compatible w/ kovri+monero) <oneiric_> it may change if necessary, currently don't see a need to <Corklander> Good. :) <oneiric_> ready to move on? <oneiric_> 3. Development timeline estimates <oneiric_> the code should stabilize in the next 1-2 weeks, and i'll change to making PR/MRs against the master branch <oneiric_> after finishing ntcp2, i2np + tunnels should take ~1-1.5 weeks each to get working <oneiric_> netdb will be somewhat more involved, and may take 2-3 weeks to get working <oneiric_> the router context should be fairly easy to implement, ~1 week <oneiric_> garlic encryption, notably AES+SessionTag management, is fairly complicated, ~2-3 weeks <oneiric_> total estimated time for core components: ~7-12 weeks <oneiric_> client components are somewhat easier to implement <oneiric_> reseed and address book should take ~1.5-2 weeks each <oneiric_> the most complicated components are i2cp and the proxy interfaces <oneiric_> atm, only socks + http proxies will be implemented as APIs for external apps (~2-2.5 weeks each) <oneiric_> i2cp is the interface between the client & router context, ~2 weeks <oneiric_> client destinations manage the interface b/w proxies & the client context, ~1.5-2 weeks <oneiric_> total estimated time for client components: ~7-8.5 weeks <oneiric_> total time for mvp router: ~4-5 months <oneiric_> the above estimates are conservative, and assume a singular developer <oneiric_> actual dev time may be much less <oneiric_> questions comments? <oneiric_> ready to move on then? <Corklander> Do you see use of wireframes/mockups that could help make development testing faster? <oneiric_> currently using Catch2 as a testing framework <oneiric_> all code so far is covered by test cases <oneiric_> currently hammering out some network bugs for ntcp2 sessions, net tests have been extremely helpful here, for example <oneiric_> does that answer your question? <oneiric_> or were you talking about something else? <Corklander> (I'm jumping the gun and asking about how to share workload using wireframes.) <oneiric_> oh, i have a diagram for component interaction that i'll finish and post after the meeting <oneiric_> it still contains streaming + SAM components, which likely won't be implemnted <oneiric_> streaming library may be, but it may turn out to be unnecessary <oneiric_> any more discussion, or ready for roadmap item? <oneiric_> 4. Roadmap <oneiric_> finish ntcp2 transport -> netdb impl -> tunnel impl -> garlic impl -> router context impl <oneiric_> client destination impl -> address book impl -> socks 4a + http proxies impl -> client context impl <oneiric_> the above roadmap is assuming singular dev, multiple devs will parallelize efforts <oneiric_> questions comments? <Corklander> On roadmap, should there be a list of infrastructure? As in git host, communications info, etc? <oneiric_> haven't thought too much about infrastructure at this point <oneiric_> once code is stable (~1-2 weeks), will dedicate more time to things like CI, git host, comms, etc <oneiric_> right now, the project is hosted on github/lab <oneiric_> heard about gitea, which also sounds like a great option <oneiric_> will likely setup a meta meeting to discuss all of that <oneiric_> thanks for bringing that up Corklander, easy to forget about <oneiric_> transitions nicely to the next item <oneiric_> any more discussion before moving on? <oneiric_> 5. Project management + contributor outreach <oneiric_> i am a developer, not a management type, and the skillsets are very different <oneiric_> i can do project management, but this is not my strength <oneiric_> at the moment, i am the only one contributing, so imho, project management is not that crucial <oneiric_> the importance will shift once more contributors become involved <oneiric_> it is good to be forward looking, and some time/effort should be dedicated to reaching out to community members with proven project management experience <oneiric_> contributor outreach is hugely important, and once core components are in place, i will dedicate more time to looking for developers to help out <oneiric_> any community help finding project managers + contributors is greatly appreciated <oneiric_> questions comments? <oneiric_> ok, almost top of the hour, final item <Corklander> You've listed time as your only requirement for now. If you have assistance with coding it would likely impact your time to get the current roadmap finished. <Corklander> What requirements would you like for people to assist you so that you can dedicate your time best? <oneiric_> absolutely, more contributors familiar with i2p (or somewhat easily brought up to speed) should decrease dev time <oneiric_> for client components, socks or http proxies should be the easiest to take on <oneiric_> familiarity with c++ is a req <oneiric_> doesn't have to be expert level, but novice-intermediate <oneiric_> i'm still a bit of a c++ greenhorn, so it would take a bit of time for me to train devs <oneiric_> anyone wanting to contribute to core components should be *very* familiar with i2p, or willing to invest a lot of independent time catching up on docs <oneiric_> will try to guide people through the mire as best as possible <oneiric_> for people totally unfamiliar with i2p, socks + http proxies will be the easiest introduction <oneiric_> socks being the easier of the two <oneiric_> ok, so we're a little over time <oneiric_> final item <oneiric_> 6. Next meeting time <oneiric_> is this a good time/day for people (know some are in UTC+1, so maybe its a bit late?) <oneiric_> also, thank you to all that attended/participated! <Corklander> I'm good with this or later for weekdays. <oneiric_> ok <oneiric_> anyone else need a different time/day? <oneiric_> so next meeting will be 18:00 UTC 21-02-2019 (two weeks from today) <oneiric_> many thanks again to everyone who attended :) <Corklander> Thanks oneiric! <oneiric_> meeting adjourned *gavel strike*