From 454098d3e687cd888fe7894b8408d651e4dcb897 Mon Sep 17 00:00:00 2001 From: el00ruobuob Date: Fri, 29 Mar 2019 07:17:50 +0100 Subject: [PATCH] Tini2p meeting log & backlog --- ...e-tini2p-dev-meeting-held-on-2019-02-07.md | 128 ++++++++++++++++++ ...e-tini2p-dev-meeting-held-on-2019-02-21.md | 72 ++++++++++ ...e-tini2p-dev-meeting-held-on-2019-03-28.md | 102 ++++++++++++++ 3 files changed, 302 insertions(+) create mode 100644 _posts/2019-02-07-logs-for-the-tini2p-dev-meeting-held-on-2019-02-07.md create mode 100644 _posts/2019-02-21-logs-for-the-tini2p-dev-meeting-held-on-2019-02-21.md create mode 100644 _posts/2019-03-28-logs-for-the-tini2p-dev-meeting-held-on-2019-03-28.md diff --git a/_posts/2019-02-07-logs-for-the-tini2p-dev-meeting-held-on-2019-02-07.md b/_posts/2019-02-07-logs-for-the-tini2p-dev-meeting-held-on-2019-02-07.md new file mode 100644 index 00000000..00b3c316 --- /dev/null +++ b/_posts/2019-02-07-logs-for-the-tini2p-dev-meeting-held-on-2019-02-07.md @@ -0,0 +1,128 @@ +--- +layout: post +title: Overview and Logs for the tini2p Dev Meeting Held on 2019-02-07 +summary: Project design & goals, Current status, Timeline, Roadmap, Contributors outreach, and miscellaneous +tags: [dev diaries, i2p, crypto] +author: el00ruobuob / oneiric +--- + +# Logs + +**\** 0. Greetings +**\** hallo +**\** Hello! +**\** 1. Project design + goals +**\** the main (somewhat rough) design document is here: https://github.com/tini2p/tini2p/DESIGN.md +**\** I show this as the URL: https://github.com/tini2p/tini2p/blob/master/DESIGN.md +**\** i2p components will be separated into (mostly) independent modules +**\** thanks Corklander +**\** only the minimal set of features for a functioning i2p router will be implemented +**\** as new protocols come online (LS2, ECIES) old crypto will be deprecated and removed +**\** any questions? +**\** comments? +**\** Are there any specific architecture requirements? As in, need an AES-boosted CPU, etc.? +**\** not that i can tell so far, but i haven't focused on multi-platform too much yet +**\** need to get it working on a single platform first :) +**\** Yup. :) +**\** that being said, i'm trying to keep portability in mind, to ease multi-platform suppoort +**\** support\* +**\** A super-slim router would have the distinct advantage of very high portability even to SoCs. +**\** it would be amazing to run on a super slim board like that +**\** that may require a port to c which is a potential path to go down once an mvp router is finished +**\** ^ maybe +**\** Also good to hear. +**\** a rust impl is also on the table, but we can revisit that in the roadmap section +**\** are we good to move on? +**\** is there a non dev variant of #tini2p-dev? +**\** kinghat: absolutely #tini2p +**\** moving on +**\** 2. Current project status +**\** currently building out the ntcp2 transport, and will move to i2np, tunnels and netdb next. +**\** client modules are completely open to independent, parallel dev +**\** core components can be developed in parallel with some communication +**\** the code is still in somewhat high flux, and am just rebasing on a single commit atm +**\** fairly close to having the networking + session management for the ntcp2 transport +**\** after that, ntcp2 will be more-or-less finished +**\** any comments questions? +**\** This is more architectural/design: what license do you plan to release? +**\** current license is BSD-3 (to be compatible w/ kovri+monero) +**\** it may change if necessary, currently don't see a need to +**\** Good. :) +**\** ready to move on? +**\** 3. Development timeline estimates +**\** the code should stabilize in the next 1-2 weeks, and i'll change to making PR/MRs against the master branch +**\** after finishing ntcp2, i2np + tunnels should take ~1-1.5 weeks each to get working +**\** netdb will be somewhat more involved, and may take 2-3 weeks to get working +**\** the router context should be fairly easy to implement, ~1 week +**\** garlic encryption, notably AES+SessionTag management, is fairly complicated, ~2-3 weeks +**\** total estimated time for core components: ~7-12 weeks +**\** client components are somewhat easier to implement +**\** reseed and address book should take ~1.5-2 weeks each +**\** the most complicated components are i2cp and the proxy interfaces +**\** atm, only socks + http proxies will be implemented as APIs for external apps (~2-2.5 weeks each) +**\** i2cp is the interface between the client & router context, ~2 weeks +**\** client destinations manage the interface b/w proxies & the client context, ~1.5-2 weeks +**\** total estimated time for client components: ~7-8.5 weeks +**\** total time for mvp router: ~4-5 months +**\** the above estimates are conservative, and assume a singular developer +**\** actual dev time may be much less +**\** questions comments? +**\** ready to move on then? +**\** Do you see use of wireframes/mockups that could help make development testing faster? +**\** currently using Catch2 as a testing framework +**\** all code so far is covered by test cases +**\** currently hammering out some network bugs for ntcp2 sessions, net tests have been extremely helpful here, for example +**\** does that answer your question? +**\** or were you talking about something else? +**\** (I'm jumping the gun and asking about how to share workload using wireframes.) +**\** oh, i have a diagram for component interaction that i'll finish and post after the meeting +**\** it still contains streaming + SAM components, which likely won't be implemnted +**\** streaming library may be, but it may turn out to be unnecessary +**\** any more discussion, or ready for roadmap item? +**\** 4. Roadmap +**\** finish ntcp2 transport -> netdb impl -> tunnel impl -> garlic impl -> router context impl +**\** client destination impl -> address book impl -> socks 4a + http proxies impl -> client context impl +**\** the above roadmap is assuming singular dev, multiple devs will parallelize efforts +**\** questions comments? +**\** On roadmap, should there be a list of infrastructure? As in git host, communications info, etc? +**\** haven't thought too much about infrastructure at this point +**\** once code is stable (~1-2 weeks), will dedicate more time to things like CI, git host, comms, etc +**\** right now, the project is hosted on github/lab +**\** heard about gitea, which also sounds like a great option +**\** will likely setup a meta meeting to discuss all of that +**\** thanks for bringing that up Corklander, easy to forget about +**\** transitions nicely to the next item +**\** any more discussion before moving on? +**\** 5. Project management + contributor outreach +**\** i am a developer, not a management type, and the skillsets are very different +**\** i can do project management, but this is not my strength +**\** at the moment, i am the only one contributing, so imho, project management is not that crucial +**\** the importance will shift once more contributors become involved +**\** 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 +**\** contributor outreach is hugely important, and once core components are in place, i will dedicate more time to looking for developers to help out +**\** any community help finding project managers + contributors is greatly appreciated +**\** questions comments? +**\** ok, almost top of the hour, final item +**\** 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. +**\** What requirements would you like for people to assist you so that you can dedicate your time best? +**\** absolutely, more contributors familiar with i2p (or somewhat easily brought up to speed) should decrease dev time +**\** for client components, socks or http proxies should be the easiest to take on +**\** familiarity with c++ is a req +**\** doesn't have to be expert level, but novice-intermediate +**\** i'm still a bit of a c++ greenhorn, so it would take a bit of time for me to train devs +**\** 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 +**\** will try to guide people through the mire as best as possible +**\** for people totally unfamiliar with i2p, socks + http proxies will be the easiest introduction +**\** socks being the easier of the two +**\** ok, so we're a little over time +**\** final item +**\** 6. Next meeting time +**\** is this a good time/day for people (know some are in UTC+1, so maybe its a bit late?) +**\** also, thank you to all that attended/participated! +**\** I'm good with this or later for weekdays. +**\** ok +**\** anyone else need a different time/day? +**\** so next meeting will be 18:00 UTC 21-02-2019 (two weeks from today) +**\** many thanks again to everyone who attended :) +**\** Thanks oneiric! +**\** meeting adjourned \*gavel strike\* diff --git a/_posts/2019-02-21-logs-for-the-tini2p-dev-meeting-held-on-2019-02-21.md b/_posts/2019-02-21-logs-for-the-tini2p-dev-meeting-held-on-2019-02-21.md new file mode 100644 index 00000000..c9241da9 --- /dev/null +++ b/_posts/2019-02-21-logs-for-the-tini2p-dev-meeting-held-on-2019-02-21.md @@ -0,0 +1,72 @@ +--- +layout: post +title: Overview and Logs for the tini2p Dev Meeting Held on 2019-02-21 +summary: Current project status, Roadmap, I2P proposal implementation, Funding, and miscellaneous +tags: [dev diaries, i2p, crypto] +author: el00ruobuob / oneiric +--- + +# Logs + +**\** 0. Greetings +**\** Hi +**\** 1. Current project status / progress since last meeting +**\** since last meeting, completed the basic components of the ntcp2 transport +**\** began work on i2np, researched proposals 123 + 144, and did some code house-keeping +**\** currently working on LeaseSet2 implementation, and other components needed for I2NP + ECIES-X25519 +**\** the project's main repo is also changed to gitlab +**\** comments/questions? +**\** Ohh... do you have the gitlab link? +**\** https://gitlab.com/tini2p/tini2p +**\** Thanks! +**\** np +**\** :) +**\** that leads us into: 2. Short-term road map +**\** looked into gitea for git hosting +**\** will be setting up a host server, and mirror to gitlab +**\** hoping the experience will be reproducible, so other projects can do the same +**\** code is getting close to being able to communicate between routers +**\** remaining pieces: tunnels, i2np, netdb +**\** garlic encryption w/ ecies is probably the most complex, and all three components rely on proposals 123 + 144 +**\** will continue working on i2np + netdb, since a majority of those components can be completed with the stable parts of the mentioned proposals +**\** hopefully ecies-x25519 will be ready when tunnel impl + garlic is necessary +**\** comments/questions? +**\** 3. I2P proposal implementation (123, 144) +**\** https://geti2p.net/spec/proposals/123-new-netdb-entries +**\** https://geti2p.net/spec/proposals/144-ecies-x25519-aead-ratchet +**\** currently Java-I2P devs are working hard on #123 +**\** dev discussion is in #ls2 on Irc2P +**\** and the dev forum +**\** str4d will be presenting a revised spec for RedDSA used in ECIES-X25519 +**\** hi all, sorry I'm late +**\** no worries, hi sgp\_ o/ +**\** RedDSA is also needed for blinding keys in EncryptedLeaseSet2 entries +**\** once str4d's revised spec is available, will begin implementing RedDSA +**\** orignal\_ and zzz have both been really inviting, and i encourage anyone interested to join the discussion +**\** comments/questions? +**\** Do you know if there's info on when #i2p-dev discussions are scheduled? +**\** for those interested, RedDSA is basically EdDSA with modified r generation +**\** Corklander: there is a schedule on their development forum for dev meetings +**\** most of the recent ones have been in #ls2 afaict +**\** clearnet list of I2P meetings: https://geti2p.net/en/meetings/ +**\** ^ has links to .i2p forum +**\** Thanks +**\** np +**\** #144 (ECIES-X25519) will follow #123 impl +**\** a lot of code from ntcp2 will be reusable, though the business logic is different +**\** block ordering, for example +**\** 4. Project funding +**\** will be posting a donation address on the monero reddit, tin2p-meta repo, and other places it makes sense +**\** atm, don't feel it's right to request full-time funding from Monero community. would like to prove the project more first +**\** for those that would like to support during these early days, you are deeply loved and appreciated +**\** when the router is able to communicate with other routers, i will get more serious about fundraising +**\** comments/questions? +**\** What coins are you planning to accept? +**\** xmr for now, and grin once i set up a wallet +**\** wownero +**\** ;) +**\** 5. Confirm next meeting time +**\** two weeks from today is really close to fork, maybe do three weeks from today, same time? +**\** nice +**\** That works for me +**\** ok, so that's 2019-03-14 18:00 UTC diff --git a/_posts/2019-03-28-logs-for-the-tini2p-dev-meeting-held-on-2019-03-28.md b/_posts/2019-03-28-logs-for-the-tini2p-dev-meeting-held-on-2019-03-28.md new file mode 100644 index 00000000..de8d1a57 --- /dev/null +++ b/_posts/2019-03-28-logs-for-the-tini2p-dev-meeting-held-on-2019-03-28.md @@ -0,0 +1,102 @@ +--- +layout: post +title: Overview and Logs for the tini2p Dev Meeting Held on 2019-03-28 +summary: Project infrastructure, Current status, Roadmap, I2P proposal implementation, and miscellaneous +tags: [dev diaries, i2p, crypto] +author: el00ruobuob / oneiric +--- + +# Logs + +**\** 0. greets +**\** hi +**\** Hey! +**\** o/ +**\** 1. Project infrastructure / DevOps +**\** hi all +**\** recently setup CircleCI, Docker and Bitbucket CI pipelines +**\** going to try out Drone CI (integrates w/ GitLab), and decide on a final CI provider +**\** will keep alternative configs in contrib/ +**\** got a basic Docker image setup with everything needed to build tini2p +**\** need to fix net tests to be able to run in a container for accurate coverage stats +**\** other than that, CI is more-or-less setup +**\** will be experimenting/playing with gitea over the next weeks, and mirror GitLab to GitHub, BitBucket, and gitea +**\** unfortunately lost access to tini2p account on GitHub, though still have push ability +**\** main github repo is now: https://github.com/tnii2p-project/tini2p +**\** 404 :( +**\** derp +**\** type +**\** typo +**\** my fingers are terrible today +**\** https://github.com/tini2p-project/tini2p +**\** Yea! +**\** -\_- +**\** lol +**\** anyway +**\** any questions/comments? i think that's all for infrastructure stuff. +**\** Do you see any dependency problems with Drone CI or the other choices? (I haven't used them so I'm not sure about any restrictions/costs.) +**\** most of them i've seen are basically the same +**\** x free hours for builds, then monery +**\** the integrations are the differentiators +**\** circle works with github and bitbucket, drone works with gitlab +**\** sry, have to go due to emrf, bbl +**\** think there are webhook integrations on most/all major gitserver providers +**\** anyway +**\** ttyl +**\** anything else on 1? +**\** 2. Current project status / what's been done +**\** spent a lot of time replacing crypto++ with libsodium + tiny-AES-c +**\** then realized, "oh, i need an SSL lib" +**\** so, added LibreSSL as a dependency for potential future Keccak patch, and replaced tiny-AES-c with SSL impl +**\** that's in an open MR: https://gitlab.com/tini2p/tini2p/merge\_requests/2 +**\** finished with code cleanup, generic crypto/signature wrappers, and a basic experimental ECIES-X25519-AEAD-Ratchet impl +**\** merged MR: https://gitlab.com/tini2p/tini2p/merge\_requests/1 +**\** currently working on generic wrappers for the proposed Blake2b EdDSA variants +**\** which i will discuss in 4 +**\** questions/comments on 2? +**\** awesome progress +**\** will also hopefully be able to help zzz with ECIES testing (fingers-crossed) +**\** thanks endogenic :) +**\** 3. Short-term road map +**\** implement the Blake2b sig variants to help other I2P projects with testing +**\** implement tunnels + basic netdb +**\** if lmdb interface is simple enough, will skip past doing blockfile format, and just use lmdb for addressbook/netdb needs +**\** that's where i want to be anyway :) +**\** adding alpha and beta milestones to the gitlab project +**\** projected alpha release for 2019/07/10 +**\** with a beta following 3 months after +**\** will see how this first cycle goes, but will try to keep to that release schedule, or shorten it if feasible +**\** good plan +**\** the minimum usable set is generally critical to keep in mind to avoid getting lost along the way +**\** dont think that's a huge issue here given the name "tiny" though :) +**\** good origins +**\** yeah, if shorter, may do alpha (2 months) -> beta (2 months) -> point release +**\** true, as part of 4. i'll talk about the current sig variant proposals, and which of those will end up in tini2p +**\** which is actually a nice transition (smooth endogenic) +**\** 4. I2P proposal implementation +**\** https://geti2p.net/spec/proposals/123-new-netdb-entries +**\** https://geti2p.net/spec/proposals/144-ecies-x25519-aead-ratchet +**\** https://geti2p.net/spec/proposals/146-red25519 +**\** https://geti2p.net/spec/proposals/148-eddsa-blake2b-ed25519 +**\** we went over 123 and 144 last meeting, iirc +**\** one thing that has changed, zzz has said he will be switching focus back to ECIES, and hammering out some spec details +**\** so we are getting closer to a finalized spec, which will reduce code footprint +**\** 146 and 148 are the new sig variant proposals +**\** for eddsa +**\** RedDSA is needed for blinding encrypted lease sets, and Blake2b variants are needed to protect against LEA attacks +**\** Ed25519ctx was also suggested, and is being considered for LEA protection +**\** personally, think Ed25519ctx is gross given the alternatives, but it's in an RFC +**\** RFC 8032 to be specific +**\** the hash function in RFC 8032 isn't specified, other than being a crypto-secure hashing function with 512-bits security +**\** Blake2b satifies all criteria +**\** for full details see the proposals and #ls2 meeting logs +**\** so, my plan is to write generic wrappers for all variants, then keep whichever get accepted +**\** right now, it's looking like RedDSA-Blake2b-EdDSA can be used for all places where a signature is needed +**\** a lot is still up in the air though, and nothing has been finalized yet +**\** any comments/questions on 4? +**\** one more thing actually, EdDSA-Blake2b-Ed25519 could also be used everywhere a signature is used +**\** afaiui EdDSA-Blake2b-Ed25519 can also do blinding needed for encrypted lease sets +**\** 5. Confirm next meeting time +**\** same time two weeks? +**\** yup +**\** right on, meeting over. thanks to all for attending