monero-project/monero-site
monero-project/monero-site
1
0
Fork 0
mirror of https://github.com/monero-project/monero-site.git synced 2024-12-23 12:09:49 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Merge !1047

Browse source 
Tini2p dev meeting log & backlog

See merge request monero-project/monero-site!1047
This commit is contained in:
luigi1111 2019-04-23 22:44:48 +02:00
commit 72757d7d0c
3 changed files with 302 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

128
_posts/2019-02-07-logs-for-the-tini2p-dev-meeting-held-on-2019-02-07.md Normal file
View file

@ -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
**\<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\*

72
_posts/2019-02-21-logs-for-the-tini2p-dev-meeting-held-on-2019-02-21.md Normal file
View file

@ -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
**\<oneiric\_>** 0. Greetings
**\<Corklander>** Hi
**\<oneiric\_>** 1. Current project status / progress since last meeting
**\<oneiric\_>** since last meeting, completed the basic components of the ntcp2 transport
**\<oneiric\_>** began work on i2np, researched proposals 123 + 144, and did some code house-keeping
**\<oneiric\_>** currently working on LeaseSet2 implementation, and other components needed for I2NP + ECIES-X25519
**\<oneiric\_>** the project's main repo is also changed to gitlab
**\<oneiric\_>** comments/questions?
**\<Corklander>** Ohh... do you have the gitlab link?
**\<oneiric\_>** https://gitlab.com/tini2p/tini2p
**\<Corklander>** Thanks!
**\<oneiric\_>** np
**\<oneiric\_>** :)
**\<oneiric\_>** that leads us into: 2. Short-term road map
**\<oneiric\_>** looked into gitea for git hosting
**\<oneiric\_>** will be setting up a host server, and mirror to gitlab
**\<oneiric\_>** hoping the experience will be reproducible, so other projects can do the same
**\<oneiric\_>** code is getting close to being able to communicate between routers
**\<oneiric\_>** remaining pieces: tunnels, i2np, netdb
**\<oneiric\_>** garlic encryption w/ ecies is probably the most complex, and all three components rely on proposals 123 + 144
**\<oneiric\_>** will continue working on i2np + netdb, since a majority of those components can be completed with the stable parts of the mentioned proposals
**\<oneiric\_>** hopefully ecies-x25519 will be ready when tunnel impl + garlic is necessary
**\<oneiric\_>** comments/questions?
**\<oneiric\_>** 3. I2P proposal implementation (123, 144)
**\<oneiric\_>** https://geti2p.net/spec/proposals/123-new-netdb-entries
**\<oneiric\_>** https://geti2p.net/spec/proposals/144-ecies-x25519-aead-ratchet
**\<oneiric\_>** currently Java-I2P devs are working hard on #123
**\<oneiric\_>** dev discussion is in #ls2 on Irc2P
**\<oneiric\_>** and the dev forum
**\<oneiric\_>** str4d will be presenting a revised spec for RedDSA used in ECIES-X25519
**\<sgp\_>** hi all, sorry I'm late
**\<oneiric\_>** no worries, hi sgp\_ o/
**\<oneiric\_>** RedDSA is also needed for blinding keys in EncryptedLeaseSet2 entries
**\<oneiric\_>** once str4d's revised spec is available, will begin implementing RedDSA
**\<oneiric\_>** orignal\_ and zzz have both been really inviting, and i encourage anyone interested to join the discussion
**\<oneiric\_>** comments/questions?
**\<Corklander>** Do you know if there's info on when #i2p-dev discussions are scheduled?
**\<oneiric\_>** for those interested, RedDSA is basically EdDSA with modified r generation
**\<oneiric\_>** Corklander: there is a schedule on their development forum for dev meetings
**\<oneiric\_>** most of the recent ones have been in #ls2 afaict
**\<oneiric\_>** clearnet list of I2P meetings: https://geti2p.net/en/meetings/
**\<oneiric\_>** ^ has links to .i2p forum
**\<Corklander>** Thanks
**\<oneiric\_>** np
**\<oneiric\_>** #144 (ECIES-X25519) will follow #123 impl
**\<oneiric\_>** a lot of code from ntcp2 will be reusable, though the business logic is different
**\<oneiric\_>** block ordering, for example
**\<oneiric\_>** 4. Project funding
**\<oneiric\_>** will be posting a donation address on the monero reddit, tin2p-meta repo, and other places it makes sense
**\<oneiric\_>** atm, don't feel it's right to request full-time funding from Monero community. would like to prove the project more first
**\<oneiric\_>** for those that would like to support during these early days, you are deeply loved and appreciated
**\<oneiric\_>** when the router is able to communicate with other routers, i will get more serious about fundraising
**\<oneiric\_>** comments/questions?
**\<Corklander>** What coins are you planning to accept?
**\<oneiric\_>** xmr for now, and grin once i set up a wallet
**\<oneiric\_>** wownero
**\<oneiric\_>** ;)
**\<oneiric\_>** 5. Confirm next meeting time
**\<oneiric\_>** two weeks from today is really close to fork, maybe do three weeks from today, same time?
**\<wowario>** nice
**\<Corklander>** That works for me
**\<oneiric\_>** ok, so that's 2019-03-14 18:00 UTC

102
_posts/2019-03-28-logs-for-the-tini2p-dev-meeting-held-on-2019-03-28.md Normal file
View file

@ -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
**\<oneiric\_>** 0. greets
**\<oneiric\_>** hi
**\<Corklander>** Hey!
**\<endogenic>** o/
**\<oneiric\_>** 1. Project infrastructure / DevOps
**\<kinghat>** hi all
**\<oneiric\_>** recently setup CircleCI, Docker and Bitbucket CI pipelines
**\<oneiric\_>** going to try out Drone CI (integrates w/ GitLab), and decide on a final CI provider
**\<oneiric\_>** will keep alternative configs in contrib/
**\<oneiric\_>** got a basic Docker image setup with everything needed to build tini2p
**\<oneiric\_>** need to fix net tests to be able to run in a container for accurate coverage stats
**\<oneiric\_>** other than that, CI is more-or-less setup
**\<oneiric\_>** will be experimenting/playing with gitea over the next weeks, and mirror GitLab to GitHub, BitBucket, and gitea
**\<oneiric\_>** unfortunately lost access to tini2p account on GitHub, though still have push ability
**\<oneiric\_>** main github repo is now: https://github.com/tnii2p-project/tini2p
**\<Corklander>** 404 :(
**\<oneiric\_>** derp
**\<oneiric\_>** type
**\<oneiric\_>** typo
**\<oneiric\_>** my fingers are terrible today
**\<oneiric\_>** https://github.com/tini2p-project/tini2p
**\<Corklander>** Yea!
**\<oneiric\_>** -\_-
**\<oneiric\_>** lol
**\<oneiric\_>** anyway
**\<oneiric\_>** any questions/comments? i think that's all for infrastructure stuff.
**\<Corklander>** 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.)
**\<oneiric\_>** most of them i've seen are basically the same
**\<oneiric\_>** x free hours for builds, then monery
**\<oneiric\_>** the integrations are the differentiators
**\<oneiric\_>** circle works with github and bitbucket, drone works with gitlab
**\<Corklander>** sry, have to go due to emrf, bbl
**\<oneiric\_>** think there are webhook integrations on most/all major gitserver providers
**\<oneiric\_>** anyway
**\<oneiric\_>** ttyl
**\<oneiric\_>** anything else on 1?
**\<oneiric\_>** 2. Current project status / what's been done
**\<oneiric\_>** spent a lot of time replacing crypto++ with libsodium + tiny-AES-c
**\<oneiric\_>** then realized, "oh, i need an SSL lib"
**\<oneiric\_>** so, added LibreSSL as a dependency for potential future Keccak patch, and replaced tiny-AES-c with SSL impl
**\<oneiric\_>** that's in an open MR: https://gitlab.com/tini2p/tini2p/merge\_requests/2
**\<oneiric\_>** finished with code cleanup, generic crypto/signature wrappers, and a basic experimental ECIES-X25519-AEAD-Ratchet impl
**\<oneiric\_>** merged MR: https://gitlab.com/tini2p/tini2p/merge\_requests/1
**\<oneiric\_>** currently working on generic wrappers for the proposed Blake2b EdDSA variants
**\<oneiric\_>** which i will discuss in 4
**\<oneiric\_>** questions/comments on 2?
**\<endogenic>** awesome progress
**\<oneiric\_>** will also hopefully be able to help zzz with ECIES testing (fingers-crossed)
**\<oneiric\_>** thanks endogenic :)
**\<oneiric\_>** 3. Short-term road map
**\<oneiric\_>** implement the Blake2b sig variants to help other I2P projects with testing
**\<oneiric\_>** implement tunnels + basic netdb
**\<oneiric\_>** if lmdb interface is simple enough, will skip past doing blockfile format, and just use lmdb for addressbook/netdb needs
**\<oneiric\_>** that's where i want to be anyway :)
**\<oneiric\_>** adding alpha and beta milestones to the gitlab project
**\<oneiric\_>** projected alpha release for 2019/07/10
**\<oneiric\_>** with a beta following 3 months after
**\<oneiric\_>** will see how this first cycle goes, but will try to keep to that release schedule, or shorten it if feasible
**\<endogenic>** good plan
**\<endogenic>** the minimum usable set is generally critical to keep in mind to avoid getting lost along the way
**\<endogenic>** dont think that's a huge issue here given the name "tiny" though :)
**\<endogenic>** good origins
**\<oneiric\_>** yeah, if shorter, may do alpha (2 months) -> beta (2 months) -> point release
**\<oneiric\_>** true, as part of 4. i'll talk about the current sig variant proposals, and which of those will end up in tini2p
**\<oneiric\_>** which is actually a nice transition (smooth endogenic)
**\<oneiric\_>** 4. I2P proposal implementation
**\<oneiric\_>** https://geti2p.net/spec/proposals/123-new-netdb-entries
**\<oneiric\_>** https://geti2p.net/spec/proposals/144-ecies-x25519-aead-ratchet
**\<oneiric\_>** https://geti2p.net/spec/proposals/146-red25519
**\<oneiric\_>** https://geti2p.net/spec/proposals/148-eddsa-blake2b-ed25519
**\<oneiric\_>** we went over 123 and 144 last meeting, iirc
**\<oneiric\_>** one thing that has changed, zzz has said he will be switching focus back to ECIES, and hammering out some spec details
**\<oneiric\_>** so we are getting closer to a finalized spec, which will reduce code footprint
**\<oneiric\_>** 146 and 148 are the new sig variant proposals
**\<oneiric\_>** for eddsa
**\<oneiric\_>** RedDSA is needed for blinding encrypted lease sets, and Blake2b variants are needed to protect against LEA attacks
**\<oneiric\_>** Ed25519ctx was also suggested, and is being considered for LEA protection
**\<oneiric\_>** personally, think Ed25519ctx is gross given the alternatives, but it's in an RFC
**\<oneiric\_>** RFC 8032 to be specific
**\<oneiric\_>** the hash function in RFC 8032 isn't specified, other than being a crypto-secure hashing function with 512-bits security
**\<oneiric\_>** Blake2b satifies all criteria
**\<oneiric\_>** for full details see the proposals and #ls2 meeting logs
**\<oneiric\_>** so, my plan is to write generic wrappers for all variants, then keep whichever get accepted
**\<oneiric\_>** right now, it's looking like RedDSA-Blake2b-EdDSA can be used for all places where a signature is needed
**\<oneiric\_>** a lot is still up in the air though, and nothing has been finalized yet
**\<oneiric\_>** any comments/questions on 4?
**\<oneiric\_>** one more thing actually, EdDSA-Blake2b-Ed25519 could also be used everywhere a signature is used
**\<oneiric\_>** afaiui EdDSA-Blake2b-Ed25519 can also do blinding needed for encrypted lease sets
**\<oneiric\_>** 5. Confirm next meeting time
**\<oneiric\_>** same time two weeks?
**\<kinghat>** yup
**\<oneiric\_>** right on, meeting over. thanks to all for attending