Roadmap 2016

[anonimal]

The following has moved to https://github.com/monero-project/kovri

I know this may be a bit ambitious, but I think that a roadmap would be great. It's also been a subject of inquiry, so I think that having some solid ground would (at the very least) "look good". I also spoke briefly with @fluffypony about an irc meeting at some point, but everyone's schedule, etc...

Thinking out-loud, I know that a few of my personal ambitions are:

1. Squashing odd startup bugs and opening tickets when ready (hangs when SU3 is 404, core dumps (Fixed in #281), etc.)
2. Reworking some signal handling (currently not working in Arch) (most likely not Arch related)
3. Reworking the UI (including options for real-time stats)
4. Much longer term goals include: hidden mode and disabling inbound
5. Oh yeah, and all these open tickets...

I currently lack the competency to go anywhere near 4. or most of 5., but there are plenty of other things to do in the mean time.

I've contributed some work into a VRP at http://trac.i2p2.i2p/wiki/Roadmaps/2h2015 that we could use as a starting point in at least that area. Maybe running with dates/ideas that are in parallel could also be beneficial.

I'm open to all ideas and will be happy (and would prefer) to start sketching things out before tackling my wishlist. By doing so, we'd all be on the same page from the get-go - and I think that would be great.

[EinMByte]

IRC meeting is probably a good idea. There are quite a few open issues at the moment, in particular short-term fixes could be #240, #236, #267, #261, #244, #234. The next release (0.11) was planned a few weeks ago, but I'll try to do it soon.

Another very important change we need is peer profiling, this is probably why tunnel build success rates are so low right now with i2pd.

[anonimal]

Hi, sorry to ping you all, but I'm wondering if you'd be interested in having an irc meeting to discuss the project since the dust has settled and most of the drama has passed (I hope). Even if the meeting is weeks or months from now, I think it would be great to set a date. @majestrate has done some cool webUI work and I have some thoughts (early work) on an arm-like monitor for i2pd (c++/ncurses, bundled or separate project to be determined) but of course, as @EinMByte pointed out, there are other issues at hand and I hope we can chat about them.

Does November 1st, 8pm UTC work for you?

@meeh420 @klondi @kytvi2p @mlt @fluffypony

[mlt]

@anonimal Thanks for pinging! The time works for me. I've been busy lately and didn't follow i2pd closely.... should catch up.

[fluffypony]

I can do that time

[majestrate]

That time works (probably). ding me on irc for a reminder I'll probably forget.

[EinMByte]

I'll probably be able to make it, although it's a bit too early to be able to be completely sure. If for some reason i can't make it, I'll let you know.

[anonimal]

Ok, great to hear from you all. I'll mark my calendar but if @EinMByte can't make it then I think we should reschedule so everyone is present. Once the date gets closer, I'll follow up to see if we need to reschedule or if that's something everyone wants to do.

[orignal]

this is probably why tunnel build success rates are so low right now with i2pd.

Status: OK Tunnel creation success rate: 49% Received: 4266K (9141 Bps) Sent: 4741K (9754 Bps)

Good luck

[klondi]

Think I didn't answer. I don't have that much time lately because of work and personal life stuff. If you need my help for something I coded feel free to ping me though and I'll try my best.

[orignal]

@klondi, you are always welcome to join me when you have time

[anonimal]

@klondi Thanks for the message! I appreciate you taking the time to help. @mlt @fluffypony I emailed you via your address provided in the git log. Please let me know if you didn't get the email and I'll send it again. @EinMByte @majestrate Email sent to your i2p addresses.

[anonimal]

For anyone reading this or who stumbles upon it:

• i2pd meeting:
• Nov. 1st, 8pm UTC

• i2pd-dev (irc2p/freenode/(oftc?))

Note: that day is DST for some countries. Please adjust accordingly.

Summary of proposed discussion points:

1. Who is actively involved?
2. What is the purpose of this project?
3. Where is this project going?
4. Governance: benefits/drawbacks, who will do what
5. Points I had made in original email (if we end up do going there)
6. Open discussion

[anonimal]

Thanks to everyone for a great meeting!

Meeting log here: http://pastethis.i2p/show/9650/

Next meeting:

• Nov. 15th, 8-9pm UTC (we'll try to keep it within an hour)

• i2pd-dev irc2p/freenode

Spill-over items from Nov. 1st meeting:

1. Provide "a better understanding of the target use cases, maturity, stability, security, and rate of change of the two forks, so the overall I2P project can make recommendations to people on which to use for a given use case." This includes providing a concrete response for "the technical purpose and use case of the bitbuckt fork and [understand] the differences with the github branch."
2. Regarding the new project direction of "manageable, well-structured, well-written, well-documented code who's ultimate goal is not a small footprint but rather features and usability" discuss specifics on what Monero's role will be versus the developer's role. This includes: "creating developer standards, guidelines to prevent conflict, coding conventions/style, inline documentation, [and] development process."
3. Discuss how to handle any bigger changes before the move to Monero (so contributors aren't left waiting, such as @majestrate's cool new WebUI):

<mlt-> fluffypony, I meant i2pd-2 shouldn't freeze indefinitely waiting for lead
<mlt-> as anonimal said
<theRelay_> 09<08fluffypony@Freenode09> oh I agree, nothing stops :)
<EinMByte> mlt-: It won't freeze, I will also try to make some occasional contributions
<EinMByte> (just no big changes)

Our new timeline:

<EinMByte> - monero finds a new lead dev
<EinMByte> - monero sets up the project in their github account
<EinMByte> - meanwhile, fluffypony handles pull requests etc
<EinMByte> - I will also check on the project whenever I have time
<EinMByte> I would like to have this all done by the end of january

New items for Nov. 15th meeting:

1. New name! Results from monero/i2p community forum or discuss when those results should arrive.
2. Status of Monero's search for a lead developer and github account (chicken-or-the-egg, shouldn't we use the new name?).
3. Status of i2pd-related Monero Missive (may or may not be completed before meeting date).

Please amend/append as needed (in case I missed something).

[orignal]

@EinMByte, please, give me a favour to comment out your following statement: " mlt-: orignal doesn't own that repository, and he never did. The repository is that of "PrivacySolutions" " i2pd was under my name at the begging and remained there for almost year until @fluffypony and @meeh420 have convinced me to transfer it to the organization. Thank you

[orignal]

New branch https://github.com/PurpleI2P/i2pd/tree/openssl has been created. It uses openssl instead crypto++ contains all ongoing changes from bitbucket. It will become master by the start of 2016 and current master will be renamed to 'einmbyte'. Everybody is welcome to make contribution to that branch.

[fluffypony]

@orignal sorry, but that's not how open-source projects work, even those with benevolent dictators (and you are clearly not benevolent).

You chose to throw a tantrum like a little child, abandon the main project, and continue elsewhere. The community has reacted accordingly.

If you want to do now come back and make sweeping changes I suggest you bring the idea to the community and get general acceptance of your idea, else the community will simply move elsewhere, and you will find yourself developing for the 3 remaining people who shockingly still have respect for you.

[orignal]

I didn't sweep anybody's changes, but create another branch without touching anything else. Since you have made the decision to move the project away from here. I'm not going to change master until it's done according to your proposal. But once it's done, I don't want this project to die. And again, I didn't abandon the main project, I was just kicked out from history, that's why I decided to create branch where full history has been restored.

[mlt]

Let's not dig into the past as we clearly have different perceptions of events. Indeed, the proposed change does not contradict decisions made at the last meeting as another branch/fork will likely move elsewhere and/or change name. @orignal, please, join the next meeting so all interested parties have an opportunity to speak up and see if there are any formal objections to the proposed change? I hope it won't take long.

[orignal]

@mlt , I appoint you to speak at that meeting, if you wish. I meantime, I had a chance to talk to @fluffypony privately and will talk to other major I2P people.

[anonimal]

:trollface:ignal, you may think you are in a position to "appoint" people but I assure, we are all laughing at that idea. Our meeting was public, everyone was invited (including you), you chose not to appear, and the community has decided that the past has passed - so we are moving on.

We will promptly continue our work elsewhere a.s.a.p but for the time being, please understand that here is our focal point of communication and we are doing our best to give you your much-needed space while continuing to finish our business (I would love to get back to actual work and not spend time bickering). I must point out though that the forked i2pd in bitbucket has only one author: which is a blatant lie. I only say this not for personal satisfaction of clearing the air, but instead for the sake of posterity and historical accuracy.

With that said, and for the sake of salvaging the original intent of this ticket (and as a courtesy to any newcomers or people who wish to stay on track (this is a "Roadmap" afterall)), please continue to refer to https://github.com/PurpleI2P/i2pd/issues/279#issuecomment-152878774 until a new repo has been made.

Thank you. :bow:

[orignal]

It seems, you have heard a lot of lie, but were delighted to spear it. No, bitbucket repo was always for contributions by anybody, but few people. I hope a new repo will be made soon and you both will get back to actual work and will not hear you here anymore.

[zlatinb]

Пусть они делают що хотят, ти сам знаеш що лучше за проекта

[orignal]

Ну так вот и я думаю также :)

[klondi]

Hum, reading everything since my last comment it seems there is still a big internal conflict going on along with some internal hostile dynamics. Maybe we should aim at solving this if we want the project to move on.

I can try to use some dynamics which will hopefully lead to solving the conflict between the developers but the first step is that both sides are willing to solve the issue and stop hostilities towards each other. Otherwise there is nothing I can do.

[zlatinb]

This is a software project, not a social club. One of the camps has a single but productive developer while the other is full of cheerleaders. Unless they can demonstrate expertise and commitment they're useless.

Dynamics don't matter, code does. Go Orignal !!!

[fluffypony]

@zlatinb trolling is not helpful, go troll elsewhere.

[zlatinb]

I'm showing my support for the only developer who has proven he can deliver results. What has your camp done besides create drama?

[fluffypony]

@klondi I don't think the interpersonal conflict is the key issue. There are two larger issues here:

1. The project has/had become contributor-hostile, which is not conducive to FOSS development.
2. There has been no community-centric governance structure, no formalised governance of any kind really.

This is extremely sensitive security software, and the privacy (maybe even the lives) of our users are in our hands. The only way for the project to resist tampering, backdoors being snuck in, and other security risks, is for many eyes to look at the code. That means the community-at-large plays a critical role in decision making, and it also means contributors of all levels of expertise should be welcomed and invited to participate.

[fluffypony]

@zlatinb I have no "camp", you are creating sides where nothing is quite as binary.

You're also incredibly hypocritical, claiming that "the other is full of cheerleaders" only to follow that up with "go orignal".

I strongly recommend you stop commenting here if you are just going to add noise to the signal.

[orignal]

@fluffypony don't you find that word "troll" became too popular here. @anonimal called me, you called @zlatinb. But how about yourself? Again, since you have made this decision,execute it. But I doubt.

[fluffypony]

@orignal I can't comment on you being called a troll, but my use of the word is consistent with the definition of a troll. Per Wikipedia: "In Internet slang, a troll is a person who sows discord on the Internet by starting arguments or upsetting people, by posting inflammatory, extraneous, or off-topic messages in an online community with the deliberate intent of provoking readers into an emotional response or of otherwise disrupting normal on-topic discussion" (italics mine)

[orignal]

@fluffypony if you and other guys wish to call me as troll, you're welcome. You can even make a doll of me and insert needles into it. But, please, do it somewhere else.

[fluffypony]

@orignal huh?? I never called you a troll, what are you talking about?

[zlatinb]

Sowing discord? Provoking emotional reaction? Harmony and positive emotions don't produce code, coding does. Again, this is a software project and the only metric that matters is code and that is what Orignal has provided consistently. The noise you talk about is added by everyone else.

[orignal]

@fluffypony I'm not talking about you personally, just in general. As you know, you are always welcome here as everybody else, excepting two persons.

[klondi]

Guys please calm down! Really!

@zlatinb if you can't see an open source project with a single developer remaining that way is doomed to die you have a serious issue. Free software isn't like a company where you can just put more money to hire another guy if the current one leaves. Even inside companies this is an issue (but not a full project threatening one). If you can see either that a toxic environment (and this is a particularly toxic one as it is now) will keep new developers away then you have two issues.

@orignal people is biased by their previous experiences with you and I believe you are putting a negative layer on top because of your own experience. Take it easy, conflicts can be solved if the parts involved are willing to do so, but it's no easy task.

@fluffypony You have a point in that i2pd hasn't had a very active community, and I can't say for the last months, but before I left it was reasonably open to external contributions. In my experience governance is a secondary issue here, a community can grow around almost any kind of governance that isn't set on scaring contributors and gives something back around those contributing.

My offer remains on the table, if you guys want to try solving this I don't mind lending a hand, but if you prefer to keep things toxic I have other projects to focus on instead.

[orignal]

@klondi, there is the resolution already that satisfies everybody. The code from trunk will be migrated to another place under different name, and then I will make 'openssl' branch to master. Everybody could decide where to contribute to. But what I suspect, guys are not so enthusiastic about their decision because this repo is not going to be abandoned as they assumed.

[zlatinb]

"But what I suspect, guys are not so enthusiastic about their decision because this repo is not going to be abandoned as they assumed."

+1

[majestrate]

I think that what we have learned from this is that communication is key yet there is an obvious language barrier that is getting in the way. I am relieved to see that @orignal didn't abandon the project like many here may have assumed but at the same time, I really do like some of the changes that @EinMByte made. Is a compromise possible or is it a pipe dream at this point?

[orignal]

psi, I like some changes made in trunk as well and wish them to be ported to my branch. For example, i2pcountrol, improved http server and webui. If nobody have it done before I will do it myself later on. As I mentioned many times before my main concern about trunk is file structure and lost history.

[majestrate]

That makes sense. I have not been following this as closely as I should've, sorry If I have made you repeat things.

[mlt]

my main concern about trunk is file structure and lost history

Are we git log --follow and git filter branch away from the positive resolution and making everybody happy? Also -wC seems helpful for blames like in git blame -wC client/i2pcontrol/I2PControlServer.cpp.

[majestrate]

@mlt wouldn't it be a massive pain to merge in the changes because of tabs -> spaces? Am I missing something? I have time this weekend to blow away at something, maybe if someone gives me some hints I can try merging some of the improvements into the openssl branch.

[mlt]

wouldn't it be a massive pain to merge in the changes because of tabs -> spaces?

It can be drastically minimized let's say with astyle or alike. I'd suggest to find an existing style or adjust some to match orignal's, and call astyle within --tree-filter of git filter. Also it, probably, shall be done with openssl branch as well, as there are minor inconsistencies in orignal's formatting.

It will break the trunk one more time though, but hopefully for the very last one. So it would be nice to either commit & push all pending work or be prepared to git filter local WIP.

On a positive side, we can stick with astyle (or whatever we chose) later to make sure things are consistent. IIRC there was a plan to standardize things anyway... formatting being one.

[orignal]

@majestrate, I would start with I2PControl. People complained there are some vital commands are not implemented in my branch. As for me, tabs/spaces is not an issue, even if it's incorrect it can be changed later.

[mlt]

As for me, tabs/spaces is not an issue, even if it's incorrect it can be changed later.

It will prevent easy cherry-picking that I think is possible make cherry-picking more difficult. So it shall be decided. I was hoping for IRC, but I guess we brought everything here :no_good:

P.S. tabs were historically there. And although everybody suggests to use spaces these days, it seems that certain popular C++ projects still use tabs. So I'm personally up for tabs at least for historical reasons. It is just a matter of Emacs/Vim/ settings.

P.P.S. There is also UniversalIndentGUI to assist. I feel like it is easier to do everything with that thing manually rather than trying to come up with an automatic way to deduce style used.It seems old and not maintained much. Also astyle doesn't seem support padding empty parentheses. uncrustify looks more up to date. @orignal what IDE/formatter are you using?

[mlt]

As I mentioned on IRC yesterday, I took an effort to make integration easier. The process takes forever so I places the resulting branch into my repo

git remote add mlt https://github.com/mlt/i2pd.git
git fetch mlt master-flat:master-flat
git diff master-flat openssl HTTPProxy.cpp
git diff master-flat openssl

It looks reasonably better. Some infamous commits now look like this. Apparently I failed to --prune-empty commits on the way. Consider this branch as read-only and do not base anything on it as I likely will force push changes. No attempt was made to keep it buildable at each commit, however there are CMake files that work on flattened master HEAD with VS 2013 (and precompiled headers) though it is not the point.

[orignal]

Revised list of features for the roadmap:

1. SAM 3.2 implementation
2. Multi-destination tunnels (for IRC)
3. Shared RTT/RTO for streams
4. gzip compression for http-proxy
5. Compatibility with new features of the official I2P