Update hash and version number for Android downloads

Apps guide

See merge request i2p-hackers/i2p.www!9

i2p2www/meetings/logs/293.log

@@ -0,0 +1,63 @@
+
+(04:00:50 PM) eyedeekay1: Hello zlatinb zzz mikalvmeeh eche|on, if you're all ready we'll start the meeting.
+(04:00:50 PM) eyedeekay1: 1) Hi
+(04:00:50 PM) eyedeekay1: 2) 0.9.47 release
+(04:00:50 PM) eyedeekay1: 3) Monthly meetings follow-up
+(04:00:50 PM) eyedeekay1: 4) Git update
+(04:01:38 PM) eyedeekay1: Hi everyone, first of all, I am sorry I did not notice that I got the date wrong in my announcement title.
+(04:02:38 PM) zzz: hi
+(04:02:58 PM) eyedeekay1: hi zzz
+(04:03:31 PM) zlatinb: hi
+(04:03:42 PM) eyedeekay1: Hi zlatinb
+(04:04:49 PM) eyedeekay1: OK so 2) the 0.9.47 release
+(04:05:27 PM) eyedeekay1: It does not look like I'm going to get rekeyOnIdle done in time for 0.9.47 either.
+(04:05:58 PM) eyedeekay1: What will be included are primarily updates to visual elements on my end.
+(04:06:19 PM) eyedeekay1: Anything from zzz or zlatinb on the 0.9.47 release topic?
+(04:06:43 PM) zzz: summary is at http://zzz.i2p/topics/2905
+(04:06:49 PM) zzz: tag freeze a week from tomorrow
+(04:06:53 PM) zzz: release in about 3 weeks
+(04:07:07 PM) zzz: diff is at about 18,500 lines which is pretty typical
+(04:07:23 PM) zzz: things are looking good. I have a few things to wrap up
+(04:07:40 PM) zzz: but I'm pretty confident we can stay on schedule
+(04:07:49 PM) zzz: EOT
+(04:08:08 PM) eyedeekay1: I saw quite a bit come in yesterday, have been trying to look at it incrementally as you push it. Really exciting to see your work. Thanks very much.
+(04:08:41 PM) zzz: that was just misc. stuff that had been sitting in my workspace for weeks, nothing to note really
+(04:09:42 PM) eyedeekay1: Well following along is educational nonetheless, I don't know where everything is, watching you work helps me recognize where different things happen
+(04:09:43 PM) zzz: just trying to get stuff cleaned up and pushed. sometimes I'll test something for months and months
+(04:10:28 PM) zzz: sure, reviewing other people's changes a great way to learn, and to catch mistakes, keep it up
+(04:10:39 PM) eyedeekay1: Will do
+(04:10:42 PM) eyedeekay1: If there's nothing else, I'll move on to 3) timeout 1m
+(04:12:40 PM) eyedeekay1: 2) Monthly Meeting Follow Up:
+(04:12:53 PM) eyedeekay1: This is the monthly meeting.
+(04:12:53 PM) eyedeekay1: I did not set up a WebIRC gateway, as I understand it would have been against our IRC rules to do so.
+(04:13:13 PM) eyedeekay1: I now have a copy of the meeting announcement rules and responsibility for those announcements has been clarified to me.
+(04:13:25 PM) eyedeekay1: The announcment for September 1, with the correct date this time, has been posted. No topics yet, please add them as you need them: http://zzz.i2p/topics/2931-meeting-tues-september-1-8pm-utc
+(04:14:55 PM) eyedeekay1: This will of course come shortly after the 0.9.47 release
+(04:15:45 PM) eyedeekay1: Anything on 2) from anyone else?
+(04:17:57 PM) eyedeekay1: 3) Git transition
+(04:18:34 PM) eyedeekay1: Git transition is finally getting underway, we have a plan and are beginning to execute upon it
+(04:19:08 PM) eyedeekay1: nextloop and I are making progress on getting the next few meaningful mtn branches mirrored over to github
+(04:19:27 PM) eyedeekay1: these are still read-only until the conclusion of their respective phases on the git migration, i.e. no pulls or MRs yet
+(04:20:04 PM) eyedeekay1: For a detailed description of these phases see: http://zzz.i2p/topics/2920-flipping-the-switch-on-git#10
+(04:20:42 PM) eyedeekay1: It would be helpful to nextloop and I if I gave nextloop permission to create repositories in the i2p namespace on github, and to write to the repositories he creates.
+(04:20:47 PM) zzz: good job on writing up the plan
+(04:21:24 PM) eyedeekay1: Thanks zzz, glad to finally have it in a usable state
+(04:22:17 PM) zzz: it's not perfect but it's 'usable' in that we can comment upon it
+(04:24:39 PM) eyedeekay1: The next thing that we'll be moving is the web site, which is nice because it's quite simple and doesn't have anything that depends on it, that should be happening this week
+(04:25:26 PM) eyedeekay1: But re: nextloop, I'd like to know that it met with broad approval to grant him this permission to create/write to github repos for us?
+(04:25:54 PM) zzz: ok. awaiting your edit to the plan/schedule to deconflict it with the .47 release
+(04:26:25 PM) eyedeekay1: Ack, got it open in my editor :)
+(04:26:48 PM) zzz: You'll have to ask the people that are currently github admins, who aren't here, and I'm not a member of
+(04:27:39 PM) eyedeekay1: Thusfar this proposal meets with their approval, although I do still have one non-responder.
+(04:29:05 PM) zzz: it's fine with me as long as you two have a reliable communication method and backup. I don't think we need any more unresponsive admins :)
+(04:29:53 PM) eyedeekay1: I think we can manage that
+(04:30:06 PM) eyedeekay1: So nextloop with get github privs
+(04:31:40 PM) zzz: long-unresponsive people with a lot of privileges might be good for a worst-case hit-by-bus backup, but it's also a potential security risk, so that needs to be managed
+(04:33:12 PM) eyedeekay1: Yeah
+(04:33:20 PM) eyedeekay1: If there's anything else we can deal with here on 3) then I think now, otherwise we'll see the revised plan on the zzz.i2p thread probably within the next day.
+(04:33:45 PM) zzz: super
+(04:34:18 PM) mikalvmeeh: (I'm halfy here, missed out on the hi)
+(04:34:56 PM) eyedeekay1: Well we've made it through the planned topics, does anyone have anything else?
+(04:36:43 PM) eyedeekay1: timeout 1m
+(04:38:51 PM) eyedeekay1: *bafs* All right that closes this meeting. Please remember September 1, the next scheduled meeting at this same time, 8PM UTC
+(04:39:12 PM) eyedeekay1: Thank you everyone for coming

i2p2www/meetings/logs/293.rst

@@ -0,0 +1,11 @@
+I2P dev meeting, August 4, 2020 @ 20:00 UTC
+==============================================
+
+Quick recap
+-----------
+
+* **Present:**
+
+eyedeekay,
+zlatinb,
+zzz

i2p2www/meetings/logs/295.log

@@ -0,0 +1,76 @@
+(04:00:04 PM) eyedeekay: Hello everyone and welcome to the October I2P Community Meeting.
+(04:00:04 PM) eyedeekay: On the agenda for today is:
+(04:00:04 PM) eyedeekay: 1) Hi
+(04:00:04 PM) eyedeekay: 2) 0.9.48 release (zzz)
+(04:00:04 PM) eyedeekay: 3) Git Progress Update (idk)
+(04:00:04 PM) eyedeekay: 4) UI Team / OTF Update (idk)
+(04:00:04 PM) eyedeekay: 5) Android update (idk)
+(04:00:17 PM) eyedeekay: Hi everyone, who all is here?
+(04:00:25 PM) orignal: hi
+(04:00:29 PM) eyedeekay: Hi orignal
+(04:00:33 PM) zzz: hello
+(04:00:39 PM) eyedeekay: Hello zzz
+(04:01:14 PM) eyedeekay: Anyone else?
+(04:01:53 PM) eyedeekay: OK moving on to 2
+(04:02:14 PM) eyedeekay: I've seen zzz doing quite a lot lately, for myself, My only plan for inside the router for the 0.9.48 release is rekeyOnIdle. Overwhelmingly my plans for this release will have to do with completing the next 2 phases of the git migration, and with changes to i2p.www which I will detail in 4).
+(04:02:45 PM) zzz: we're I think, 5 weeks into the cycle. things are going well
+(04:03:14 PM) zzz: orignal and I working on improving tunnel building (proposal 152), and have started to land some of that code
+(04:03:29 PM) zzz: SSU2 research is going slowly, and certainly won't have any code in .48
+(04:03:50 PM) zzz: 7500 lines of diff in the release so far, pretty typical
+(04:04:08 PM) zzz: target is mid-to-late Novemeber for the .48 release, we'll probably set a date soon
+(04:04:18 PM) zzz: EOT
+(04:04:44 PM) eyedeekay: Thanks very much zzz
+(04:05:14 PM) eyedeekay: Thanks also for the frequent forum updates, it makes some of your progress easier to digest and explain to others
+(04:05:43 PM) eyedeekay: On to 3)
+(04:06:03 PM) eyedeekay: We are in phase three of the git migration.
+(04:06:08 PM) eyedeekay: i2p.www is migrated. It had the most dependence on mtn of all the projects.
+(04:06:14 PM) eyedeekay: i2p.firefox is also migrated.
+(04:06:22 PM) eyedeekay: We are going to have i2p.newsxml migrated on Thursday evening, at 18.00 UTC.
+(04:06:32 PM) eyedeekay: After that I will be getting it touch with zzz about migrating zzzot or snark-rpc next.
+(04:06:37 PM) eyedeekay: Repositories where mtn syncing has been disabled are kept in sync between github and gitlab.
+(04:06:44 PM) eyedeekay: We are on a steady path now, as soon as one repo is migrated, we start the next.
+(04:06:58 PM) eyedeekay: EOT
+(04:08:23 PM) eyedeekay: Any questions on Git?
+(04:09:06 PM) eyedeekay: Timeout 1m
+(04:10:16 PM) eyedeekay: OK on to 4)
+(04:11:20 PM) eyedeekay: The design firm hired by the OTF created a revised style guide. The new guide is somewhat more "flexible" than the old one, while also encouraging us toward a level of internal consistency.
+(04:11:20 PM) eyedeekay: It is located here: https://uracreative.github.io/i2p-styleguide/. A post requesting comments from the community on the style recommendations, and which ones to implement, and how, is here: http://i2pforum.i2p/viewtopic.php?f=21&t=986&sid=bbca7a971055b8449737ba038ebbfa49
+(04:11:20 PM) eyedeekay: The difficulty of implementing the design recommendations results from the fact that changes implemented partially tend to be visually unappealing, for example see the recent icon issue in I2PSnark.
+(04:12:26 PM) eyedeekay: However, this only comprises 1/2 of the advice we recieved
+(04:13:01 PM) eyedeekay: The most significant improvement we could make identified by the programs paid for by the OTF entailing the work of Ura Design and Simsec was an overall problem with onboarding new participants of all types.
+(04:13:16 PM) eyedeekay: We consider this the priority. The early phases of improving it will mostly occur in i2p.www
+(04:13:19 PM) eyedeekay: One of the most common questions that has been asked is "Who is I2P for."
+(04:13:42 PM) eyedeekay: The design/usability people are obviously not the only people who have asked that question
+(04:13:52 PM) eyedeekay: So we identified "types" of participants, including users, service operators, app developers, router developers.
+(04:13:52 PM) eyedeekay: We had a lot of answers to that question, but one of the most common patterns in our answers was that it's much easier to say who I2P "Applications" are for.
+(04:14:07 PM) eyedeekay: So we want to get people using applications faster and more easily. Changing these paths is what has been referred to as "Information Architecture"
+(04:14:07 PM) eyedeekay: Accomplishing this will entail producing:
+(04:14:07 PM) eyedeekay:  - Installation instructions on Windows that include installing a Java version which is known to work with I2P.
+(04:14:07 PM) eyedeekay:  - Pages on the site explaining the bundled apps that come with the Java I2P router.
+(04:14:07 PM) eyedeekay:  - Inclusion of I2P in Private Browsing webextension into the Windows I2P profile bundle
+(04:14:07 PM) eyedeekay:  - An IRC client recommendation and guide.
+(04:14:07 PM) eyedeekay:  - First-class service hosting guides(Like the one for Gitlab), for new operators, including a re-write of the Reseed Service Guide. Also planned are NextCloud and IRC hosting guides.
+(04:14:07 PM) eyedeekay:  - Re-organization of the home page and the top-level navigation menu around the users.
+(04:14:44 PM) eyedeekay: Sorry for basically going long-form with it, but take your time please, I wanted to make sure I gave a substantial update
+(04:17:14 PM) eyedeekay: EOT. Any questions?
+(04:17:26 PM) zzz: is the OTF work complete? when did they finish? when did the revised style guide become available?
+(04:19:20 PM) eyedeekay: The OTF paid the design firm, and they finished last month. Just a moment while I check the history
+(04:19:56 PM) eyedeekay: August 8th
+(04:20:10 PM) zzz: what I'm getting at is, how can we fix our processes so that the status and results of funded work are actually communicated to the community in a timely manner?
+(04:21:07 PM) eyedeekay: Usually the solution to that is me keeping in touch with someone. In this case, that someone probably ought to take the form of me doing periodic updates to i2pforums.i2p
+(04:22:38 PM) zzz: ok. it's just very odd that a funded project that results in advice for developers never actually got communicated to developers for two months
+(04:23:06 PM) zzz: so if we ever go around again on this, that will be a discussion for process improvement
+(04:23:14 PM) zzz: thanks for the report
+(04:23:35 PM) eyedeekay: Just doing my best to solve problems :)
+(04:23:39 PM) eyedeekay: Which brings us to 5)
+(04:24:46 PM) eyedeekay: I am now the administrator of all the servers where we offer Android apps for download, since the other admin was unresponsive.
+(04:24:51 PM) eyedeekay: I was eventually able to contact the other admin, and he has agreed to act as a back up.
+(04:24:59 PM) eyedeekay: The plan going forward is for me to upload to GPlay and our F-Droid on the same day as Debian packages are released.
+(04:25:03 PM) eyedeekay: This means that our F-Droid will be available on the same day that Debian packages are uploaded. GPlay will still be delayed by what seems like 1-6 days, not much I can do for that.
+(04:25:29 PM) eyedeekay: This also means that I'm the admin of download.i2p2.de now, so I can fix that too. I can basically fix everything but trac.
+(04:27:09 PM) eyedeekay: EOT
+(04:28:15 PM) eyedeekay: Oh that's what I forgot. I am *not* in charge of the upload to the F-Droid community repository. That's nextloop still.
+(04:30:21 PM) eyedeekay: Does anyone have anything they wish to add, want to cover for the meeting, or any questions about anything we've covered so far?
+(04:31:02 PM) eyedeekay: timeout 1m
+(04:31:13 PM) zzz: reminder (again) - put the august meeting on the website
+(04:32:00 PM) eyedeekay: I thought I had? OK, will add it right after we're done

i2p2www/meetings/logs/295.rst

@@ -0,0 +1,11 @@
+I2P dev meeting, October 6, 2020 @ 20:00 UTC
+============================================
+
+Quick recap
+-----------
+
+* **Present:**
+
+eyedeekay,
+orignal,
+zzz

i2p2www/pages/downloads/macros

@@ -2,15 +2,15 @@
 {% set i2pinstall_jar_hash     = '3ddf3afb0c06edeed4810c6d1f34d909959dd94640adf7c638781b4a3b282e9e' %}
 {% set i2psource_hash          = 'dbccada6a353b54ceb844fe8cb0912c0363375a2f57214d23fcf463c4e6d2c4f' %}
 {% set i2pupdate_hash          = '328f85ba28ff6f60480aa0dcda88654fabeabcf63b732a770354bff7f134b135' %}
-{% set i2p_android_hash        = 'c4604736ec45f35a1570ace124cc2a111f1c8b2d04972f340752ef4833e9953f' %}
+{% set i2p_android_hash        = 'b35eb467511343a8aecdf6a1f19c0459baac007c99a93e0933ce5ab70b5a7261' %}
 {% set i2p_macnative_hash      = '70447e8a352654afd940cfc6c05f094732de7ab05db7c42c173e49f37259d601' %}
 
 {% set i2p_windows_subver = '' %}
 {% set i2p_macosx_launcher_version = '0.1.8' %}
 
-{% set i2p_android_version = '0.9.47' %}
+{% set i2p_android_version = '0.9.47-1' %}
 {% set i2p_android_version_kytv = '0.9.22' %}
-{% set i2p_android_version_fdroid = '0.9.47' %}
+{% set i2p_android_version_fdroid = '0.9.47-1' %}
 
 
 {% macro package_outer(type, name, icon) -%}

i2p2www/pages/downloads/windows.html

@@ -1,5 +1,6 @@
 {% extends "global/layout.html" %}
 {% block title %}Microsoft Windows{% endblock %}
+{% block accuratefor %}0.9.47{% endblock %}
 {% block content %}
 <h1>{{ _('Installing I2P, its dependencies, and recommended external software on Windows 10') }}</h1>
 

i2p2www/pages/global/nav.html

@@ -4,10 +4,20 @@
   <li class="has-sub"><div class="menuitem"><span>{{ _('About') }}</span></div>
     <ul>
       <li><a href="{{ site_url('about/intro') }}"><div class="menuitem"><span>{{ _('Introduction to I2P') }}</span></div></a></li>
+      <li><a href="{{ site_url('about/software') }}"><div class="menuitem"><span>{{ _('Guide to I2P Software') }}</span></div></a></li>
       <li class="has-sub"><div class="menuitem"><span>{{ _('Help') }}</span></div>
         <ul>
           <li><a href="{{ site_url('faq') }}"><div class="menuitem"><span>{{ _('FAQ') }}</span></div></a></li>
           <li><a href="{{ site_url('about/browser-config') }}"><div class="menuitem"><span>{{ _('How to browse I2P') }}</span></div></a></li>
+          <li class="has-sub"><div class="menuitem"><span>{{ _('Applications') }}</span></div>
+            <ul>
+              <li><a href="{{ site_url('docs/applications/supported') }}"><div class="menuitem"><span>{{ _('Supported applications') }}</span></div></a></li>
+              <li><a href="{{ site_url('docs/applications/bittorrent') }}"><div class="menuitem"><span>{{ _('Bittorrent') }}</span></div></a></li>
+              <li><a href="{{ site_url('docs/applications/gitlab') }}"><div class="menuitem"><span>{{ _('GitLab') }}</span></div></a></li>
+              <li><a href="{{ site_url('docs/applications/git') }}"><div class="menuitem"><span>{{ _('Git') }}</span></div></a></li>
+              <li><a href="{{ site_url('docs/applications/git-bundle') }}"><div class="menuitem"><span>{{ _('git+Bittorrent') }}</span></div></a></li>
+            </ul>
+          </li>
           <li class="has-sub"><div class="menuitem"><span>{{ _('References') }}</span></div>
             <ul>
               <li><a href="{{ site_url('about/glossary') }}"><div class="menuitem"><span>{{ _('Glossary') }}</span></div></a></li>
@@ -21,19 +31,19 @@
               <li><a href="{{ site_url('get-involved/develop/developers-keys') }}"><div class="menuitem"><span>{{ _('Developers keys') }}</span></div></a></li>
             </ul>
           </li>
+          <li class="has-sub"><div class="menuitem"><span>{{ _('Comparisons') }}</span></div>
+            <ul>
+              <li><a href="{{ site_url('comparison') }}"><div class="menuitem"><span>{{ _('Overview of comparisons') }}</span></div></a></li>
+              <li><a href="{{ site_url('comparison/tor') }}"><div class="menuitem"><span>Tor</span></div></a></li>
+              <li><a href="{{ site_url('comparison/freenet') }}"><div class="menuitem"><span>Freenet</span></div></a></li>
+              {#<li><a href="{{ site_url('comparison/gnunet') }}"><div class="menuitem"><span>GNUnet</span></div></a></li> #}
+              <li><a href="{{ site_url('comparison/other-networks') }}"><div class="menuitem"><span>{{ _('Other anonymous networks') }}</span></div></a></li>
+            </ul>
+          </li>
           <li><a href="{{ site_url('contact') }}"><div class="menuitem"><span>{{ _('Contact us') }}</span></div></a></li>
         </ul>
       </li>
       <li><a href="{{ site_url('get-involved') }}"><div class="menuitem"><span>{{ _('Get involved!') }}</span></div></a></li>
-      <li class="has-sub"><div class="menuitem"><span>{{ _('Comparisons') }}</span></div>
-        <ul>
-          <li><a href="{{ site_url('comparison') }}"><div class="menuitem"><span>{{ _('Overview of comparisons') }}</span></div></a></li>
-          <li><a href="{{ site_url('comparison/tor') }}"><div class="menuitem"><span>Tor</span></div></a></li>
-          <li><a href="{{ site_url('comparison/freenet') }}"><div class="menuitem"><span>Freenet</span></div></a></li>
-          {#<li><a href="{{ site_url('comparison/gnunet') }}"><div class="menuitem"><span>GNUnet</span></div></a></li> #}
-          <li><a href="{{ site_url('comparison/other-networks') }}"><div class="menuitem"><span>{{ _('Other anonymous networks') }}</span></div></a></li>
-        </ul>
-      </li>
       <li class="has-sub"><div class="menuitem"><span>{{ _('People') }}</span></div>
         <ul>
           <li><a href="{{ site_url('about/team') }}"><div class="menuitem"><span>{{ _('Team') }}</span></div></a></li>
@@ -100,12 +110,6 @@
                   <li><a href="{{ site_url('docs/api/i2pcontrol') }}"><div class="menuitem"><span>I2PControl</span></div></a></li>
                 </ul>
               </li>
-              <li class="has-sub"><div class="menuitem"><span>{{ _('Applications') }}</span></div>
-                <ul>
-                  <li><a href="{{ site_url('docs/applications/supported') }}"><div class="menuitem"><span>{{ _('Supported applications') }}</span></div></a></li>
-                  <li><a href="{{ site_url('docs/applications/bittorrent') }}"><div class="menuitem"><span>{{ _('Bittorrent') }}</span></div></a></li>
-                </ul>
-              </li>
               <li class="has-sub"><div class="menuitem"><span>{{ _('Protocols') }}</span></div>
                 <ul>
                   <li><a href="{{ site_url('docs/protocol') }}"><div class="menuitem"><span>{{ _('Protocol stack') }}</span></div></a></li>
@@ -137,6 +141,7 @@
               <li><a href="{{ site_url('get-involved/guides/new-developers') }}"><div class="menuitem"><span>{{ _('New developers') }}</span></div></a></li>
               <li><a href="{{ site_url('get-involved/guides/ides') }}"><div class="menuitem"><span>{{ _('Using an IDE with I2P') }}</span></div></a></li>
               <li><a href="{{ site_url('get-involved/guides/dev-guidelines') }}"><div class="menuitem"><span>{{ _('Developer guidelines and coding style') }}</span></div></a></li>
+              <li><a href="{{ site_url('docs/applications/git') }}"><div class="menuitem"><span>{{ _('Git') }}</span></div></a></li>
               <li><a href="{{ site_url('get-involved/guides/monotone') }}"><div class="menuitem"><span>{{ _('Monotone') }}</span></div></a></li>
               <li><a href="{{ site_url('get-involved/guides/new-translators') }}"><div class="menuitem"><span>{{ _('New translators') }}</span></div></a></li>
             </ul>

i2p2www/pages/site/about/intro.html

@@ -2,109 +2,41 @@
 {% block title %}{{ _('Intro') }}{% endblock %}
 {% block content %}
 <h1>{{ _('The Invisible Internet Project') }} (I2P)</h1>      
-<p>{% trans ip='http://en.wikipedia.org/wiki/Internet_Protocol',
-tcp='http://en.wikipedia.org/wiki/Transmission_Control_Protocol',
-pke='http://en.wikipedia.org/wiki/Public_key_encryption' -%}
-I2P is an anonymous network, exposing a simple layer that applications can 
-use to anonymously and securely send messages to each other. The network itself is 
-strictly message based (a la <a href="{{ ip }}">IP</a>), but there is a 
-library available to allow reliable streaming communication on top of it (a la 
-<a href="{{ tcp }}">TCP</a>).  
-All communication is end to end encrypted (in total there are four layers of 
-encryption used when sending a message), and even the end points ("destinations") 
-are cryptographic identifiers (essentially a pair of <a href="{{ pke }}">public keys</a>).
+<h2>What is I2P?</h2>
+<p>{% trans %}The Invisible Internet Project (I2P) is a fully encrypted private network layer that has been developed with privacy and security by design in order to provide protection for your activity,
+location and your identity.  The software ships with a router that connects you to the network and applications for sharing, communicating and building. {%- endtrans %}</p>
+
+<h3>I2P Cares About Privacy</h3>
+
+<p>{% trans %}The Invisible Internet values privacy and consent, which can only be achieved with privacy-by-default. It is always your choice to share, your platform to own, and the connections you want to make. It is privacy by design, plain, simple and truly free. Additionally I2P offers resistance to pattern recognition and blocking by censors. Because the network relies on peers to route traffic, location blocking is also reduced.{%- endtrans %}</p>
+
+
+<p>{% trans %}I2P hides the server from the user and the user from the server. All I2P traffic is internal to the I2P network. Traffic inside I2P does not interact with the Internet directly. It is a layer on top of the Internet. It uses encrypted unidirectional tunnels between you and your peers. No one can see where traffic is coming from, where it is going or what the contents are.
+{%- endtrans %}</p> 
+
+<h3>How to Connect to the I2P Network</h3>
+
+<p>{% trans %}The Invisible Internet Project provides software to download that connects you to the network.In addition to the network  privacy benefits, I2P provides an application layer that allows people to use and create familiar apps for daily use. I2P provides its own unique DNS so that you can self host or mirror content on the network. You can create and own your platform that you can add to the I2P directory or only invite your friends. The I2P network functions in the same way the Internet does, just with some extra configuration. The best part is that if you do not find something you want, you can build it. When you download the I2P software, it includes everything you need to connect, share, and create privately. 
 {%- endtrans %}</p>
 
-<h2>{{ _('How does it work?') }}</h2>
+<h3>An Overview of the Network</h3>
 
-<p>{% trans tunnelrouting=site_url('docs/how/tunnel-routing') -%}
-To anonymize the messages sent, each client application has their I2P "router"
-build a few inbound and outbound "<a href="{{ tunnelrouting }}">tunnels</a>" - a 
-sequence of peers that pass messages in one direction (to and from the client, 
-respectively).  In turn, when a client wants to send a message to another client, 
-the client passes that message out one of their outbound tunnels targeting one of the 
-other client's inbound tunnels, eventually reaching the destination.  Every 
-participant in the network chooses the length of these tunnels, and in doing so, 
-makes a tradeoff between anonymity, latency, and throughput according to their 
-own needs.  The result is that the number of peers relaying each end to end 
-message is the absolute minimum necessary to meet both the sender's and the 
-receiver's threat model.
+<p>{% trans %}I2P uses cryptography to achieve a variety of properties for the tunnels it builds and the communications it transports. I2P tunnels use transports, NTCP2 and SSU, to hide the nature of the traffic being transported over it. Connections are encrypted from router-to-router, and from client-to-client(end-to-end). Forward-secrecy is provided for all connections. Because I2P is cryptographically addressed, I2P addresses are self-authenticating and only belong to the user who generated them.
 {%- endtrans %}</p>
 
-<p>{% trans netdb=site_url('docs/how/network-database'),
-dht='http://en.wikipedia.org/wiki/Distributed_hash_table',
-kad='http://en.wikipedia.org/wiki/Kademlia' -%}
-The first time a client wants to contact another client, they make a query 
-against the fully distributed "<a href="{{ netdb }}">network 
-database</a>" - a custom structured <a href="{{ dht }}">
-distributed hash table (DHT)</a> based off the 
-<a href="{{ kad }}">Kademlia algorithm</a>. This is done 
-to find the other client's inbound tunnels efficiently, but subsequent messages 
-between them usually includes that data so no further network database lookups 
-are required.
+<p>{% trans %}I2P is a secure and traffic protecting Internet-like layer. The network is made up of peers ("routers") and unidirectional inbound and outbound virtual tunnels. Routers communicate with each other using protocols built on existing transport mechanisms (TCP, UDP, etc), passing messages. Client applications have their own cryptographic identifier ("Destination") which enables it to send and receive messages. These clients can connect to any router and authorize the temporary allocation ("lease") of some tunnels that will be used for sending and receiving messages through the network. I2P has its own internal network database (using a modification of the Kademlia DHT) for distributing routing and contact information securely.
 {%- endtrans %}</p>
 
-<p>{% trans docs=site_url('docs') -%}
-More details about how I2P works are <a href="{{ docs }}">available</a>.
-{%- endtrans %}</p>
+<h3>About Decentralization and I2P</h3>
 
-<h2>{{ _('What can you do with it?') }}</h2>
+<p>{% trans %}The I2P network is almost completely decentralized, with exception to what are what are called "Reseed Servers," which is how you first join the network. This is to deal with the DHT ( Distributed Hash Table ) bootstrap problem. Basically, there's not a good and reliable way to get out of running at least one permanent bootstrap node that non-network users can find to get started. Once you're connected to the network, you only discover peers by building "exploratory" tunnels, but to make your initial connection, you need to get a peer set from somewhere. The reseed servers, which you can see listed on http://127.0.0.1:7657/configreseed in the Java I2P router, provide you with those peers. You then connect to them with the I2P router until you find one who you can reach and build exploratory tunnels through. Reseed servers can tell that you bootstrapped from them, but nothing else about your traffic on the I2P network.{%- endtrans %}</p>
 
-<p>{% trans i2ptunnel=site_url('docs/api/i2ptunnel') -%}
-Within the I2P network, applications are not restricted in how they can 
-communicate - those that typically use UDP can make use of the base I2P 
-functionality, and those that typically use TCP can use the TCP-like streaming
-library.  We have a generic TCP/I2P bridge application 
-("<a href="{{ i2ptunnel }}">I2PTunnel</a>") that enables people to forward TCP streams
-into the I2P network as well as to receive streams out of the network and 
-forward them towards a specific TCP/IP address.
-{%- endtrans %}</p>
+<h3>I see IP addresses of all other I2P nodes in the router console. Does that mean my IP address is visible by others?</h3>
 
-<p>{% trans bittorrent='http://www.bittorrent.com/',
-freenet='https://freenetproject.org/',
-mnet='https://en.wikipedia.org/wiki/Mnet_%28Computer_program%29',
-livejournal='http://www.livejournal.com/' -%}
-I2PTunnel is currently used to let people run their own anonymous website 
-("eepsite") by running a normal webserver and pointing an I2PTunnel 'server' 
-at it, which people can access anonymously over I2P with a normal web browser 
-by running an I2PTunnel HTTP proxy ("eepproxy").  In addition, we use the same 
-technique to run an anonymous IRC network (where the IRC server is hosted 
-anonymously, and standard IRC clients use an I2PTunnel to contact it).  There 
-are other application development efforts going on as well, such as one to 
-build an optimized swarming file transfer application (a la 
-<a href="{{ bittorrent }}">BitTorrent</a>), a 
-distributed data store (a la <a href="{{ freenet }}">Freenet</a> / 
-<a href="{{ mnet }}">MNet</a>), and a blogging system (a fully 
-distributed <a href="{{ livejournal }}">LiveJournal</a>), but those are 
-not ready for use yet.
-{%- endtrans %}</p>
+<p>{% trans %}Yes, this is how a fully distributed peer-to-peer network works. Every node participates in routing packets for others, so your IP address must be known to establish connections. While the fact that your computer runs I2P is public, nobody can see your activities in it. You can't say if a user behind this IP address is sharing files, hosting a website, doing research or just running a node to contribute bandwidth to the project.{%- endtrans %}
 
-<p>{% trans squid='http://www.squid-cache.org/' -%}
-I2P is not inherently an "outproxy" network - the client you send a message 
-to is the cryptographic identifier, not some IP address, so the message must 
-be addressed to someone running I2P.  However, it is possible for that client
-to be an outproxy, allowing you to anonymously make use of their Internet 
-connection.  To demonstrate this, the "eepproxy" will accept normal non-I2P 
-URLs (e.g. "http://www.i2p.net") and forward them to a specific destination
-that runs a <a href="{{ squid }}">squid</a> HTTP proxy, allowing 
-simple anonymous browsing of the normal web.  Simple outproxies like that are 
-not viable in the long run for several reasons (including the cost of running 
-one as well as the anonymity and security issues they introduce), but in 
-certain circumstances the technique could be appropriate.
-{%- endtrans %}</p>
+<h3>What I2P Does Not Do</h3>
+
+<p>{% trans %}The I2P network does not officially "Exit" traffic. It has outproxies to the Internet run by volunteers, which are centralized services. I2P is primarily a hidden service network and outproxying is not an official function, nor is it advised. The privacy benefits you get from participating in the the I2P network come from remaining in the network and not accessing the internet. I2P recommends that you use Tor Browser or a trusted VPN when you want to browse the Internet privately.{%- endtrans %}</p>
 
-<p>{% trans team=site_url('about/team'), volunteer=site_url('get-involved'),
-licenses=site_url('get-involved/develop/licenses'), sam=site_url('docs/api/sam'),
-roadmap=site_url('get-involved/roadmap') -%}
-The I2P development <a href="{{ team }}">team</a> is an open group, welcome to all 
-who are interested in <a href="{{ volunteer }}">getting involved</a>, and all of 
-the code is <a href="{{ licenses }}">open source</a>.  The core I2P SDK and the 
-current router implementation is done in Java (currently working with both 
-sun and kaffe, gcj support planned for later), and there is a 
-<a href="{{ sam }}">simple socket based API</a> for accessing the network from 
-other languages (with a C library available, and both Python and Perl in 
-development).  The network is actively being developed and has not yet reached 
-the 1.0 release, but the current <a href="{{ roadmap }}">roadmap</a> describes 
-our schedule.
-{%- endtrans %}</p>
 {% endblock %}

i2p2www/pages/site/about/software.html

@@ -0,0 +1,80 @@
+{% extends "global/layout.html" %}
+{% block title %}{{ _('Intro') }}{% endblock %}
+{% block content %}
+<h1>{{ _('The I2P Software') }} (I2P)</h1>      
+
+<p>{% trans %}When you install the I2P software made available at geti2p.net, you are 
+actually installing an I2P router and an accompanying bundle of basic 
+applications. The I2P Java distribution is the first I2P software gateway and 
+has been actively developed since 2001.{%- endtrans %}</p>
+<p>{% trans %}The applications are made available through a webUI, which listens at 
+127.0.0.1:7657, and the main page of which is called the “Router Console,” 
+where you monitor the health of your connection to the network and access 
+applications to use on the network.{%- endtrans %}</p>
+<h3>{% trans %}What is included:{%- endtrans %}</h3>
+<p>{% trans %}<strong>The Set Up Wizard</strong>: When you download the 
+I2P software, a set up wizard will guide you through a few configuration steps 
+while your router is making its first connections to the network. This happens 
+the same way that your home router connects you to the Internet. During the set 
+up process, you will be given the option to test your bandwidth and set your 
+bandwidth limits in order to ensure a good connection as a network peer.{%- endtrans %}</p>
+<p>{% trans %}<strong>The I2P Router Console</strong>: Here is where you can see your 
+network connections and information about your router. You will be able to see how many peers you 
+have, and other information that will help if you need to troubleshoot. You can 
+stop and start the router as well. You will see the applications that the 
+software includes, as well as links to some community forums and sites on the 
+I2P network. You will receive news when there is a a new software release, and 
+will be able to download the latest version here as well. Additionally, you can 
+find shortcuts to other available applications. The console is customizable and 
+includes a default light theme with a dark theme option.{%- endtrans %}</p>
+<p>{% trans %}<strong>SusiMail</strong>: SusiMail is a secure email client. It is primarily 
+intended for use with Postman’s email servers inside of the I2P network . It 
+is designed to avoid leaking information about email use to other networks. 
+SusiMail is bridged so it can send and receive email from the internet as well. 
+Occasionally you may see some services like Gmail classifying it as spam, which 
+you can correct in your Internet email service providers settings.{%- endtrans %}</p>
+<p>{% trans bittorrent=site_url('docs/applications/bittorrent') -%}<strong><a href="{{ bittorrent }}">I2PSnark</a></strong>: Snark is an I2P network only BitTorrent client. It never makes a connection to a peer over any other network.{%- endtrans %}</p>
+<p>{% trans addressbook=site_url('docs/naming') -%}<strong><a href="{{ addressbook }}">The AddressBook</a></strong>: This is a locally-defined list of 
+human-readable addresses ( ie: i2p-projekt.i2p) and corresponding I2P addresses.(udhdrtrcetjm5sxzskjyr5ztpeszydbh4dpl3pl4utgqqw2v4jna.b32.i2p) It integrates with other applications to 
+allow you to use those human-readable addresses in place of those I2P 
+addresses. It is more similar to a hosts file or a contact list than a network 
+database or a DNS service. There is no recognized global namespace, you decide 
+what any given .i2p domain maps to in the end.{%- endtrans %}</p>
+<p><strong>The QR Code Generator</strong>: Besides the Addressbook, I2P 
+addresses can be shared by converting them into QR codes and scanning them with 
+a camera. This is especially useful for Android devices.</p>
+<p>{% trans i2ptunnel=site_url('docs/api/i2ptunnel') -%}<strong><a href="{{ i2ptunnel }}">I2P Hidden Services Manager</a></strong> This is a general-purpose 
+adapter for forwarding services ( ie SSH ) into I2P and proxying client 
+requests to and from I2P. It provides a variety of “Tunnel Types” which are 
+able able to do advance filtering of traffic before it reaches I2P.{%- endtrans %}</p>
+<h3>{% trans %}Applications Outside I2P to use with I2P{%- endtrans %}</h3>
+<p>{% trans browser=site_url('about/browser-config') %}<strong><a href="{{ browser }}">Mozilla Firefox</a></strong>: A web browser with advanced privacy and 
+security features, this is the best browser to configure to browse I2P 
+sites.{%- endtrans %}</p>
+<p>{% trans browser=site_url('about/browser-config') %}<strong><a href="{{ browser }}">Chromium</a></strong>: A web browser developed by Google that is the 
+Open-Source base of Google Chrome, this is sometimes used as an alternative to 
+Firefox.{%- endtrans %}</p>
+<p>{% trans %}<strong><a href="https://biglybt.com">BiglyBT</a></strong>: A Feature-Rich bittorrent client including I2P 
+support and the unique ability to “Bridge” regular torrents in-to I2P so 
+people can download them anonymously.{%- endtrans %}</p>
+<p>{% trans ssh=site_url('blog/post/2019/06/15/i2p-i2pd-ssh-config') %}<strong><a href="https://openssh.com">OpenSSH</a></strong>: OpenSSH is a popular program used by systems administrators to <a href="{{ ssh }}">remotely administer a server</a>, or to provide “Shell” accounts for users on the server.{%- endtrans %}</p>
+<p>{% trans git=site_url('docs/applications/git'), gitlab=site_url('docs/applications/gitlab') %}<strong><a href="{{ git }}">Git</a>/<a href="{{ gitlab}}">Gitlab</a></strong>: Git is a source-code control tool which is 
+distributed, and often recommends a fork-first workflow. Hosting source code on 
+I2P is an important activity, so Gitlab-specific instructions are available for 
+all to use.{%- endtrans %}</p>
+<p>{% trans %}<strong><a href="https://debian.org">Debian</a> and <a href="https://ubuntu.com">Ubuntu</a> GNU/Linux</strong>: It is possible to obtain 
+packages for Debian and Ubuntu GNU/Linux over I2P using <a href="https://i2pgit.org/idk/apt-transport-i2p">apt-transport-i2p</a> and 
+<a href="https://i2pgit.org/idk/apt-transport-i2phttp">apt-transport-i2phttp</a>. In the future, a bittorrent-based transport may also be 
+developed. {%- endtrans %}</p>
+<h3>{% trans %} Applications for Developers to create new things{%- endtrans %}</h3>
+<p>{% trans sam=site_url('docs/api/sam') %}<strong><a href="{{ sam }}">The SAM API Bridge</a></strong>: The SAM API is a language-independent 
+API for writing applications that are I2P-native by communicating with the 
+local I2P router. It can provide Streaming-like capabilities, Anonymous 
+Datagrams, or Repliable Datagrams.{%- endtrans %}</p>
+<p>{% trans bob=site_url('docs/api/bob') %}<strong><a href="{{ bob }}">The BOB API Bridge</a></strong>: This is a deprecated technology, BOB 
+users should migrate to SAM if it is possible for them to do so.{%- endtrans %}</p>
+<p>{% trans i2cp=site_url('docs/protocol/i2cp') %}<strong><a href="{{ i2cp }}">The I2CP API</a></strong>: Not strictly an application, this is how Java 
+applications communicate with the I2P router to set up tunnels, generate and 
+manage keys, and communicate with other peers on the network.{%- endtrans %}</p>
+
+{% endblock %}

i2p2www/pages/site/docs/api/samv3.html

@@ -1,7 +1,7 @@
 {% extends "global/layout.html" %}
 {% block title %}SAM V3{% endblock %}
-{% block lastupdated %}July 2020{% endblock %}
-{% block accuratefor %}0.9.47{% endblock %}
+{% block lastupdated %}2020-10{% endblock %}
+{% block accuratefor %}0.9.48{% endblock %}
 {% block content %}
 <p>Specified below is a simple client protocol for interacting with I2P.
 </p>
@@ -838,8 +838,8 @@ $port is the port number of the socket server to which SAM will
 forward connection requests. It is mandatory.
 
 </p><p>
-When a connection request arrives from I2P, the SAM bridge requests a
-socket connection from $host:$port. If it is accepted after no more
+When a connection request arrives from I2P, the SAM bridge opens a
+socket connection to $host:$port. If it is accepted in less
 than 3 seconds, SAM will accept the connection from I2P, and then:
 
 </p><p>

i2p2www/pages/site/docs/applications/git-bundle.html

@@ -0,0 +1,35 @@
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}Setting up Gitlab with I2P{% endtrans %}{% endblock %}
+{% block lastupdated %}2020-09{% endblock %}
+{% block accuratefor %}0.9.47{% endblock %}
+{% block content %}
+<h1 id="using-a-git-bundle-to-fetch-the-i2p-source-code">{% trans -%}Using a git bundle to fetch the I2P source code{%- endtrans %}</h1>
+<p>{% trans -%} Cloning large software repositories over I2P can be difficult, and using git can sometimes make this harder. Fortunately, it can also sometimes make it easier. Git has a <code>git bundle</code> command which can be used to turn a git repository into a file which git can then clone, fetch, or import from a location on your local disk. By combining this capability with bittorrent downloads, we can solve our remaining problems with <code>git clone</code>. {%- endtrans %}</p>
+<h2 id="before-you-start">{% trans -%}Before you Start{%- endtrans %}</h2>
+<p>{% trans -%} If you intend to generate a git bundle, you <strong>must</strong> already possess a full copy of the <strong>git</strong> repository, not the mtn repository. You can get it from github or from git.idk.i2p, but a shallow clone(a clone done to –depth=1) <em>will not</em> <em>work</em>. It will fail silently, creating what looks like a bundle, but when you try to clone it it will fail. If you are just retrieving a pre-generated git bundle, then this section does not apply to you. {%- endtrans %}</p>
+<h2 id="fetching-i2p-source-via-bittorrent">{% trans -%}Fetching I2P Source via Bittorrent{%- endtrans %}</h2>
+<p>{% trans -%} Someone will need to supply you with a torrent file or a magnet link corresponding to an existing <code>git bundle</code> that they have already generated for you. A recent, correctly-generated bundle of the mainline i2p.i2p source code as-of Wednesday, March 18, 2020, can be found inside of I2P at my pastebin <a href="http://paste.idk.i2p/f/4h137i">paste.idk.i2p/f/4hq37i</a>. {%- endtrans %}</p>
+<p>{% trans -%} Once you have a bundle, you will need to use git to create a working repository from it. If you’re using GNU/Linux and i2psnark, the git bundle should be located in $HOME/.i2p/i2psnark or, as a service on Debian, /var/lib/i2p/i2p-config/i2psnark. If you are using BiglyBT on GNU/Linux, it is probably at “$HOME/BiglyBT Downloads/” instead. The examples here assume I2PSnark on GNU/Linux, if you use something else, replace the path to the bundle with the download directory preferred by your client and platform. {%- endtrans %}</p>
+<h3 id="using-git-clone">{% trans -%}Using <code>git clone</code>{%- endtrans %}</h3>
+<p>{% trans -%}Cloning from a git bundle is easy, just:{%- endtrans %}</p>
+<pre><code>git clone $HOME/.i2p/i2psnark/i2p.i2p.bundle</code></pre>
+<p>{% trans -%}If you get the following error, try using git init and git fetch manually instead.{%- endtrans %}</p>
+<pre><code>fatal: multiple updates for ref &#39;refs/remotes/origin/master&#39; not allowed</code></pre>
+<h3 id="using-git-init-and-git-fetch">{% trans -%}Using <code>git init</code> and <code>git fetch</code>{%- endtrans %}</h3>
+<p>{% trans -%}First, create an i2p.i2p directory to turn into a git repository.{%- endtrans %}</p>
+<pre><code>mkdir i2p.i2p &amp;&amp; cd i2p.i2p</code></pre>
+<p>{% trans -%}Next, initialize an empty git repository to fetch changes back into.{%- endtrans %}</p>
+<pre><code>git init</code></pre>
+<p>{% trans -%}Finally, fetch the repository from the bundle.{%- endtrans %}</p>
+<pre><code>git fetch $HOME/.i2p/i2psnark/i2p.i2p.bundle</code></pre>
+<h3 id="replace-the-bundle-remote-with-the-upstream-remote">{% trans -%}Replace the bundle remote with the upstream remote{%- endtrans %}</h3>
+<p>{% trans -%} Now that you have a bundle, you can keep up with changes by setting the remote to the upstream repository source. {%- endtrans %}</p>
+<pre><code>git remote set-url origin git@127.0.0.1:i2p-hackers/i2p.i2p</code></pre>
+<h2 id="generating-a-bundle">{% trans -%}Generating a Bundle{%- endtrans %}</h2>
+<p>{% trans -%} First, follow the <a href="GIT.md">Git guide for Users</a> until you have a successfully <code>--unshallow</code>ed clone of clone of the i2p.i2p repository. If you already have a clone, make sure you run <code>git fetch --unshallow</code> before you generate a torrent bundle. {%- endtrans %}</p>
+<p>{% trans -%}Once you have that, simply run the corresponding ant target:{%- endtrans %}</p>
+<pre><code>ant bundle</code></pre>
+<p>{% trans -%} and copy the resulting bundle into your I2PSnark downloads directory. For instance: {%- endtrans %}</p>
+<pre><code>cp i2p.i2p.bundle* $HOME/.i2p/i2psnark/</code></pre>
+<p>{% trans -%} In a minute or two, I2PSnark will pick up on the torrent. Click on the “Start” button to begin seeding the torrent. {%- endtrans %}</p>
+{% endblock %}

i2p2www/pages/site/docs/applications/git.html

@@ -0,0 +1,100 @@
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}Setting up Gitlab with I2P{% endtrans %}{% endblock %}
+{% block lastupdated %}2020-09{% endblock %}
+{% block accuratefor %}0.9.47{% endblock %}
+{% block content %}
+<h1 id="git-over-i2p-for-users">Git over I2P for Users</h1>
+<h2>Attention: Not all repositories are migrated to git yet. At this time, i2p.www and i2p.firefox are accepting merge requests via gitlab.</h2>
+<p>{% trans -%} Tutorial for setting up git access through an I2P Tunnel. This tunnel will act as your access point to a single git service on I2P. {%- endtrans %}</p>
+<h2 id="before-anything-else-know-the-capabilities-the-service-offers-to-the-public">Before anything else: Know the capabilities the service offers to the public</h2>
+<p>{% trans -%} Depending on how the git service is configured, it may or may not offer all services on the same address. In the case of gittest.i2p, there is a public HTTP URL, but this URL is read-only and cannot be used to make changes. To do that, you must also know the SSH base32, which isn’t public at this time. Unless I’ve told you the SSH base32 to gittest.i2p, head over to the <a href="GITLAB.md">Server</a> tutorial to set up your own. {%- endtrans %}</p>
+<h2 id="first-set-up-an-account-at-a-git-service">First: Set up an account at a Git service</h2>
+<p>{% trans -%} To create your repositories on a remote git service, sign up for a user account at that service. Of course it’s also possible to create repositories locally and push them to a remote git service, but most will require an account and for you to create a space for the repository on the server. Gitlab has a very simple sign-up form: {%- endtrans %}</p>
+<figure>
+<img src="/_static/images/git/register.png" alt="" /><figcaption>Registration is easy!</figcaption>
+</figure>
+<h2 id="second-create-a-project-to-test-with">Second: Create a project to test with</h2>
+<p>{% trans -%} To make sure the setup process works, it helps to make a repository to test with from the server, and for the sake of this tutorial, we’re going to use a fork of the I2P router. First, browse to the i2p-hackers/i2p.i2p repository: {%- endtrans %}</p>
+<figure>
+<img src="/_static/images/git/explore.png" alt="" /><figcaption>Browse to i2p.i2p</figcaption>
+</figure>
+<figure>
+<img src="/_static/images/git/i2p.png" alt="" /><figcaption>I2P Hackers i2p.i2p</figcaption>
+</figure>
+<p>{% trans -%} Then, fork it to your account. {%- endtrans %}</p>
+<figure>
+<img src="/_static/images/git/fork.png" alt="" /><figcaption>Roger is forking</figcaption>
+</figure>
+<figure>
+<img src="/_static/images/git/forked.png" alt="" /><figcaption>Roger is finished</figcaption>
+</figure>
+<h2 id="third-set-up-your-git-client-tunnel">Third: Set up your git client tunnel</h2>
+<p>{% trans -%} To have read-write access to my server, you’ll need to set up a tunnel for your SSH client. As an example, we’re going to use the HTTP tunnel instead, but if all you need is read-only, HTTP/S cloning, then you can skip all this and just use the http_proxy environment variable to configure git to use the pre-configured I2P HTTP Proxy. For example: {%- endtrans %}</p>
+<pre><code>http_proxy=http://localhost:4444 git clone http://gittest.i2p/i2p-developer/i2p.i2p</code></pre>
+<figure>
+<img src="/_static/images/git/wizard1.png" alt="" /><figcaption>Client tunnel</figcaption>
+</figure>
+<figure>
+<img src="/_static/images/git/wizard2.png" alt="" /><figcaption>Git over I2P</figcaption>
+</figure>
+<p>{% trans -%} Then, add the address you will be pushing and pulling from. Note that this example address is for Read-Only HTTP-over-I2P clones, if your admin does not allow the git HTTP(Smart HTTP) protocol, then you will need to get the SSH clone base32 from them. If you have an SSH clone base32, substitute it for the base32 in this step, which will fail. {%- endtrans %}</p>
+<figure>
+<img src="/_static/images/git/wizard3.png" alt="" /><figcaption>gittest.i2p</figcaption>
+</figure>
+<p>{% trans -%} Pick a port to forward the I2P service to locally. {%- endtrans %}</p>
+<figure>
+<img src="/_static/images/git/wizard4.png" alt="" /><figcaption>localhost:localport</figcaption>
+</figure>
+<p>{% trans -%} I use it alot, so I start my client tunnel automatically, but it’s up to you. {%- endtrans %}</p>
+<figure>
+<img src="/_static/images/git/wizard5.png" alt="" /><figcaption>Auto Start</figcaption>
+</figure>
+<p>{% trans -%} When you’re all done, it should look alot like this. {%- endtrans %}</p>
+<figure>
+<img src="/_static/images/git/wizard6.png" alt="" /><figcaption>Review settings</figcaption>
+</figure>
+<h2 id="trans--fourth-attempt-a-clone--endtrans">{% trans -%}Fourth: Attempt a clone{%- endtrans %}</h2>
+<p>{% trans -%}Now your tunnel is all set up, you can attempt a clone over SSH.{%- endtrans %}</p>
+<pre><code>GIT_SSH_COMMAND=&quot;ssh -p 7442&quot; \
+    git clone git@127.0.0.1:i2p-developer/i2p.i2p</code></pre>
+<p>{% trans -%} You might get an error where the remote end hangs up unexpectedly. Unfortunately git still doesn’t support resumable cloning. Until it does, there are a couple fairly easy ways to handle this. The first and easiest is to try and clone to a shallow depth: {%- endtrans %}</p>
+<pre><code>GIT_SSH_COMMAND=&quot;ssh -p 7442&quot; \
+    git clone --depth 1 git@127.0.0.1:i2p-developer/i2p.i2p</code></pre>
+<p>{% trans -%} Once you’ve performed a shallow clone, you can fetch the rest resumably by changing to the repo directory and running: {%- endtrans %}</p>
+<pre><code>git fetch --unshallow</code></pre>
+<p>{% trans -%} At this point, you still don’t have all your branches yet. You can get them by running the following commands: {%- endtrans %}</p>
+<pre><code>git config remote.origin.fetch &quot;+refs/heads/*:refs/remotes/origin/*&quot;
+git fetch origin</code></pre>
+<p>{% trans -%} Which tells git to alter the repository configuration so that fetching from origin fetches all branches. {%- endtrans %}</p>
+<p>{% trans -%} If that doesn’t work, you can try opening the tunnel configuration menu and adding some backup tunnels. {%- endtrans %}</p>
+<figure>
+<img src="/_static/images/git/tweak2.png" alt="" /><figcaption>Backup Tunnels</figcaption>
+</figure>
+<p>{% trans -%} If that doesn’t work, then the next easy thing to try is to decrease the tunnel length. Don’t do this if you believe you are at risk of your code-contribution activity being de-anonymized by a well-resourced attacker seeking to run many malicious nodes and control your whole path. If that sounds unlikely to you then you can probably do it safely. {%- endtrans %}</p>
+<figure>
+<img src="/_static/images/git/tweak1.png" alt="" /><figcaption>One-Hop Tunnels</figcaption>
+</figure>
+<h2 id="trans--suggested-workflow-for-developers--endtrans">{% trans -%}<em>Suggested Workflow for Developers!</em>{%- endtrans %}</h2>
+<p>{% trans -%} Revision control can make your life easier, but it works best if you use it well! In light of this, we strongly suggest a fork-first, feature-branch workflow as many are familiar with from Github. In such a workflow, the master branch is used as a sort of “Trunk” for updates and is never touched by the programmmer, instead, all changes to the master are merged from branches. In order to do set up your workspace for this, take the following steps:{%- endtrans %}</p>
+<ul>
+<li>{% trans -%}<strong>Never make changes to the Master Branch</strong>. You will be using the master branch to periodially obtain updates to the official source code. All changes should be made in feature branches.{%- endtrans %}</li>
+</ul>
+<ol type="1">
+<li><p>{% trans -%}Set up a second remote in your local repository using the upstream source code.{%- endtrans %}</p>
+<pre><code>git remote add upstream git@127.0.0.1:i2p-hackers/i2p.i2p</code></pre></li>
+<li><p>{% trans -%}Pull in any upstream changes on your current master:{%- endtrans %}</p>
+<pre><code>git pull upstream master</code></pre></li>
+<li><p>{% trans -%}Before making any changes to the source code, check out a new feature branch to develop on:{%- endtrans %}</p>
+<pre><code>git checkout -b feature-branch-name</code></pre></li>
+<li><p>{% trans -%}When you’re done with your changes, commit them and push them to your branch{%- endtrans %}</p>
+<pre><code>git commit -am &quot;I added an awesome feature!&quot;
+git push origin feature-branch-name</code></pre></li>
+<li><p>{% trans -%}Submit a merge request. When the merge request is approved and brought into the upstream master, check out the master locally and pull in the changes:{%- endtrans %}</p>
+<pre><code>git checkout master
+git pull upstream master</code></pre></li>
+<li><p>{% trans -%}Whenever a change to the upstream master(i2p-hackers/i2p.i2p) is made, you can update your master code using this procedure as well.{%- endtrans %}</p>
+<pre><code>git checkout master
+git pull upstream master</code></pre></li>
+</ol>
+
+{% endblock %}

i2p2www/pages/site/docs/applications/gitlab.html

@@ -0,0 +1,95 @@
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}Setting up Gitlab with I2P{% endtrans %}{% endblock %}
+{% block lastupdated %}2020-09{% endblock %}
+{% block accuratefor %}0.9.47{% endblock %}
+{% block content %}
+<h1 id="gitlab-over-i2p-setup">{% trans -%}Gitlab over I2P Setup{%- endtrans %}</h1>
+<div class="meta" data-author="idk" data-date="2020-03-16" data-excerpt="{% trans -%}Mirror I2P Git repositories and Bridge Clearnet repositories for others.{%- endtrans %}">
+
+</div>
+<p>{% trans -%} This is the setup process I use for configuring Gitlab and I2P, with Docker in place to manage the service itself. Gitlab is very easy to host on I2P in this fashion, it can be administered by one person without much difficulty. In my configuration, I use a Debian VM to host docker containers and an I2P router, on a Debian Host system, however, this may be more than necessary for some people. These instructions should work on any Debian-based system, regardless of whether it is in a VM or not, and should easily translate to any system where Docker and an I2P router are available. This guide starts at Docker and does not assume any VM underneath. {%- endtrans %}</p>
+<h2 id="dependencies-and-docker">{% trans -%}Dependencies and Docker{%- endtrans %}</h2>
+<p>{% trans -%} Because Gitlab runs in a container, we only need to install the dependencies required for the container on our main system. Conveniently, you can install everything you need with: {%- endtrans %}</p>
+<pre><code>sudo apt install docker.io</code></pre>
+<p>{% trans -%} on an otherwise unmodified Debian system, or if you have added Docker’s own “Community” Debian repository, you may use: {%- endtrans %}</p>
+<pre><code>sudo apt install docker-ce</code></pre>
+<p>{% trans -%} instead. {%- endtrans %}</p>
+<h3 id="fetch-the-docker-containers">{% trans -%}Fetch the Docker Containers{%- endtrans %}</h3>
+<p>{% trans -%} Once you have docker installed, you can fetch the docker containers required for gitlab. <em>Don’t run them yet.</em> {%- endtrans %}</p>
+<pre><code>docker pull gitlab/gitlab-ce</code></pre>
+<p>{% trans -%} For those who are concerned, the gitlab-ce Docker image is built using only Ubuntu Docker images as a parent, which are built from scratch images. Since there are no third-party images involved here, updates should come as soon as they are available in the host images. To review the Dockerfile for yourself, visit the <a href="https://gitlab.com/gitlab-org/omnibus-gitlab/-/blob/master/docker/Dockerfile">Gitlab source code</a>. {%- endtrans %}</p>
+<h2 id="set-up-an-i2p-http-proxy-for-gitlab-to-useimportant-information-optional-steps">{% trans -%}Set up an I2P HTTP Proxy for Gitlab to use(Important information, optional steps){%- endtrans %}</h2>
+<p>{% trans -%} Gitlab servers inside of I2P can be run with or without the ability to interact with servers on the internet outside of I2P. In the case where the Gitlab server is <em>not allowed</em> to interact with servers outside of I2P, they cannot be de-anonymized by cloning a git repository from a git server on the internet outside of I2P. They can, however, export and mirror repositories from other git services inside of I2P. {%- endtrans %}</p>
+<p>{% trans -%} In the case where the Gitlab server is <em>allowed</em> to interact with servers outside of I2P, it can act as a “Bridge” for the users, who can use it to mirror content outside I2P to an I2P-accessible source, however it <em>is not anonymous</em> in this case. Git services on the non-anonymous internet will be connected to directly. {%- endtrans %}</p>
+<p>{% trans -%} <strong>If you want to have a bridged, non-anonymous Gitlab instance with access to</strong> <strong>web repositories,</strong> no further modification is necessary. {%- endtrans %}</p>
+<p>{% trans -%} <strong>If you want to have an I2P-Only Gitlab instance with no access to Web-Only</strong> <strong>Repositories</strong>, you will need to configure Gitlab to use an I2P HTTP Proxy. Since the default I2P HTTP proxy only listens on <code>127.0.0.1</code>, you will need to set up a new one for Docker that listens on the Host/Gateway address of the Docker network, which is usually <code>172.17.0.1</code>. I configure mine on port <code>4446</code>. {%- endtrans %}</p>
+<h2 id="start-the-container-locally">{% trans -%}Start the Container Locally{%- endtrans %}</h2>
+<p>{% trans -%} Once you have that set up, you can start the container and publish your Gitlab instance locally. {%- endtrans %}</p>
+<pre><code>docker run --detach \
+  --env HTTP_PROXY=http://172.17.0.1:4446 \
+  --publish 127.0.0.1:8443:443 --publish 127.0.0.1:8080:80 --publish 127.0.0.1:8022:22 \
+  --name gitlab \
+  --restart always \
+  --volume /srv/gitlab/config:/etc/gitlab:Z \
+  --volume /srv/gitlab/logs:/var/log/gitlab:Z \
+  --volume /srv/gitlab/data:/var/opt/gitlab:Z \
+  gitlab/gitlab-ce:latest</code></pre>
+<p>{% trans -%} Visit your Local Gitlab instance and set up your admin account. Choose a strong password, and configure user account limits to match your resources. {%- endtrans %}</p>
+<h2 id="modify-gitlab.rboptional-but-a-good-idea-for-bridged-non-anonymous-hosts">{% trans -%}Modify gitlab.rb(Optional, but a good idea for “Bridged non-anonymous” hosts){%- endtrans %}</h2>
+<p>{% trans -%} It’s also possible to apply your HTTP Proxy settings in a more granular way, so that you can only allow users to mirror repositories from the domains that you choose. Since the domain is presumably operated by an organization, you can use this to ensure that repositories that are mirrorable follow a reasonable set of policies. After all, there is far more abusive content on the non-anonymous internet than there is on I2P, we wouldn’t want to make it too easy to introduce abusive content from such a nefarious place. {%- endtrans %}</p>
+<p>{% trans -%} Add the following lines to your gitlab.rb file inside the /src/gitlab/config container. These settings will take effect when you restart in a moment. {%- endtrans %}</p>
+<pre><code>gitlab_rails[&#39;env&#39;] = {
+    &quot;http_proxy&quot; =&gt; &quot;http://172.17.0.1:4446&quot;,
+    &quot;https_proxy&quot; =&gt; &quot;http://172.17.0.1:4446&quot;,
+    &quot;no_proxy&quot; =&gt; &quot;.github.com,.gitlab.com&quot;
+}
+gitaly[&#39;env&#39;] = {
+    &quot;http_proxy&quot; =&gt; &quot;http://172.17.0.1:4446&quot;,
+    &quot;https_proxy&quot; =&gt; &quot;http://172.17.0.1:4446&quot;,
+    &quot;no_proxy&quot; =&gt; &quot;unix,.github.com,.gitlab.com&quot;
+}
+gitlab_workhorse[&#39;env&#39;] = {
+    &quot;http_proxy&quot; =&gt; &quot;http
+    &quot;https_proxy&quot; =&gt; &quot;http://172.17.0.1:4446&quot;,
+    &quot;no_proxy&quot; =&gt; &quot;unix,.github.com,.gitlab.com&quot;
+}</code></pre>
+<h3 id="set-up-your-service-tunnels-and-sign-up-for-a-hostname">{% trans -%}Set up your Service tunnels and sign up for a Hostname{%- endtrans %}</h3>
+<p>{% trans -%} Once you have Gitlab set up locally, go to the I2P Router console. You will need to set up two server tunnels, one leading to the Gitlab web(HTTP) interface on TCP port 8080, and one to the Gitlab SSH interface on TCP Port 8022. {%- endtrans %}</p>
+<h4 id="gitlab-webhttp-interface">{% trans -%}Gitlab Web(HTTP) Interface{%- endtrans %}</h4>
+<p>{% trans -%} For the Web interface, use an “HTTP” server tunnel. From <a href="http://127.0.0.1:7657/i2ptunnelmgr">http://127.0.0.1:7657/i2ptunnelmgr</a> launch the “New Tunnel Wizard” and enter the following values at each step: {%- endtrans %}</p>
+<ol type="1">
+<li>{% trans -%}Select “Server Tunnel”{%- endtrans %}</li>
+<li>{% trans -%}Select “HTTP Server”{%- endtrans %}</li>
+<li>{% trans -%}Fill in “Gitlab Web Service” or otherwise describe the tunnel{%- endtrans %}</li>
+<li>{% trans -%}Fill in <code>127.0.0.1</code> for the host and <code>8080</code> for the port.{%- endtrans %}</li>
+<li>{% trans -%}Select “Automatically start tunnel when Router Starts”{%- endtrans %}</li>
+<li>{% trans -%}Confirm your selections.{%- endtrans %}</li>
+</ol>
+<h5 id="register-a-hostnameoptional">{% trans -%}Register a Hostname(Optional){%- endtrans %}</h5>
+<p>{% trans -%} Web services on I2P can register hostnames for themselves by providing an authentication string to a jump service provider like <a href="http://stats.i2p">stats.i2p</a>. To do this, open the <a href="http://127.0.0.1:7657/i2ptunnelmgr">http://127.0.0.1:7657/i2ptunnelmgr</a> again and click on the “Gitlab Web Service” item you just set up. Scroll to the bottom of the “Edit Server Settings” section and click Registration Authentication. Copy the field that says “Authentication for adding Hostname” and visit <a href="http://stats.i2p/i2p/addkey.html">stats.i2p</a> to add your hostname. Note that if you want to use a subdomain(Like git.idk.i2p) then you will have to use the correct authentication string for your subdomain, which is a little bit more complicated and merits it’s own instructions. {%- endtrans %}</p>
+<h4 id="gitlab-ssh-interface">{% trans -%}Gitlab SSH Interface{%- endtrans %}</h4>
+<p>{% trans -%} For the SSH interface, use a “Standard” server tunnel. From <a href="http://127.0.0.1:7657/i2ptunnelmgr">http://127.0.0.1:7657/i2ptunnelmgr</a> launch the “New Tunnel Wizard” and enter the following values at each step: {%- endtrans %}</p>
+<ol type="1">
+<li>{% trans -%}Select “Server Tunnel”{%- endtrans %}</li>
+<li>{% trans -%}Select “Standard Server”{%- endtrans %}</li>
+<li>{% trans -%}Fill in “Gitlab SSH Service” or otherwise describe the tunnel{%- endtrans %}</li>
+<li>{% trans -%}Fill in <code>127.0.0.1</code> for the host and <code>8022</code> for the port.{%- endtrans %}</li>
+<li>{% trans -%}Select “Automatically start tunnel when Router Starts”{%- endtrans %}</li>
+<li>{% trans -%}Confirm your selections.{%- endtrans %}</li>
+</ol>
+<h2 id="re-start-the-gitlab-service-with-the-new-hostname">{% trans -%}Re-start the Gitlab Service with the new Hostname{%- endtrans %}</h2>
+<p>{% trans -%} Finally, if you either modified <code>gitlab.rb</code> or you registered a hostname, you will need to re-start the gitlab service for the settings to take effect. {%- endtrans %}</p>
+<pre><code>docker stop gitlab
+docker rm gitlab
+docker run --detach \
+  --hostname your.hostname.i2p \
+  --hostname thisisreallylongbase32hostnamewithfiftytwocharacters.b32.i2p \
+  --env HTTP_PROXY=http://172.17.0.1:4446 \
+  --publish 127.0.0.1:8443:443 --publish 127.0.0.1:8080:80 --publish 127.0.0.1:8022:22 \
+  --name gitlab \
+  --restart always \
+  --volume /srv/gitlab/config:/etc/gitlab:Z \
+  --volume /srv/gitlab/logs:/var/log/gitlab:Z \
+  --volume /srv/gitlab/data:/var/opt/gitlab:Z \
+  gitlab/gitlab-ce:latest</code></pre>
+{% endblock %}

i2p2www/spec/i2np.rst

@@ -3,8 +3,8 @@ I2NP Specification
 ==================
 .. meta::
     :category: Protocols
-    :lastupdated: 2020-06
-    :accuratefor: 0.9.46
+    :lastupdated: 2020-10
+    :accuratefor: 0.9.48
 
 .. contents::
 
@@ -1476,7 +1476,7 @@ Notes
 * The I2NP message ID for this message must be set according to the tunnel
   creation specification.
 
-* Typical number of records in today's network is 5.
+* Typical number of records in today's network is 4, for a total size of 2113.
 
 .. _msg-VariableTunnelBuildReply:
 
@@ -1503,7 +1503,7 @@ Notes
 * The I2NP message ID for this message must be set according to the tunnel
   creation specification.
 
-* Typical number of records in today's network is 5.
+* Typical number of records in today's network is 4, for a total size of 2113.
 
 
 References

i2p2www/spec/proposals/152-ecies-tunnels.rst

@@ -6,7 +6,7 @@ ECIES Tunnels
     :author: chisana, zzz, orignal
     :created: 2019-07-04
     :thread: http://zzz.i2p/topics/2737
-    :lastupdated: 2020-09-23
+    :lastupdated: 2020-10-26
     :status: Open
     :target: 0.9.51
 
@@ -31,6 +31,9 @@ follow this spec for creating tunnels containing ECIES hops.
 This proposal specifies changes needed for ECIES-X25519 Tunnel Building.
 For an overview of all changes required for ECIES routers, see proposal 156 [Prop156]_.
 
+This proposal maintains the same size for tunnel build records,
+as required for compatibility. Smaller build records and messages will be
+implemented later - see [Prop157]_.
 
 
 Cryptographic Primitives
@@ -84,6 +87,7 @@ Non-Goals
 - Shrinking tunnel build messages (requires all-ECIES hops and a new proposal)
 - Use of tunnel build options as defined in [Prop143]_, only required for small messages
 - Bidirectional tunnels - for that see [Prop119]_
+- Smaller tunnel build messages - for that see [Prop157]_
 
 
 Threat Model
@@ -342,7 +346,7 @@ Summary of changes:
 - Unencrypted record is longer because there is less encryption overhead
 
 
-The request record does not contain any explicit tunnel or reply keys.
+The request record does not contain any ChaCha reply keys.
 Those keys are derived from a KDF. See below.
 
 All fields are big-endian.
@@ -383,6 +387,9 @@ Bit 7 indicates that the hop will be an inbound gateway (IBGW).  Bit 6
 indicates that the hop will be an outbound endpoint (OBEP).  If neither bit is
 set, the hop will be an intermediate participant.  Both cannot be set at once.
 
+The request exipration is for future variable tunnel duration.
+For now, the only supported value is 600 (10 minutes).
+
 The tunnel build options is a Mapping structure as defined in [Common]_.
 This is for future use. No options are currently defined.
 If the Mapping structure is empty, this is two bytes 0x00 0x00.
@@ -585,7 +592,8 @@ Request Record Keys (ECIES)
 -----------------------------------------------------------------------
 
 These keys are explicitly included in ElGamal BuildRequestRecords.
-For ECIES BuildRequestRecords, these keys are derived from the DH exchange.
+For ECIES BuildRequestRecords, the tunnel keys and AES reply keys are included,
+but the ChaCha reply keys are derived from the DH exchange.
 See [Prop156]_ for details of the router static ECIES keys.
 
 Below is a description of how to derive the keys previously transmitted in request records.
@@ -660,6 +668,9 @@ Failing to use unique keys opens an attack vector for colluding hops to confirm
   sesk = GENERATE_PRIVATE()
   sepk = DERIVE_PUBLIC(sesk)
 
+  // MixHash(sepk)
+  h = SHA256(h || sepk);
+
   End of "e" message pattern.
 
   This is the "es" message pattern:
@@ -765,35 +776,15 @@ This design minimizes risk.
 Implementation Notes
 =====================
 
-
+* Older routers do not check the encryption type of the hop and will send ElGamal-encrypted
+  records. Some recent routers are buggy and will send various types of malformed records.
+  Implementers should detect and reject these records prior to the DH operation
+  if possible, to reduce CPU usage.
 
 
 Issues
 ======
 
-* Is an HKDF required for the keys, what's the advantage of doing that vs.
-  just including them in the build record as before?
-
-* Make KDFs be similar to those in Noise (NTCP2) and Ratchet
-
-* HKDF output no more than 64 bytes preferred
-
-* In the current Java implementation, the full router hash field in the build
-  request record at bytes 4-35 is not checked and does not appear to be necessary.
-
-* Each record is CBC encrypted with the same AES reply key and IV, as with the current design.
-  Is this a problem? Can it be fixed?
-
-* In the current Java implementation, the originator leaves one record empty
-  for itself. Thus a message of n records can only build a tunnel of n-1 hops.
-  This is necessary for inbound tunnels (where the next-to-last hop
-  can see the hash prefix for the next hop), but not for outbound tunnels.
-  However, if the build message length is different for inbound and outbound
-  tunnels, this would allow hops to determine which direction the tunnel was.
-
-* Should we define new, smaller VTBM/VTBRM I2NP messages for all-ECIES tunnels
-  now instead of waiting for the rollout?
-
 
 
 Migration
@@ -837,6 +828,9 @@ References
 .. [Prop156]
     {{ proposal_url('156') }}
 
+.. [Prop157]
+    {{ proposal_url('157') }}
+
 .. [Tunnel-Creation]
    {{ spec_url('tunnel-creation') }}
 

i2p2www/spec/proposals/156-ecies-routers.rst

@@ -5,7 +5,7 @@ ECIES Routers
     :author: zzz, orignal
     :created: 2020-09-01
     :thread: http://zzz.i2p/topics/2950
-    :lastupdated: 2020-09-05
+    :lastupdated: 2020-10-19
     :status: Open
     :target: 0.9.51
 
@@ -46,6 +46,7 @@ See [Prop152]_ for additional goals.
 - Maximize compatibility with current network
 - Do not require "flag day" upgrade to entire network
 - Gradual rollout to minimize risk
+- New, smaller tunnel build message
 
 
 Non-Goals
@@ -54,7 +55,7 @@ Non-Goals
 See [Prop152]_ for additional non-goals.
 
 - No requirement for dual-key routers
-- Complete redesign of tunnel build messages requiring a "flag day", for that see [Prop153]_
+- Layer encryption changes, for that see [Prop153]_
 
 
 Design
@@ -92,9 +93,17 @@ are required to use ECIES instead of ElGamal.
 In addition, we will make improvements to the tunnel build messages
 to increase security.
 
+In phase 1, we will change the format and encryption of the
+Build Request Record and Build Response Record for ECIES hops.
+These changes will be compatible with existing ElGamal routers.
 These changes are defined in proposal 152 [Prop152]_.
-Proposal 152 is preliminary and has not been fully reviewed.
-It will require significant corrections and cleanup.
+
+In phase 2, we will add a new version of the
+Build Request Message, Build Reply Message,
+Build Request Record and Build Response Record.
+The size will be reduced for efficiency.
+These changes must be supported by all hops in a tunnel, and all hops must be ECIES.
+These changes are defined in proposal 157 [Prop157]_.
 
 
 
@@ -147,6 +156,7 @@ Tunnel Building: See [Prop152]_.
 
 End-to-End Encryption: See [ECIES]_.
 
+New Tunnel Build Message: See [Prop157]_.
 
 
 Justification
@@ -194,13 +204,23 @@ by mid-2019 in reaction to unfinished proposal 145 [Prop145]_.
 Ensure there's nothing in the code bases
 that prevents point-to-point connections to non-ElGamal routers.
 
+Code correctness checks:
+
+- Ensure that ElGamal routers do not request AEAD-encrypted replies to DatabaseLookup messages
+  (when the reply comes back through an exploratory tunnel to the router)
+- Ensure that ECIES routers do not request AES-encrypted replies to DatabaseLookup messages
+  (when the reply comes back through an exploratory tunnel to the router)
+
 Until later phases, when specifications and implementations are complete:
 
 - Ensure that tunnel builds are not attempted by ElGamal routers through ECIES routers.
 - Ensure that encrypted ElGamal messages are not sent by ElGamal routers to ECIES floodfill routers.
+  (DatabaseLookups and DatabaseStores)
 - Ensure that encrypted ECIES messages are not sent by ECIES routers to ElGamal floodfill routers.
+  (DatabaseLookups and DatabaseStores)
 - Ensure that ECIES routers do not automatically become floodfill.
 
+No changes should be required.
 Target release, if changes required: 0.9.48
 
 
@@ -213,6 +233,7 @@ by mid-2019 in reaction to unfinished proposal 145 [Prop145]_.
 Ensure there's nothing in the code bases
 that prevents storage of non-ElGamal RouterInfos in the network database.
 
+No changes should be required.
 Target release, if changes required: 0.9.48
 
 
@@ -226,19 +247,25 @@ use its own build request record for an inbound tunnel to test and debug.
 Then test and support ECIES routers building tunnels with a mix of
 ElGamal and ECIES hops.
 
-Then enable tunnel building through ECIES routers with a minimum version TBD.
+Then enable tunnel building through ECIES routers.
+No minimum version check should be necessary unless incompatible changes
+to proposal 152 are made after a release.
 
-Target release: 0.9.49 or 0.9.50, early-mid 2021
+Target release: 0.9.48, late 2020
 
 
 Ratchet messages to ECIES floodfills
 ----------------------------------------
 
 Implement and test reception of ECIES messages (with zero static key) by ECIES floodfills.
-Enable auto-floodfill by ECIES routers.
-Then enable sending ECIES messages to ECIES routers with a minimum version TBD.
+Implement ant test reception of AEAD replies to DatabaseLookup messages by ECIES routers.
 
-Target release: 0.9.49 or 0.9.50, early-mid 2021
+Enable auto-floodfill by ECIES routers.
+Then enable sending ECIES messages to ECIES routers.
+No minimum version check should be necessary unless incompatible changes
+to proposal 152 are made after a release.
+
+Target release: 0.9.49, early 2021
 
 
 Rekeying
@@ -255,6 +282,18 @@ Probably start rekeying mid-2021.
 Target release: TBD
 
 
+New Tunnel Build Message
+--------------------------
+
+Implement and test the new Tunnel Build Message as defined in proposal 157 [Prop157]_.
+Roll the support out in a release.
+Do additional testing, then enable it in the next release.
+
+Probably mid-2021.
+
+Target release: TBD
+
+
 ECIES for New Installs
 --------------------------
 
@@ -306,6 +345,9 @@ References
 .. [Prop154]
     {{ proposal_url('154') }}
 
+.. [Prop157]
+    {{ proposal_url('157') }}
+
 .. [Tunnel-Creation]
     {{ spec_url('tunnel-creation') }}
 

i2p2www/spec/proposals/157-new-tbm.rst

@@ -0,0 +1,271 @@
+========================================
+Smaller Tunnel Build Messages
+========================================
+.. meta::
+    :author: zzz, orignal
+    :created: 2020-10-09
+    :thread: http://zzz.i2p/topics/2957
+    :lastupdated: 2020-10-09
+    :status: Open
+    :target: 0.9.51
+
+.. contents::
+
+
+
+Overview
+========
+
+
+Summary
+-------
+
+The current size of the encrypted tunnel Build Request and Response records is 528.
+For typical Variable Tunnel Build and Variable Tunnel Build Reply messages,
+the total size is 2113 bytes. This message is fragmented into 1KB three tunnel
+messages for the reverse path.
+
+Changes to the 528-byte record format for ECIES-X25519 routers are specified in [Prop152]_.
+For a mix of ElGamal and ECIES-X25519 routers in a tunnel, the record size must remain
+528 bytes. However, if all routers in a tunnel are ECIES-X25519, a new, smaller
+build record is possible, because ECIES-X25519 encryption has much less overhead
+than ElGamal.
+
+Smaller messages would save bandwidth. Also, if the messages could fit in a
+single tunnel message, the reverse path would be three times more efficient.
+
+This proposal defines new request and reply records and new Buid Request and Build Reply messages.
+
+
+Goals
+-----
+
+See [Prop152]_ and [Prop156]_ for additional goals.
+
+- Smaller records and messages
+- Maintain sufficient space for future options, as in [Prop152]_
+- Fit in one tunnel message for the reverse path
+- Support ECIES hops only
+- Maintain improvements implemented in [Prop152]_
+- Maximize compatibility with current network
+- Do not require "flag day" upgrade to entire network
+- Gradual rollout to minimize risk
+- Reuse existing cryptographic primitives
+
+
+Non-Goals
+-----------
+
+See [Prop156]_ for additional non-goals.
+
+- No requirement for mixed ElGamal/ECIES tunnels
+- Layer encryption changes, for that see [Prop153]_
+- No speedups of crypto operations. It's assumed that ChaCha20 and AES are similar.
+
+
+Design
+======
+
+
+Records
+-------------------------------
+
+See appendix for calculations.
+
+Encrypted request and reply records will be 236 bytes, compared to 528 bytes now.
+
+The plaintext request records will be either 160 or 172 bytes,
+compared to 222 bytes for ElGamal records,
+and 464 bytes for ECIES records as defined in [Prop152]_.
+
+The plaintext response records will be either 160 or 172 bytes,
+compared to 496 bytes for ElGamal records,
+and 512 bytes for ECIES records as defined in [Prop152]_.
+
+If we use AES for reply encryption, records must be a multiple of 16.
+If we use ChaCha20 (NOT ChaCha20/Poly1305), they can be 172 bytes.
+TBD.
+
+Request records will be made smaller by using HKDF to create the
+layer and reply keys, so they do not need to be explicitly included in the request.
+
+
+Tunnel Build Messages
+-----------------------
+
+Both will be "variable" with a one-byte number of records field,
+as with the existing Variable messages.
+
+Build: Type 25
+
+Reply: Type 26
+
+Total length: 641 or 689 bytes
+
+
+Record Encryption
+------------------
+
+Request and reply record encryption: as defined in [Prop152]_.
+
+Reply record encryption for other slots: AES or ChaCha20?
+
+
+
+Specification
+=============
+
+
+Request Record
+-----------------------
+
+TBD
+
+
+Response Record
+-----------------------
+
+TBD
+
+
+KDF
+-----------------------
+
+TBD
+
+
+Tunnel Build Messages
+-----------------------
+
+TBD
+
+
+Justification
+=============
+
+This design maximizes reuse of existing cryptographic primitives, protocols, and code.
+
+This design minimizes risk.
+
+
+
+
+Implementation Notes
+=====================
+
+
+
+
+Issues
+======
+
+- HKDF details
+- AES or ChaCha for reply encryption?
+- Should we do additional hiding from the paired OBEP or IBGW? Garlic?
+
+
+Migration
+=========
+
+The implementation, testing, and rollout will take several releases
+and approximately one year. The phases are as follows. Assignment of
+each phase to a particular release is TBD and depends on
+the pace of development.
+
+Details of the implementation and migration may vary for
+each I2P implementation.
+
+Tunnel creator must ensure that all hops are ECIES-X25519, AND are at least version TBD.
+The tunnel creator does NOT have to be ECIES-X25519; it can be ElGamal.
+However, if the creator is ElGamal, it reveals to the closest hop that it is the creator.
+So, in practice, these tunnels should only be created by ECIES routers.
+
+It should NOT be necessary for the paired-tunnel OBEP or IBGW is ECIES or
+of any particular version, because they SHOULD support
+relaying of unknown message types.
+This should be verified in testing.
+
+Phase 1: Implementation, not enabled by default
+
+Phase 2 (next release): Enable by default
+
+
+Appendix
+==========
+
+
+.. raw:: html
+
+  {% highlight lang='text' %}
+Current 4-slot size: 4 * 528 + overhead = 3 tunnel messages
+
+  4-slot build message to fit in one tunnel message, ECIES-only:
+
+  1024
+  - 21 fragment header
+  ----
+  1003
+  - 39 unfragmented instructions
+  ----
+  964
+  - 16 I2NP header
+  ----
+  948
+  - 1 number of slots
+  ----
+  947
+  / 4 slots
+  ----
+  236 New encrypted build record size (vs. 528 now)
+  - 16 trunc. hash
+  - 32 eph. key
+  - 16 MAC
+  ----
+  172 cleartext build record max (vs. 222 now)
+
+  Current build record cleartext size before unused padding: 193
+
+  Removal of full router hash and HKDF generation of keys/IVs would free up plenty of room for future options.
+  If everything is HKDF, required cleartext space is about 82 bytes (without any options)
+
+
+
+{% endhighlight %}
+
+
+References
+==========
+
+.. [Common]
+    {{ spec_url('common-structures') }}
+
+.. [ECIES]
+   {{ spec_url('ecies') }}
+
+.. [I2NP]
+    {{ spec_url('i2np') }}
+
+.. [Prop123]
+    {{ proposal_url('123') }}
+
+.. [Prop144]
+    {{ proposal_url('144') }}
+
+.. [Prop145]
+    {{ proposal_url('145') }}
+
+.. [Prop152]
+    {{ proposal_url('152') }}
+
+.. [Prop153]
+    {{ proposal_url('153') }}
+
+.. [Prop154]
+    {{ proposal_url('154') }}
+
+.. [Prop156]
+    {{ proposal_url('156') }}
+
+.. [Tunnel-Creation]
+    {{ spec_url('tunnel-creation') }}
+

site-updater-docker.sh

@@ -1,4 +1,4 @@
-#! /usr/bin/env sh
+#! /usr/bin/env bash
 
 ## Set additional docker run arguments by changing the variable
 ## i2p_www_docker_run_args