cc acetone's article to applications/dns

Start of the spec sections, very much WIP

.mtn-ignore

@@ -1,9 +0,0 @@
-env
-\.pot\.old$
-\.pyc$
-\.pyo$
-\.mo$
-~$
-\.custom$
-\.wsgi$
-\.pybabel-stamp$

Dockerfile

@@ -1,4 +1,4 @@
-FROM debian:stable
+FROM debian:buster
 ENV SERVERNAME=geti2p.net
 ENV SERVERMAIL=example@geti2p.net
 
@@ -8,7 +8,7 @@ WORKDIR /var/www/i2p.www
 
     ## Install the dependencies
 RUN apt-get update && \
-    apt-get -y install apache2 apache2-utils libapache2-mod-wsgi python2-dev python-pip patch python-virtualenv git && \
+    apt-get -y install apache2 apache2-utils libapache2-mod-wsgi python2-dev python-pip patch python-virtualenv git python-polib && \
     ## Start setting up the site
     rm -rfv env && \
     virtualenv --distribute env                && \  

README.md

@@ -34,9 +34,7 @@ If you want to mirror the I2P website, thanks! Here is a checklist:
   - In particular, do not change the `CANONICAL_DOMAIN` variable in
     `i2p2www/__init__.py`, it needs to point to the official site for SEO.
 - If you need to edit variables in `etc/update.vars`, copy the file to
-  `etc/update.vars.custom` and edit appropriately. The only variable you
-  may need to edit is `MTNURL` in `etc/update.vars` (if your Monotone client
-  tunnel is listening on a different port).
+  `etc/update.vars.custom` and edit appropriately.
 - If you want to enable caching, copy `i2p2www/settings.py.sample` to
   `i2p2www/settings.py` and edit appropriately.
 - Add `./site-updater.sh` to your crontab. This will keep the site updated,
@@ -99,11 +97,6 @@ in `etc/translation.vars` can be overridden by creating the file
     $ git commit -am "Updated translations"
     ```
 
-    ```
-    # older mtn instructions
-    $ mtn ci `cat newtranslations.txt` -m "Updated translations"
-    ```
-
 6. Check in any new translations:
    First, look to see which translations are supported in i2pwww/__init__.py.
    For any new translations that are NOT in __init__.py,
@@ -115,11 +108,6 @@ in `etc/translation.vars` can be overridden by creating the file
     $ git add i2p2www/translations/* && git commit -am "New translations"
     ```
 
-    ```
-    # older mtn instructions
-    $ mtn add -R i2p2www/translations/ && mtn ci i2p2www/translations/ -m "New translations"
-    ```
-
 ## Pushing updated translation source (.pot) files to Transifex:
 
 1. Update the .pot files with any changes to the website text:
@@ -135,11 +123,6 @@ in `etc/translation.vars` can be overridden by creating the file
     $ git commit -am "Updated translation strings"
     ```
 
-    ```
-    # older mtn instructions
-    $ mtn ci pots/ -m "Updated translation strings"
-    ```
-
 3. Push pots file changes to Transifex:
 
     ```

docker-run-dev.sh

@@ -0,0 +1,5 @@
+#! /usr/bin/env sh
+virtualenv --distribute env
+. env/bin/activate
+#./setup_venv.sh
+DEV=on ./runserver.py

i2p2www/__init__.py

@@ -22,8 +22,8 @@ except ImportError:
 ###########
 # Constants
 
-CURRENT_I2P_VERSION = '0.9.48'
-CURRENT_I2P_FIREFOX_PROFILE_VERSION = '0.02b'
+CURRENT_I2P_VERSION = '1.5.0'
+CURRENT_I2P_FIREFOX_PROFILE_VERSION = '1.05.0'
 
 CANONICAL_DOMAIN = 'geti2p.net'
 
@@ -48,6 +48,7 @@ SUPPORTED_LANGS = [
     'zh_TW',
     'el',
     'he',
+    'hu',
     'it',
     'ja',
     'ko',
@@ -75,6 +76,7 @@ SUPPORTED_LANG_NAMES = {
     'fr': u'Français',
     'el': u'Greek Ελληνικά',
     'he': u'Hebrew עברית',
+    'hu': u'Hungarian',
     'it': u'Italiano',
     'ja': u'Japanese 日本語',
     'ko': u'Korean 한국말',

i2p2www/blog/2010/12/22/release-0.8.2.html

@@ -11,7 +11,7 @@ Please help grow the network.
 <a href="http://www.i2p2.de/getinvolved.html">Get involved</a>,
 spread the word,
 and <a href="http://www.i2p2.de/donate.html">donate</a>!
-If you find a bug, please enter a report on <a href="http://trac.i2p2.de/report/1">trac</a>.
+If you find a bug, please enter a report on <a href="http://i2pgit.org/i2p-hackers/i2p.i2p/issues">gitlab</a>.
 We are still looking for help on new and existing translations.
 Please volunteer on IRC #i2p.
 </p>

i2p2www/blog/2011/01/24/release-0.8.3.html

@@ -17,7 +17,7 @@ Please help grow the network.
 <a href="http://www.i2p2.de/getinvolved.html">Get involved</a>,
 spread the word,
 and <a href="http://www.i2p2.de/donate.html">donate</a>!
-If you find a bug, please enter a report on <a href="http://trac.i2p2.de/report/1">trac</a>.
+If you find a bug, please enter a report on <a href="http://i2pgit.org/i2p-hackers/i2p.i2p/issues">gitlab</a>.
 We are still looking for help on new and existing translations.
 Please volunteer on IRC #i2p.
 </p>

i2p2www/blog/2011/03/02/release-0.8.4.html

@@ -7,7 +7,7 @@ Please help grow the network.
 <a href="http://www.i2p2.de/getinvolved.html">Get involved</a>,
 spread the word,
 and <a href="http://www.i2p2.de/donate.html">donate</a>!
-If you find a bug, please enter a report on <a href="http://trac.i2p2.de/report/1">trac</a>.
+If you find a bug, please enter a report on <a href="http://i2pgit.org/i2p-hackers/i2p.i2p/issues">gitlab</a>.
 We are still looking for help on new and existing translations.
 Please volunteer on IRC #i2p-dev.
 </p>

i2p2www/blog/2011/04/18/release-0.8.5.html

@@ -6,7 +6,7 @@ Please help grow the network.
 <a href="http://www.i2p2.de/getinvolved.html">Get involved</a>,
 spread the word,
 and <a href="http://www.i2p2.de/donate.html">donate</a>!
-If you find a bug, please enter a report on <a href="http://trac.i2p2.de/report/1">trac</a>.
+If you find a bug, please enter a report on <a href="http://i2pgit.org/i2p-hackers/i2p.i2p/issues">gitlab</a>.
 We are still looking for help on new and existing translations.
 Please volunteer on IRC #i2p-dev.
 </p>

i2p2www/blog/2011/05/16/release-0.8.6.html

@@ -7,7 +7,7 @@ Please help grow the network.
 <a href="http://www.i2p2.de/getinvolved.html">Get involved</a>,
 spread the word,
 and <a href="http://www.i2p2.de/donate.html">donate</a>!
-If you find a bug, please enter a report on <a href="http://trac.i2p2.de/report/1">trac</a>.
+If you find a bug, please enter a report on <a href="http://i2pgit.org/i2p-hackers/i2p.i2p/issues">gitlab</a>.
 We are still looking for help on new and existing translations.
 Please volunteer on IRC #i2p-dev.
 </p>

i2p2www/blog/2011/06/27/release-0.8.7.html

@@ -26,7 +26,7 @@ Please help grow the network.
 <a href="http://www.i2p2.de/getinvolved.html">Get involved</a>,
 spread the word,
 and <a href="http://www.i2p2.de/donate.html">donate</a>!
-If you find a bug, please enter a report on <a href="http://trac.i2p2.de/report/1">trac</a>.
+If you find a bug, please enter a report on <a href="http://i2pgit.org/i2p-hackers/i2p.i2p/issues">gitlab</a>.
 We are still looking for help on new and existing translations.
 Please volunteer on IRC #i2p-dev.
 </p>

i2p2www/blog/2011/08/23/release-0.8.8.html

@@ -13,7 +13,7 @@ Please help grow the network.
 <a href="http://www.i2p2.de/getinvolved.html">Get involved</a>,
 spread the word,
 and <a href="http://www.i2p2.de/donate.html">donate</a>!
-If you find a bug, please enter a report on <a href="http://trac.i2p2.de/report/1">trac</a>.
+If you find a bug, please enter a report on <a href="http://i2pgit.org/i2p-hackers/i2p.i2p/issues">gitlab</a>.
 We are still looking for help on new and existing translations.
 Please volunteer on IRC #i2p-dev.
 </p>

i2p2www/blog/2020/12/10/Hello-git-goodbye-mtn.rst

@@ -0,0 +1,91 @@
+======================================================
+{% trans -%}Hello Git, Goodbye Monotone{%- endtrans %}
+======================================================
+
+.. meta::
+   :author: idk
+   :date: 2020-12-10
+   :category: git
+   :excerpt: {% trans %}Hello git, goodbye mtn{% endtrans %}
+
+{% trans -%}
+Hello Git, Goodbye Monotone
+{%- endtrans %}
+===========================
+
+{% trans -%}
+The I2P Git Migration is nearly concluded
+{%- endtrans %}
+-----------------------------------------
+
+{% trans -%}
+For over a decade, I2P has relied on the venerable Monotone service to support
+its version control needs, but during the past few years, most of the world has
+moved on to the now-universal Git version control system. In that same
+time, the I2P Network has become faster and more reliable, and accessible
+workarounds to Git's non-resumability have been developed.
+{%- endtrans %}
+
+{% trans -%}
+Today marks a significant occasion for I2P, as we switched off the old mtn
+i2p.i2p branch, and moved the development of the core Java I2P libraries from
+Monotone to Git officially.
+{%- endtrans %}
+
+{% trans -%}
+While our use of mtn has been questioned in the past, and it's not always been a
+popular choice, I'd like to take this moment, as perhaps the very last project to use
+Monotone to thank the Monotone developers, current and former, wherever they are,
+for the software they created.
+{%- endtrans %}
+
+.. image:: /_static/images/GoodbyeMTN.png
+
+{% trans -%}
+GPG Signing
+{%- endtrans %}
+-----------
+
+{% trans -%}
+Checkins to the I2P Project repositories require you to configure GPG signing for
+your git commits, including Merge Requests and Pull Requests. Please configure
+your git client for GPG signing before you fork i2p.i2p and check anything in.
+{%- endtrans %}
+
+{% trans -%}
+Official Repositories and Gitlab/Github Syncing
+{%- endtrans %}
+-----------------------------------------------
+
+{% trans -%}
+The official repository is the one hosted at https://i2pgit.org/i2p-hackers/i2p.i2p
+and at https://git.idk.i2p/i2p-hackers/i2p.i2p, but there is a "Mirror" available
+at Github at https://github.com/i2p/i2p.i2p.
+{%- endtrans %}
+
+{% trans -%}
+Now that we're on git, we can synchronize repositories from our own self-hosted Gitlab
+instance, to Github, and back again. This means that it is possible to create and submit
+a merge request on Gitlab and when it is merged, the result will be synced with Github,
+and a Pull Request on Github, when merged, will appear on Gitlab.
+{%- endtrans %}
+
+{% trans -%}
+This means that it's possible to submit code to us through our Gitlab instance or through
+Github depending on what you prefer, however, more of the I2P developers are regularly
+monitoring Gitlab than Github. MR's to Gitlab are more likely to be merged sooner
+than PR's to Github.
+{%- endtrans %}
+
+{% trans -%}
+Thanks
+{%- endtrans %}
+------
+
+{% trans -%}
+Congratulations and thanks to everyone who helped in the git migration, especially
+zzz, eche|on, nextloop, and our site mirror operators! While some of us will miss
+Monotone, it has become a barrier for new and existing participants in I2P development
+and we're excited to join the world of developers using Git to manage their distributed
+projects.
+{%- endtrans %}

i2p2www/blog/2021/02/17/0.9.49-Release.rst

@@ -0,0 +1,108 @@
+===========================================
+{% trans -%}0.9.49 Release{%- endtrans %}
+===========================================
+
+.. meta::
+   :author: zzz
+   :date: 2021-02-17
+   :category: release
+   :excerpt: {% trans %}0.9.49 with SSU fixes and faster crypto{% endtrans %}
+
+{% trans -%}
+Update details
+{%- endtrans %}
+============================================
+
+{% trans -%}
+0.9.49 continues the work to make I2P faster and more secure.
+We have several improvements and fixes for the SSU (UDP) transport that should result in faster speeds.
+This release also starts the migration to new, faster ECIES-X25519 encryption for routers.
+(Destinations have been using this encryption for a few releases now)
+We've been working on the specifications and protocols for new encryption for several years,
+and we are getting close to the end of it! The migration will take several releases to complete.
+{%- endtrans %}
+
+{% trans -%}
+For this release, to minimize disruption, only new installs and a very small percentage of existing installs
+(randomly selected at restart) will be using the new encryption.
+If your router does "rekey" to use the new encryption, it may have lower traffic or less reliability than usual for several days after you restart.
+This is normal, because your router has generated a new identity.
+Your performance should recover after a while.
+{%- endtrans %}
+
+{% trans -%}
+We have "rekeyed" the network twice before, when changing the default signature type,
+but this is the first time we've changed the default encryption type.
+Hopefully it will all go smoothly, but we're starting slowly to be sure.
+{%- endtrans %}
+
+{% trans -%}
+As usual, we recommend that you update to this release. The best way to
+maintain security and help the network is to run the latest release.
+{%- endtrans %}
+
+
+**{% trans %}RELEASE DETAILS{% endtrans %}**
+
+**{% trans %}Changes{% endtrans %}**
+
+- {% trans %}Build: Git migration{% endtrans %}
+- {% trans %}Build: Move web resources to wars{% endtrans %}
+- {% trans %}i2psnark WebSeed support{% endtrans %}
+- {% trans %}i2psnark padding file support{% endtrans %}
+- {% trans %}i2ptunnel: Move proxy resources to jar{% endtrans %}
+- {% trans %}Router: Redesign ECIES encryption for floodfills (proposal 156){% endtrans %}
+- {% trans %}Router: Verify RI stores after startup{% endtrans %}
+- {% trans %}Router: Reduce Sybil threshold{% endtrans %}
+- {% trans %}Router: ECIES for new routers{% endtrans %}
+- {% trans %}Router: Start of ECIES migration{% endtrans %}
+- {% trans %}SSU: Send individual fragments of messages{% endtrans %}
+- {% trans %}SSU: Westwood+ congestion control{% endtrans %}
+- {% trans %}SSU: Fast retransmit{% endtrans %}
+
+
+**{% trans %}Bug Fixes{% endtrans %}**
+
+- {% trans %}Build: Fix Gradle build{% endtrans %}
+- {% trans %}Crypto: Increase ratchet tag window to prevent message loss{% endtrans %}
+- {% trans %}I2CP: Fix encrypted leaseset combined with ECIES crypto or offline keys{% endtrans %}
+- {% trans %}i2ptunnel: Fix config file saving issues{% endtrans %}
+- {% trans %}Router: Fix leaseset request fails causing watchdog to bark{% endtrans %}
+- {% trans %}Router: Hidden mode fixes{% endtrans %}
+- {% trans %}SSU: Fix partial acks not being sent{% endtrans %}
+- {% trans %}SSU: Fix occasional high CPU usage{% endtrans %}
+
+
+**{% trans %}Other{% endtrans %}**
+
+- {% trans %}Crypto: AES performance improvements{% endtrans %}
+- {% trans %}DoH: Change to RFC 8484 style{% endtrans %}
+- {% trans %}i2ptunnel: Remove DSA shared clients{% endtrans %}
+- {% trans %}Proxy: Add jump servers{% endtrans %}
+- {% trans %}Router: Add more countries for hidden mode{% endtrans %}
+- {% trans %}Router: Tunnel peer selection changes{% endtrans %}
+- {% trans %}Router: Move Sybil subsystem from console to router for embedded use{% endtrans %}
+- {% trans %}Router: Verify RI stores for a while after startup{% endtrans %}
+- {% trans %}Util: New unit tests{% endtrans %}
+- {% trans %}Translation updates{% endtrans %}
+
+
+
+
+`{% trans %}Full list of fixed bugs{% endtrans %}`__
+
+__ http://{{ i2pconv('trac.i2p2.i2p') }}/query?resolution=fixed&milestone=0.9.49
+
+
+**{% trans %}SHA256 Checksums:{% endtrans %}**
+
+::
+
+      af4f022f3532b46dd341717fd08447007ca5217b6c88664be693cac7f71912ea  i2pinstall_0.9.49_windows.exe
+      1614da8703b43e5bdc55007c784f2c211d00650ae0308273605d2ddc321b807e  i2pinstall_0.9.49.jar
+      5164ffb6eab228b4082d203c691906faa9ff32f09f41c3cebe6d941e03b0b9f2  i2psource_0.9.49.tar.bz2
+      af685caf28c842be6589471ebe32fc6bd85ad3fc609f1f5e0fbcae69b5d2575f  i2pupdate_0.9.49.zip
+      f41a6b47d2ea6e1b0d87427a57bd99a3d7f971d57de39b425dbf5017fae156dc  i2pupdate.su3
+
+
+

i2p2www/blog/2021/05/17/0.9.50-Release.rst

@@ -0,0 +1,104 @@
+===========================================
+{% trans -%}0.9.50 Release{%- endtrans %}
+===========================================
+
+.. meta::
+   :author: zzz
+   :date: 2021-05-17
+   :category: release
+   :excerpt: {% trans %}0.9.50 with IPv6 fixes{% endtrans %}
+
+{% trans -%}
+Update details
+{%- endtrans %}
+============================================
+
+{% trans -%}
+0.9.50 continues the transition to ECIES-X25519 for router encryption keys.
+We have enabled DNS over HTTPS for reseeding to protect users from passive DNS snooping.
+There are numerous fixes and improvements for IPv6 addresses, including new UPnP support.
+{%- endtrans %}
+
+{% trans -%}
+We have finally fixed some longstanding SusiMail corruption bugs.
+Changes to the bandwidth limiter should improve network tunnel performance.
+There are several improvements in our Docker containers.
+We have improved our defenses for possible malicious and buggy routers in the network.
+{%- endtrans %}
+
+{% trans -%}
+As usual, we recommend that you update to this release. The best way to
+maintain security and help the network is to run the latest release.
+{%- endtrans %}
+
+
+**{% trans %}RELEASE DETAILS{% endtrans %}**
+
+**{% trans %}Changes{% endtrans %}**
+
+- {% trans %}Docker improvements{% endtrans %}
+- {% trans %}NTCP: Remove support for version 1{% endtrans %}
+- {% trans %}Reseed: Use DNSOverHTTPS{% endtrans %}
+- {% trans %}Router: Increase ECIES rekey probability{% endtrans %}
+- {% trans %}Router: Persist Sybil blocklist{% endtrans %}
+- {% trans %}SSU: Enable introducers and introductions via IPv6 (proposal 158){% endtrans %}
+- Tomcat 9.0.45
+- {% trans %}Transports: Publish support for outbound IPv4/v6 (proposal 158){% endtrans %}
+- {% trans %}UPnP: Add support for IPv6{% endtrans %}
+
+
+
+**{% trans %}Bug Fixes{% endtrans %}**
+
+- {% trans %}Debian: Fix link to compiler jar{% endtrans %}
+- {% trans %}i2psnark: Fix theme selection{% endtrans %}
+- {% trans %}Jetty: Fix detection of SSL connector{% endtrans %}
+- {% trans %}NetDB: Fix NPE when validating expired blinded leaseset{% endtrans %}
+- {% trans %}NTP: Year 2036 fixes{% endtrans %}
+- {% trans %}Router: Fix rekeying every restart on ARM{% endtrans %}
+- {% trans %}Router: Fix decryption of encrypted leasesets{% endtrans %}
+- {% trans %}SAM: Fix removal of subsessions{% endtrans %}
+- {% trans %}SSU: Fix excessive dropping by the bandwidth limiter{% endtrans %}
+- {% trans %}SSU: Fix publishing 'C' capability when not an introducer{% endtrans %}
+- {% trans %}SSU: Fixes for firewalled/not firewalled state transitions{% endtrans %}
+- {% trans %}SSU: IPv6 fixes{% endtrans %}
+- {% trans %}SSU: Peer test fixes{% endtrans %}
+- {% trans %}SusiMail: Fix theme selection{% endtrans %}
+- {% trans %}SusiMail: Fix stream closed errors{% endtrans %}
+- {% trans %}SusiMail: Fix corruption in display of large, new messages{% endtrans %}
+- {% trans %}Tunnels: Several fixes in the participating tunnel bandwidth limiter{% endtrans %}
+- {% trans %}UPnP: Fix leases not being renewed before expiration{% endtrans %}
+
+
+
+**{% trans %}Other{% endtrans %}**
+
+- {% trans %}Build: Remove empty jars and wars from installers{% endtrans %}
+- {% trans %}Build: Prep for different release and API versions{% endtrans %}
+- {% trans %}Build: Remove launcher code{% endtrans %}
+- {% trans %}Gradle build fixes{% endtrans %}
+- {% trans %}Profiles: Disable tunnel peer test{% endtrans %}
+- {% trans %}Profiles: Remove unused tunnel test response time stat{% endtrans %}
+- {% trans %}SSU: Avoid outbound connections to buggy routers{% endtrans %}
+- {% trans %}Transports: Increase connection limits for some platforms{% endtrans %}
+- {% trans %}Translation updates{% endtrans %}
+
+
+
+
+`{% trans %}Full list of fixed bugs{% endtrans %}`__
+
+__ http://{{ i2pconv('trac.i2p2.i2p') }}/query?resolution=fixed&milestone=0.9.50
+
+
+**{% trans %}SHA256 Checksums:{% endtrans %}**
+
+::
+
+     92e38abf0650671e08460dd25711afa67f7933a0b6fa655cbd2746662f06fb30  i2pinstall_0.9.50_windows.exe
+     34902d2a7e678fda9261d489ab315661bd2915b9d0d81165acdee008d9031430  i2pinstall_0.9.50.jar
+     66d32b3fd29fb5d68c1cbfdcf2ee74a671ebb359cdc697260291f12e441d94ff  i2psource_0.9.50.tar.bz2
+     c32e9472e25b5d086198dba8e555604a12593ec92be987565b2fc5efa5ce3a7f  i2pupdate_0.9.50.zip
+     400e342a46a4ef76948e5118ce4005f7b03dd22424acb407f42d99f0bf581352  i2pupdate.su3
+
+

i2p2www/blog/2021/08/23/1.5.0-Release.rst

@@ -0,0 +1,74 @@
+===========================================
+{% trans -%}1.5.0 Release{%- endtrans %}
+===========================================
+
+.. meta::
+   :author: zzz
+   :date: 2021-08-23
+   :category: release
+   :excerpt: {% trans %}1.5.0 with new tunnel build messages{% endtrans %}
+
+{% trans -%}
+Update details
+{%- endtrans %}
+============================================
+
+{% trans -%}
+Yes, that's right, after 9 years of 0.9.x releases, we are going straight from 0.9.50 to 1.5.0.
+This does not signify a major API change, or a claim that development is now complete.
+It is simply a recognition of almost 20 years of work to provide anonymity and security for our users.
+{%- endtrans %}
+
+{% trans -%}
+This release finishes implementation of smaller tunnel build messages to reduce bandwidth.
+We continue the transition of the network's routers to X25519 encryption.
+Of course there are also numerous bug fixes and performance improvements.
+{%- endtrans %}
+
+{% trans -%}
+As usual, we recommend that you update to this release. The best way to
+maintain security and help the network is to run the latest release.
+{%- endtrans %}
+
+
+**{% trans %}RELEASE DETAILS{% endtrans %}**
+
+**{% trans %}Changes{% endtrans %}**
+
+- RRD4J 3.8
+- {% trans %}Tunnels: Finish support for new build messages (proposal 157){% endtrans %}
+- {% trans %}Updates: Support for .dmg and .exe updates{% endtrans %}
+
+
+**{% trans %}Bug Fixes{% endtrans %}**
+
+- {% trans %}Console: Fix generation of SSL keys on Java 17{% endtrans %}
+- {% trans %}i2psnark: Fix autostart for magnets{% endtrans %}
+- {% trans %}Router: Fix rare deadlock in publishing our RI{% endtrans %}
+- {% trans %}SSU: Fix handling of bad peer test responses{% endtrans %}
+- {% trans %}UPnP: IPv6 fixes{% endtrans %}
+
+
+**{% trans %}Other{% endtrans %}**
+
+- {% trans %}Jetty: Improve sort in directory listings{% endtrans %}
+- {% trans %}Jetty: Add X-I2P-Location header{% endtrans %}
+- {% trans %}Router: Increase probability to rekey to ECIES{% endtrans %}
+- {% trans %}Streaming: Performance improvements for low-latency connections{% endtrans %}
+- {% trans %}Translation updates{% endtrans %}
+
+
+`{% trans %}Full list of fixed bugs{% endtrans %}`__
+
+__ http://{{ i2pconv('trac.i2p2.i2p') }}/query?resolution=fixed&milestone=1.5.0
+
+
+**{% trans %}SHA256 Checksums:{% endtrans %}**
+
+::
+
+     2c9c382852e17e124d77a2bf28f95056599fd458f8de77adcf8e2aaa22b3ef81  i2pinstall_1.5.0_windows.exe
+     8c843c90870223b4808065761d059a02b168b74daddd1773c36f0a0245e201f9  i2pinstall_1.5.0.jar
+     26e5f4d95b1a0766870f97b30e57c9a8e98690279c3bf09198e30effabecc450  i2psource_1.5.0.tar.bz2
+     ea1b4b8095f4d6f5568ce879242e1d5b077de1beb4366f4a75a75cffd559ee7f  i2pupdate_1.5.0.zip
+     5d4812278350ce80f3a718f40698afc7f20f0808ef1e2ff56432ab0c2891134c  i2pupdate.su3

i2p2www/blog/2021/08/26/20-Years-of-I2P.rst

@@ -0,0 +1,104 @@
+===========================================
+{% trans -%}I2P Celebrates its 20th Year{%- endtrans %}
+===========================================
+
+.. meta::
+   :author: idk
+   :date: 2021-08-26
+   :category: general
+   :excerpt: {% trans %}I2P has been around for 20 years, let's take a look back{% endtrans %}
+
+{% trans -%}
+20 Years of I2P
+{%- endtrans %}
+============================================
+
+{% trans -%}
+It's hard to believe, but I2P has been around for nearly 20 years! From its
+beginning as a C project which provided anonymous access to IRC, we've had
+hundreds of contributors, accepted checkins from dozens of coders, used 2
+main languages, 3 version control systems, experienced a migration of its
+crypography, and multiple soft-forks. There have been around 500 registered
+sites on the Invisible Web, and countless unregistered I2P sites that were only
+accessible via their cryptographic hostnames.
+{%- endtrans %}
+
+{% trans -%}
+Thanks to the participation of users like you, the network has grown from a tiny
+group of power users to over 75,000 nodes operated from all over the world,
+made of I2P routers bundled in perhaps dozens of applications. Today I2P is
+available in on Windows, Mac OSX, Linux, and has ports for FreeBSD, OpenBSD, and
+many other systems. I2P can run on phones and even in SOHO routers (thanks to the
+independent C++ implementation of the protocol, i2pd).
+{%- endtrans %}
+
+{% trans -%}
+A Routing Protocol with Flagship Applications
+{%- endtrans %}
+---------------------------------------------
+
+{% trans -%}
+Even before other anonymity projects were providing their own application
+bundles, I2P was a tool for building applications that were configured for
+anonymity. Over the years, we've leaned on this strength, by expanding our
+APIs to support more and more versatile applications. Today, we're still
+developing new ways of building I2P into applications.
+{%- endtrans %}
+
+{% trans -%}
+Using the power of the Hidden Services Manager or the SAM API, developers of all
+kinds of applications can empower their users with anonymity using I2P. Exciting
+downstream projects like Monero's I2P-Zero have made it very easy for developers
+to help their users get connected to I2P. Today, I2P helps provide anonymity to
+dozens of applications including Bitcoin, IRC, email and multiple file-sharing
+protocols.
+{%- endtrans %}
+
+{% trans -%}
+An Anonymous Network By Everyone, For Everyone
+{%- endtrans %}
+----------------------------------------------
+
+{% trans -%}
+I2P has always been a decentralized network, because its obvious that providing
+an anonymity network is an intrinsically collaborative process. To illustrate
+with the most extreme example, a single computer cannot provide itself
+with anonymity, nor can it be a useful network, by definiton. However, building
+I2P in this fully-decentralized manner hasn't always been easy.
+{%- endtrans %}
+
+{% trans -%}
+From the beginning, I2P would need to be scalable, and be able to balance itself
+so that  high-bandwidth nodes wouldn't be able to easily take over the network.
+Sybil attacks would leave the realm of academia and we would need to develop
+new defenses against them.
+{%- endtrans %}
+
+{% trans -%}
+We've worked very hard to never compromise on this stance, and today every I2P
+router helps participate in providing the network with bandwidth resources and
+providing the users with anonymity. In doing so, we've learned incredible things
+and produced a network which at times has seemed inconceivable.
+{%- endtrans %}
+
+{% trans -%}
+Celebrating I2P
+{%- endtrans %}
+---------------
+
+{% trans -%}
+Over the next 2 weeks, we've planned some blog posts where we'll explore the past,
+present, and future of I2P, highlight applications and tools that build on
+and enhance I2P, and showcase the best of our community. Check back here for
+more in the coming days!
+{%- endtrans %}
+
+* {% trans -%}`The History of I2P
+  </en/blog/post/2021/08/28/History-of-I2P>`_{%- endtrans %}
+* {% trans -%}`Dependency-Free I2P of the Future - Jpackage Bundles and I2P-Zero (from Monero)
+  </en/blog/post/2021/09/08/I2P-Jpackage-Bundles-and-Zero>`_{%- endtrans %}
+* {% trans -%}`Level-Up your I2P use with Encrypted LeaseSets
+  </en/blog/post/2021/09/07/Level-Up-Encrypted-Leasesets>`_{%- endtrans %}
+* {% trans -%}Dividing the Triangle: How I2P Eases Naming and Increases Flexibility for End-Users{%- endtrans %}
+* {% trans -%}I2P's Usability Journey{%- endtrans %}
+* {% trans -%}Building Bridges - Making Connections with Other Privacy Projects{%- endtrans %}

i2p2www/blog/2021/08/28/History-of-I2P.rst

@@ -0,0 +1,510 @@
+===========================================================
+{% trans -%}20 Years of Privacy: A brief History of I2P{%- endtrans %}
+===========================================================
+
+.. meta::
+    :author: sadie
+    :date: 2021-08-28
+    :category: general
+    :excerpt: {% trans %}A history of I2P As We Know It{% endtrans %}
+
+{% trans -%}
+Invisibility is the best defense: building an internet within an internet
+{%- endtrans %}
+-------------------------------------------------------------------------
+
+    {% trans -%}I believe most people want this technology so they can express
+    themselves freely. It’s a comfortable feeling when you know you can
+    do that. At the same time we can conquer some of the problems seen
+    within the Internet by changing the way security and privacy is
+    viewed, as well as the extent to what it is valued.{%- endtrans %}
+
+
+{% trans -%}In October 2001, 0x90 ( Lance James) had a dream. It started as a
+“desire for instant communication with other Freenet users to talk about
+Freenet issues, and exchange Freenet keys while still maintaining
+anonymity, privacy and security.” It was called IIP — the Invisible IRC
+Project.{%- endtrans %}
+
+.. compound::
+  .. image:: /_static/images/history/invisibleirc_banner.png
+    :width: 100%
+  .. image:: /_static/images/history/invisibleirc.png
+    :width: 100%
+
+{% trans -%}The Invisible IRC Project was based on an ideal and framework behind The
+InvisibleNet:{%- endtrans %}
+
+{% trans -%}In an interview from 2002, 0x90 described the project:{%- endtrans %}
+
+    {% trans -%}“InvisibleNet is a research & development driven organization whose main
+    focus is the innovation of intelligent network technology. Our goal is
+    to provide the highest standards in security and privacy on the widely
+    used, yet notoriously insecure Internet."{%- endtrans %}
+
+    {% trans -%}"The InvisibleNet team is comprised of a talented group of developers and
+    architects entirely dedicated to providing its users with both
+    convenience and the very best in secure communication."{%- endtrans %}
+
+    {% trans -%}"Our technological ideals are reflected in the implementation of a
+    framework that is solid in design, and transparent in its application."{%- endtrans %}
+
+    {% trans -%}"Here at InvisibleNet we strive towards the greatest level of quality
+    possible by keeping all areas of our research & development open and
+    available to the public for peer review, feedback, suggestions and new
+    ideas.”{%- endtrans %}
+
+    {% trans -%}"The Invisible Internet Project: Defined as the “New Internet”.
+    Peer 2 Peer Internet. Using your peers to protect you. It is a
+    similar concept to the Invisible IRC Project, with its design as our
+    test model. We plan to re-design the Internet by taking it a step
+    further and having security and privacy be first priority."{%- endtrans %}
+
+    {% trans -%}"The Invisible Internet Project or Protocol will be utilizing the
+    tests and research/development concepts of the Invisible IRC Project
+    to give us the scalability that we need and leverage this to take it
+    to the next level."{%- endtrans %}
+
+    {% trans -%}"This, in essence will be an impenetrable neural-network, that is
+    self-driven, self-defensed, and completely seamless to already
+    applied protocols, specifically client to server (or agents as I call
+    them). It will be THE next transport layer, a layer on top of the
+    notoriously insecure Internet, to deliver full anonymity, privacy,
+    and security at the highest level possible. Decentralized and peer to
+    peer Internet, by the way, means no more worrying about your ISP
+    controlling your traffic. This will allow you to do seamless
+    activities and change the way we look at security and even the
+    Internet, utilizing public key cryptography, IP steganography, and
+    message authentication. The Internet that should have been, will be
+    soon."{%- endtrans %}
+
+.. compound::
+  .. image:: /_static/images/history/invisiblenet.png
+     :width: 100%
+
+| {% trans -%}All citations and quotes are from the interviews found here:{%- endtrans %}
+| http://invisibleip.sourceforge.net/iip/mediaDCInterview1.php
+| http://invisibleip.sourceforge.net/iip/mediaDCInterview2.php
+| http://invisibleip.sourceforge.net/index.php
+
+{% trans -%}By 2003, several other similar projects had started, the largest being
+Freenet, GNUNet, and Tor. All of these projects had broad goals to
+encrypt and anonymize a variety of traffic. For IIP, it became clear
+that IRC alone was not a big-enough target. What was needed was an
+anonymizing layer for all protocols. IIP by now was also being called
+“InvisibleNet”.{%- endtrans %}
+
+{% trans -%}In early 2003, a new anonymous developer, “jrandom” joined the project.
+His explicit goal was to broaden the charter of IIP.{%- endtrans %}
+
+{% trans -%}jrandom wished to rewrite the IIP code base in Java, a language he was
+familiar with, and the same language Freenet was using. He also wished
+to redesign the IIP protocols based on recent papers and the early
+design decisions that Tor and Freenet were making. Some of these
+concepts and naming conventions, such as “onion routing”, were modified
+to become “garlic routing”. For several of the design decisions, jrandom
+made different choices than Tor did, including selecting different
+cryptographic primitives in a number of places. Many (but not all) of
+these choices turned out quite well. For some others, such as using
+unidirectional tunnels rather than Tor’s bidirectional tunnels, the
+benefits and trade-offs are still not well-studied.{%- endtrans %}
+
+{% trans -%}jrandom also set out a clear vision for the architecture of the code. It
+would be a client/server model, with the server (i.e. the router)
+isolated from any “client” protocols. Clients such as web browsers, web
+servers, IRC clients and servers, and others, would communicate through
+the router using I2CP, the I2P Client Protocol.{%- endtrans %}
+
+{% trans -%}jrandom also had strong opinions on the direction of the project and its
+philosophy. He was strongly committed to open source and free software.
+He explicitly set a goal of protection from organizations with
+“unlimited financial and political resources.”{%- endtrans %}
+
+{% trans -%}By late summer 2003, jrandom had taken control of the project, and
+renamed it the Invisible Internet Project or “I2P”. He published a
+document outlining the philosophy of the project, and placed its
+technical goals and design in the context of mixnets and anonymizing
+layers. He also published the specification of two protocols (I2CP and
+I2NP) and their underlying data structures, that formed the basis of the
+network I2P uses today. Lance (“nop”) was last seen in a project meeting
+on November 11, 2003.{%- endtrans %}
+
+.. image:: /_static/images/history/bw1.png
+
+https://www.bloomberg.com/news/articles/2003-09-14/the-underground-internet
+
+.. image:: /_static/images/history/bw2.png
+
+{% trans -%}By fall 2003, I2P, Freenet, and Tor were rapidly developing. Business
+Week published an article on “The Underground Internet” which referenced
+InvisibleNet and discussed “darknets” extensively. jrandom released I2P
+version 0.2 on November 1, 2003, and continued rapid releases for the
+next 3 years. He maintained regular weekly meetings and status notes
+during this time. Several popular services and “respites” emerged during
+this time. Auto updates via clearnet HTTP became available in 2004.{%- endtrans %}
+
+{% trans -%}Through 2004 and 2005, router development continued, and several
+“clients” or applications were added to the I2P package. “Mihi” wrote
+the first streaming protocol implementation and the i2ptunnel interface
+for configuring and starting client tunnels. “Susi” wrote the web mail
+and address book applications SusiMail and SusiDNS. Many people worked
+on the router console web interface. A bridge to make it easier for
+non-I2P clients to communicate over I2P, called “SAM” (Simple Anonymous
+Messaging) was added.{%- endtrans %}
+
+| {% trans -%}In February 2005, zzz installed I2P for the first time.{%- endtrans %}
+| {% trans -%}Anonymity projects were in the news. After surveying the field, he
+  installed Freenet, and found it ambiguous, and difficult to explore.
+  Not only that, it was very resource heavy and it was difficult to get
+  anything to load. Tor and I2P were the other options, and he tried
+  I2P.{% endtrans %}
+
+{% trans -%}zzz had no preconceived plans to contribute to the project, and had
+never written a line of Java. He had maybe used IRC once. At this time,
+I2P was at version 0.5, with maybe a thousand users and three hard-coded
+floodfills. Forum.i2p and postman’s tracker were up and running at the
+time, and weekly meetings and status notes, and releases every couple of
+week were happening.{%- endtrans %}
+
+{% trans -%}By summer 2005, zzz had set up two websites. The first was zzz.i2p,
+which over the years became a central resource for I2P development, and
+still is. The second was stats.i2p, the first site to gather statistics
+on I2P network performance and present graphs on both the network and
+individual routers. While the individual router statistics eventually
+had to be shut down due to the tremendous growth of the network, the
+overall performance graphs remain. We are not sure that he ever planned
+to become the release manger for almost 2 decades, but we are happy he
+did. The project has not only stayed active, it has thrived and scaled
+to the demands of its growth.{%- endtrans %}
+
+.. compound::
+  .. image:: /_static/images/history/statsi2p.png
+     :width: 100%
+
+{% trans -%}On July 27, 2005, jrandom released I2P version 0.6, including an
+innovative new UDP transport protocol he designed called “SSU”, for
+Secure Semi-reliable UDP. It contained features for IP discovery and
+firewall traversal.{%- endtrans %}
+
+{% trans -%}In September 2005, jrandom bundled “Syndie”, his new high-latency
+anonymous messaging system. In October 2005, jrandom ported Snark, a
+Java BitTorrent client, to become an I2P application and bundled it with
+the I2P package. This completed the collection of client applications
+that are still bundled with I2P today.{%- endtrans %}
+
+{% trans -%}In late 2005 and early 2006, jrandom redesigned the way that I2P built
+tunnels. This was a major effort that was done to increase the security
+of the tunnel building, which is crucial to maintain anonymity and
+resist attacks. He worked closely with the Freenet developers, including
+“Toad”, on this design. The new build protocol required new I2NP
+messages and a hard cut-over or “flag day”. These changes were released
+in version 0.6.1.10 on February 16, 2006. This is significant as it is
+the last flag day I2P has had. While, in practice, an 0.6.1.10 router
+would not work well, if at all, in today’s network, we are, technically
+speaking, backwards-compatible with this ten-year-old version today.{%- endtrans %}
+
+{% trans -%}By early 2006, the I2P software was at least feature-complete, but it
+was still not widely-known. jrandom’s view was that it shouldn’t be
+marketed publicly until it was near-perfect, and labeled as version 1.0.
+The network had perhaps a thousand users at the time. Project members
+were discouraged from talking about it online, and the website
+(`i2p.net <http://i2p.net>`__) was unpolished and incomplete.{%- endtrans %}
+
+{% trans -%}On July 27, 2006, jrandom released I2P version 0.6.1.23, including an
+innovative new TCP transport protocol he designed called “NTCP”, for
+new-IO-based TCP. It used Java’s new IO library for efficient handling
+of large numbers of TCP connections.{%- endtrans %}
+
+{% trans -%}In late 2006, jrandom turned his focus to Syndie. He came to see it as
+his top priority, and the “killer application” for I2P. Highly secure
+and almost unusable, it delayed messages for up to two days before
+delivery to resist traffic analysis. Later in 2006, he stopped work on
+the bundled Syndie application and started a new, incompatible,
+standalone messaging application. This application was, confusingly,
+also called “Syndie”. The new Syndie was a large and complex
+development, and it was essentially a one-man project.{%- endtrans %}
+
+{% trans -%}From late 2006 into 2007, core I2P development and releases slowed
+dramatically. From almost 30 releases in 2005 and 13 in the first half
+of 2006, there were only 5 in the second half of 2006 and only 4 in all
+of 2007. During this time, zzz and a developer named Complication had
+source code commit privileges and were making changes, but their
+understanding of the code base was limited. zzz worked, for example, on
+improving i2psnark, fixing bugs, and redesigning the strategy for
+anticipatory tunnel building. But there was a lot more that needed to be
+done. Complication and zzz did what they could, and they wrote the code
+for almost all the changes in the four 2007 releases
+(0.6.1.27–0.6.1.30). By this time, jrandom was providing very little
+guidance, code review, or direction for the project.{%- endtrans %}
+
+{% trans -%}It wasn’t apparent at the time, but the project was in trouble.{%- endtrans %}
+
+{% trans -%}jrandom had almost stopped working on the core I2P router and
+applications. Even the new Syndie, which he had declared as far more
+important than I2P itself, languished. After regular releases through
+March 2007, his next Syndie release, 1.100a, was August 25, 2007. All
+I2P releases were required to be signed by jrandom’s key, and he built
+and signed his last release, 0.6.1.30, on October 7, 2007.{%- endtrans %}
+
+{% trans -%}In November 2007, disaster struck. Complication and zzz received a
+cryptic message from jrandom, that he would have to take time off from
+both Syndie and I2P development for a year or more. He expected that he
+would still be available to sign releases, but was willing to pass the
+release signing key to somebody else. Complication and zzz immediately
+replied with a request for the release key and other credentials, such
+as access to the website, mailing list, CVS administration, and others.
+Unfortunately, they never heard from jrandom again.{%- endtrans %}
+
+{% trans -%}Late 2007 and early 2008, they awaited jrandom’s response, and wondered
+what to do next. However, all of the project infrastructure remained
+active, so it didn’t seem to be an immediate crisis. They knew, however,
+that without the release key or website access, they would have to sign
+with new keys, host the files on a new website, and require everybody to
+manually update since their keys wouldn’t be recognized.{%- endtrans %}
+
+{% trans -%}The second stage of the disaster happened on January 13, 2008. The
+hosting company for almost all `i2p.net <http://i2p.net>`__ servers
+suffered a power outage, and they did not fully return to service. Only
+jrandom had the credentials required to restore service. In addition,
+the centralized CVS source control appeared to be down, so five years of
+source control history appeared to be lost. Luckily, the CVS server was
+up, only the name server for it was down. The full contents of the CVS
+archive was quickly downloaded.{%- endtrans %}
+
+| {% trans -%}Complication, welterde, and zzz quickly made a number of decisions to
+  get the project back up and running. Welterde started a new website at
+  `i2p2.de <http://i2p2.de>`__. I2P needed to move to a decentralized
+  source code control system. They tested bazaar and that did not work
+  well over I2P. Git was just getting started. jrandom had used monotone
+  for Syndie and liked its security properties, and it worked well over
+  I2P, so it was selected.{%- endtrans %}
+| {% trans -%}Several people set up new services. The next release, 0.6.1.31, was
+  signed by Complication and required a manual upgrade. It was released
+  on February 10, 2008.{%- endtrans %}
+
+{% trans -%}The project realized that even though it claimed to be totally
+decentralized, it actually depended on a number of centralized
+resources, above all, on jrandom. Work was done throughout 2008 to
+decentralize the project, and distribute roles to a number of people.
+Additionally, it was realized that development had essentially stalled
+in 2007, because jrandom had stopped working on it, but had not
+delegated to other developers. Nobody had an overall understanding of
+the code base.{%- endtrans %}
+
+{% trans -%}Complication continued to sign the releases through mid-2009, but his
+contributions declined as he focused on activism and other projects.
+Starting with release 0.7.6 on July 31, 2009, zzz would sign the next 49
+releases.{%- endtrans %}
+
+{% trans -%}In December 2008, zzz attended his first CCC, 25C3 in Berlin, and met
+other I2P project team members for the first time, including hottuna and
+welterde. The experience was overwhelming, and also humbling, as he
+struggled to explain I2P to others or answer even basic questions about
+its design and use of cryptography.{%- endtrans %}
+
+{% trans -%}By mid-2009, zzz had come to understand the code base much better. Far
+from being complete or perfect, it was filled with problems and
+scalability issues. In 2009 the project experienced more network growth
+due to its anonymizing properties as well as its circumvention
+abilities. Participants appeared who were beginning to adopt the network
+for reasons like censorship and clearnet issues like blocking of popular
+services. For development gains, in-net auto updates became available
+for the software.{%- endtrans %}
+
+.. image:: /_static/images/history/propaganda.jpeg
+
+{% trans -%}July 2010 zzz briefly presented I2P at the end of Adrian Hong’s
+presentation at HOPE XXXX. Adrian talked about how tech has helped
+expose human rights violations, and the need for defensive tools for
+activists. He urged that we all be ambassadors for all tech, stay on top
+of new tech, and keep the barrier low and educate people about how to
+use the tool we create.{%- endtrans %}
+
+{% trans -%}He also talked about how we need many options for people to use, and
+asked how do we make it easier to support human rights, freedom of
+expression?{%- endtrans %}
+
+{% trans -%}At the end of the talk, zzz was invited on stage to introduce I2P and
+give an overview of what the project was about. The same weekend, it was
+pointed out that the I2P documentation was not in great shape.{%- endtrans %}
+
+{% trans -%}In Fall 2010, zzz declared a moratorium on I2P development until the
+website documentation was complete and accurate. It took 3 months to get
+it done.{%- endtrans %}
+
+{% trans -%}Beginning in 2010, until COVID restrictions were put in place, zzz, ech,
+hottuna, and other I2P contributors have attended CCC ( Chaos
+Communications Congress) every year. Over the years, meeh, Zab, Sadie,
+LazyGravy, KYTV, IDK and others have made the trip to Germany to share
+tables with other projects and celebrate the end of a year of releases.
+The project looks forward to one day being able to meet up again and
+have an in-person yearly roadmap meeting.{%- endtrans %}
+
+{% trans -%}Anoncoin, a digital cryptocurrency that focuses on privacy and anonymity
+for its users was created in 2013. It was the first coin that provided
+built-in support for I2P, as well as Tor that makes it impossible to
+determine the IP address of the user. The developers, including meeh,
+also ran organizations like Privacy Solutions, and provided infrastructure
+support to the I2P network by running services like outproxies and
+reseed servers.{%- endtrans %}
+
+{% trans -%}I2PBote development started to take off again in 2014 when str4d began
+contributing to the project. Bote is a server-less email client — it
+stores email in a `distributed hash
+table <http://en.wikipedia.org/wiki/Distributed_hash_table>`__. Email is
+“automatically encrypted and digitally signed, which ensures no one but
+the intended recipient can read the email, and third parties cannot
+forge them.” ( https://i2pbote.xyz/). The project has existed since
+2009.{%- endtrans %}
+
+.. compound::
+  .. image:: /_static/images/history/bote.png
+     :width: 100%
+
+> I2PBote screenshot Credit: AceBarry
+
+{% trans -%}At Real World Crypto that year, zzz, psi and str4d began to talk about
+and review the plan to update I2P’s cryptography. The same year, the
+project was awarded a $5k donation from Duck Duck Go. Lavabit,
+SecureDrop, RiseUp and Mailpile also received donations for supporting
+better trust and privacy online.{%- endtrans %}
+
+{% trans -%}By late 2014 most new signing crypto was complete, including ECDSA and
+EdDSA. New destination crypto was available; but new router info crypto
+needed to wait a year for the network to upgrade sufficiently.{%- endtrans %}
+
+{% trans -%}During the early part of 2015, zzz posted to Twitter that it would be
+great to have a mini conference for I2P. In Spring, it was decided that
+I2PCon would take place that August over the course of a weekend.{%- endtrans %}
+
+{% trans -%}Hottuna and Sadie organized most of the details, getting graphic assets
+created, posters printed and a banner made for the podium. Nick at
+Hacklab, where the event would take place, helped with making sure the
+space was ready for the event. Sadie reached out to the local infosec
+community and helped secure guest speakers as well. The event happened
+on one of the hottest weekends of the Summer, with attendees arriving
+from America and Europe. The I2P community did an amazing job of
+supporting the event by postering, giving talks, and spreading the word
+in forums and on social media. The talks can be viewed on KYTV’s YouTube
+Channel https://www.youtube.com/channel/UCZfD2Dk6POE-VU8DOqW7VVw{%- endtrans %}
+
+.. compound::
+  .. image:: /_static/images/history/i2pcon1.png
+     :width: 100%
+
+{% trans -%}In January 2016 at Real World Crypto Stanford — str4d gave a talk on the
+crypto migration progress and future plans for the project. zzz and
+others would continue weekly meetings to plan the migration over the
+next few years.{%- endtrans %}
+
+{% trans -%}NTCP2 was implemented in 2018, in release 0.9.36. It was disabled by
+default so that it could be tested. It was enabled in 0.9.37. NTCP1 was
+disabled in 0.9.40.{%- endtrans %}
+
+    {% trans -%}The new I2P transport protocol provides effective resistance against
+    DPI censorship. It also results in reduced CPU load because of the
+    faster, modern cryptography used. It makes I2P more likely to run on
+    low-end devices, such as smartphones and home routers. Both major I2P
+    implementations have full support for NTCP2 and it make NTCP2
+    available for use starting with version 0.9.36 (Java) and 2.20 (i2pd,
+    C++).{%- endtrans %}
+
+{% trans -%}The complete implementation details can be read here
+https://geti2p.net/en/blog/post/2018/08/20/NTCP2{%- endtrans %}
+
+{% trans -%}0.9.39 included extensive changes for new network database types
+(proposal 123). The i2pcontrol plugin was bundled as a web-app to support
+development of RPC applications.{%- endtrans %}
+
+{% trans -%}In 2019, the team decided to attend more conferences. That year IDK and
+zzz attended DefCon, and IDK gave a workshop on I2P application
+development. At Monero Village, zzz gave a talk called I2P for
+Cryptocurrency Developers.{%- endtrans %}
+
+{% trans -%}Late that year, Sadie and IDK attended Our Networks in Toronto, where
+IDK gave a lightning talk about I2P.{%- endtrans %}
+
+{% trans -%}Sadie attended RightsCon in Tunis and the Internet Freedom Festival in
+Valencia to meet with NGO’s and Human Right Defenders. Thanks to the the
+connections we made, the project received grants for usability and
+accessibility support from Open Tech Fund, and most recently Internews.
+This will ensure more user friendly onboarding, UX, and information
+architecture improvements to support the growing interest in the
+network. It will also support specific tooling to help in-need users
+with specific risk surfaces through user research.{%- endtrans %}
+
+.. image:: /_static/images/history/phong.png
+
+{% trans -%}That Summer, Hoàng Nguyên Phong had his research into I2P censorship
+accepted too FOCI at USENIX in Santa Clara. Sadie had supported the
+research and they attended together. I2P Metrics was created during this
+time https://i2p-metrics.np-tokumei.net/, and well as research into more
+resistant reseed servers for the I2P network
+https://homepage.np-tokumei.net/post/notes-i2p-reseed-over-cloudflare/.
+You can read the research report here
+https://homepage.np-tokumei.net/post/notes-otf-wrapup-blogpost/.{%- endtrans %}
+
+{% trans -%}At CCC that year, the decision was made to migrate from Monotone too
+GitLab. The project was one of the last to use Monotone, and it was time
+to prepare to move on. IDK would spend 2020 ensuring the process was as
+smooth as it could be. The pandemic would result in the team not being
+able to see each other that year to celebrate the ( mostly) smooth move
+to Gitlab. On December 10. 2020, the project switched off the old mtn
+i2p.i2p branch, and moved the development of the core Java I2P libraries
+from Monotone to Git officially.{%- endtrans %}
+
+    {% trans -%}Congratulations and thanks to everyone who helped in the git
+    migration, especially zzz, eche|on, nextloop, and our site mirror
+    operators! While some of us will miss Monotone, it has become a
+    barrier for new and existing participants in I2P development and
+    we’re excited to join the world of developers using Git to manage
+    their distributed projects.{%- endtrans %}
+
+https://geti2p.net/en/blog/post/2020/12/10/Hello-git-goodbye-mtn
+
+{% trans -%}0.9.47 enabled the new end-to-end encryption protocol (proposal 144) by
+default for some services. A Sybil analysis and blocking tool was also
+now enabled by default. 0.9.48 enabled the new end-to-end encryption
+protocol (proposal 144) for most services. Preliminary support was added
+for new tunnel build message encryption (proposal 152). There were
+significant performance improvements throughout the router.{%- endtrans %}
+
+{% trans -%}0.9.49 was the release that brought faster crypto. The I2P network
+became faster and more secure. Improvements and fixes for the SSU (UDP)
+transport resulted in faster speeds. The release also started the
+migration to new, faster ECIES-X25519 encryption for routers. The
+project had been working on the specifications and protocols for new
+encryption for several years, and was getting close to the end of it.
+The migration would take several releases to complete.{%- endtrans %}
+
+{% trans -%}To minimize disruption, only new installs and a very small percentage of
+existing installs (randomly selected at restart) would be using the new
+encryption.{%- endtrans %}
+
+{% trans -%}The project had “rekeyed” the network twice before, when changing the
+default signature type, but this was the first time it had changed the
+default encryption type. 0.9.50 enabled DNS over HTTPS for reseeding to
+protect users from passive DNS snooping. There were numerous fixes and
+improvements for IPv6 addresses, including new UPnP support.{%- endtrans %}
+
+.. _31b4:
+
+{% trans -%}1.5.0 — The early anniversary release because it is so good!{%- endtrans %}
+------------------------------------------------------------
+
+    {% trans -%}Yes, that’s right, after 9 years of 0.9.x releases, we are going
+    straight from 0.9.50 to 1.5.0. This does not signify a major API
+    change, or a claim that development is now complete. It is simply a
+    recognition of almost 20 years of work to provide anonymity and
+    security for our users.{%- endtrans %}
+
+    {% trans -%}This release finishes implementation of smaller tunnel build messages
+    to reduce bandwidth. We continue the transition of the network’s
+    routers to X25519 encryption. Of course there are also numerous bug
+    fixes and performance improvements.{%- endtrans %}
+
+    {% trans -%}As usual, we recommend that you update to this release. The best way
+    to maintain security and help the network is to run the latest
+    release.{%- endtrans %}
+
+{% trans -%}Congratulations team. Let’s do another 20.{%- endtrans %}

i2p2www/blog/2021/09/07/Level-Up-Encrypted-Leasesets.rst

@@ -0,0 +1,193 @@
+=============================================================
+{% trans -%}Level up your I2P Skills with Encrypted LeaseSets{%- endtrans %}
+=============================================================
+
+.. meta::
+   :author: idk
+   :date: 2021-09-07
+   :category: general
+   :excerpt: {% trans %}It has been said that I2P emphasizes Hidden Services, we examine one interpretation of this{% endtrans %}
+
+{% trans -%}
+Level up your I2P Skills with Encrypted LeaseSets
+{%- endtrans %}
+=================================================
+
+{% trans -%}
+It has been said in the past that I2P emphasizes support for Hidden Services,
+which is true in many ways. However, what this means to users, developers, and
+hidden service administrators isn't always the same. Encrypted LeaseSets and
+their use-cases provide a unique, practical window into how I2P makes hidden
+services more versatile, easier to administer, and how I2P extends on the
+Hidden Service concept to provide security benefits for potentially interesting
+use-cases.
+{%- endtrans %}
+
+{% trans -%}
+What is a LeaseSet?
+-------------------
+{%- endtrans %}
+
+{% trans -%}
+When you create a hidden service, you publish something called a "LeaseSet" to
+the I2P NetDB. The "LeaseSet" is, in the simplest terms, what other I2P users
+need to discover "where" your hidden service is on the I2P Network. It contains
+"Leases" which identify tunnels that can be used to reach your hidden service,
+and the public key of your destination, which clients will encrypt messages to.
+This type of hidden service is reachable by anyone who has the address, which
+is probably the most common use case for now.
+{%- endtrans %}
+
+{% trans -%}
+Sometimes, you might not want to allow your hidden services to be accessible by
+anyone, though. Some people use hidden services as a way of accessing an SSH
+server on a home PC, or to stitch together a network of IOT Devices. In these
+cases it's not necessary, and may be counter-productive, to make your hidden
+service accessible to everyone one the I2P Network. This is where "Encrypted
+LeaseSets" come into play.
+{%- endtrans %}
+
+{% trans -%}
+Encrypted LeaseSets: VERY Hidden Services
+------------------------------------------
+{%- endtrans %}
+
+{% trans -%}
+Encrypted LeaseSets are LeaseSets which are published to the NetDB in an
+encrypted form, where none of the Leases or public keys are visible unless
+the client has the keys required to decrypt the LeaseSet inside of it. Only
+clients you share keys with(For PSK Encrypted LeaseSets), or who share their
+keys with you(For DH Encrypted LeaseSets), will be able to see the destination
+and no one else.
+{%- endtrans %}
+
+{% trans -%}
+I2P Supports several strategies for Encrypted LeaseSets. The key characteristics
+of each strategy are important to understand when deciding which one to use. If
+an Encrypted LeaseSet uses a "Pre-Shared Key(PSK)" strategy, then the server
+will generate a key(or keys) which the server operator then shares with each
+client. Of course, this exchange must happen out-of-band, possibly via an
+exchange on IRC for example. This version of Encrypted LeaseSets is sort of
+like logging into Wi-Fi with a password. Except, what you're logging into is
+a Hidden Service.
+{%- endtrans %}
+
+{% trans -%}
+If an Encrypted LeaseSet uses a "Diffie-Hellman(DH)
+strategy, then they keys are generated on the client instead. When a
+Diffie-Hellman client connects to a destination with an Encrypted LeaseSet, they
+must first share their keys with the server operator. The server operator then
+decides whether to authorize the DH client. This version of Encrypted LeaseSets
+is sort of like SSH with an `authorized_keys` file. Except, what you're logging
+into is a Hidden Service.
+{%- endtrans %}
+
+{% trans -%}
+By Encrypting your LeaseSet, you not only make it impossible for unauthorized
+users to connect to your destination, you make it impossible for unauthorized
+visitors to even discover the real destination of the I2P Hidden Service. Some
+readers have probably already considered a use-case for their own Encrypted
+LeaseSet.
+{%- endtrans %}
+
+{% trans -%}
+Using Encrypted LeaseSets to Safely Access a Router Console
+-----------------------------------------------------------
+{%- endtrans %}
+
+{% trans -%}
+As a general rule, the more complex information a service has access to about
+your device, the more dangerous it is to expose that service to the Internet or
+indeed, to a Hidden Service network like I2P. If you want to expose such a
+service, you need to protect it with something like a password, or, in the case
+of I2P, a much more thorough and secure option could be an Encrypted LeaseSet.
+{%- endtrans %}
+
+{% trans -%}
+**Before continuing, please read and understand that if you do the following**
+**procedure without an Encrypted LeaseSet, you will be defeating the security of**
+**your I2P router. Do not configure access to your router console over I2P without**
+**an Encrypted LeaseSet. Additionally, do not share your Encrypted LeaseSet PSK's**
+**with any devices you do not control.**
+{%- endtrans %}
+
+{% trans -%}
+One such service which is useful to share over I2P, but ONLY with an Encrypted
+LeaseSet, is the I2P router console itself. Exposing the I2P router console on
+one machine to I2P with an Encrypted LeaseSet allows another machine with a
+browser to administer the remote I2P instance. I find this useful for remotely
+monitoring my regular I2P Services. It could also be used to monitor a server
+which is used to seed a torrent long-term as a way to access I2PSnark.
+{%- endtrans %}
+
+{% trans -%}
+For as long as it takes to explain them, setting up an Encrypted LeaseSet is
+straightforward to configure via the Hidden Services Manager UI. 
+{%- endtrans %}
+
+{% trans -%}
+On the "Server"
+---------------
+{%- endtrans %}
+
+.. compound::
+  .. image:: /_static/images/encryptls/newhs.png
+     :width: 100%
+
+{% trans -%}
+Start by opening the Hidden Services Manager at http://127.0.0.1:7657/i2ptunnelmgr
+and scroll to the bottom of the section that says "I2P Hidden Services." Create
+a new hidden service with the host "127.0.0.1" and the port "7657" with these
+"Tunnel Cryptography Options" and save the hidden service. 
+{%- endtrans %}
+
+.. compound::
+  .. image:: /_static/images/encryptls/demosettings.png
+     :width: 100%
+
+{% trans -%}
+Then, select your new tunnel from the Hidden Services Manager main page. The
+Tunnel Cryptography Options should now include your first Pre-Shared Key. Copy
+this down for the next step, along with the Encrypted Base32 Address of your
+tunnel.
+{%- endtrans %}
+
+.. compound::
+  .. image:: /_static/images/encryptls/demoresult.png
+     :width: 100%
+
+{% trans -%}
+On the "Client"
+---------------
+{%- endtrans %}
+
+{% trans -%}
+Now switch computers to the client which will connect to the hidden service,
+and visit the Keyring Configuration at http://127.0.0.1:7657/configkeyring to
+add the keys from earlier. Start by pasting the Base32 from the Server into
+the field labeled: "Full destination, name, Base32, or hash." Next, paste the
+Pre-Shared Key from the server into the "Encryption Key" field. Click save,
+and you're ready to securely visit the Hidden Service using an Encrypted
+LeaseSet.
+{%- endtrans %}
+
+.. compound::
+  .. image:: /_static/images/encryptls/client.png
+     :width: 100%
+
+{% trans -%}
+Now You're Ready to Remotely Administer I2P
+-------------------------------------------
+{%- endtrans %}
+
+{% trans -%}
+As you can see, I2P offers unique capabilities to Hidden Service Administrators
+which empower them to securely manage their I2P connections from anywhere in the
+world. Other Encrypted LeaseSets I keep on the same device for the same reason
+point to the SSH server, the Portainer instance I user to manage my service
+containers, and my personal NextCloud instance. With I2P, truly private, always
+reachable Self-Hosting is an achievable goal, in fact I think it's one of the
+things we're uniquely suited to, because of Encrypted LeaseSets. With them, I2P
+could become the key to securing self-hosted home automation or simply become
+the backbone of a new more private peer-to-peer web.
+{%- endtrans %}

i2p2www/blog/2021/09/15/i2p-jpackages.rst

@@ -0,0 +1,102 @@
+==========================================================================
+{% trans -%}Improving I2P Adoption and Onboarding using Jpackage, I2P-Zero{%- endtrans %}
+==========================================================================
+
+.. meta::
+   :author: idk
+   :date: 2021-09-15
+   :category: general
+   :excerpt: {% trans %}Versatile and emerging ways of installing and embedding I2P in your application{% endtrans %}
+
+{% trans -%}
+For the majority of I2P's existence, it's been an application that runs with the
+help of a Java Virtual Machine that is already installed on the platform. This
+has always been the normal way to distribute Java applications, but it leads to
+a complicated installation procedure for many people. To make things even more
+complicated, the "right answer" to making I2P easy to install on any given
+platform might not be the same as any other platform. For example, I2P is quite
+simple to install with standard tools on Debian and Ubuntu based operating
+systems, because we can simply list the required Java components as "Required"
+by our package, however on Windows or OSX, there is no such system allowing us to make
+sure that a compatible Java is installed.
+{%- endtrans %}
+
+{% trans -%}
+The obvious solution would be to manage the Java installation ourselves, but
+this used to a problem in-and-of-itself, outside of the scope of I2P. However,
+in recent Java versions, a new set of options has emerged which has the
+potential to solve this problem for many Java software. This exciting tool is
+called **"Jpackage."**
+{%- endtrans %}
+
+{% trans -%}
+I2P-Zero and Dependency-Free I2P Installation
+{%- endtrans %}
+---------------------------------------------
+
+{% trans -%}
+The first very successful effort at building a dependency-free I2P Package was
+I2P-Zero, which was created by the Monero project originally for use with the
+Monero cryptocurrency. This project got us very excited because of it's success
+in creating a general-purpose I2P router which could easily packaged with an
+I2P application. Especially on Reddit, many people express their preference for
+the simplicity of setting up an I2P-Zero router.
+{%- endtrans %}
+
+{% trans -%}
+This really proved to us that a dependency-free I2P Package which was easy to
+install was possible using modern Java tools, but I2P-Zero's use case was a
+little bit different than ours. It is best for embedded apps that need an I2P
+router that they can easily control using it's convenient control port on port
+"8051". Our next step would be to adapt the technology to the general-purpose
+I2P Application.
+{%- endtrans %}
+
+{% trans -%}
+OSX Application Security Changes affect I2P IzPack Installer
+{%- endtrans %}
+------------------------------------------------------------
+
+{% trans -%}
+The issue became more pressing in recent versions of Mac OSX, where it is no
+longer straightforward to use the "Classic" installer which comes in the .jar
+format. This is because the application is not "Notarized" by Apple authorities
+and it is deemed a security risk. **However**, Jpackage can produce a .dmg file,
+which can be notarized by Apple authorities, conveniently solving our problem.
+{%- endtrans %}
+
+{% trans -%}
+The new I2P .dmg installer, created by Zlatinb, makes I2P easier to install on
+OSX than ever, no longer requiring users to install Java themselves and using
+standard OSX installation tools in their prescribed ways. The new .dmg installer
+makes setting up I2P on Mac OSX easier than it's ever been.
+{%- endtrans %}
+
+Get the dmg_.
+
+.. _dmg: /mac
+
+{% trans -%}
+The I2P of the future is Easy to Install
+{%- endtrans %}
+----------------------------------------
+
+{% trans -%}
+One of the things I hear from users the most is that if I2P wants adoption, it
+needs to be easy to use for people. Many of them want a "Tor Browser Like" user
+experience, to quote or paraphrase many familiar Redditors. Installation should
+not require complicated and error-prone "post-installation" steps. Many new
+users are not prepared to deal with their browser configuration in a thorough
+and complete way. To address this problem, we created the I2P Profile Bundle
+which configured Firefox so that it would automatically "Just Work" for I2P.
+As it's developed, it's added security features and improved integration with
+I2P itself. In it's latest version, it **also** bundles a complete, Jpackage
+powered I2P Router. The I2P Firefox Profile is now a fully-fledged distribution
+of I2P for Windows, with the only remaining dependency being Firefox itself.
+This should provide an unprecedented level of convenience for I2P users on
+Windows.
+{%- endtrans %}
+
+Get the installer_.
+
+.. _installer: /nsis

i2p2www/blog/2021/09/18/i2p-bitcoin.draft.rst

@@ -0,0 +1,108 @@
+=============================================================
+{% trans -%}Bitcoin Core adds support for I2P!{%- endtrans %}
+=============================================================
+
+.. meta::
+   :author: idk
+   :date: 2021-09-18
+   :category: general
+   :excerpt: {% trans %}A new use case and a signal of growing acceptance{% endtrans %}
+
+{% trans -%}
+An event months in the making, Bitcoin Core has added official support for I2P!
+Bitcoin-over-I2P nodes can interact fully with the rest of the Bitcoin nodes,
+using the help of nodes that operate within both I2P and the clearnet, making
+them first-class participants in the Bitcoin network. It's exciting to see
+large communities like Bitcoin taking notice of the advantages I2P can bring
+to them providing privacy and reachability to people all over the world.
+{%- endtrans %}
+
+{% trans -%}
+How it Works
+{%- endtrans %}
+------------
+
+{% trans -%}
+I2P support is automatic, via the SAM API. This is also exciting news, because
+it highlights some of the things I2P is singularly good at, like empowering 
+application developers to build I2P connections programmatically and
+conveniently. Bitcoin-over-I2P users can use I2P with no manual configuration by
+enabling the SAM API and running Bitcoin with I2P enabled.
+{%- endtrans %}
+
+{% trans -%}
+Configuring your I2P Router
+{%- endtrans %}
+---------------------------
+
+{% trans -%}
+In order to set up an I2P Router to provide anonymous connectivity to bitcoin,
+the SAM API needs to be enabled. In Java I2P, you should go to `http://127.0.0.1:7657/configclients
+<http://127.0.0.1:7657/configclients>`_. and start the SAM Application Bridge
+with the "Start" button. You may also want to enable the SAM Application Bridge
+by default by checking the "Run at Startup" box and clicking "Save Client
+Configuration."
+{%- endtrans %}
+
+{% trans -%}
+On i2pd, the SAM API is normally enabled by default, but if it isn't, you should
+set::
+
+  sam.enabled=true
+
+in your i2pd.conf file.
+{%- endtrans %}
+
+{% trans -%}
+Configuring your Bitcoin Node for Anonymity and Connectivity
+{%- endtrans %}
+------------------------------------------------------------
+
+{% trans -%}
+Getting Bitcoin itself launched in an anonymous mode still requires editing some
+configuration files in the Bitcoin Data Directory, which is %APPDATA%\Bitcoin on
+Windows, ~/.bitcoin on Linux, and ~/Library/Application Support/Bitcoin/ on Mac
+OSX. It also requires at least version 22.0.0 for I2P support to be present. 
+{%- endtrans %}
+
+{% trans -%}
+After following these instructions, you should have a private Bitcoin
+node which uses I2P for I2P connections, and Tor for .onion and clearnet
+connections, so that all your connections are anonymous. For convenience,
+Windows users should open their Bitcoin Data Directory by opening the start menu
+and searching for "Run." Inside the run prompt, type "%APPDATA%\Bitcoin" and
+press enter.
+{%- endtrans %}
+
+{% trans -%}
+In that directory create a file called "i2p.conf." On Windows, you should make
+sure that you've add quotes around the file when you save it, in order to
+prevent Windows from adding a default file extension to the file. The file
+should contain the following I2P-Related Bitcoin configuration options::
+
+  i2psam=127.0.0.1:7656
+  i2pacceptincoming=true
+  onlynet=i2p
+
+Next, you should create another file called "tor.conf." The file should contain
+the following Tor related configuration options::
+
+  proxy=127.0.0.1:9050
+  onion=127.0.0.1:9050
+  onlynet=tor
+
+Finally, you'll need to "include" these configuration options in your Bitcoin
+configuration file, called "bitcoin.conf" in the Data Directory. Add these two
+lines to your bitcoin.conf file::
+
+  includeconf=i2p.conf
+  includeconf=tor.conf
+
+Now your Bitcoin node is configured to only use anonymous connections. In order
+to enable direct connections to remote nodes, remove the lines beginning in::
+
+  onlynet=
+
+You can do this if you do not require your Bitcoin node to be anonymous, and
+it helps anonymous users connect to the rest of the Bitcoin network.
+{%- endtrans %}

i2p2www/blog/2021/09/18/i2p-bitcoin.draft.rst.bak

@@ -0,0 +1,105 @@
+=============================================================
+{% trans -%}Bitcoin Core adds support for I2P!{%- endtrans %}
+=============================================================
+
+.. meta::
+   :author: idk
+   :date: 2021-09-18
+   :category: general
+   :excerpt: {% trans %}A new use case and a signal of growing acceptance{% endtrans %}
+
+{% trans -%}
+An event months in the making, Bitcoin Core has added official support for I2P!
+Bitcoin-over-I2P nodes can interact fully with the rest of the Bitcoin nodes,
+using the help of nodes that operate within both I2P and the clearnet, making
+them first-class participants in the Bitcoin network. It's exciting to see
+large communities like Bitcoin taking notice of the advantages I2P can bring
+to them providing privacy and reachability to people all over the world.
+{%- endtrans %}
+
+{% trans -%}
+How it Works
+{%- endtrans %}
+------------
+
+{% trans -%}
+I2P support is automatic, via the SAM API. This is also exciting news, because
+it highlights some of the things I2P is singularly good at, like empowering 
+application developers to build I2P connections programmatically and
+conveniently. Bitcoin-over-I2P users can use I2P with no manual configuration by
+enabling the SAM API and running Bitcoin with I2P enabled.
+{%- endtrans %}
+
+{% trans -%}
+Configuring your I2P Router
+{%- endtrans %}
+---------------------------
+
+{% trans -%}
+In order to set up an I2P Router to provide anonymous connectivity to bitcoin,
+the SAM API needs to be enabled. In Java I2P, you should go to `http://127.0.0.1:7657/configclients
+<http://127.0.0.1:7657/configclients>`_. and start the SAM Application Bridge
+with the "Start" button. You may also want to enable the SAM Application Bridge
+by default by checking the "Run at Startup" box and clicking "Save Client
+Configuration."
+{%- endtrans %}
+
+{% trans -%}
+On i2pd, the SAM API is normally enabled by default, but if it isn't, you should
+set::
+
+  sam.enabled=true
+
+in your i2pd.conf file.
+{%- endtrans %}
+
+{% trans -%}
+Configuring your Bitcoin Node for Anonymity and Connectivity
+{%- endtrans %}
+------------------------------------------------------------
+
+{% trans -%}
+Getting Bitcoin itself launched in an anonyous mode still requires editing some
+configuration files in the Bitcoin Data Directory, which is %APPDATA%\Bitcoin on
+Windows, ~/.bitcoin on Linux, and ~/Library/Application Support/Bitcoin/ on Mac
+OSX. It also requires at least version 22.0.0 for I2P support to be present. 
+After following the following instructions, you should have a private Bitcoin
+node which uses I2P for I2P connections, and Tor for .onion and clearnet
+connections, so that all your connections are anonymized. For convenience,
+Windows users should open their Bitcoin Data Directory by opening the start menu
+and searching for "Run." Inside the run prompt, type "%APPDATA%\Bitcoin" and
+press enter.
+{%- endtrans %}
+
+{% trans -%}
+In that directory create a file called "i2p.conf." On Windows, you should make
+sure that you've add quotes around the file when you save it, in order to
+prevent Windows from adding a default file extension to the file. The file
+should contain the following I2P-Related Bitcoin configuration options::
+
+  i2psam=127.0.0.1:7656
+  i2pacceptincoming=true
+  onlynet=i2p
+
+Next, you should create another file called "tor.conf." The file should contain
+the following Tor related configuration options::
+
+  proxy=127.0.0.1:9050
+  onion=127.0.0.1:9050
+  onlynet=tor
+
+Finally, you'll need to "Include" these configuration options in your Bitcoin
+configuration file, called "bitcoin.conf" in the Data Directory. Add these two
+lines to your bitcoin.conf file::
+
+  includeconf=i2p.conf
+  includeconf=tor.conf
+
+Now your Bitcoin node is configured to only use anonymous connections. In order
+to enable direct connections to remote nodes, remove the lines beginning in::
+
+  onlynet=
+
+You can do this if you do not require your Bitcoin node to be anonymous, and
+it helps anonymous users connect to the rest of the Bitcoin network.
+{%- endtrans %}

i2p2www/downloads.py

@@ -7,19 +7,38 @@ from random import randint
 
 from i2p2www import CURRENT_I2P_VERSION, MIRRORS_FILE
 
+#DEFAULT_MIRROR = {
+#    "net": "clearnet", 
+#    "protocol": "https", 
+#    "domain": "files.i2p-projekt.de", 
+#    "path": "/%(version)s/%(file)s", 
+#    "org": "i2p-projekt", 
+#    "country": "de",
+#}
+
 DEFAULT_MIRROR = {
-    'net': 'clearnet',
-    'protocol': 'https',
-    'domain':   'download.i2p2.de',
-    'org':      'sigterm.no',
-    'country':  'no',
+    "net": "clearnet",
+    "protocol": "https",
+    "domain": "download.i2p2.de",
+    "path": "/releases/%(version)s/%(file)s",
+    "org": "sigterm.no",
+    "org_url": "https://download.i2p2.de", 
+    "country": "no",
 }
 
+#{
+ #   'net': 'clearnet',
+ #   'protocol': 'https',
+ #   'domain':   'download.i2p2.de',
+ #   'org':      'sigterm.no',
+ #   'country':  'no',
+#}
+
 DEFAULT_I2P_MIRROR = {
     'net': 'i2p',
     'protocol': 'http',
-    'domain':   'whnxvjwjhzsske5yevyokhskllvtisv5ueokw6yvh6t7zqrpra2q.b32.i2p',
-    'org':      'sigterm.no',
+    'domain':   'mgp6yzdxeoqds3wucnbhfrdgpjjyqbiqjdwcfezpul3or7bzm4ga.b32.i2p',
+    'org':      'eyedeekay.github.io',
     'country':  'i2p',
 }
 
@@ -70,6 +89,19 @@ def downloads_debian():
 def downloads_windows():
     return render_template('downloads/windows.html')
 
+# AIO-Windows-specific page
+def downloads_easyinstall():
+    # TODO: read mirror list or list of available files
+    if request.headers.get('X-I2P-Desthash') and not request.headers.get('X-Forwarded-Server'):
+        def_mirror = DEFAULT_I2P_MIRROR
+    else:
+        def_mirror = DEFAULT_MIRROR
+    return render_template('downloads/easyinstall.html', def_mirror=def_mirror)
+
+# Docker-specific page
+def downloads_docker():
+    return render_template('downloads/docker.html')
+
 # Firefox-specific page
 def downloads_firefox():
     # TODO: read mirror list or list of available files
@@ -81,7 +113,21 @@ def downloads_firefox():
 
 # The Lab
 def downloads_lab():
-    return render_template('downloads/lab.html')
+    # TODO: read mirror list or list of available files
+    if request.headers.get('X-I2P-Desthash') and not request.headers.get('X-Forwarded-Server'):
+        def_mirror = DEFAULT_I2P_MIRROR
+    else:
+        def_mirror = DEFAULT_MIRROR
+    return render_template('downloads/lab.html', def_mirror=def_mirror)
+
+# Mac DMG page
+def downloads_mac():
+    # TODO: read mirror list or list of available files
+    if request.headers.get('X-I2P-Desthash') and not request.headers.get('X-Forwarded-Server'):
+        def_mirror = DEFAULT_I2P_MIRROR
+    else:
+        def_mirror = DEFAULT_MIRROR
+    return render_template('downloads/mac.html', def_mirror=def_mirror)
 
 def downloads_config():
     return render_template('downloads/config.html')

i2p2www/legacy.py

@@ -19,6 +19,10 @@ LEGACY_FUNCTIONS_MAP={
     'debian':        {'function': 'downloads_debian', 'params': {}},
     'firefox':        {'function': 'downloads_firefox', 'params': {}},
     'lab':           {'function': 'downloads_lab',    'params': {}},
+    'mac':           {'function': 'downloads_mac',    'params': {}},
+    'easyinstall':           {'function': 'downloads_easyinstall',    'params': {}},
+    'nsis':           {'function': 'downloads_easyinstall',    'params': {}},
+    'windows':           {'function': 'downloads_windows',    'params': {}},
     'download':      {'function': 'downloads_list',   'params': {}},
     'installation':  {'function': 'downloads_list',   'params': {}},
     'meetings':      {'function': 'meetings_index',   'params': {}},

i2p2www/meetings/logs/297.log

@@ -0,0 +1,158 @@
+(08:01:02 PM) eyedeekay: Hi everyone and welcome to the March 2 Meeting, please let me know if you're here
+(08:01:27 PM) eyedeekay: zzz zlatinb eche|on eche|off
+(08:01:42 PM) eyedeekay: Agenda
+(08:01:42 PM) eyedeekay: 1) Hi 
+(08:01:42 PM) eyedeekay: 2) 0.9.49 remaining items 
+(08:01:42 PM) eyedeekay: 3) Mac Launcher Status 
+(08:01:42 PM) eyedeekay: 5) 0.9.50 release 
+(08:01:42 PM) eyedeekay: 6) Trac migration summary
+(08:01:46 PM) Irc2PGuest1578 [kilian@xvbemdlawzj2qlt3cgjgaclevziobxvwmipcvecbla4xqkmwjd2q.b32.i2p] entered the room.
+(08:01:46 PM) zzz: hi
+(08:01:55 PM) zlatinb: hi
+(08:01:55 PM) eyedeekay: 4) 1.0.0 vs 0.9.50
+(08:03:04 PM) eyedeekay: hi zzz, hi zlatinb, timeout 30s anyone else?
+(08:03:39 PM) eyedeekay: Thanks everyone, starting right in with 2) 0.9.49 remaining items
+(08:03:51 PM) eyedeekay: The only one I know of is the .dmg version of the Mac installer
+(08:04:20 PM) zzz: the others are official debian and ubuntu
+(08:04:45 PM) zzz: I'll explain a little more
+(08:04:50 PM) eyedeekay: Ok thanks.
+(08:05:06 PM) zzz: unfortunately, debian bullseye just hit a freeze
+(08:05:29 PM) zzz: our debian maintainer either wasn't aware of the schedule or didn't advise us to hurry
+(08:05:51 PM) zzz: so while we did pull in the schedule to for ubuntu hirsute 21.04, the debian deadline was earlier
+(08:06:09 PM) zzz: since ubuntu pulls from debian, ubuntu didn't get it either
+(08:06:45 PM) zzz: this is a once every two year thing, but still, would have been nice to know
+(08:06:54 PM) zzz: as it was, we hurried up about ubuntu, all for nothing
+(08:07:25 PM) zzz: so, at some point, debian will unfreeze, and 49 should show up in sid. but bullseye is 48
+(08:07:27 PM) zzz: eot
+(08:07:59 PM) eyedeekay: Thanks zzz. So for the time being the recommendation for Debian users to get an up-to-date router should be via our repository
+(08:08:17 PM) zzz: yup. ditto ubuntu.
+(08:08:32 PM) zzz: oh, if I may, a brief report on the network:
+(08:08:41 PM) eyedeekay: Sure go ahead
+(08:08:48 PM) zzz: 52% updated to 49; 6% rekeyed to ECIES. All looks good so far
+(08:09:03 PM) zzz: very few bugs found or reported
+(08:09:05 PM) zzz: eot
+(08:09:21 PM) eyedeekay: Excellent to hear, thanks for the report
+(08:09:49 PM) eyedeekay: And I guess I can work on figuring out what mailing list we need to be subscribed to to get word earlier on when Debian will freeze
+(08:10:02 PM) eyedeekay: 3) Mac Launcher Status
+(08:10:14 PM) eyedeekay: This is the DMG based installer, not the .jar
+(08:10:54 PM) eyedeekay: I dropped the ball on this one, by failing to notify people that the previous maintainer was no longer building the installer
+(08:11:15 PM) eyedeekay: As a result I removed the Mac installer from the site
+(08:11:39 PM) zzz: iirc the last one built was .45 a year ago, and it probably was a broken link for most of last year
+(08:11:41 PM) eyedeekay: I have since aquired a Mac with the intent to take up maintenance of the product
+(08:12:00 PM) eyedeekay: zzz you are correct
+(08:12:04 PM) zlatinb: there is a problem with the dmg installer - at least on my mac I can't get the router to stop.  Some daemon keeps restarting it
+(08:12:09 PM) zzz: so it was actually a longstanding issue. you were correct to remove it, thanks for that
+(08:13:16 PM) zlatinb: so if other mac users are in the same situation we should come up with some sort of guide for cleaning up
+(08:13:28 PM) zzz: have you figured out if there's some auto-update or notification built in? and if so is that broken also? or is it just the news entry in the console?
+(08:13:57 PM) zlatinb: auto-update does work, strangely enough
+(08:13:57 PM) eyedeekay: It can't auto-update, at least not successfully
+(08:14:04 PM) eyedeekay: Oh well that's weird
+(08:14:09 PM) zlatinb: I just can't kill it and make sure it stays dead
+(08:14:28 PM) eyedeekay: Well sounds like some of the behavior is pretty erratic
+(08:14:56 PM) zzz: eyedeekay, last we discussed it, there was some debate as to the value of this installer product to our users, compared to the effort required to maintain it
+(08:15:15 PM) zzz: how do we nvestigate and evaluate those two factors?
+(08:15:58 PM) zzz: and zlatinb do you have any thoughts on the value of a "mac way" installer today?
+(08:16:36 PM) zlatinb: I still think a Mac way and Win way installers are far superior than the izpack monstrocity
+(08:16:37 PM) eyedeekay: I think zlatinb and I will need to compare notes, I'm seeing different behavior than he is and if I don't know why continuing to build and support it becomes much more intimidating
+(08:17:16 PM) zlatinb: but I think we need to re-evaluate the complexity in light of jpackage coming out with Java 14+
+(08:18:02 PM) zlatinb: either way, a  Mac-way installer would/should be lower priority than Win-way installer
+(08:18:05 PM) zzz: I'm not a mac person, but "far superior" was the consensus at the time we started development of the installer
+(08:18:43 PM) zzz: if the consensus is different now, I'd like to understand why
+(08:19:24 PM) zlatinb: to my knowledge it's still the same consensus, just the ecosystem has changed (i.e. jpackage exists)
+(08:20:26 PM) eyedeekay: IIRC my experience with Mac at the time was basically nil and my favor for the idea was based on the idea that working with familiar packaging systems makes our packages easier to trust
+(08:20:39 PM) eyedeekay: jpackage does the runtime image/eliminate the need to install Java thing right? the dmg to my knowledge didn't do that?
+(08:20:51 PM) zzz: right
+(08:21:18 PM) zlatinb: right
+(08:21:30 PM) zlatinb: jpackage builds dmgs supposedly, I haven't tried it
+(08:21:38 PM) zzz: so jpackage would be some 100MB thing. since it's only for one OS, it's feasible to do it for mac. 
+(08:21:47 PM) zzz: yeah dmgs would have to be tested for sure
+(08:22:14 PM) zlatinb: it builds windows installers too, I haven't used that functionality though
+(08:22:26 PM) zlatinb: and rpms and debs but I'm pretty sure we don't want those
+(08:22:52 PM) zzz: one of our failings as a project is that the dmg was always labeled 'experimental' on our d/l page. We never paid it enough attention to remove the label or even notice that nobody was building it
+(08:22:57 PM) Irc2PGuest1578 left the room (quit: Read error).
+(08:24:06 PM) zzz: as with all our other official products, if we're going to support it we need enough resources for a competent maintainer
+(08:25:15 PM) zzz: at this point I propose that we continue the evaluation of both user demand and effort required, both for existing dmg and jpackage.
+(08:25:29 PM) zzz: interim report in one month, final decision in two months, in time for .50
+(08:25:52 PM) zlatinb: any thoughts how to go about that?  survey? 
+(08:26:32 PM) eyedeekay: I could set up a Reddit survey after the meeting
+(08:26:42 PM) zzz: forum posts
+(08:27:11 PM) eyedeekay: Works for me, I'll add it to next month's meeting agenda
+(08:28:06 PM) eyedeekay: Anything else on 3)?
+(08:28:32 PM) eyedeekay: 4) 1.0.0 vs 0.9.50
+(08:29:02 PM) zzz: this was my item
+(08:29:10 PM) eyedeekay: Take it away zzz
+(08:29:28 PM) zzz: I don't feel strongly either way, but I think we should go to 1.0.0 in the next year or so
+(08:29:49 PM) zzz: as we don't have a separate stable branch, 1.0.0 is not a particular guarantee of stability
+(08:30:23 PM) Irc2PGuest1578 [kilian@xvbemdlawzj2qlt3cgjgaclevziobxvwmipcvecbla4xqkmwjd2q.b32.i2p] entered the room.
+(08:30:27 PM) zzz: so my question is what people think, and can the PR team accomplish messaging on what 1.0.0 is or isn't, on some timeline?
+(08:30:29 PM) zzz: eot
+(08:31:14 PM) zlatinb: so I have two points regarding 1.0.0:
+(08:31:41 PM) zlatinb: 1) RED needs tuning and I will die on that hill if I must.  Tunning it properly may require more than one release
+(08:32:19 PM) zlatinb: 2) Back to the installers issue - if we can build much smoother installers for the major platforms, a 1.0.0. release will have much greater impact
+(08:32:20 PM) zlatinb: eot
+(08:33:40 PM) eyedeekay: I think we can devise and accomplish messaging and PR for 1.0.0, if 1.0.0 coincides with migration of cryptography away from Elgamal, and I agree with zab on 2)
+(08:34:30 PM) zzz: we can always pick some headline feature to brag about, any release. It's fairly arbitrary. We could pick any release this year and claim it's when we're ditching elgamal. It's happening already
+(08:35:44 PM) zzz: as I'm not hearing any strong consensus, I propose that the next release is 0.9.50, and we discuss it again after that release, in 3 months
+(08:35:51 PM) eyedeekay: Then 2) remains pretty important to me, installers are a pain point as strange as that seems
+(08:36:15 PM) eyedeekay: I agree that the next one should be 0.9.50
+(08:36:27 PM) anonymousmaybe left the room (quit: Read error).
+(08:36:31 PM) T3s|4 left the room (quit: Read error).
+(08:37:36 PM) eyedeekay: Anything else on 4)?
+(08:38:16 PM) T3s|4 [~T3s4@573a4z46ixhpfeuej2hggtzg2wvsllq6nurtha5dzpd7l42awaeq.b32.i2p] entered the room.
+(08:38:16 PM) mode (+v T3s|4) by ChanServ
+(08:38:18 PM) eyedeekay: 5) 0.9.50 release
+(08:38:42 PM) anonymousmaybe [anonymousm@zvezcslfl5ndd6ciniqp2ei3cm6kvcovceeu3nzheqe7rqcj3rra.b32.i2p] entered the room.
+(08:38:42 PM) mode (+v anonymousmaybe) by ChanServ
+(08:39:19 PM) zzz: I'll let you go first, then I'll list what I've been up to
+(08:41:28 PM) eyedeekay: It's been about 2 weeks since the 0.9.49 release, in that time I've been working on style bugs, moving the configuration of X-I2P-Location into the application instead of requiring a reverse proxy or specific configuration, and have been working on finding ways to improve gitlab
+(08:42:17 PM) eyedeekay: In particular a way to migrate trac tickets to gitlab en-masse and a way to create tickets anonymously are on my gitlab list
+(08:43:06 PM) eyedeekay: Those are actually largely accomplished and part of the next agenda item, so I won't waste time on that now
+(08:43:56 PM) eyedeekay: EOT
+(08:44:06 PM) zzz: super
+(08:44:26 PM) zzz: I fixed NTP for the year 2036 issue
+(08:44:33 PM) zzz: implemented UPnP for IPv6
+(08:44:45 PM) zzz: reduced memory usage by the profiles
+(08:44:55 PM) zzz: added support for IPv6 introducers
+(08:45:17 PM) zzz: added "4/6" caps support for better tracking of who can connect to who
+(08:45:39 PM) zzz: did some work on smaller tunnel build messages (prop. 157), although that work is going a lot slower than the #ls2 team would like
+(08:46:26 PM) zzz: and I reported a major SSU bug to i2pd. they've fixed it. I'm hopeful they will cut a release for it this month, as I think it's really affecting network performance for some subset of connections
+(08:46:35 PM) zzz: eot
+(08:46:44 PM) eyedeekay: Thanks zzz
+(08:47:25 PM) zlatinb: I would like to do some experiments wrt tuning RED in the testnet.  Current theory is that it's way too aggressive and slows down single-stream connections to an unnecessary degree.  Will report as usual.  EOT
+(08:47:36 PM) eyedeekay: Thanks zlatinb
+(08:48:17 PM) eyedeekay: 6) Trac migration summary
+(08:48:17 PM) zzz: re: roadmap. I updated it today on the website to reflect what was in .49 and moved other stuff to .50. eyedeekay please do the same for the items you know about
+(08:48:32 PM) eyedeekay: Ack zzz, will do that this evening
+(08:51:18 PM) wodencafe left the room (quit: Read error).
+(08:51:37 PM) wodencafe [wodencafe@4qx5zjj3rypztq5h4kc2clviwid5cir7cm6iqrqa2l2npvlgt7ta.b32.i2p] entered the room.
+(08:51:51 PM) eyedeekay: Re: trac I am in a rock and a hard place here. I'm admin on trac and not the box that trac runs on. I can't do anything to update it or make it better on my own, all I can do is chase time-consuming issues.
+(08:51:51 PM) eyedeekay: I really want to get rid of it, but we obviously can't blow away all those tickets or the rest of the information here.
+(08:51:51 PM) eyedeekay: I'm proposing that we migrate trac tickets to gitlab tickets and encourage the use of gitlab for issue-tracking purposes
+(08:52:51 PM) eyedeekay: Trac tickets don't map 1:1 onto gitlab tickets, tickets for I2P applications will need to be added to the i2p.i2p issue tracker and tagged on gitlab with the corresponding application
+(08:54:04 PM) eyedeekay: I've finally figured out how to do it using some of the corresponding material from Tor
+(08:54:37 PM) zzz: that's probably the right answer, but we should probably do a quick evaluation of the alternatives, for example just copying over everything to trac on a box we control
+(08:54:51 PM) zzz: and again, an estimate of the one-time and ongoing resources required
+(08:55:18 PM) zzz: we were going to have a meeting a couple months ago on it, so perhaps now it's time
+(08:55:54 PM) lithium left the room (quit: Quit: leaving).
+(08:56:02 PM) eyedeekay: Instinctively, running 2 services(Trac and Gitlab) will probably be higher effort over time, but maybe less effort initially
+(08:56:05 PM) zzz: i just want to be clear on what we're trying to accomplish
+(08:56:05 PM) lithium [lithium@f25fchfdvktukmhg2rkz5es4mlrroyywcou27bpr4mxzfuf3jgya.b32.i2p] entered the room.
+(08:56:38 PM) zzz: a full migration to gitlab is an enormous fix for the problem of somebody not responding to emails
+(08:56:50 PM) zzz: so the question is what else do we get for it
+(08:57:58 PM) zlatinb: tight integration with git, MRs, code review, all that
+(08:58:02 PM) zzz: and we need a short list of our requirements, esp. for registration and anti-spam
+(09:00:01 PM) zzz: I also think we should take lessons from the git migration last year, and have clear milestones and schedule and status
+(09:00:36 PM) eyedeekay: Registration has become a difficult point. I estimate roughly 1/3 of registrations are spam, but it's so difficult to tell the difference because I do not ask for very much information from git users
+(09:01:37 PM) eyedeekay: Tor's solution re: anonymous registration is neat, and potentially very useful, but the more I look at it the more I think it may be overkill for us
+(09:02:35 PM) zzz: I propose that we find out who wants to be in a meeting about this, and then we'll schedule the meeting later
+(09:03:29 PM) eyedeekay: I can work with that. I'll start a new forum thread for the Trac Migration.
+(09:04:49 PM) zzz: zlatinb, would you like to be in on it?
+(09:05:03 PM) zlatinb: sure
+(09:05:21 PM) zzz: super
+(09:07:56 PM) eyedeekay: That's everything from the agenda, anything else to add?
+(09:08:00 PM) eyedeekay: Timeout 60s
+(09:09:32 PM) eyedeekay: That closes the meeting *baffs*
+(09:09:32 PM) eyedeekay: Thanks zzz zlatinb for coming, I'll post the meeting log to the site shortly
+(09:10:09 PM) zzz: thank you
+(09:11:05 PM) devcron left the room (quit: Quit: leaving).
+(09:11:11 PM) eyedeekay: no problem zzz

i2p2www/meetings/logs/297.rst

@@ -0,0 +1,11 @@
+I2P dev meeting, March 2, 2021 @ 20:00 UTC
+==========================================
+
+Quick recap
+-----------
+
+* **Present:**
+
+eyedeekay,
+zzz,
+zlatinb

i2p2www/meetings/logs/298.log

@@ -0,0 +1,264 @@
+(04:02:03 PM) eyedeekay: Hi everyone, zzz, zlatinb, community members, welcome to the April 6, 2020 meeting
+(04:02:09 PM) eyedeekay: A lot to discuss today:
+(04:02:12 PM) eyedeekay: 1) Hi
+(04:02:12 PM) eyedeekay: 2) Mac Launcher Report, jpackage/dmg
+(04:02:12 PM) eyedeekay: 3) Mac user interest survey results
+(04:02:12 PM) eyedeekay: 4) Windows all-in-one installer
+(04:02:12 PM) eyedeekay: 5) Update channels - http://git.idk.i2p/i2p-hackers/i2p.i2p/-/wikis/...
+(04:02:12 PM) eyedeekay: 6) Trac Migration Report/Evaluation
+(04:02:12 PM) eyedeekay: 7) 0.9.50 release
+(04:02:39 PM) eyedeekay: 1) Hi is everybody here?
+(04:02:43 PM) zzz: hi
+(04:02:46 PM) eyedeekay: Hi zzz
+(04:02:54 PM) zlatinb: hi
+(04:02:59 PM) eyedeekay: Hi zlatinb
+(04:03:08 PM) eyedeekay: Anybody else?
+(04:03:40 PM) eyedeekay: OK On to 2) then Mac Launcher Report
+(04:04:13 PM) eyedeekay: This was my topic but I think zlatinb and I should share it a bit, I have more to add to the User Interest Survey section
+(04:04:54 PM) zlatinb: ok
+(04:05:24 PM) eyedeekay: The current situation as I understand it is that we've decided that the old launcher is not the way, reflected in zzz removing the code from the main git branch this morning
+(04:07:04 PM) eyedeekay: And that we can deal with the issue of doing updates in the background in order to avoid making the update process more complicated while making the install process less
+(04:08:42 PM) eyedeekay: That "real" service installs probably won't be part of the jpackaged version of the router, because auto-starting apps start when the user logs in and not when the system is ready
+(04:08:53 PM) zlatinb: I think that is accurate.  I have verified that the sequence of steps in the script that is on the wiki page is completely "silent"
+(04:08:53 PM) zlatinb: the end-to-end flow needs to be tested ofc
+(04:08:53 PM) zzz: yeah I think the install experience is better, the update experience could be a little to a lot worse, TBD
+(04:09:25 PM) zzz: although if you include java updates in the izpack update experience, maybe we wouldn't be any worse
+(04:09:28 PM) mode (+v anonymousmaybe) by ChanServ
+(04:09:39 PM) zzz: thats the part we need to investigate further
+(04:09:58 PM) zzz: and decide how to make those tradeoffs
+(04:11:17 PM) eyedeekay: I think I think the Java nagware makes it almost the same
+(04:11:34 PM) eyedeekay: But I haven't actually had to do a Java update on my Mac yet either
+(04:12:35 PM) zzz: do we have any quantitative sense of how much better JRE 16 is over 8?
+(04:12:37 PM) eyedeekay: There was a slightly surprising result on the user-interest survey, a slim majority of users found installing Java to be easy, including one user who marked him or herself as a beginnger
+(04:13:37 PM) zlatinb: 16 vs 8? not atm, can google for benchmarks ofc, but the new apis are useful
+(04:14:01 PM) zlatinb: such as getting the pid from inside java, dock badges and notifications, etc.
+(04:15:14 PM) zlatinb: regarding an investigation of the full update process, it will organically be done as part of the work on the new update process, to be discussed later in this meeting
+(04:16:19 PM) zlatinb: I'm confident it can be very smooth; the implementation question is AppleScript vs bash script vs ?? 
+(04:16:57 PM) zzz: I thought it was just exec 'open xxx.dmg'?
+(04:17:54 PM) zlatinb: someone hasn't been following the wiki page tsk tsk :)  no it's a quite involved process of converting the .dmg to another format.  That avoids any visual promopts and license agreement
+(04:19:12 PM) zlatinb: basically 1. convert the .dmg to .cdr 2. mount cdr 3. move the existing AppBundle out of the way 4. cp -R new AppBundle 5. clean up, unmount .cdr 6. launch new app bundle
+(04:20:12 PM) zlatinb: I tested and verified the conversion and mounting are entirely "silent".  If we do not want to be silent but want the user to see what is happening, we can use AppleScript
+(04:20:20 PM) zlatinb: no idea why we would want that but it's on the table
+(04:21:14 PM) eyedeekay: Neat. Not that I think it matters that much, but is that how .dmg bundles are "supposed" to update? Is there a chance that would be disabled in the future without a path to fix it?
+(04:22:03 PM) zlatinb: the official way of updating is to use a Mac OS facility that relies on the existence of a clearnet server.  VLC updates that way for example.
+(04:22:30 PM) zzz: given the size of the agenda, I suggest we move on to find out if the survey says anybody wants this at all
+(04:22:49 PM) eyedeekay: Can do
+(04:23:49 PM) eyedeekay: The results of the survey summarized as follows:
+(04:23:49 PM) eyedeekay:  - Most of the people surveyed did not have Java installed when they were first  attempting to install I2P.
+(04:23:49 PM) eyedeekay:  - Users found installing Java easy, with a slim majority(3/5) of respondents saying that installing Java was not difficult. This included people who marked themselves as "beginner" computer user. This actually surprised me quite a bit.
+(04:23:49 PM) eyedeekay:  - 6 of 12 users skipped some or all of the Yes/No questions.
+(04:23:49 PM) eyedeekay:  - We had several users who skipped multiple Yes/No questions who left free-response answers. They were universally not complimentary to the install process.
+(04:23:49 PM) eyedeekay:  - All but one of the Yes/No respondents who answered the question were users of the .dmg bundle. Of these, there were 5/13. All others were non-responses. This  could indicate the overwhelming popularity of the .dmg approach.
+(04:23:49 PM) eyedeekay:  - The one non-user of the old .dmg bundle answered "Yes" to would use a new one if it emerged
+(04:24:31 PM) eyedeekay: That's copied directly from a longer summary I'll post to zzz.i2p later today
+(04:25:16 PM) zzz: we didn't ask directly if people want a dmg installer vs izpack? Or how can we infer that?
+(04:26:02 PM) eyedeekay: We referred to the izpack as the ".jar" installer since end users don't know what packaging tools we use
+(04:26:09 PM) zzz: or, an even simpler question: does the survey tell us we should do a dmg installer or not?
+(04:26:25 PM) eyedeekay: I believe the survey supports doing a .dmg installer
+(04:26:52 PM) zzz: strongly? weakly? "overwhelmingly"?
+(04:27:25 PM) eyedeekay: Pretty strongly, the only counterpoint to the .dmg installer was that people found installing Java easy
+(04:27:41 PM) eyedeekay: Thereby recommending the incumbent in that case
+(04:27:51 PM) zzz: ok
+(04:28:03 PM) eyedeekay: Everybody who answered the question said ".dmg installer"
+(04:28:47 PM) zlatinb: but that hasn't even been available for download for a while.  Do we know if they refer to the experimental one we just built or to the old one?
+(04:29:08 PM) eyedeekay: I specifically asked "The .dmg installer which lost support earlier this year"
+(04:29:17 PM) zlatinb: ok
+(04:29:51 PM) eyedeekay: Also I asked about whether they were able to transition from the old .dmg installer back to an IzPack installer
+(04:30:16 PM) eyedeekay: No one was able, but I think we knew that because of the unstoppable restarts issue
+(04:30:18 PM) mode (+v subatomic) by ChanServ
+(04:31:20 PM) zlatinb: that issue may have been specific to my system, I have no way of knowing.  I may have helped meeh run an interim build that may have been broken... many possibilities.
+(04:32:50 PM) eyedeekay: I remember seeing it on my old Mac that was a lemon so same
+(04:32:59 PM) eyedeekay: I'll have an extended summary with the raw anonymized results to post to zzz.i2p this evening
+(04:33:03 PM) eyedeekay: EOT #3
+(04:34:22 PM) zlatinb: I would ask that we go back to #2 for a bit
+(04:34:32 PM) zlatinb: and at least decide on a deadline for making a decision
+(04:35:05 PM) zlatinb: because with the lack of notarization the current izpack installer is pretty hideous.  Sadie posted on medium the full workflow and it's something like 35 steps
+(04:35:24 PM) zlatinb: that include the user turning off some OS protections which are on by default
+(04:35:53 PM) zlatinb: fyi I asked orignal and some guy from the ilita irc what they do for i2pd
+(04:36:10 PM) zlatinb: and the short answer was: disarm all assemssments and roll with it
+(04:36:32 PM) zzz: I'm not hearing any objections, so I think we keep working toward a solution. I'm not sure we need a deadline, especially if the effort is modest
+(04:36:33 PM) zlatinb: I really don't think we can expect our users to do that
+(04:37:20 PM) zlatinb: effot is modest if we do not count the update system overhaul which we'll discuss separately
+(04:37:33 PM) zlatinb: eot
+(04:37:55 PM) zzz: ok, then we'll find out what the deadline is to resolve the update stuff
+(04:38:53 PM) zlatinb: ok
+(04:40:25 PM) eyedeekay: Are we deciding that here and now? Because my vote would go to having it all ready to phase in at 0.9.51.
+(04:40:58 PM) zlatinb: we'll discuss it as part of 5), right?
+(04:41:09 PM) eyedeekay: Sure sounds good
+(04:41:21 PM) eyedeekay: On to 4) then Windows all in one installer
+(04:41:49 PM) eyedeekay: zlatinb added this to the agenda, but I'll probably have a lot to add here too. Do you want to get us started zlatinb?
+(04:42:40 PM) zlatinb: well eyedeekay did most of the hard work on combining the firefox profile installer with a JRE image and a router and making sure it installs and runs.  There's ofc some rough edges atm.
+(04:42:59 PM) zlatinb: There's also a wiki page that can be used for questions
+(04:43:30 PM) zlatinb: I think it's worth giving it some attention and spending the time to do a proper product definition with requirements and all that, similar to what was done for the .dmg
+(04:43:58 PM) zlatinb: We're working with users on r/i2p who have helped us greatly and continue to help us
+(04:44:15 PM) zlatinb: but ofc atm this is a PoC
+(04:44:15 PM) zlatinb: eot
+(04:45:38 PM) zzz: there seems to be no wikis listed on the index page at http://git.idk.i2p/i2p-hackers/i2p.i2p/-/wikis/home so ppl need the full url?
+(04:45:41 PM) eyedeekay: Yes despite being an early POC, most of the feedback I've received has been positive. One unfortunate thing is that apparently NSIS goes crazy if the user has a different character set than the administrator, the hardest part has been avoiding this pitfall so far
+(04:46:01 PM) eyedeekay: Right-hand side for me, I'll get you the full URL
+(04:46:29 PM) eyedeekay: https://i2pgit.org/i2p-hackers/i2p.firefox/-/wikis/All-in-One-I2P-Installer-for-Windows
+(04:47:08 PM) zzz: hmm if not logged in it says 'no wiki pages'. if logged in it gives you a 'create new wiki' page.
+(04:47:57 PM) zlatinb: check that you're in i2p.firefox project, not i2p.i2p
+(04:48:07 PM) zzz: oh ok
+(04:49:19 PM) psi: hi (lurking)
+(04:49:42 PM) zlatinb: hi psi
+(04:49:52 PM) eyedeekay: Hi psi
+(04:50:07 PM) eyedeekay: And here's the branch in case you need it: https://i2pgit.org/i2p-hackers/i2p.firefox/-/tree/EXPERIMENTAL-jpackage
+(04:50:34 PM) psi: wasn't there talk about using nsis for windows packaging?
+(04:50:56 PM) eyedeekay: Yes this is some of that talk
+(04:50:56 PM) psi: (that's item 4 nvm)
+(04:51:27 PM) psi: oh
+(04:51:30 PM) psi: i see we are on that
+(04:51:55 PM) psi: so if you are using cmake/cpack nsis is great because you cross compile for windows from linux trivially
+(04:52:04 PM) psi: not sure how it works in java land
+(04:52:23 PM) zzz: I've raised a few objections about this windows proposal over the last month, none fatal, but I don't think they've been adequately addressed
+(04:52:29 PM) zzz: I'll list 3 here
+(04:52:47 PM) eyedeekay: Unfortunately we might to this to take advantage of jpackage builds, which do require us to build on the target platform at this time
+(04:53:03 PM) zzz: 1) it's all a distraction from the mac installer that got us started and is probably higher priority and we'll learn from doing it first
+(04:53:15 PM) psi: point 1 is enough there
+(04:53:24 PM) zzz: 2) almost all the justifications listed or theorized are weaker than that for the mac installer
+(04:53:34 PM) psi: i'd say focus on the mac infra before wandering out into the packaging aybss
+(04:53:55 PM) psi: you'll find a way to have scope creep
+(04:53:57 PM) zzz: 3) the so-far-unofficial firefox profile is assumed included, but hasn't been justified or reviewed separately
+(04:54:02 PM) zzz: eot
+(04:54:31 PM) psi: for now macos packaging is plenty of a task and you need not increase scope
+(04:54:47 PM) psi: once you get the macos infra working come back to windows nsis 
+(04:55:03 PM) psi: i for one want to drop macos support at work becuase it's just bad
+(04:55:12 PM) psi: the whole target is getting worse with each release
+(04:55:33 PM) psi: and apple is actively hostile to free software projects
+(04:55:51 PM) psi: if you dont mind bending over to let apple in then it's probably fine
+(04:56:10 PM) zlatinb: well that's a picturesque way of putting it psi :)
+(04:56:12 PM) psi: it's all a question of how much time you want to burn dealing with them
+(04:56:29 PM) psi: if the number of users is low enough it's just not worth it
+(04:56:39 PM) eyedeekay: I can definitely live with waiting for Mac to be ready to take Windows further, I think everyone sees my point re: the installer and it's relationship to onboarding
+(04:57:00 PM) zlatinb: but I've already gone through the joys of notarization so that part's taken care of
+(04:57:10 PM) zlatinb: (that's the most unpleasant part btw)
+(04:57:33 PM) psi: so this is a kind of high level directional question, windows is actually getting a bit better and apple is getting worse, the projected direction each are going is pretty clear to me
+(04:57:52 PM) psi: if we dont have a dedicate mac guy then the mac parts will rot
+(04:58:00 PM) psi: dedicated mac guy*
+(04:58:05 PM) psi: that is what happened at work D:
+(04:58:34 PM) zlatinb: well I try to document everything that I do, but you're right, one of the requirements is an Apple Id which means de-anoning
+(04:58:44 PM) psi: that's probably fine
+(04:58:50 PM) psi: the real problem is the everything else part
+(04:58:57 PM) zlatinb: it's not that bad
+(04:59:05 PM) psi: it is if you need eleveated privs
+(04:59:05 PM) zlatinb: we can discuss after the meeting if you're interested
+(04:59:16 PM) psi: for i2p is fine
+(04:59:16 PM) zlatinb: we don't for I2P, it's a slide install
+(04:59:19 PM) zzz: the thing I still don't understand is that we had a broken link to the old dmg installer for a year and nobody complained. during that time we thought we had a dedicated mac guy, but he vanished
+(04:59:19 PM) psi: and yea we can talk later
+(04:59:30 PM) psi: yea
+(04:59:44 PM) psi: if a mac users tries it and it's broken they'll just uninstall
+(04:59:48 PM) psi: they wont report a bug
+(04:59:52 PM) zlatinb: exactly
+(05:00:03 PM) psi: and with i2pd being a thing they can just try that
+(05:00:12 PM) psi: if i2pd works they'll use that
+(05:00:16 PM) eyedeekay: I bet if I really combed I could find a reddit question
+(05:00:25 PM) zlatinb: it doesn't, requires disarming all assessments
+(05:00:53 PM) eyedeekay: But another factor is that until a few months ago the .dmg installer would have installed and may have updated, because the signature on it hadn't expired yet
+(05:02:24 PM) zlatinb: there is like one mac guy on ilita and he is a very advanced mac user
+(05:02:33 PM) zlatinb: anyway, we're drifting
+(05:02:33 PM) psi: yea
+(05:02:33 PM) zlatinb: psi is right that mac users won't complain and just give up
+(05:02:33 PM) psi: are there regular project level UX aditing for each platform?
+(05:02:33 PM) zzz: not true, the link was broken as of 0.9.44, because the last dmg release was .43
+(05:02:33 PM) psi: i.e. seeing if platform X is broken?
+(05:02:33 PM) zlatinb: sadly no
+(05:02:33 PM) psi: thinking out loud i see a common overaching theme
+(05:02:33 PM) psi: over arching theme
+(05:02:34 PM) zzz: correction .45 was the last, broken as of .46
+(05:03:03 PM) zlatinb: we had the windows installer broken for two days until parg complained about it, just a data point
+(05:03:27 PM) zzz: one hour in, eyedeekay can you keep things moving please?
+(05:03:35 PM) eyedeekay: Yes
+(05:03:52 PM) eyedeekay: I think we've done enough on #4 for now anyway
+(05:03:58 PM) psi: yea
+(05:04:07 PM) eyedeekay: 5) update channels
+(05:04:21 PM) eyedeekay: This one is yours zlatinb
+(05:04:56 PM) zlatinb: right, so the main purpose of update channels is to support the new installers, but of course it can turn out to be useful in other situations as well.
+(05:04:57 PM) zlatinb: such as:
+(05:05:16 PM) zlatinb: if we decide to transition to stable-vs-beta releases after 1.0.0
+(05:05:46 PM) zlatinb: to summarize what's on the wiki page:
+(05:06:09 PM) zlatinb: we introduce the notion of an update channel which is platform X readiness tuple
+(05:06:29 PM) psi: i2p has been effectively rolling release for a decade right?
+(05:06:57 PM) zlatinb: to do it in backwards-compatible way with least amount of work the update url will be constructed http://...b32.i2p/<platform>/<readiness>/news.su3
+(05:07:25 PM) zlatinb: no changes to news.xml format
+(05:08:08 PM) zlatinb: So very little modifications to the workflow of the su3 generators
+(05:08:33 PM) zlatinb: small changes to the backend of the router, and small-to-medium changes to the console ui
+(05:09:04 PM) zlatinb: for more detailed discussion see the wiki page
+(05:09:36 PM) zlatinb: at this meeting I would like to agree on what priority this should be, when do we want it done, who will do which part ideally too
+(05:09:38 PM) zlatinb: eot
+(05:10:04 PM) zzz: the issues are who runs and manages and translates the new feeds and their backups ... same as now, or different
+(05:10:11 PM) zzz: if it's option 1 then it's almost no dev effort
+(05:10:35 PM) zlatinb: oh yeah option 2 (from the wiki page) is out, ignore it completely
+(05:10:59 PM) zzz: so are you proposing the same news hosts as now for the new feeds? (ech and idk), if so, need their buyin, if not, need to know who
+(05:11:44 PM) zlatinb: I would say start with the same hosts for now
+(05:12:08 PM) eyedeekay: I'm absolutely happy to host the new feeds on my end
+(05:12:27 PM) zlatinb: I'll reach out to ech sometime soon about it
+(05:13:51 PM) eyedeekay: Since option 2 is out by extension option 3 is as well, right?
+(05:13:59 PM) zlatinb: yeah
+(05:14:36 PM) zlatinb: option 1 achieves everything and is very little effort relative to the other options
+(05:15:31 PM) zlatinb: so... 
+(05:16:23 PM) zlatinb: since this is a prerequisite for enabling in-network updates of a .dmg installer and we seem to be in agreement that we're going ahead with that, shall we say 0.9.51 for this item?
+(05:16:49 PM) eyedeekay: +1
+(05:17:08 PM) zzz: oh I thought you wanted a deadline for deciding. thats a deadline for finishing
+(05:17:24 PM) zzz: but sure, that's a reasonable target
+(05:17:50 PM) zlatinb: I wanted a deadline for deciding on the .dmg installer.. but I can retreat if there are reasonable arguments against deciding now :)
+(05:18:03 PM) mode (+v val) by ChanServ
+(05:18:26 PM) zzz: sounds good
+(05:19:10 PM) zlatinb: ok... we have one more meeting before the 0.9.51 cycle starts in earnest, right?
+(05:19:17 PM) eyedeekay: Yes we do
+(05:19:44 PM) zlatinb: we can then expand on the details on the wiki, including specific code locations that need to change by then
+(05:19:56 PM) zlatinb: I'm reluctant to start actual coding even if on a branch
+(05:20:18 PM) zzz: there shouldn't be any coding really, or very little
+(05:20:37 PM) zlatinb: I'll try to scope it out by the next meeting
+(05:21:18 PM) zlatinb: ok, that's eot from me on 5)
+(05:21:26 PM) eyedeekay: Ok then moving on to 6) Trac Migration Report/Evaluation
+(05:22:30 PM) eyedeekay: I've made a chart, it's been approved, I've done a dry run on a server at home, it worked. There are hundreds of tickets to migrate, almost all of which will be added to i2p.i2p with tags corresponding to the "component" they were on trac.
+(05:23:54 PM) eyedeekay: I think I can do the whole migration this month and have it done by the start of the next meeting. I'm going to go from small-to-large like I did with mtn->git. I'm going to go much faster this time, most of these can expected to take one day or less to complete. I'll be starting with i2p.www
+(05:24:21 PM) zzz: have we definitely decided to do it, or are there open issues e.g. registration for tickets, spam, etc. ?????
+(05:24:29 PM) mode (+v anonymousmaybe) by ChanServ
+(05:24:59 PM) eyedeekay: Spam has dropped considerably over the past month, user registrations are now open without my approval. Anyone who can confirm an email can register.
+(05:25:32 PM) eyedeekay: I can still "approve" users who cannot or do not wish to use a real e-mail.
+(05:25:35 PM) zzz: iirc we know where we're headed but we haven't made the final decision yet, especially because of the reg. issue
+(05:25:53 PM) zzz: but I don't have last month's meeting logs in front of me
+(05:26:14 PM) eyedeekay: The biggest issue, approval-only for registration, is no longer the case
+(05:26:48 PM) zzz: ok so that and the migration tech issues were the biggest. anything else that's a blocker, or are you recommending we proceed?
+(05:27:35 PM) eyedeekay: I am believe that I should proceed this month with the ticket migration
+(05:27:45 PM) mode (+v dr|z3d) by ChanServ
+(05:27:51 PM) zzz: sounds good
+(05:28:02 PM) eyedeekay: OK I'll get started probably at the end of this week
+(05:28:26 PM) eyedeekay: Last but not least the 7) 0.9.50 release update
+(05:28:29 PM) zzz: oh I remember
+(05:28:29 PM) zzz: notifications
+(05:28:40 PM) zzz: on tickets, MRs, etc. seem completely broken
+(05:29:04 PM) zzz: ofc they are on trac also...
+(05:29:44 PM) zzz: so maybe not a blocker but def. an annoyance
+(05:29:47 PM) eyedeekay: Are you not getting them? I thought I had them fixed, I started getting mine. I'll figure out why it is and deal with it ASAP
+(05:30:19 PM) zzz: nope. zlatinb how about you?
+(05:30:28 PM) zlatinb: nada
+(05:30:34 PM) zlatinb: did get a few at one point but after the update or downtime nothing
+(05:30:55 PM) zlatinb: but I check the activity feeds obsessively :)
+(05:31:19 PM) eyedeekay: Shoot. OK I must have missed it when I put the server back up after the thing in December. I'll fix it soon.
+(05:31:38 PM) eyedeekay: Wait no I have an email from zzz on the X-i2p-location issue...
+(05:31:46 PM) eyedeekay: Can't be that. Anyway, I'll find it
+(05:32:14 PM) zzz: thanks
+(05:32:16 PM) zzz: re: 7)
+(05:32:23 PM) zzz: I'll be very brief
+(05:32:37 PM) zzz: we're 7 weeks into a nominal 12 wk cycle, target mid-to-late May
+(05:32:45 PM) zzz: all big changes should be in
+(05:32:49 PM) zzz: lots of SSU and IPv6 stuff
+(05:33:08 PM) zzz: doing testing w/ i2pd on prop. 158 (ipv6 introducers)
+(05:33:18 PM) zzz: for draft release announcement see zzz.i2p
+(05:33:20 PM) zzz: EOT
+(05:33:52 PM) zlatinb: I just want to chime in re: bandwidth utilisation
+(05:34:04 PM) zlatinb: this release has the potential to improve throughput by a LOT
+(05:34:40 PM) zlatinb: so with the changes to RED and CDQ tuning we should keep an eye on whatever network metrics we can get
+(05:34:50 PM) zzz: let's hope. also lots of i2pd fixes in their mid-cycle release a couple weeks ago, and more in the next one, will help network performance
+(05:35:38 PM) zlatinb: I'm just worried we'll hit some bottlenecks that we never hit before
+(05:35:50 PM) zlatinb: but that's growing pains I guess
+(05:36:09 PM) zzz: same story different day
+(05:36:48 PM) eyedeekay: Thanks zzz, thanks zlatinb.
+(05:37:53 PM) eyedeekay: I've got very little to add here, and I think we've been here long enough, so unless there's anything else you want to discuss I'm going to call us to a close
+(05:38:03 PM) eyedeekay: Timeout 1m
+(05:39:19 PM) eyedeekay: Thanks everyone for coming, see around IRC
+(05:39:31 PM) eyedeekay: I will post meeting logs in a few minutes

i2p2www/meetings/logs/298.rst

@@ -0,0 +1,12 @@
+I2P dev meeting, April 6, 2021 @ 20:00 UTC
+==========================================
+
+Quick recap
+-----------
+
+* **Present:**
+
+eyedeekay,
+zzz,
+zlatinb,
+psi

i2p2www/meetings/logs/299.log

@@ -0,0 +1,113 @@
+(04:01:04 PM) eyedeekay: Hi everyone, it's time for the May 4th meeting
+(04:01:13 PM) zlatinb: hi
+(04:01:21 PM) zzz: hello
+(04:01:39 PM) eyedeekay: 1) Hi 
+(04:01:39 PM) eyedeekay: 2) Mac Launcher Report, Follow-up 
+(04:01:39 PM) eyedeekay: 3) Trac Migration Report, Post-op 
+(04:01:39 PM) eyedeekay: 4) 0.9.50 release
+(04:01:39 PM) eyedeekay: 5) Update Channels Report
+(04:01:39 PM) eyedeekay: 6) Docker Improvements
+(04:01:39 PM) eyedeekay: 7) Bote Plugin Keys
+(04:02:17 PM) eyedeekay: zab are 2) and 5) likely to overlap, should I put them together?
+(04:02:26 PM) zlatinb: sure
+(04:02:56 PM) eyedeekay: OK so let's swap 3 and 5 from that list above, and do update channels right after Mac Launcher
+(04:03:11 PM) eyedeekay: 2) Mac Launcher Report
+(04:03:59 PM) zlatinb: so far I've received one positive report by an unknown user, and know at least a few people have tried the .dmg
+(04:04:28 PM) zlatinb: so for the installer part I think we're in a very good shape.  I can't think of any changes required that are not related to the update functionality
+(04:04:49 PM) zlatinb: s/installer/app bundle/
+(04:05:24 PM) zlatinb: that's all on stricly-2) from me
+(04:06:10 PM) eyedeekay: Excellent. I don't have anything to add right, so we can move on to 3) Update Channels
+(04:06:24 PM) eyedeekay: Unless zzz has something?
+(04:06:36 PM) zzz: no
+(04:07:00 PM) eyedeekay: Ok then zlatinb update channels are also your topic
+(04:07:22 PM) zlatinb: zzz and I did some initial analysis/scoping of what needs to happen to enable update channels
+(04:08:05 PM) zlatinb: the consensus (I think) is that there will be some changes to code in i2p.i2p as well as some code residing in the mac-jpackage repo
+(04:08:36 PM) zlatinb: we're still enumerating all the corner cases but so far haven't come upon a dealbreaker
+(04:09:24 PM) zzz: agreed, sounds pretty straightforward and not too much effort. testing is probably more of the work than coding
+(04:09:36 PM) zlatinb: I'm very busy until the release but after that will focus on this.  Can get more technical but it gets very low-level for this meeting
+(04:09:39 PM) zlatinb: eot
+(04:10:05 PM) eyedeekay: Thanks for the report
+(04:10:12 PM) eyedeekay: That brings us to 4) 0.9.50 release
+(04:11:08 PM) dr|z3d: you missed Trac migration.
+(04:11:26 PM) eyedeekay: I was going to do it as 5, not 4
+(04:11:40 PM) dr|z3d: ok, as you were!
+(04:11:45 PM) eyedeekay: We're 11 days away from the release now
+(04:12:09 PM) eyedeekay: Tags are set to be frozen tomorrow
+(04:12:22 PM) eyedeekay: I have no more string changes for i2p.i2p
+(04:13:43 PM) eyedeekay: zzz, zlatinb what would you like to add?
+(04:14:08 PM) zzz: not much... I'll push the strings to transifex at 4 PM UTC tomorrow
+(04:14:26 PM) zlatinb: orignal made an interesting point just 30 minutes ago about NTCP queue capacity, might be worth looking into b4 the release
+(04:14:27 PM) zzz: I'm done with 50. already working on the next one
+(04:15:18 PM) zzz: I didn't see it, but I'd be reluctant to make any changes now. I am testing some NTCP queue changes for the next release
+(04:15:29 PM) zzz: eot
+(04:15:38 PM) zlatinb: eot from me too
+(04:15:53 PM) eyedeekay: 5) Trac Migration Report, Post-op
+(04:16:35 PM) eyedeekay: Trac migration was sticky mostly for the reasons I felt it needed to happen, in particular trac xmlrpc broke on our instance at about the same time as last months meeting
+(04:17:34 PM) eyedeekay: After trying and failing to fix it for a couple weeks I just decided it would be easier to (carefully) scrape our trac issues down and migrate them to gitlab using the gitlab API
+(04:18:20 PM) eyedeekay: Otherwise, it was successful, and as a by-product created a readable static archive of all our trac tickets at this time
+(04:18:32 PM) eyedeekay: eot
+(04:18:44 PM) zzz: so whats the status? done?
+(04:19:16 PM) eyedeekay: For the purposes of tracking tickets, trac migration is done. Trac still has wiki articles of some interest to back up but the tickets are done.
+(04:19:43 PM) zzz: ok. I changed the urls in our code to point to gitlab
+(04:20:14 PM) eyedeekay: I changed most of the ones on the website, but am still grepping through .rst files for the last few
+(04:20:28 PM) zzz: can you please add notes and links on trac home page and ticket page and login page and wherever else, with new i2p and clearnet links?
+(04:20:42 PM) eyedeekay: Sure, will do
+(04:21:49 PM) zzz: this now makes us reliant on gitlab (when it was just code, we could always use github) ... do we have any backup admin?
+(04:21:49 PM) eyedeekay: I will also go through all the README's and make sure they reference the correct places too
+(04:22:50 PM) eyedeekay: echelon has an admin account on gitlab, but no one else has SSH access to the server underneath right now
+(04:22:50 PM) mode (+v anonymousmaybe) by ChanServ
+(04:23:30 PM) eyedeekay: I can look into syncing the issues with github using a bot, it's not that different than the second half of the migration process
+(04:23:39 PM) zzz: ok, you two may want to review who can do what to make sure we're covered
+(04:23:45 PM) zzz: good job
+(04:24:09 PM) eyedeekay: Thanks
+(04:24:22 PM) eyedeekay: That brings us to 6) Docker Improvements
+(04:24:42 PM) eyedeekay: zlatinb do you want to fill the people who haven't tried them yet in here :)
+(04:25:10 PM) zlatinb: lol yes, the new docker image is smaller and supports persistent volumes for configuration and snark downloads
+(04:25:35 PM) zlatinb: documentation is in the source, the Docker.md file.  I would like to add a page to the website with that same content
+(04:26:03 PM) zlatinb: that's really it
+(04:26:30 PM) eyedeekay: Good call about the site, right now we advertise it but don't document how to use it at all
+(04:26:40 PM) zzz: who is in charge of the geti2p docker account and who else has access?
+(04:26:48 PM) zzz: or does it not work like that?
+(04:27:35 PM) zzz: does it just auto-build every checkin and that's it?
+(04:27:37 PM) eyedeekay: I'm in charge of the geti2p docker account, I can grant access to people from gitlab, it was started by Ace Barry or hkparker IIRC but I'm the admin now
+(04:28:04 PM) eyedeekay: It builds the `latest` every checkin and builds an image for every tag beginning in `i2p-*`
+(04:28:50 PM) zzz: ok so whatever changes zlatinb did are already in there
+(04:28:52 PM) zzz: got it
+(04:29:00 PM) zlatinb: yes
+(04:29:30 PM) zlatinb: eyedeekay: I saw you just dockerized the android build process?
+(04:30:50 PM) eyedeekay: Yeah I did, it was a way of bundling up all the release requirements into a re-usable form
+(04:31:35 PM) zzz: eyedeekay, speaking of android, I saw something about google adding more rules and bumping requirements effective later this year. You may wish to put aside some time before this release to get ahead of it
+(04:33:10 PM) eyedeekay: I'm double-checking all my Android release stuff this week to make sure that all goes smoothly
+(04:34:18 PM) zzz: as I said the new rules aren't effective for a few months but wouldn't hurt to address them now
+(04:34:41 PM) zzz: or, it might hurt, but better sooner than later
+(04:34:42 PM) zzz: eot
+(04:35:14 PM) eyedeekay: Well depends on F-Droid, sometimes they lag behind GPlay in requirements in a way which is somewhat mutually-exclusive, but it'll be better to know about it if it's going to happen
+(04:36:02 PM) eyedeekay: I think we're ready for number 7) Bote Plugin Keys
+(04:36:20 PM) eyedeekay: This one came up for me in conversation with some redditors last week
+(04:37:06 PM) eyedeekay: People are trying to use mhatta's fork of Bote but they are not able to do so because they are not able to install the plugin keys easily
+(04:37:30 PM) eyedeekay: They also mostly don't know how to intepret the certificate error in the sidebar to troubleshoot the issue
+(04:38:17 PM) eyedeekay: s/keys/certificates/
+(04:38:41 PM) eyedeekay: I would like us to consider adding mhatta's to the default so people no longer encounter this error
+(04:39:17 PM) zzz: 1) he should provide better instructions to his users; 2) he needs to make the request of us
+(04:40:22 PM) eyedeekay: Fair enough.
+(04:40:46 PM) eyedeekay: That brings us to the end of the listed topics, anything else to add?
+(04:41:06 PM) zlatinb: yes, I'd like us to think about making it easier to build testnets
+(04:41:08 PM) zzz: and I'd ask that he get .49 into debian, which never happened
+(04:41:55 PM) zlatinb: we've had two people build LXC testnets and one person build Docker, all three use quite different approaches
+(04:42:14 PM) zlatinb: so is there any interest in figuring out what the pain points are and making things easier?
+(04:42:51 PM) zzz: I have interest in finding out if there's interest :)
+(04:43:10 PM) eyedeekay: Yes there is from my side, I would like to get a testnet running, preferably a docker one
+(04:44:13 PM) zlatinb: cool.. so we should look into it.. of the top of my head initial seeding is the worst part
+(04:45:14 PM) eyedeekay: Are there any Docker testnet instructions written down yet or are they all LXC-based?
+(04:45:18 PM) zzz: my solution to seeding worked well for me, it's roughly solved for lxc
+(04:45:47 PM) zlatinb: LoveIsGrief may have something in his repos on gitlab 
+(04:47:55 PM) zlatinb: eot from me
+(04:49:07 PM) eyedeekay: I guess then if I want a Docker testnet I should probably look into their work, and fill in whatever blanks I encounter based on the process for LXC
+(04:49:43 PM) zzz: I checked all my horrible lxc shell scripts into i2p.scripts
+(04:50:29 PM) eyedeekay: Thanks zzz, horrible or not I'm sure they'll tell me what I need to know
+(04:51:32 PM) eyedeekay: Anything else for the meeting?
+(04:51:50 PM) eyedeekay: timeout 1m
+(04:51:50 PM) zzz: no
+(04:51:58 PM) zlatinb: not from me
+(04:52:19 PM) eyedeekay: OK then thanks everyone for coming
+(04:52:44 PM) eyedeekay: I'll post the logs to the site shortly, see you around IRC

i2p2www/meetings/logs/299.rst

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

i2p2www/meetings/logs/300.log

@@ -0,0 +1,136 @@
+(04:01:11 PM) eyedeekay: Hi everyone, welcome to the Tuesday, June 1 Community meeting
+(04:01:25 PM) eyedeekay: 1) Hi
+(04:01:25 PM) eyedeekay: 2) 300 logged community meetings
+(04:01:25 PM) eyedeekay: 3) 0.9.51
+(04:01:25 PM) eyedeekay: 4) go-i2p
+(04:01:25 PM) eyedeekay: 5) reproducible build status
+(04:01:25 PM) eyedeekay: 6) update channels report / Mac bundle report
+(04:01:25 PM) eyedeekay: 7) Next release number, deferred item from April 6 meeting
+(04:01:25 PM) eyedeekay: 8) 0.9.50 status / remaining release items
+(04:01:42 PM) eyedeekay: 1) hi
+(04:01:50 PM) eyedeekay: Hi everybody
+(04:02:08 PM) zzz: hi
+(04:02:10 PM) zlatinb: hi
+(04:02:31 PM) eyedeekay: Hi zzz, hi zlatinb.
+(04:02:31 PM) eyedeekay: Anybody else with us today?
+(04:03:00 PM) eyedeekay: OK 2) 300 logged community meetings
+(04:03:45 PM) eyedeekay: Congratulations everybody, the first meeting we have recorded on the web site was 19 years ago, nearly 20 now, and now we're 300 meeting later
+(04:04:18 PM) eyedeekay: Thanks to all I2P contributors in the past as well as in the present
+(04:04:54 PM) zzz: yes
+(04:05:16 PM) zzz: any eepsites from back then still work
+(04:05:44 PM) zzz: and some bugs from back then are still to be found and fixed! I fixed a bug from 2004 today
+(04:06:58 PM) eyedeekay: I saw that over in #ls2 earlier, especial thanks to zzz who has been the heart and soul of this project for longer than most of us have even been around :)
+(04:07:20 PM) zzz: can't do it alone, never could
+(04:08:11 PM) zzz: but that's all the time you get for reminiscing, let's get on with the work
+(04:08:24 PM) eyedeekay: Again thanks and congratulations to everybody, on to 3) 0.9.51
+(04:09:34 PM) eyedeekay: We're about 2 weeks into this release, for my part I'm working on my X-I2P-Location feature in the default site and thinking about options for integrating a browser profile with a main installer at the moment
+(04:09:59 PM) eyedeekay: What is everyone else working on for this release at this time?
+(04:10:41 PM) zzz: I'd like to remind everyone to update the website roadmap with your plans for the next release. There's not a lot there right now
+(04:11:05 PM) eyedeekay: Ack, thanks for reminding us, I will do mine this evening after the meeting
+(04:11:27 PM) zlatinb: I will be starting the Mac-specific side of the Mac bundle updater, unless we decide to split the work otherwise.  I'm happy to work on the i2p.i2p side as well, will discuss more in point 6)
+(04:11:32 PM) zzz: the #ls2 team is continuing to work on proposal 157 (new tunnel build messages), it's going slower than planned. Not clear right now how much will get into the next release
+(04:12:09 PM) zzz: the proposal is still incomplete, so until we do that, we can't finish the code
+(04:12:42 PM) zzz: SSU2 is still not started. We had hoped to have it done this year... that seems unlikely at this point. We could use some more help
+(04:12:56 PM) zzz: EOT
+(04:14:15 PM) eyedeekay: Thanks zzz, zlatinb. I'll do what I can to contribute as my understanding grows. Speaking of that, 4) go-i2p
+(04:15:41 PM) eyedeekay: I've written a cursory proposal for go-i2p in the proposal branch on gitlab.
+(04:15:41 PM) eyedeekay: Besides that, I've nearly completed migrating the common structures from the old distro off of using byte-slice representation to using objects(structs) for representation, and re-written the tests to accomodate this change
+(04:16:07 PM) eyedeekay: That means I'm at the point where I'm writing new code instead of just updating what's there, which is pretty exciting
+(04:16:29 PM) eyedeekay: No transport yet, but that will be the next thing on the roadmap
+(04:16:35 PM) eyedeekay: EOT
+(04:16:41 PM) zzz: are you still over in a separate branch and if so why haven't you merged back?
+(04:17:39 PM) eyedeekay: I've got ~4 tests to finish up before I do
+(04:18:30 PM) eyedeekay: Once all the existing tests pass again or I can be sure they are redundant I'll merge it back
+(04:18:34 PM) zzz: ok. and where are we with the full-go vs. go wrapper around i2pd? If the latter is really only 2 hours of work, as orignal claimed, shouldn't that be the next step?
+(04:18:55 PM) zzz: as a proof of concept, or MVP, or to judge demand from go projects
+(04:19:22 PM) zzz: then you could later just swap it out with the go router via the same API
+(04:20:53 PM) eyedeekay: I've got it started but I'm having some issues figuring out exactly how to create the C wrapper for api.h, probably just because the process is new to me
+(04:22:34 PM) zzz: ok. I still don't understand if the i2pd wrapper is a) an alternative to be evaluated; b) something definitely to be done first but we're doing both; c) low-priority/TBD
+(04:22:53 PM) zzz: or d) we've rejected it
+(04:24:04 PM) eyedeekay: IMO it should be b), because I should learn how to write a C wrapper for C++ code, and because the ability to easily embed i2pd in anything that SWIG supports would be very useful to have in general
+(04:25:18 PM) zzz: ok you have an estimated date for that?
+(04:27:52 PM) eyedeekay: Orignal's right, it's 2 hours of work for someone who knows how to do it already. The hard part to guess is how long I have to read examples to know what I'm doing. The 15th seems safe.
+(04:28:14 PM) zzz: thanks, EOT
+(04:28:40 PM) eyedeekay: OK that's everything I have for it too
+(04:28:41 PM) eyedeekay: 5) reproducible build status
+(04:28:57 PM) eyedeekay: zlatinb this one is yours
+(04:29:21 PM) zlatinb: So, there's something that is reproducible on Mac and Linux with English locale and JDK 11 and sort of works
+(04:29:44 PM) zlatinb: I know how to fix it for all Locales and to build on Windows too, there are a few small tweaks necessary for that
+(04:30:31 PM) zlatinb: Despite it's PoC status I think we should have a web page with instructions for others interested in trying it out
+(04:31:04 PM) zlatinb: as it uses the gradle build system it doesn't add to the release load and I'm happy to own it
+(04:31:35 PM) zlatinb: that's about it
+(04:31:38 PM) zzz: I said this on my forum already but I think it's important. We already have reproducible builds for Debian/Ubuntu. This is for gradle, which is not a supported build product now
+(04:32:13 PM) zzz: I question the value of it, and the ability to support it when we're lacking all the repro. build infrastructure of debian
+(04:33:05 PM) zzz: and announcements that 'i2p is now reproducible' is misleading/wrong. we need to be very clear about what it is
+(04:35:01 PM) zzz: I don't think our testing is sufficient to claim reproucibility, and we don't publish our tool versions anyway.
+(04:35:34 PM) zzz: eot
+(04:37:23 PM) zlatinb: The only tool that matters is the JDK, and that is published to be 11.  I am very skeptical that our Debian/Ubuntu builds are truly reproducible, and doubt that anyone will be able to reproduce the .deb packages on their own.  Just because it passes the build bot doesn't mean it's reproducible, but that's another point.
+(04:37:55 PM) zlatinb: There is value added to certain class of users even from an incomplete PoC that "strives" towards reproducibility or however we want to word it.
+(04:38:38 PM) zlatinb: If nothing else it shows that we're aware that there is demand and are making effort (albeight low priority) to address that demand
+(04:38:43 PM) zzz: the build bot has a lot of tests in it, more than we're testing, including changing username, PWD, locale, time, timezone
+(04:39:02 PM) psi: doesn't debian have a bunch of hooks and shims that normalize timestamps and directories?
+(04:39:08 PM) zlatinb: but it's clearly not changing the timestamps of the checked out code, otherwise it would break right away
+(04:39:14 PM) psi: (for deterministic builds, also hi)
+(04:39:25 PM) zzz: there may be 'demand' but not clear it's enough to justify the effort
+(04:40:01 PM) zzz: yes psi, that's the build infrastructure we rely on for our reproducible debian builds
+(04:40:08 PM) eyedeekay: I can confirm that zlatinb and I did not compare notes on what tools we were using, other than that we were on the same JDK, we certainly didn't compare individual libraries
+(04:40:21 PM) zlatinb: the effort falls on me, as I said I'm happy to own it, and most of the work is already done
+(04:40:31 PM) zzz: we have an answer now, 'use debian'
+(04:40:53 PM) zlatinb: no, the answer is "use the debian toolchain and build environment to build your .deb"
+(04:41:09 PM) zzz: I'm not convinced your testing is thorough enough to claim 'mostly done'
+(04:41:55 PM) zlatinb: There are no known issues remaining, and the unknown ones we'll bump into as more and more people use it
+(04:42:00 PM) zzz: and I'm not convinced we need another release product solely for those demanding non-debian reproducibility
+(04:43:06 PM) zzz: I don't think we want to rely on users to discover reproducibility issues. we need some testing harness or build bot to confirm it given various permutations listed above and others
+(04:43:13 PM) zlatinb: it doesn't need to be a release-quality product, I keep saying it is work-in-progress and will remain so for the foreseeable future.
+(04:44:00 PM) psi: is the purpose an end user ready package or is it to appase the intellecuals?
+(04:44:01 PM) zzz: in that case, no objections
+(04:44:30 PM) zlatinb: clearly to appease the intellectuals, 100%
+(04:45:22 PM) psi: gotcha, just catching up
+(04:46:15 PM) zlatinb: what's wrong with having the users help find reproducibility issues?
+(04:47:14 PM) zzz: 1) because most users won't actualy try to reproduce; but 2) if it's not an official release-quality product, nevermind
+(04:47:34 PM) eyedeekay: Moving right along to 6) update channels report / Mac bundle report
+(04:48:14 PM) eyedeekay: Unless we need to keep going on 5)?
+(04:48:37 PM) zzz: I'm done with 5)
+(04:48:51 PM) eyedeekay: OK, 6 then
+(04:49:24 PM) eyedeekay: zlatinb this is also your topic
+(04:50:20 PM) zlatinb: not much to report since the last meeting on the Mac bundle side of things; I've been dogfooding it a bit
+(04:51:15 PM) zlatinb: I will probably have time this month to look into update channels properly.  At least the part that will live in the mac-jpackage repo
+(04:51:30 PM) zlatinb: can also look into the changes required to i2p.i2p unless someone else wants to have a stab at those?
+(04:51:33 PM) zlatinb: eot
+(04:52:07 PM) zzz: I'm happy to do the other side, let's coordinate this week
+(04:52:30 PM) zlatinb: ok sounds good
+(04:52:52 PM) zlatinb: that's all from me on 6)
+(04:52:56 PM) zzz: I believe there's a few choices we have discussed but haven't fully decided on, but shouldn't be hard
+(04:52:57 PM) zzz: eot
+(04:53:08 PM) eyedeekay: 7) Next release number, deferred item from April 6 meeting
+(04:53:57 PM) eyedeekay: 1.0.0? 9.51.0? There were several choices in the thread
+(04:54:26 PM) zzz: yes. 2 months ago, I presented 0.9.50 vs. 1.0.0
+(04:54:44 PM) zzz: since then, I noted that bitcoin core is going from 0.22 to 23.0
+(04:54:54 PM) zzz: if a number is just a number, it can be anything
+(04:55:18 PM) zzz: 0.9.51, 1.0.0, 2.0, 9.51, 10.0. whatever we want
+(04:55:54 PM) zzz: if "1.0.0" brings up too much anxiety or implicit promise of perfection, we can avoid that by jumping right over it
+(04:56:15 PM) zzz: or, we can just keep doing 0.9.x forever, or until some particular goal we haven't agreed to yet.
+(04:56:18 PM) zzz: EOT. thoughts?
+(04:56:55 PM) eyedeekay: I think a number is a number as long as the one we choose is on top when standard tools sort it, and in light of that, 9.51 has some appeal.
+(04:57:52 PM) zlatinb: If we had a roadmap for installers I would put a nice round 1.0.0 after those are finished, but we don't have such a roadmap, so I'd rather avoid 1.0.0 altogether.  Other than that 0.9.51 or 9.51 are the same to me.
+(04:58:27 PM) zzz: don't necessarily need consensus today either, we have two more meetings before the next release
+(04:59:04 PM) zzz: could always do a reddit poll although that may be counterproductive
+(05:01:40 PM) zzz: let's discuss again next month eyedeekay 
+(05:01:41 PM) zzz: eot
+(05:02:15 PM) eyedeekay: I do agree with zlatinb, if we were to use "1.0.0" as PR to seek new users, improving the installers would probably make such an effort more successful. If we wanted to preserve the opportunity to do do a 1.0.0 when that is done then we'd need to do 0.9.51, eot
+(05:02:28 PM) eyedeekay: 8) 0.9.50 status / remaining release items
+(05:03:16 PM) eyedeekay: zzz added this, but there's at least two of these I should probably answer for, GPlay and F-Droid
+(05:04:27 PM) eyedeekay: There was a bit of a mess with GPlay during release time, I had to migrate us to an Android app bundle which requires me to generate a key and upload it to Google so that they could confirm I was the one uploading the app
+(05:05:16 PM) eyedeekay: I failed at this process the first time which required me to contact google support, which caused a delay in the Android releases
+(05:05:47 PM) eyedeekay: For reasons related to the release process, this also delayed F-Droid builds.
+(05:06:33 PM) eyedeekay: From now on, F-Droid will be an apk, and Google Play will be an .aab, and the release process for one will not depend on the other. EOT.
+(05:06:46 PM) eyedeekay: Anything to add zzz?
+(05:07:20 PM) zzz: debian is the big issue. anybody heard from mhatta? he completely missed .49, now we're waiting on 50
+(05:09:01 PM) eyedeekay: Not in quite a while unfortunately, I can reach out again
+(05:09:08 PM) zzz: as far as net status, about 35-45% of net updated, about 25% have rekeyed, very smooth, no major complaints
+(05:09:08 PM) zzz: please keep this item on the agenda for next month, since we're not done yet
+(05:09:08 PM) zzz: eot
+(05:09:34 PM) eyedeekay: Will do
+(05:09:47 PM) eyedeekay: Anything else for 8?
+(05:10:00 PM) eyedeekay: Or in general? timeout 1m
+(05:11:26 PM) eyedeekay: All right then, thanks for coming everybody, next meeting will be July 6

i2p2www/meetings/logs/300.rst

@@ -0,0 +1,12 @@
+I2P dev meeting, June 1, 2021 @ 20:00 UTC
+=========================================
+
+Quick recap
+-----------
+
+* **Present:**
+
+eyedeekay,
+zzz,
+zlatinb,
+psi

i2p2www/meetings/logs/301.log

@@ -0,0 +1,69 @@
+(04:01:20 PM) eyedeekay: Hi everyone, it's time for the monthly community meeting, but as I forgot to make the announcement I will not be surprised if no one is here. In case anyone else is here, I'm open to having the meeting now. If no one else is here, I'll announce a new one on zzz.i2p so we can re-schedule
+(04:01:37 PM) zzz: hi
+(04:01:47 PM) eyedeekay: Hi zzz
+(04:02:10 PM) eyedeekay: zlatinb, anybody else here?
+(04:03:39 PM) eyedeekay: Ok that's my bad. Well zzz, I've got a short 2-item agenda for us if you've got time:
+(04:03:39 PM) eyedeekay: 2) Next Version Number
+(04:03:39 PM) eyedeekay: 3) Jpackage Updates
+(04:03:39 PM) eyedeekay: But I was hoping to have zlatinb for 3)
+(04:04:06 PM) zzz: 4) remaining 0.9.50 release items
+(04:04:31 PM) eyedeekay: Ack
+(04:05:10 PM) eyedeekay: 2) Next version number
+(04:06:27 PM) eyedeekay: I'm less and less reluctant about 1.0.0 now
+(04:07:31 PM) eyedeekay: zlatinb had some ideas about where performance could be improved, and what we both agreed on was that we needed something more onboardable for 1.0.0, i.e. the jpackage things
+(04:08:05 PM) zzz: I think an arbitrary jump to something like 1.5.0 or 2.5.0 or 5.1 avoids the 1.0.0 angst
+(04:10:04 PM) mode (+v zlatinb) by ChanServ
+(04:11:37 PM) eyedeekay: 1.5.0 seems right somehow? or maybe 1.51
+(04:12:22 PM) zzz: small numbers seem better
+(04:12:48 PM) eyedeekay: Yeah you're right
+(04:13:36 PM) eyedeekay: 1.5.0 works for me if it works for you
+(04:15:13 PM) zzz: I'll put it in a post on my forum and see what the reaction is
+(04:15:30 PM) eyedeekay: Sounds good
+(04:16:05 PM) eyedeekay: 3) Jpackage Updates
+(04:17:24 PM) eyedeekay: On my end I've got a WIP jpackage+Windows Installer+Firefox profile bundle which should be self-updating as of this morning. It's still untested and a draft PR, I'm sure I'll find something broken about it tonight, but so far, so good
+(04:17:35 PM) mode (+v anonymousmaybe) by ChanServ
+(04:18:55 PM) eyedeekay: It works by starting the installer just before the router shuts down, sleeping until the router shuts down, then allowing the installer to re-start the router when it completes
+(04:19:25 PM) zlatinb: not much on my end, I'm still a little stuck on figuring out how to an end-to-end test that starts from checking news.xml, fetching the update.dmg, performing the update, restarting the router
+(04:19:41 PM) zlatinb: but the concept is the same as on windows
+(04:22:35 PM) zlatinb: just quite a bit of infrastructure to set up I guess
+(04:23:01 PM) eyedeekay: I don't have much else to add, except that I'm going to try to figure out how to test it against a test news server tonight, which should help figure out the infrastructure
+(04:24:13 PM) eyedeekay: 4) Remaining 0.9.50 release items
+(04:24:27 PM) eyedeekay: Oops, pasted that too soon
+(04:24:37 PM) eyedeekay: Anything else on 3)?
+(04:25:02 PM) eyedeekay: 4) Remaining 0.9.50 release items
+(04:25:10 PM) zzz: still no debian/ubuntu, who's in charge of bugging mhatta?
+(04:25:40 PM) eyedeekay: I've been bugging him as much as I can, opened a PR on bote to get his attention, not sure what's up there. No response
+(04:26:11 PM) eyedeekay: Maybe I'm just not looking in the right place anymore
+(04:26:25 PM) zzz: it's now been 7 months since he cut a release
+(04:27:40 PM) zzz: anyway, I believe that's the only remaining item
+(04:28:12 PM) eyedeekay: I heard Debian accepts anonymous maintainers if they have a portfolio and a GPG key now, I could reach out and apply? I hate to make myself even more of a bus factor, but at least I pretty much know how to go from i2p.i2p->deb
+(04:30:17 PM) zzz: the problem is that I think he has several changes he never upstreamed back to us, so those differences would have to be resolved
+(04:31:53 PM) eyedeekay: If he does then I think they'd have to be reflected in the debian/patches, maybe I can find a way
+(04:31:53 PM) zzz: thats all I got, put it on the list for next month
+(04:32:00 PM) eyedeekay: Will do
+(04:32:16 PM) zlatinb: for this item I want to ask about the streaming buffer overflow
+(04:32:43 PM) zlatinb: is that something we want addressed for the next release?
+(04:32:50 PM) zzz: huh?
+(04:32:57 PM) zlatinb: s/overflow/choke/
+(04:33:14 PM) zzz: what item?
+(04:33:23 PM) zlatinb: oh sorry, thought we were discussing 0.9.51
+(04:33:27 PM) zlatinb: nvm
+(04:33:32 PM) zzz: but no, not a pressing problem, more of a test issue, low priority
+(04:34:01 PM) zzz: we were discussing .50 debs
+(04:34:32 PM) eyedeekay: I've got time, if zzz's got time I'm happy to make that item 5)
+(04:34:44 PM) zlatinb: yes please
+(04:34:49 PM) eyedeekay: Go for it
+(04:35:11 PM) zlatinb: I think it happens in the live net on short tunnels, not 0 but 1-hop
+(04:35:41 PM) zlatinb: at least I've seen suspicious behavior in muwire when configured with 1-hop tunnels on both nodes
+(04:36:24 PM) eyedeekay: I have a bunch of 1-hop services, is there anything I can look for in the logs to help you confirm it?
+(04:37:12 PM) zlatinb: at this early stage it can be debugged in a testnet, logging is too verbose for a live server
+(04:37:58 PM) zlatinb: I would like to spend some time on that and if there is a problem and a fix for it aim to put it in the next release
+(04:39:21 PM) zzz: to answer your question, it's a known issue for many years, presumed very rare in live net, the impacts are transient and possibly unfixable... so it's worth investigating (and I asked for help doing that), but for those reasons I wouldn't put it as a must-fix for the next release
+(04:39:56 PM) zlatinb: I think the recent speed improvements have made it less rare
+(04:40:31 PM) zzz: sure. maybe, maybe not
+(04:41:17 PM) zlatinb: ok I'll investigate and see what comes out
+(04:41:35 PM) eyedeekay: It'll be interesting to see what you find
+(04:42:10 PM) eyedeekay: Anything else for the meeting?
+(04:43:09 PM) eyedeekay: All right then that's it for today
+(04:43:18 PM) eyedeekay: Thanks zlatinb and zzz for being and bearing with me, I'll post the logs shortly and make sure I get the announcement up on zzz.i2p this time
+(04:43:24 PM) eyedeekay: being *here

i2p2www/meetings/logs/301.rst

@@ -0,0 +1,11 @@
+I2P dev meeting, July 6, 2021 @ 20:00 UTC
+=========================================
+
+Quick recap
+-----------
+
+* **Present:**
+
+eyedeekay,
+zzz,
+zlatinb

i2p2www/meetings/logs/302.log

@@ -0,0 +1,95 @@
+(04:00:31 PM) eyedeekay: 1) Hi 
+(04:00:31 PM) eyedeekay: 2) 0.9.51/1.5.0 
+(04:00:31 PM) eyedeekay: 3) Remaining 0.9.50 items 
+(04:00:31 PM) eyedeekay: 4) Streaming choke findings 
+(04:00:31 PM) eyedeekay: 5) Jpackage Updates 
+(04:00:52 PM) eyedeekay: Hi everybody, time for the Tuesday meeting, who else is here?
+(04:00:58 PM) zlatinb: hi
+(04:01:05 PM) zzz: yo
+(04:01:24 PM) eyedeekay: Cool let's get started
+(04:01:34 PM) eyedeekay: 2) 0.9.51/1.5.0
+(04:01:45 PM) eyedeekay: zzz posted on the forum about the numbering change
+(04:02:06 PM) Irc2PGuest39607: hi!
+(04:02:24 PM) eyedeekay: Hi IRC2PGuest39607
+(04:02:38 PM) zzz: yeah, we preliminary-decided on 1.5.0 last month, how does everybody feel about it a month later?
+(04:02:40 PM) mode (+v anonymousmaybe) by ChanServ
+(04:03:08 PM) eyedeekay: It looks like we didn't get any opninions on it, I'm still OK with 1.5.0 as the next release
+(04:03:45 PM) X: I like moving towards a 1.x.x
+(04:03:47 PM) zzz: me too. will take time to get used to, but it feels like a good idea
+(04:04:17 PM) zlatinb: questions: are the maven jars going to stay at api version?  are plugins going to be checked against api versions?
+(04:05:36 PM) zzz: my guess is no for both
+(04:06:06 PM) zlatinb: ok, as long as it's consistent
+(04:06:51 PM) zzz: think of the API version as the "network version". Anything visible to the user should be release version
+(04:07:30 PM) eyedeekay: That makes sense to me, and I know 1.5.0 will work with our maven releases
+(04:07:42 PM) zzz: idk, may I also give a quick status report here?
+(04:07:50 PM) eyedeekay: Yes go ahead
+(04:08:00 PM) mode (+v anonymousmaybe) by ChanServ
+(04:08:09 PM) zzz: everything is pretty much done for the next release. 10k lines of diff
+(04:08:28 PM) zzz: tag freeze aug 11, checkin deadline aug. 20, release week of aug. 23
+(04:08:31 PM) zzz: EOT
+(04:08:40 PM) eyedeekay: Thanks zzz
+(04:09:02 PM) eyedeekay: Are we ready for 3) Remaining 0.9.50 items?
+(04:09:52 PM) eyedeekay: Right now the remaining release items are the same as the remaining release items for last month, which are Debian package releases
+(04:10:53 PM) zzz: sad story, but at this point all we can do is encourage people to switch to the PPA
+(04:11:08 PM) eyedeekay: I've still not received a response from our maintainer so for current debian packages, the only options are deb.i2p2.de/no and the PPA
+(04:11:49 PM) eyedeekay: I'll go ahead and make it clear on the website that those are the recommended packages
+(04:12:07 PM) eyedeekay: 4) Streaming Choke Findings
+(04:12:55 PM) eyedeekay: This was zlatinb's topic, please share your findings when you are ready zlatinb
+(04:13:20 PM) zlatinb: Choking does happen on the live network, probably due to some miscalculation of receive buffer size (125 vs 128), probably due to ecies MTU changes, dunno
+(04:13:56 PM) zlatinb: I haven't looked into more detail other than to try doubling the receive buffer and verifying that choking no longer occurs
+(04:14:42 PM) zlatinb: in general there are other streaming angles I would like to look into more detail but that will be for the next release. 
+(04:14:45 PM) zlatinb: eot
+(04:14:54 PM) zlatinb: s/next/after next/
+(04:14:57 PM) eyedeekay: Interesting. Thanks for looking into that. Should I include this as a topic for next month as well?
+(04:15:10 PM) zzz: definitely a topic for further research, but I don't think it rises to the level of needing to be an agenda item
+(04:15:30 PM) eyedeekay: OK thanks
+(04:16:11 PM) eyedeekay: Last is 5) jpackage updates
+(04:16:16 PM) zzz: but lets make sure zlatinb agrees?
+(04:16:16 PM) zlatinb: i agree
+(04:16:48 PM) eyedeekay: Ack. I'll leave it off the next agenda then
+(04:17:50 PM) eyedeekay: jpackage updates: zlatinb and I both have been working on jpackage bundles, zab's is for Mac OSX and is a signed DMG based package, mine is for Windows and is an NSIS based EXE that works like the Firefox Profile Installer
+(04:18:30 PM) eyedeekay: We've both been working on getting them to be self-updating and stable, I had a look at zab's work last night and did some catching-up
+(04:19:57 PM) eyedeekay: We've been doing releases of the experimental bundles at the same time as the regular releases before, the 1.5.0 AIO bundle and DMG bundle should be self-updating by then
+(04:20:17 PM) zzz: AIO?
+(04:20:37 PM) eyedeekay: All-in-One, the Windows/jpackage/profile bundle
+(04:21:43 PM) eyedeekay: Anything to add from your side on this zlatinb?
+(04:22:12 PM) zlatinb: the dmg is done and tested, I'm happy to have it as a download option when 1.5.0 comes out
+(04:22:20 PM) zzz: let's be clear what the plan is. We're going to have both of these on the download page, roughly on the same schedule as the rest of the 1.5.0 release? And labeled as what? Alpha? Beta?
+(04:23:11 PM) zlatinb: I would prefer "Alternative download option" rather than an alpha/beta label
+(04:23:35 PM) zlatinb: dmg is definitely not alpha, beta might be ok
+(04:24:19 PM) zzz: I'd also like to have a clear understanding of how we're going to steer people to one or the other. e.g., if you want it to run as a service, don't use this one.
+(04:24:34 PM) zzz: don't need to figure it all out at this meeting but sometime before the release
+(04:25:22 PM) eyedeekay: We've got a separate page for them where we call them "Experimental" for now. I intend to consider the AIO EXE installer "experimental" for one more cycle. For adding it as an alternative download option for Windows users on the lang/download page I intend to label it as such
+(04:25:35 PM) zzz: zlatinb, if it's only been tested by one person so far, then I think we need baby steps and a beta label
+(04:26:05 PM) zlatinb: ok
+(04:26:17 PM) zzz: "alternative" doesn't mean anything, we need to steer people one way or another. Those instructions can change as we get more testing
+(04:27:23 PM) zzz: eyedeekay, last time I peeked at yours, which was a couple weeks ago, you had a long way to go, so you're going to have to hustle, and tell us when it's time to take a look
+(04:28:18 PM) zzz: there's also no particular reason to hit the Aug. 23 mark, or have the same schedule as the dmg, if it's not ready
+(04:28:48 PM) eyedeekay: Sure, I won't be pushing a new version out until I'm pretty sure it will work every single time
+(04:29:38 PM) eyedeekay: I checked in a lot last night after looking through zab's changes but I haven't done a new update test yet
+(04:30:42 PM) zzz: I've spent hours and hours helping zab, and 5 minutes skimming yours... maybe you're getting more help from him, or are just grabbing most of his code, but you need to holler when you're ready
+(04:31:57 PM) eyedeekay: I borrowed a chunk of zab's code and adapted it but otherwise I've just been figuring it out as I go
+(04:32:25 PM) eyedeekay: I'll update the gitlab merge thread shortly to explain where it's the same and where it differs though
+(04:32:49 PM) eyedeekay: *this evening
+(04:33:53 PM) zzz: this goes for anytime we add an "official" release product on our download page or anywhere. It's a big step to add something new and stand behind it, and I don't ever want to add something without a lot of thought, and full consensus
+(04:35:15 PM) eyedeekay: Agreed
+(04:35:43 PM) zzz: :)
+(04:36:40 PM) eyedeekay: I think that we should settle the remaining alpha/beta and download page issues to reach that consensus in one of the jpackage threads on zzz.i2p then
+(04:37:56 PM) eyedeekay: That's all I had on 5, which brings us to the end of the agenda unless anyone has anything to add?
+(04:38:29 PM) zlatinb: an item for next meeting or the one after that:
+(04:38:44 PM) zlatinb: changes to the news.xml generation workflow to accomodate dmg and exe bundles
+(04:39:07 PM) zlatinb: eot
+(04:39:16 PM) zzz: last thing on 5) is that you two and echelon must have an agreed plan for the news, yes.
+(04:40:12 PM) eyedeekay: I'll put it on the agenda for the next month announcement and get in touch with ech on my side
+(04:40:12 PM) eyedeekay: Last minute addition from me, I'll be at Def Con from late Thursday until Monday, spending a most of the time at the CryptoCurrency village, I'll be helping people figure out Bitcoin and Monero I2P integrations
+(04:40:43 PM) zzz: what that probably means in practice is zlatinb telling idk and echelon some of the preliminary decisions and going from there
+(04:40:53 PM) zzz: eot, sorry slow typing
+(04:41:30 PM) eyedeekay: That sounds like good place to start
+(04:41:51 PM) zzz: great, have fun, good luck. You have a guess on the best time for people to find you, or clues how to track you down?
+(04:43:36 PM) eyedeekay: Crypto Village table is probably the best place to look, I marked 1-3 every day on the form but it'll probably be a little before 1, a little after 3
+(04:44:29 PM) eyedeekay: I'll get myself an ActivityPub account so people can toot at me other times
+(04:44:44 PM) zzz: ok, haven't seen any PR yet, about time to spin up sadie on twitter, and/or some reddit and forum posts
+(04:45:16 PM) eyedeekay: Will do
+(04:46:22 PM) eyedeekay: Anything else for the meeting? timeout 1m
+(04:47:38 PM) eyedeekay: All right thanks everybody
+(04:48:31 PM) eyedeekay: See you around IRC, next month's meeting will be September 7

i2p2www/meetings/logs/302.rst

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

i2p2www/meetings/logs/303.log

@@ -0,0 +1,115 @@
+(04:02:11 PM) eyedeekay: Hi everyone, sorry for the short notice, welcome to the September 7th meeting
+(04:02:11 PM) eyedeekay: 1) Hi
+(04:02:11 PM) eyedeekay: 2) Remaining 0.9.50/1.5.0 items
+(04:02:11 PM) eyedeekay: 3) Debian Repository Changes
+(04:02:11 PM) eyedeekay: 4) Jpackage Distributions
+(04:02:11 PM) eyedeekay: 5) 1.6.0 plans
+(04:03:12 PM) zlatinb: hi
+(04:03:21 PM) eyedeekay: Hi zlatinb
+(04:04:21 PM) eyedeekay: OK we can just get started, if anybody else joins us mid meeting please chime in and let us know you're here
+(04:04:49 PM) zzz: hi
+(04:04:54 PM) eyedeekay: Hi zzz
+(04:05:03 PM) eyedeekay: I'll take 2) remaining 0.9.50 items and 1.5.0 items
+(04:05:41 PM) serempa: hi
+(04:05:55 PM) eyedeekay: Hi serempa, welcome to the community meeting
+(04:06:19 PM) serempa: oh lucky me :)
+(04:06:20 PM) eyedeekay: It's the usual story, our Debian upstream package maintained by mhatta is not up to date, at this point we recommend that you use the project debian repository, newly under my administration at http(s)://deb.i2p2.de
+(04:06:54 PM) eyedeekay: First Tuesday of every month, 8PM UTC, tell your friends :)
+(04:07:19 PM) serempa: hmm actually I'm using i2pd 
+(04:07:28 PM) zzz: looks like our f-droid and official f-droid still todo eyedeekay ?
+(04:07:41 PM) eyedeekay: Yes I was just coming to that
+(04:09:26 PM) eyedeekay: I am still getting the F-Droid repository updated, I have no control over when official F-Droid gets updated so the recommendation will be similar, our F-Droid will be updated before the official F-Droid repository is
+(04:10:23 PM) eyedeekay: So for up-to-date packages our self-hosted F-Droid is likely required
+(04:10:48 PM) zzz: I don't see anything else that's missing
+(04:11:42 PM) eyedeekay: Those are the only two release products remaining
+(04:12:35 PM) serempa: sorry to ask but any arm packages maintained by someone?
+(04:13:16 PM) zzz: we work on any platform that has java
+(04:13:20 PM) serempa: in rpi repos its 0.9.38-3.1
+(04:13:47 PM) eyedeekay: That's raspbian without adding deb.i2p2.de to the sources.list?
+(04:14:01 PM) eyedeekay: Just to be clear serempa?
+(04:14:05 PM) zzz: you can follow the instructions on geti2p.net/debian to use our repo serempa
+(04:14:21 PM) serempa: ooh gotcha sorry
+(04:14:23 PM) eyedeekay: Yes it should have up-to-date pi packages
+(04:14:37 PM) eyedeekay: Which brings us to 3) Debian repository changes
+(04:14:37 PM) eyedeekay: We had a DNS issue with the old http://deb.i2p2.no repository
+(04:15:43 PM) eyedeekay: The server we used to use for it is no longer being used for anything, it's been retired. From now on, deb.i2p2.de and deb.i2p2.no are available using both HTTP and HTTPS
+(04:16:40 PM) eyedeekay: Please let us know if you run into any issues using the new setup, which should have fewer issues overall
+(04:17:22 PM) eyedeekay: Anything to add on 3)?
+(04:18:07 PM) eyedeekay: 4) Jpackage Distributions
+(04:19:29 PM) eyedeekay: Zab had a successful jpackage release so far, at least, some people are using it
+(04:20:29 PM) eyedeekay: We've got a better idea of how to adapt the news server now so that the jpackages can retrieve news and updates for their distributions
+(04:20:45 PM) eyedeekay: I'm delaying my release until I am able to release a new version of I2P In Private Browsing which includes a few bugfixes and which will set the home page a and search engine
+(04:21:31 PM) eyedeekay: That should be about another week
+(04:21:49 PM) eyedeekay: Anything else on 4) zlatinb? zzz?
+(04:22:06 PM) zlatinb: oops wait
+(04:22:06 PM) zlatinb: lag lag
+(04:22:37 PM) eyedeekay: Not a problem, go ahead zlatinb
+(04:22:39 PM) zlatinb: yes, the mac dmg is getting ~25 downloads/day on average
+(04:22:44 PM) eyedeekay: Nice!
+(04:23:10 PM) zlatinb: the /en/download/mac page gets good traffic too.  A lot of people visit it after trying to download the .jar
+(04:23:50 PM) zzz: back sorry, computer issues
+(04:24:12 PM) eyedeekay: (04:22:39 PM) zlatinb: yes, the mac dmg is getting ~25 downloads/day on average
+(04:24:12 PM) eyedeekay: (04:22:44 PM) eyedeekay: Nice!
+(04:24:12 PM) eyedeekay: (04:23:10 PM) zlatinb: the /en/download/mac page gets good traffic too.  A lot of people visit it after trying to download the .jar
+(04:24:24 PM) eyedeekay: In case you need it^
+(04:25:09 PM) zzz: have you three resolved the news server URL issues yet?
+(04:25:39 PM) zlatinb: which doesn't work at all on recent Mac OS versions because notarization
+(04:25:39 PM) zlatinb: eot
+(04:25:39 PM) zlatinb_ is now known as zlatinb
+(04:25:47 PM) zlatinb: bad lag, sorry
+(04:27:00 PM) eyedeekay: Not yet, zlatinb when would be a good time for us to meet and talk about the remaining news URL issues? I have one or two questions for you about requirements for that, if we could meet this week that would be enough
+(04:27:42 PM) zlatinb: yes, I'm happy to do the python changes once we agree on how to handle things
+(04:27:56 PM) zlatinb: the big question is do we want separate news feeds for the different products or just different metadata
+(04:28:05 PM) zlatinb: we need to decide on that
+(04:29:45 PM) eyedeekay: Then I'd like to do a quick voice meeting for that sometime this week, we can schedule later, I'm not sure which pros and cons I care about yet
+(04:30:01 PM) zlatinb: sure
+(04:30:08 PM) eyedeekay: Sounds good
+(04:30:21 PM) eyedeekay: Anything else for 4)?
+(04:30:30 PM) zzz: you'll need a different feed the first time you do an in-between update, e.g. for java
+(04:31:17 PM) zzz: be sure to include echelon as he may have his own issues
+(04:32:19 PM) eyedeekay: In-between like from non-jpackage to jpackage? On my side that's "disabled" the NSIS installer won't over-write an IzPack installer if it finds one
+(04:33:01 PM) zzz: couldn't think of the right word. I mean an intermediate release, between the upstream releases, e.g. 1.5.1
+(04:33:10 PM) eyedeekay: Oh I see
+(04:33:20 PM) eyedeekay: That makes sense, thanks for pointing that out
+(04:33:50 PM) eyedeekay: I'll send out a group email so we're all looped in
+(04:34:12 PM) eyedeekay: And we'll definitely need those because of OpenJDK releases
+(04:34:34 PM) eyedeekay: So we definitely care
+(04:35:13 PM) eyedeekay: OK anything else for 4)?
+(04:36:21 PM) eyedeekay: That brings us to 5) 1.6.0 plans
+(04:37:45 PM) eyedeekay: We should probably just take a moment to write out our plans down, timeout 3min
+(04:38:23 PM) zzz: I've updated the roadmap on the website for 1.5.0 and 1.6.0 - eyedeekay please review and fixup your items
+(04:38:45 PM) zlatinb: I'm going to see if there is a quick fix for the SSU slowness that I've observed in the testnet.  If it's something simple like a delayed ack taking too long I think we can put it in 1.6.0
+(04:39:04 PM) zlatinb: if it turns out to be more complicated then it's not really worth it as we're working on replacement
+(04:39:40 PM) zzz: I don't have a lot on my list for 1.6.0... at this point my main priority is SSU2, which is very early days, I don't expect it to be completed before mid next year
+(04:39:52 PM) eyedeekay: Ack, zzz, I will do this evening
+(04:39:52 PM) eyedeekay: I brought copypasta, this is the list taped to my bookshelf:
+(04:39:52 PM) eyedeekay: Code/Packaging:
+(04:39:52 PM) eyedeekay: 1) Eliminate the class of "Unmanaged" plugins, make Fork-and-Exec plugins manageable.
+(04:39:52 PM) eyedeekay: 2) Add support for Client-Side of X-I2P-Location to HTTP Proxy
+(04:39:52 PM) eyedeekay: 3) Debianize the I2P Browser Profile
+(04:39:52 PM) eyedeekay: 4) Pluginize the I2P Browser Profile
+(04:39:52 PM) eyedeekay: 5) Move goSam and sam3 to i2pgit.org instead of Github
+(04:39:52 PM) eyedeekay: 6) Clean up sam-forwarder UDP tunnels and move to go-i2p namespace
+(04:39:52 PM) eyedeekay: 7) Finally fix and merge go-i2p changes upstream
+(04:39:52 PM) eyedeekay: Web/Documentation:
+(04:39:52 PM) eyedeekay: 1) Document "How to Use" I2P for Android Browsing, Mail, Bittorrent
+(04:39:52 PM) eyedeekay: 2) Split download page into managable chunks, redirect to page by OS
+(04:39:52 PM) eyedeekay: 3) Document Jpackage install processes on Web Site
+(04:39:52 PM) eyedeekay: Misc:
+(04:39:52 PM) eyedeekay: 1) Migrate i2p.keyring.i2p to i2pgit.org
+(04:39:52 PM) eyedeekay: 2) Pluginize my other apps(BRB, Railroad, reseed-tools)
+(04:39:52 PM) eyedeekay: 3) Go rewrite of News Server(newsxml-tools)
+(04:39:52 PM) eyedeekay: 4) Generic Go SU3 Signing tool
+(04:40:33 PM) zzz: eyedeekay, I need misc #1 this week please
+(04:40:47 PM) eyedeekay: Absolutely
+(04:40:54 PM) zzz: super, thx
+(04:41:10 PM) eyedeekay: No problem
+(04:42:03 PM) eyedeekay: Anything else on 5)?
+(04:43:21 PM) eyedeekay: Anything else for the meeting? Timeout 2m in case of lag
+(04:43:53 PM) zlatinb: hmm yes has anyone noticed terrible lag today?  I'm also having to try up to 10 times to push something to git.idk.i2p
+(04:46:39 PM) eyedeekay: I have noticed some inconsistent difficulties pushing to git.idk.i2p in the past week
+(04:48:07 PM) eyedeekay: Usually gone in a few minutes but requiring multiple retries
+(04:49:37 PM) eyedeekay: I have it configured for 6 tunnels and 2 backup tunnels using one hop right now
+(04:54:59 PM) eyedeekay: It isn't multihomed but I could make it so
+(04:55:08 PM) eyedeekay: If there's anything else for the meeting? timeout 1m
+(04:57:26 PM) eyedeekay: All right thanks for coming everyone, same time next month, I'll post the meeting minutes to the site shortly

i2p2www/meetings/logs/303.rst

@@ -0,0 +1,11 @@
+I2P dev meeting, September 7, 2021 @ 20:00 UTC
+==============================================
+
+Quick recap
+-----------
+
+* **Present:**
+
+eyedeekay,
+zzz,
+zlatinb

i2p2www/meetings/logs/304.log

@@ -0,0 +1,74 @@
+(04:00:04 PM) eyedeekay: Hi everyone welcome to the community meeting
+(04:00:04 PM) eyedeekay: 1) Hi
+(04:00:04 PM) eyedeekay: 2) Remaining 0.9.50/1.5.0 items
+(04:00:04 PM) eyedeekay: 3) Jpackage Distributions
+(04:00:04 PM) eyedeekay: 4) 1.6.0 Development Status
+(04:00:15 PM) mode (-m ) by zzz
+(04:00:16 PM) eyedeekay: 1) Hi who is here today?
+(04:00:24 PM) zlatinb: hi
+(04:00:24 PM) zzz: here
+(04:00:48 PM) eyedeekay: Hi zzz, hi zlatinb
+(04:01:30 PM) eyedeekay: 2) Remaining 0.9.50/1.5.0 items
+(04:02:21 PM) eyedeekay: It's the same story here as last meeting, we currently cannot reach mhatta, and our debian main packages are therefore not updated
+(04:02:55 PM) eyedeekay: The official recommendation for installing I2P on Debian and Ubuntu will be changing in the next release to use our own .deb repository/PPA
+(04:03:26 PM) eyedeekay: We're also updating the instructions to reflect some recommendations which will make usage of our repository more secure
+(04:03:52 PM) eyedeekay: In the new setup, our .deb package signing keys will only be valid for our packages, instead of across all packages
+(04:04:04 PM) eyedeekay: Current deb/ubuntu users will not need to change anything
+(04:05:04 PM) eyedeekay: That's all I have for 2) anything from anyone else?
+(04:05:23 PM) T3s|4: eyedeekay:  ^all noted, and I am also present
+(04:06:21 PM) eyedeekay: Thanks T3s|4
+(04:06:21 PM) eyedeekay: Timeout 1m for 2)
+(04:07:36 PM) eyedeekay: OK 3) Jpackage Distributions
+(04:08:02 PM) zlatinb: I have two items for this topic, both not good
+(04:08:18 PM) eyedeekay: OK maybe you should start us off then
+(04:08:42 PM) zlatinb: 3.1 - the Mac DMG was not deployed properly to the sigterm.no mirror and I discovered it two weeks after release
+(04:09:11 PM) zlatinb: which is a major fail, we need to understand why it happened and how can we prevent it in future
+(04:09:30 PM) zlatinb: 3.2 - I just tried the windows AIO on a fresh windows 10 VM with just Firefox installed, and the .bat couldn't launch the I2P.exe
+(04:09:50 PM) zlatinb: launching I2P.exe manually worked fine, but something in the connection between the two failed
+(04:09:50 PM) zzz: what is AIO?
+(04:09:55 PM) eyedeekay: Easy-Install
+(04:09:56 PM) zlatinb: All-In-One
+(04:10:17 PM) zlatinb: EOT
+(04:11:42 PM) eyedeekay: The sigterm.no fail was partly my fault, I've resolved the issue there which had to do with the way I used to do mirror-syncing.
+(04:12:13 PM) eyedeekay: Re the Windows bundle, that should definitely not be the case, not good. I'll follow up with it on i2p.firefox as soon as the meeting is over, thanks for bringing it to my attention.
+(04:12:50 PM) zlatinb: ok, happy to help debug in any way
+(04:14:54 PM) eyedeekay: OK on my side I'm testing the changes to i2p.newsxml for us to do updates with, should be ready to review this week, there are some minor changes to the instructions for running the news server I'll need to go over with ech but we're already in communication about that
+(04:16:03 PM) zzz: 3.3 re: bundles for OSX, I recommend we advertise that they are untested on ARM Macs, that performance is unknown, and we should solicit testers
+(04:16:17 PM) eyedeekay: Yes agreed, I can make that change to the web site tonight
+(04:16:19 PM) zzz: and from that, decide when to start making ARM builds
+(04:17:17 PM) eyedeekay: Will do
+(04:17:20 PM) zzz: note that Java 17 in theory supports OSX ARm native, but I don't know if any of the openjdk-type sites have the JRE builds yet
+(04:18:26 PM) zzz: EOT, thx
+(04:18:38 PM) zlatinb: building for Mac aarch64 needs to happen on Mac aarch64 because jpackage
+(04:18:55 PM) zlatinb: so that means I need to get an ARM Mac at some point
+(04:19:12 PM) zlatinb: or someone else needs to get an Apple dev account
+(04:19:31 PM) zlatinb: eot
+(04:20:35 PM) eyedeekay: My Mac is also x86_64 unfortunately or I'd offer to do it
+(04:21:17 PM) eyedeekay: Anything else for 3)?
+(04:22:19 PM) eyedeekay: OK then 4) is 1.6.0 Development Status
+(04:25:17 PM) eyedeekay: zzz's been keeping us up to date with his developments and status here: http://zzz.i2p/topics/3170-1-6-0-release-summary           
+(04:25:20 PM) eyedeekay: 6 weeks in, approx. 7 weeks to go
+(04:25:40 PM) eyedeekay: One of my two big planned changes for the router console isn't likely to go in, X-I2P-Locations in the HTTP proxy
+(04:26:10 PM) eyedeekay: The other, managing fork-and-forget plugins are going to be ready this week
+(04:27:10 PM) eyedeekay: Work on SSU2 continues in #LS2
+(04:27:10 PM) eyedeekay: zlatinb and zzz have also been identifying and debugging performance issues in SSU1
+(04:27:26 PM) eyedeekay: Anything to add zzz, zlatinb
+(04:27:28 PM) eyedeekay: ?
+(04:28:07 PM) zzz: so far there's not a lot of big things in this release
+(04:28:21 PM) zzz: very small diff as of now
+(04:28:50 PM) zzz: let's get any other big changes in soon
+(04:29:36 PM) eyedeekay: I'm not letting anything big or drastic go past this weekend for me. If I can't get it done by Monday I'll stick to small stuff.
+(04:29:40 PM) zzz: should be on track for a late Nov. release
+(04:30:43 PM) zzz: eot
+(04:30:45 PM) zzz: oh, also awaiting a post-EOL Jetty 9.3.30 release with some CVE backports. They've tagged it but not posted the builds yet, that's typical for them
+(04:31:43 PM) eyedeekay: If they wait to long to post the builds would it require delaying the release?
+(04:32:37 PM) zzz: should only be a week or so. if for some reason they don't do it, we can just take their patches
+(04:33:02 PM) eyedeekay: OK, thanks for clarifying
+(04:33:35 PM) eyedeekay: Is there anything else for 4) and if not, is there anything anyone else would like to discuss while we're here?
+(04:35:03 PM) eyedeekay: Timeout 1m
+(04:35:04 PM) zzz: if anybody with a registered nick wants voice, let me know before I click the 'm' button. sorry for the inconvenience
+(04:37:10 PM) eyedeekay: OK everybody thanks for coming to the meeting
+(04:37:10 PM) eyedeekay: See you around IRC and at the meeting next month
+(04:37:20 PM) eyedeekay: I've got some website updates to make
+(04:37:59 PM) eyedeekay: Please note zzz's ^ statement about voice on the IRC server
+(04:40:00 PM) eyedeekay: Oh one other thing, I'm going to be out-of-town Thursday and Friday, I'll be working offline those days. Message idk_afk if I'm not online and I will see it by the evening

i2p2www/meetings/logs/304.rst

@@ -0,0 +1,12 @@
+I2P dev meeting, Sept 7, 2021 @ 20:00 UTC
+=========================================
+
+Quick recap
+-----------
+
+* **Present:**
+
+eyedeekay,
+zzz,
+zlatinb,
+T3s|4

i2p2www/pages/downloads/browser-content.html

@@ -71,7 +71,7 @@ Chrome is available. In order to configure it, create a new <em>Profile</em>
 especially for your I2P browsing, separate from the default profile. Then install
 this <a href="https://chrome.google.com/webstore/detail/i2pchromejs/ikdjcmomgldfciocnpekfndklkfgglpe"><em>Extension</em></a> in your newly-created profile. This profile
 is now configured to use I2P. Highly detailed instructions are available at the
-<a href="https://eyedeekay.github.io/I2P-Configuration-for-Chromium">homepage.</a>
+<a href="https://eyedeekay.github.io/I2P-Configuration-For-Chromium">homepage.</a>
 {% endtrans %}</p>
 <h4>{% trans %}All Chrome Versions{% endtrans %}</h4>
 <p>{% trans -%}

i2p2www/pages/downloads/docker.html

@@ -0,0 +1,109 @@
+{% extends "global/layout.html" %}
+{% block title %}Docker{% endblock %}
+{% block accuratefor %}0.9.50{% endblock %}
+{% block content %}
+<h1 id="i2p-in-docker">{% trans -%}Installing I2P in Docker{%- endtrans %}</h1>
+<h3 id="quick-start">{% trans -%}Very quick start{%- endtrans %}</h3>
+<p>{% trans -%}If you just want to give I2P a quick try, follow these steps{%- endtrans %}:</p>
+<ol>
+<li>{% trans -%}Create two directories "i2pconfig" and "i2ptorrents"{%- endtrans %}</li>
+<li>{% trans -%}Copy the following text and save it in a file "docker-compose.yml".{%- endtrans %}</li>
+<pre><code>
+version: "3.5"
+services:
+    i2p:
+        image: geti2p/i2p
+        network_mode: host
+        volumes:
+            - ./i2pconfig:/i2p/.i2p
+            - ./i2ptorrents:/i2psnark
+</code></pre>
+<li>{% trans -%}Execute "docker-compose up"{%- endtrans %}</li>
+<li>{% trans -%}Start a browser and go to http://127.0.0.1:7657 to complete the setup wizard.{%- endtrans %}</li>
+</ol>
+<p>{% trans -%}<p>Note that this quick-start approach is not suitable for production use.  If you want to use I2P in production please read all the instructions on this page.{%- endtrans %}</p>
+<h3 id="building-an-image">{% trans -%}Building an image{%- endtrans %}</h3>
+<p>{% trans -%}There is an i2P image available over at <a href="https://hub.docker.com">DockerHub</a>. If you do not want to use that one, you can build one yourself:{%- endtrans %}</p>
+<pre><code>docker build -t i2p .</code></pre>
+<h3 id="running-a-container">{% trans -%}Running a container{%- endtrans %}</h3>
+<h4 id="volumes">{% trans -%}Volumes{%- endtrans %}</h4>
+<p>{% trans -%}The container requires a volume for the configuration data to be mounted. Optionally, you can mount a separate volume for torrent (“i2psnark”) downloads. See the example below.{%- endtrans %}</p>
+<h4 id="memory-usage">{% trans -%}Memory usage{%- endtrans %}</h4>
+<p>{% trans -%}By the default the image limits the memory available to the Java heap to 512MB. You can override that with the <code>JVM_XMX</code> environment variable.{%- endtrans %}</p>
+<h4 id="ports">{% trans -%}Ports{%- endtrans %}</h4>
+<p>{% trans -%}There are several ports which are exposed by the image. You can choose which ones to publish depending on your specific needs.{%- endtrans %}</p>
+<table>
+<thead>
+<tr class="header">
+<th>{% trans -%}Port{%- endtrans %}</th>
+<th>{% trans -%}Description{%- endtrans %}</th>
+<th>{% trans -%}TCP/UDP{%- endtrans %}</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td>4444</td>
+<td>{% trans -%}HTTP Proxy{%- endtrans %}</td>
+<td>{% trans -%}TCP{%- endtrans %}</td>
+</tr>
+<tr class="even">
+<td>4445</td>
+<td>{% trans -%}HTTPS Proxy{%- endtrans %}</td>
+<td>{% trans -%}TCP{%- endtrans %}</td>
+</tr>
+<tr class="odd">
+<td>6668</td>
+<td>{% trans -%}IRC Proxy{%- endtrans %}</td>
+<td>{% trans -%}TCP{%- endtrans %}</td>
+</tr>
+<tr class="even">
+<td>7654</td>
+<td>{% trans -%}I2CP Protocol{%- endtrans %}</td>
+<td>{% trans -%}TCP{%- endtrans %}</td>
+</tr>
+<tr class="odd">
+<td>7656</td>
+<td>{% trans -%}SAM Bridge TCP{%- endtrans %}</td>
+<td>{% trans -%}TCP{%- endtrans %}</td>
+</tr>
+<tr class="even">
+<td>7657</td>
+<td>{% trans -%}Router console{%- endtrans %}</td>
+<td>{% trans -%}TCP{%- endtrans %}</td>
+</tr>
+<tr class="odd">
+<td>7658</td>
+<td>{% trans -%}I2P Site{%- endtrans %}</td>
+<td>{% trans -%}TCP{%- endtrans %}</td>
+</tr>
+<tr class="even">
+<td>7659</td>
+<td>{% trans -%}SMTP Proxy{%- endtrans %}</td>
+<td>{% trans -%}TCP{%- endtrans %}</td>
+</tr>
+<tr class="odd">
+<td>7660</td>
+<td>{% trans -%}POP Proxy{%- endtrans %}</td>
+<td>{% trans -%}TCP{%- endtrans %}</td>
+</tr>
+<tr class="even">
+<td>12345</td>
+<td>{% trans -%}I2NP Protocol{%- endtrans %}</td>
+<td>{% trans -%}TCP and UDP{%- endtrans %}</td>
+</tr>
+</tbody>
+</table>
+<p>{% trans -%}You probably want at least the Router Console (7657) and the HTTP Proxy (4444). If you want I2P to be able to receive incoming connections from the internet, and hence not think it’s firewalled, publish the I2NP Protocol port (12345) - but make sure you publish to a different random port, otherwise others may be able to guess you’re running I2P in a Docker image.{%- endtrans %}</p>
+<h4 id="example">{% trans -%}Example{%- endtrans %}</h4>
+<p>{% trans -%}Here is an example container that mounts <code>i2phome</code> as home directory, <code>i2ptorrents</code> for torrents, and opens HTTP Proxy, IRC, Router Console and I2NP Protocols. It also limits the memory available to the JVM to 256MB.{%- endtrans %}</p>
+<pre><code>docker run \
+    -e JVM_XMX=256m \
+    -v i2phome:/i2p/.i2p \
+    -v i2ptorrents:/i2psnark \
+    -p 4444:4444 \
+    -p 6668:6668 \
+    -p 7657:7657 \
+    -p 54321:12345 \
+    -p 54321:12345/udp \  # I2NP port needs TCP and UDP.  Change the 54321 to something random, greater than 1024.
+    i2p:latest</code></pre>
+{% endblock %}

i2p2www/pages/downloads/easyinstall.html

@@ -0,0 +1,133 @@
+{% extends "global/layout.html" %}
+{%- from "downloads/macros" import package_outer with context -%}
+{% block title %}I2P Easy Install Bundle (Beta) for Windows{% endblock %}
+{% block content %}
+
+<h1>{{ _('I2P Easy Install Bundle (Beta) for Windows') }}</h1>
+<p>{% trans firefox="/firefox" -%}
+This is an "All-in-One" installer for Windows 10 which includes the complete I2P
+desktop software and all of its dependencies in a single, easy-to-install
+package. It is built on the premise that I2P should be easy, and that we should
+help our users get their initial configuration in place instead of requiring an
+elaborate install process. To learn more about the Firefox profile that
+comes bundled with this installer, visit <a href="{{ firefox }}">The Firefox
+Profile Page</a>.
+{%- endtrans %}</p>
+<h2>{{ _('What do I need to use it?') }}</h2>
+<p><strong>{% trans -%}
+Just Firefox (Or Tor Browser).{%- endtrans %}</strong>
+{% trans issueurl="https://i2pgit.org/i2p-hackers/i2p.firefox/-/issues/2" -%}
+This installer still requires Firefox to be installed on the system, it does not
+bundle a Firefox installer of its own. Please obtain Firefox from Mozilla, or
+Tor Browser from the Tor Project or one of their mirrors. If you would like to
+discuss supporting other browsers, please join the discussionon the
+<a href="{{ issueurl }}">Gitlab Issue</a>. This is a Windows-only
+product.
+{%- endtrans %}</p>
+<h2>{{ _('Why should I use it?') }}</h2>
+<p>{% trans -%}
+This installer package reduces the number of steps required to install an I2P
+router on Windows from about 30 to a matter of completing a single, familiar
+installer process, combining the I2P installation and Browser configuration into
+the same steps. Besides that, it launches the user directly into the
+automatically configured I2P browser with their applications ready-to-use, with
+no need to refer to potentially unhelpful system-wide Windows settings. The I2P
+it uses is otherwise identical to the "regular" I2P.
+{%- endtrans %}</p>
+<h2>{{ _('How do I use it?') }}</h2>
+<p>{% trans firefox="https://www.mozilla.org/", postfilename=pver('I2P-Profile-Installer-%s.exe') -%}
+First, download and install <a href="{{ firefox }}">Firefox</a>, then,
+just download and install <a href="{{ postfilename }}">this installer</a>. To
+start an installer, "double-click" the downloaded .exe file.
+{%- endtrans %}</p>
+<p>{% trans -%}
+Running the installer will create a shortcut to start browsing I2P in your start
+menu and on your desktop. Clicking this shortcut will start I2P if necessary,
+then start an I2P Browser. On the first run, you will also be promted with the
+bandwidth wizard in your browser window. You will also see a "Toopie" icon in
+your taskbar to indicate that I2P is working when the browser window is closed.
+{%- endtrans %}</p>
+<p>{% trans -%}
+I2P Browsing uses a separate, I2P-Only Firefox
+profile, so it won't interfere with your regular Firefox use or require any
+special configuration. You don't even need to close existing Firefox windows.
+{%- endtrans %}</p>
+
+{%- set name     = 'Windows' -%}
+{%- set icon     = 'images/download/windows.png' -%}
+{%- set filename = 'I2P-Profile-Installer-%s-signed.exe' -%}
+{%- set hash     = 'eadb338a5895f73e6ed4985a9f7dfdac722f74c9bcdd0bd35957e7dcd5759a3a' -%}
+
+{% call package_outer('windows', name, icon) %}
+    <div class = "file">
+	    <a class = "default" href="{{ url_for('downloads_redirect', version=pver(), net=def_mirror.net, protocol=def_mirror.protocol, domain=def_mirror.domain, file=pver(filename) )}}">
+		    <span class = "name">{{ pver(filename) }}</span><br/>
+		    <span class="mirror">{{ _('Mirror:') }} <img src="{{ url_for('static', filename='images/flags/'+def_mirror.country+'.png') }}" /> {{ def_mirror.org }}</span>
+	    </a>
+	    <a class="mirrors" href="{{ get_url('downloads_select', version=pver(), file=pver(filename)) }}">{{ _('select alternate mirror') }}</a>
+    </div>
+    <div class="meta">
+	    <div class="hash">
+		    <code>{{ hash }}</code>
+	    </div>
+    </div>
+    <p>{% trans -%}
+    Download that file and complete the steps it shows.
+    {%- endtrans %}</p>
+{% endcall %}
+
+{% trans signer='zlatinb',
+signingkey=url_for('static', filename='zlatinb.key.crt') -%}
+The files are signed by {{ signer }},
+<a href="{{ signingkey }}">whose key is here</a>.
+{%- endtrans %}
+
+<h2>{{ _('What is in it?') }}</h2>
+<p><strong>{% trans -%}
+A Jpackaged I2P Router: {%- endtrans %}</strong>
+{% trans -%}The I2P router is "jpackaged" which means that it includes all
+the required Java components it needs to run successfully. It does not require
+a separate Java installation, because it bundles a Java 16 Runtime which is only
+used for I2P.
+{%- endtrans %}</p>
+<p><strong>{% trans -%}
+Browser Extensions: {%- endtrans %}</strong>
+{% trans -%}The browser profile also includes both the NoScript and HTTPSEverywhere plugin for
+better protection Javascript based attacks and HTTPS support where available. It
+also keeps your I2P search activity separate from your visible internet search
+activity. The profile configures the I2P Proxy for all sites and browser features.
+I2P In Private Browsing is used to provide I2P-Specific browser integrations.
+{%- endtrans %}</p>
+<h3>{{ _('Source Code and Issue Tracking') }}</h3>
+<div>{% trans -%}
+If you would like to examine the source code for individual components, you may
+find it on i2pgit.org or github.com. The license for each respective component
+can be found in the license directory of the <code>i2p.firefox</code> project.
+{%- endtrans %}</div>
+<div><a href="https://i2pgit.org/i2p-hackers/i2p.firefox">{% trans -%}Gitlab Repository{%- endtrans %}</a></div>
+<div><a href="https://github.com/i2p/i2p.firefox">{% trans -%}Github Repository{%- endtrans %}</a></div>
+<div>{% trans -%}
+If you wish to file an issue about the Firefox profile, please use Gitlab to
+contact us. For security-sensitive issues, please remember to check the
+"This issue is confidential and should only be visible to team members with at least Reporter access"
+option when filing the issue.
+{%- endtrans %}</div>
+<div><a href="https://i2pgit.org/i2p-hackers/i2p.firefox/issues">{% trans -%}Gitlab Repository{%- endtrans %}</a></div>
+<h2>{{ _('How is it different from Tor Browser?') }}</h2>
+<p>{% trans -%}
+This is not a fork of Firefox. Instead, it is a browser profile with pre-configured
+settings, combined with an I2P router and some launcher scripts. That means that
+it requires Firefox(Or Tor Browser) to be installed before you can use it. This
+is for security reasons, it is important that you are able to recieve reliable
+updates from a trustworthy vendor.
+{%- endtrans %}</p>
+<p>{% trans -%}
+I2P routers are designed to have long uptimes, and so unlike Tor Browser, the
+lifetime of your I2P Router is not tied to the lifetime of your I2P browsing
+session. The browser profile will manage your history, your browser's local
+storage and cache, and your browsing context but it will never stop your I2P
+router on its own. You may stop the router using the web interface on the
+router console homepage.
+{%- endtrans %}</p>
+
+{% endblock %}

i2p2www/pages/downloads/firefox.html

@@ -2,22 +2,46 @@
 {%- from "downloads/macros" import package_outer with context -%}
 {% block title %}Firefox Profile{% endblock %}
 {% block content %}
-<h1>{{ _('I2P Firefox Browser Profile') }}</h1>
+
+<h1>{{ _('I2P Easy Install Bundle (Beta) for Windows') }}</h1>
+<p>{% trans nsis="/nsis" -%}
+The I2P Firefox Browser Profile has been expanded into the new I2P Easy Install
+Bundle, which is in Beta. If you already have an I2P Router installed, it is
+still safe to use this installer to configure your I2P Browser. Your existing
+I2P Settings will be left untouched. If you do not have an I2P router installed,
+then you do not need to install I2P. This package will install I2P at the same
+time it installs the browser profile. This page has been kept to document the
+motivations and design of the included Firefox profile. To learn more about the
+new bundle, visit <a href="{{ nsis }}">The Easy Install Bundle Page</a>.
+{%- endtrans %}</p>
+<h2>{{ _('I2P Firefox Browser Profile') }}</h2>
 <p>{% trans -%}
 Now that you have joined the I2P network, you will want to see I2P Sites and and 
-other content that is hosted on the network. The Firefox browser is 
-pre-configured to allow you to access the content available on the network. It 
-also keeps your I2P search activity separate from your internet search activity.
+other content that is hosted on the network. The Firefox browser profile is 
+pre-configured to allow you to access the content available on the network.
 {%- endtrans %}</p>
+<h2>{{ _('Why should I use it?') }}</h2>
 <p>{% trans -%}
-This browser also includes both the NoScrpt and HTTPSEverywhere plugin for
-better protection Javascript based attacks and HTTPS support where available.
+Browsers are highly complex and powerful engines for executing code and displaying
+information obtained mainly from strangers on the internet. By default, they
+tend to leak a great deal of information about the person using them to the servers
+they retrieve information from. Using this browser profile allows you to become
+part of a "common" set of very similar browser users, instead of appearing unique
+or revealing details of your hardware or software. Because this involves disabling 
+some browser features, this also reduces the attack surface available to outsiders. 
+This keeps you safer while browsing the Invisible Web.
+{%- endtrans %}</p>
+<h2>{{ _('How do I use it?') }}</h2>
+<p>{% trans firefox="https://www.mozilla.org/", postfilename=pver('I2P-Profile-Installer-%s.exe') -%}
+First, download and install <a href="{{ firefox }}">Firefox</a>, then,
+just download and install <a href="{{ postfilename }}">this installer</a>. To
+start an installer, "double-click" the downloaded .exe file.
 {%- endtrans %}</p>
 
 {%- set name     = 'Windows' -%}
 {%- set icon     = 'images/download/windows.png' -%}
-{%- set filename = 'I2P-Profile-Installer-%s.exe' -%}
-{%- set hash     = '8eb1e9f69200a42192acabe4686bb3541f7f409b2f9702f2f9e5c6870515fa56' -%}
+{%- set filename = 'I2P-Profile-Installer-%s-signed.exe' -%}
+{%- set hash     = 'eadb338a5895f73e6ed4985a9f7dfdac722f74c9bcdd0bd35957e7dcd5759a3a' -%}
 
 {% call package_outer('windows', name, icon) %}
     <div class = "file">
@@ -43,4 +67,52 @@ The files are signed by {{ signer }},
 <a href="{{ signingkey }}">whose key is here</a>.
 {%- endtrans %}
 
+<h2>{{ _('What is in it?') }}</h2>
+<p><strong>{% trans -%}
+A Jpackaged I2P Router: {%- endtrans %}</strong>
+{% trans -%}The I2P router is "jpackaged" which means that it includes all
+the required Java components it needs to run successfully. It does not require
+a separate Java installation, because it bundles a Java 16 Runtime which is only
+used for I2P.
+{%- endtrans %}</p>
+<p><strong>{% trans -%}
+Browser Extensions: {%- endtrans %}</strong>
+{% trans -%}The browser profile also includes both the NoScript and HTTPSEverywhere plugin for
+better protection Javascript based attacks and HTTPS support where available. It
+also keeps your I2P search activity separate from your visible internet search
+activity. The profile configures the I2P Proxy for all sites and browser features.
+I2P In Private Browsing is used to provide I2P-Specific browser integrations.
+{%- endtrans %}</p>
+<h3>{{ _('Source Code and Issue Tracking') }}</h3>
+<div>{% trans -%}
+If you would like to examine the source code for individual components, you may
+find it on i2pgit.org or github.com. The license for each respective component
+can be found in the license directory of the <code>i2p.firefox</code> project.
+{%- endtrans %}</div>
+<div><a href="https://i2pgit.org/i2p-hackers/i2p.firefox">{% trans -%}Gitlab Repository{%- endtrans %}</a></div>
+<div><a href="https://github.com/i2p/i2p.firefox">{% trans -%}Github Repository{%- endtrans %}</a></div>
+<div>{% trans -%}
+If you wish to file an issue about the Firefox profile, please use Gitlab to
+contact us. For security-sensitive issues, please remember to check the
+"This issue is confidential and should only be visible to team members with at least Reporter access"
+option when filing the issue.
+{%- endtrans %}</div>
+<div><a href="https://i2pgit.org/i2p-hackers/i2p.firefox/issues">{% trans -%}Gitlab Repository{%- endtrans %}</a></div>
+<h2>{{ _('How is it different from Tor Browser?') }}</h2>
+<p>{% trans -%}
+This is not a fork of Firefox. Instead, it is a browser profile with pre-configured
+settings, combined with an I2P router and some launcher scripts. That means that
+it requires Firefox(Or Tor Browser) to be installed before you can use it. This
+is for security reasons, it is important that you are able to recieve reliable
+updates from a trustworthy vendor.
+{%- endtrans %}</p>
+<p>{% trans -%}
+I2P routers are designed to have long uptimes, and so unlike Tor Browser, the
+lifetime of your I2P Router is not tied to the lifetime of your I2P browsing
+session. The browser profile will manage your history, your browser's local
+storage and cache, and your browsing context but it will never stop your I2P
+router on its own. You may stop the router using the web interface on the
+router console homepage.
+{%- endtrans %}</p>
+
 {% endblock %}

i2p2www/pages/downloads/lab.html

@@ -1,191 +0,0 @@
-{% extends "global/layout.html" %}
-{%- from "downloads/macros" import package_outer with context -%}
-{% block title %}I2P Lab{% endblock %}
-{% block content %}
-<h1>{{ _('I2P Laboratory') }}</h1>
-<p>
-{% trans -%}
-Welcome to the I2P Laboratory!
-This is the home of various experimental projects that are not yet ready to go live.
-We invite you to look around and give them a try, but we do not offer support for them.
-Any of these projects may be discontinued at any time.
-{%- endtrans %}
-</p>
-<p>
-{% trans forum='https://i2pforum.net/viewforum.php?f=36' -%}
-We welcome your feedback at the <a href="{{ forum }}">I2P Forum</a>.
-{%- endtrans %}
-<p>
-
-<hr>
-
-<h3>{{ _('Current Projects') }}</h3>
-<div class = "labproject" >
-<h5>{{ _('Zero-Dependency installer') }}</h5>
-<p>
-{% trans forum='https://i2pforum.net/viewforum.php?f=36' %}
-This is an I2P installer for Windows that does not depend on an existing Java installation.
-It includes all required dependencies.
-<p>This installer is built using the Java 9+ utility JLink which bundles a minimum JRE and creates an executable.  The source code is in the monotone branch "i2p.jlink".  After that an NSIS script is used to create the actual installer.  The source code for that script is in the monotone "i2p.wininst" branch.</p>
-<p>You can report bugs in the <a href="{{ forum }}">I2P Lab Forum</a>.</p>
-{%- endtrans %}
-</p>
-{% trans %}
-<p>Status: Proof-Of-Concept</p>
-<p>Known Bugs And Limitations: plugins that use pack200 compression do not work.</p>
-{%- endtrans %}
-
-{%- set name     = 'Windows' -%}
-{%- set icon     = 'images/download/windows.png' -%}
-{%- set filename = 'Zero-I2P0.9.41-JRE11.0.3-INST0.1.exe' -%}
-{%- set hash     = '95dd4a6db5719319c2a5cf509ab3f551114fb76f677ca395e4f20af8ec88c204' -%}
-{% call package_outer('windows', name, icon) %}
-<div class = "file">
-	<a class = "default" href="https://download.i2p2.de/experimental/Zero-I2P0.9.41-JRE11.0.3-INST0.1.exe">
-		<span class = "name">{{ filename }}</span>
-	</a>
-</div>
-<div class = "meta">
-	<div class = "hash">
-		<code>{{ hash }}</code>
-	</div>
-</div>
-<p>{% trans -%}
-Download that file and run it.
-{%- endtrans %}</p>
-{% endcall %}
-</div>
-<!--
-{% trans signer='zlatinb',
-signingkey=url_for('static', filename='zlatinb.key.crt') -%}
-The files are signed by {{ signer }},
-<a href="{{ signingkey }}">whose key is here</a>.
-{%- endtrans %}
--->
-
-
-<div class = "labproject" >
-  <h5>{{ _('I2P Browser') }}</h5>
-  <p>{% trans -%}
-  The Invisible Internet browser is a fork of TorBrowser/Mozilla Firefox ESR that comes preconfigured with proxy settings, NoScript and i2pbutton which contains some security/privacy improvements like a drag and drop filter and external app blocker.
-  {%- endtrans %}</p>
-  <p>{% trans -%}
-  Builds for Linux, Windows and Mac OS X are available. Currently we provide binaries for 64bit systems. 32bit builds for Linux and Windows are planned.
-  {%- endtrans %}</p>
-  <p>{% trans -%}
-  At this time I2P Browser does not ship with its own I2P router. Ensure that you have I2P installed and running before you launch the I2P Browser.
-  {%- endtrans %}</p>
-  {% trans %}
-  Status: Beta-4
-  <ul>
-    <li><a href="https://github.com/mikalv/test-i2p-browser">Firefox Branch</a></li>
-    <li><a href="https://github.com/mikalv/i2p-browser-build-scripts">Build Scripts</a></li>
-    <li><a href="https://github.com/mikalv/i2pbutton">Browser Extension</a></li>
-  </ul>
-  {%- endtrans %}
-
-  {%- set name     = 'Windows' -%}
-  {%- set icon     = 'images/download/windows.png' -%}
-  {%- set filename = 'i2pbrowser-install-win64-2.0-beta4_en-US.exe' -%}
-  {%- set hash     = '65a2f84a7dca9d000e359dc1cd5168555f363a29a837fadbbf9fff58c8b7bad9' -%}
-  {% call package_outer('windows', name, icon) %}
-  <div class = "file">
-    <a class = "default" href="https://download.i2p2.de/experimental/i2pbrowser-beta4/windows64/i2pbrowser-install-win64-2.0-beta4_en-US.exe">
-      <span class = "name">{{ filename }}</span>
-    </a>
-  </div>
-  <div class = "meta">
-    <div class = "hash">
-      <code>{{ hash }}</code>
-    </div>
-  </div>
-  <p>{% trans -%}
-  The default is to download the english version, however it's also built for some other languages,
-  please check out the link below
-  if you want to see if we have the browser in your language.
-  {%- endtrans %}</p>
-  <a href="https://download.i2p2.de/experimental/i2pbrowser-beta4/windows64/">https://download.i2p2.de/experimental/i2pbrowser-beta4/windows64/</a>
-  {% endcall %}
-
-  {%- set name     = 'Mac OS X' -%}
-  {%- set icon     = 'images/download/mac-osx.png' -%}
-  {%- set filename = 'I2PBrowser-2.0-beta4-osx64_en-US.dmg' -%}
-  {%- set hash     = '95dff56f2443920f027a9a649793f67a37db55850980035956d7dcaad95f0d93' -%}
-  {% call package_outer('mac-osx', name, icon) %}
-  <div class = "file">
-    <a class = "default" href="https://download.i2p2.de/experimental/i2pbrowser-beta4/macosx64/I2PBrowser-2.0-beta4-osx64_en-US.dmg">
-      <span class = "name">{{ filename }}</span>
-    </a>
-  </div>
-  <div class = "meta">
-    <div class = "hash">
-      <code>{{ hash }}</code>
-    </div>
-  </div>
-  <p>{% trans -%}
-  The default is to download the english version, however it's also built for some other languages,
-  please check out the link below
-  if you want to see if we have the browser in your language.
-  {%- endtrans %}</p>
-  <a href="https://download.i2p2.de/experimental/i2pbrowser-beta4/macosx64/">https://download.i2p2.de/experimental/i2pbrowser-beta4/macosx64/</a>
-  {% endcall %}
-
-  {%- set name     = 'Linux' -%}
-  {%- set icon     = 'images/download/freebsd-tux.png' -%}
-  {%- set filename = 'i2p-browser-linux64-2.0-beta4_en-US.tar.xz' -%}
-  {%- set hash     = 'da772ebe03937b09915f9016d9c09b64666025b4ae4c9353861dcf40d916ca7d' -%}
-  {% call package_outer('freebsd-tux', name, icon) %}
-  <div class = "file">
-    <a class = "default" href="https://download.i2p2.de/experimental/i2pbrowser-beta4/linux64/i2p-browser-linux64-2.0-beta4_en-US.tar.xz">
-      <span class = "name">{{ filename }}</span>
-    </a>
-  </div>
-  <div class = "meta">
-    <div class = "hash">
-      <code>{{ hash }}</code>
-    </div>
-  </div>
-  <p>{% trans -%}
-  The default is to download the english version, however it's also built for some other languages,
-  please check out the link below
-  if you want to see if we have the browser in your language.
-  {%- endtrans %}</p>
-  <a href="https://download.i2p2.de/experimental/i2pbrowser-beta4/linux64">https://download.i2p2.de/experimental/i2pbrowser-beta4/linux64</a>
-  {% endcall %}
-</div>
-
-<div class = "labproject" >
-  <h5>{{ _('Docker image') }}</h5>
-  <p>
-  {% trans %}
-  This is an I2P Docker image for those that prefers containers.
-  It includes all required dependencies.
-  {%- endtrans %}
-  </p>
-  {% trans %}
-  Status: Proof-Of-Concept
-  {%- endtrans %}
-
-  {%- set name     = 'Linux' -%}
-  {%- set icon     = 'images/download/freebsd-tux.png' -%}
-  {% call package_outer('freebsd-tux', name, icon) %}
-  <div class = "file">
-    <a class = "default" href="https://hub.docker.com/r/meeh/i2p.i2p">
-      <span class = "name">docker pull meeh/i2p.i2p</span>
-    </a>
-  </div>
-  <p>{% trans -%}
-  Run the command to pull from docker hub.
-  {%- endtrans %}</p>
-  <br>
-  <p>{% trans -%}
-
-  {%- endtrans %}</p>
-  Bugs can be reported on <a href="https://trac.i2p2.de/newticket?component=package/docker">trac</a> (With component set to package/docker).
-  The source code (Dockerfile) can be found at our repository. You can also view it at github, <a href="https://github.com/i2p/i2p.i2p/blob/master/Dockerfile">here</a>.
-  The ports 7654,7656,7657,7658,4444,6668,8998,7659,7660 and 4445 are exposed (tcp) but some depends on your router config if they are up or not, and would be off by default.
-  {% endcall %}
-</div>
-
-
-{% endblock %}

i2p2www/pages/downloads/list.html

@@ -5,6 +5,7 @@
 
 {% block title %}{{ _('Download') }}{% endblock %}
 {% block content_nav %}
+<script type="text/javascript" src="/_static/site.js"></script>
 <ul>
 <li><a href="#windows">Windows</a>
 <li><a href="#mac">Mac OS X</a>
@@ -23,13 +24,17 @@
 If you would like to try the latest experimental I2P projects, visit the <a href = "{{ lab }}">I2P Lab</a>
 {% endtrans -%}-->
 <h3>{{ _('Getting Started') }}</h3>
-<p>{% trans java='https://java.com/download/',
+<h4>{% trans %}Basic Steps{% endtrans %}</h4>
+<p>{% trans %}For most platforms and systems, setting I2P installed and running will
+consist of up to three steps.{% endtrans %}</p>
+<ul>
+  <li><strong>{% trans %}Install Java: {% endtrans %}</strong>{% trans java='https://java.com/download/',
 openjdk='http://openjdk.java.net/install/',
 icedtea='http://icedtea.classpath.org/wiki/Main_Page',
 arm8='https://openjdk.java.net/install/',
 ibmsdk7='http://www.ibm.com/developerworks/java/jdk/linux/download.html',
-detectjre='https://java.com/en/download/installed.jsp?detect=jre&amp;try=1' %}
-In addition to the I2P download, you need to install Java if you do not have it 
+detectjre='https://java.com/en/download/installed.jsp?detect=jre&amp;try=1' %} I2P is written in Java and requires
+a Java system to be installed to run. In addition to the I2P download, you need to install Java if you do not have it 
 already installed. I2P requires Java Runtime Version 7 or higher.
 (<a href="{{ java }}">Oracle</a>,
 <a href="{{ openjdk }}">OpenJDK</a>, or
@@ -40,13 +45,28 @@ PowerPC: <a href="{{ ibmsdk7 }}">IBM Java SE 7 or 8</a>)
 <br />
 <a href="{{ detectjre }}">Determine your installed Java version here</a>
 or type <tt>java -version</tt> at your command prompt.
-{% endtrans %}
-</p><p>
+Only two platforms do not require Java to be installed before I2P is installed, those platforms are:{% endtrans %}</li>
+  <ul>
+    <li><strong>{% trans %}Android: {% endtrans %}</strong>{% trans %}Android comes with a Java virtual machine
+as part of the platform, which I2P for Android uses. Therefore it is not necessary to install Java to use
+I2P for Android.{% endtrans %}</li>
+    <li><strong>{% trans %}Debian and Ubuntu: {% endtrans %}</strong>{% trans %}On Debian and Ubuntu when using
+a .deb package to install, the system will automatically install and configure a Java environment for you.{% endtrans %}</li>
+  </ul>
+  <li><strong>{% trans %}Install I2P: {% endtrans %}</strong>{% trans %}Once you have Java installed, you should
+run the I2P installer for your platform. This step applies to all systems.{% endtrans %}</li>
+  <li><strong>{% trans %}Install/Configure a Browser(Optional): {% endtrans %}</strong>{% trans %}Finally, you'll need to
+configure applications to use I2P. Many applications can use I2P, but the first application most people configure is a Web
+Browser for browsing I2P sites. Detailed instructions are available on the{% endtrans %}
+<a href="{{ site_url() }}about/browser-config">{% trans %}Browser Page{% endtrans %}</a>.</li>
+</ul><p>
 {% trans -%}
 Windows: Java 8 is recommended. Java 9 or higher may not work.
 {%- endtrans %}
 </p>
 
+
+
 <h3>{{ _('Release Notes') }}</h3>
 <ul><li>
 <a href="{{ site_url() }}blog/category/release">{{ _('Release Notes') }}</a>
@@ -58,8 +78,6 @@ Windows: Java 8 is recommended. Java 9 or higher may not work.
 <a href="https://raw.githubusercontent.com/i2p/i2p.android.base/master/CHANGELOG">{{ _('Android Change Log') }}</a>
 </li></ul>
 
-
-
 <h3>{{ _('Pick your I2P Bundle') }}</h3>
 
 <p>
@@ -78,17 +96,28 @@ I2P connections.</p>
 
 <div class="downloadlist">
 
-{% call package('windows') %}
+    <h5>{%- trans %}I2P for Windows{%- endtrans %}</h5>
+    {% call package('windows') %}
     <p>{% trans -%}
-    Download the file and double-click to run it.
+    After installing Java, download the file and double-click to run it.
     {%- endtrans %}</p>
+    <h3>{% trans %}Easy-Install Bundle (Beta){% endtrans %}</h3>
     <div class="file">
-      <a class="default" href="{{ get_url('downloads_windows') }}">{% trans %}If you need additional help setting up dependencies and getting I2P ready, a detailed install guide is available here.{% endtrans %}</a>
+      <p>{% trans %}It's now possible to install all I2P components using
+      a single package(<strong>No Java Required</strong>). To try out the new installer, click here.
+      This bundle can also be used to configure a Firefox Profile. It will not
+      interfere with an existing I2P installation if one exists.
+      {% endtrans %}</p>
+      <a class="default" href="/nsis">{% trans %}I2P Easy Install Bundle (Beta){% endtrans %}</a>
     </div>
+    <h3>{% trans %}Detailed Install Guide{% endtrans %}</h3>
     <div class="file">
-      <a class="default" href="/firefox">{% trans %}I2P Firefox Browser Profile{% endtrans %}</a>
+      <p></p>
+      <a class="default" href="{{ get_url('downloads_windows') }}">{% trans %}Here is a helpful guide to installing I2P for Windows using a separate Java installation and the classic installer.{% endtrans %}</a>
     </div>
 {% endcall %}
+
+    <h5>{%- trans %}I2P for Mac OSX{%- endtrans %}</h5>
 {% call package('mac') %}
     <p>{% trans i2pversion=ver() -%}
     The most reliable way to launch the installer is from a terminal like this:
@@ -107,8 +136,16 @@ I2P connections.</p>
     <code>java -jar i2pinstall_{{ i2pversion }}.jar -console</code> to follow
     the install procedure in your terminal.
     {%- endtrans %}
+
+    <h3>{% trans %}DMG Bundle (Beta){% endtrans %}</h3>
+    If you do not want to use the installer or do not have a Java Runtime Environment available
+    on your Mac, you can try our latest DMG bundle.
+    <div class="file">
+        <a class="default" href="{{ get_url('downloads_mac') }}">{% trans %}Mac OS DMG Bundle (BETA){% endtrans %}</a>
+    </div>
 {% endcall %}
 
+    <h5>{%- trans %}I2P for Linux{%- endtrans %}</h5>
 {% call package('unix') %}
     <p>{% trans i2pversion=ver() -%}
     The most reliable way to launch the installer is from a terminal like this:
@@ -129,6 +166,7 @@ I2P connections.</p>
     {%- endtrans %}
 {% endcall %}
 
+    <h5>{%- trans %}I2P for Debian and Ubuntu{%- endtrans %}</h5>
 {% call package_outer('deb', 'Debian / Ubuntu', 'images/download/debian-ubuntu.png') %}
     <div class="file">
       <a class="default" href="{{ get_url('downloads_debian') }}">{% trans %}Packages for Debian &amp; Ubuntu are available.{% endtrans %}</a>
@@ -141,6 +179,7 @@ I2P connections.</p>
     {%- endtrans %}</p>
 {% endcall %}
 
+    <h5>{%- trans %}I2P for Android{%- endtrans %}</h5>
 {% call package('android') %}
     <div class="warning">
       {% trans -%}
@@ -157,27 +196,30 @@ I2P connections.</p>
     </div>
 {% endcall %}
 
+    <h5>{%- trans %}I2P for Docker{%- endtrans %}</h5>
 {% call package_outer('docker', 'Docker', 'images/download/docker.png') %}
     <div class="meta">
+        <!--
+        TODO: next time we do a release and set a git tag, change this to match the
+        sha256 hash of the docker container.
         <div class="hash">
-        <code>35cb620d82c6cab8764792720c061379bb8493325d75ad2e376455b44718935</code>
-        </div>
+        <code>1de04ec13945a0505e5b23e2bd22ad9cfaac0da3372c972160b58322b1ca48eb</code>
+        </div>-->
     </div>
     <p>{% trans -%}I2P is now available as a Docker package from the Docker Hub.
     You may retrieve the image by running the 'docker pull' command.
       {%- endtrans %}
     </p>
     <pre><code>{% trans-%}
-    docker pull meeh/i2p.i2p
+    docker pull geti2p/i2p
       {%- endtrans %}
     </pre></code>
-    <a href="https://hub.docker.com/r/meeh/i2p.i2p/">Docker Hub</a>
-
+    <a href="https://hub.docker.com/r/geti2p/i2p/">Docker Hub</a>
+    <div class="file">
+      <a class="default" href="{{ get_url('downloads_docker') }}">{% trans %}Additional instructions for configuring your container can be found here.{% endtrans %}</a>
+    </div>
 {% endcall %}
 
-
-
-
 {% call package('source') %}
     <p>{% trans monotoneurl=site_url('get-involved/guides/new-developers'),
              gitrepo='http://'+i2pconv('git.repo.i2p')+'/w/i2p.i2p.git',
@@ -191,7 +233,7 @@ I2P connections.</p>
     {%- endtrans %}</p>
     <p>{% trans monotoneurl=site_url('get-involved/guides/new-developers'),
              github='https://github.com/i2p/i2p.android.base' -%}
-    Android source is in <a href="{{ monotoneurl }}#getting-the-i2p-code">monotone</a>
+    Android source is in <a href="{{ monotoneurl }}#getting-the-i2p-code">git</a>
     and on <a href="{{ github }}">Github</a>.
     Android builds require the I2P source.
     See the documentation in the Android source for additional build requirements and instructions.

i2p2www/pages/downloads/mac.html

@@ -0,0 +1,88 @@
+{% extends "global/layout.html" %}
+{%- from "downloads/macros" import package_outer with context -%}
+{% block title %}Mac OS DMG Bundle (BETA){% endblock %}
+{% block content %}
+
+<h1>{{ _('Mac OS DMG Bundle (BETA)') }}</h1>
+<p>{% trans -%}
+We are excited to offer you a DMG bundle for Mac OS.  It installs and behaves
+the same way many other Mac OS applications do and does not require a Java
+Runtime Environment to be available.
+{%- endtrans %}</p>
+<p>{% trans perf="https://i2pgit.org/i2p-hackers/i2p-jpackage-mac/-/issues/1" -%}
+This bundle is built for <code>x86_64(Intel)</code> Macs. It will run on
+<code>ARM(M1)</code> Macs in emulated mode, but the performance is unknown. M1 Mac
+users should report results to us at the <a href="{{ perf }}">Gitlab Repository</a>.
+{%- endtrans %}</p>
+<h2>{{ _('How do I use it?') }}</h2>
+<p>{% trans -%}
+Double-Click on the .dmg file, which you may download from this page. When a
+window appears with the I2P application inside it, "drag" the application to the
+"Applications" side of the window to install it. Once you're finished, I2P is
+installed and can be launched from Finder. This procedure is the same as any
+other Mac application. When you launch I2P, the I2P icon will appear on the Dock
+and a few seconds later a browser will open with the I2P console page, inviting
+you to complete the bandwidth setup wizard.
+{%- endtrans %}</p>
+<p>{% trans browser="https://geti2p.net/htproxyports" -%}
+If you want to browse hidden websites ('eepsites') on the I2P network, you need
+to configure your browser. Instructions for configuring a range of browsers are
+available on <a href="{{ browser }}">the browser configuration
+page</a>.
+{%- endtrans %}</p>
+<h2>{{ _('Why should I use it?') }}</h2>
+<p>{% trans -%}
+Two important reasons, 1) because this package is a .dmg, it can be signed with
+a certificate which will be recognized by your computer. This means that your
+computer can automatically make sure that you've obtained I2P from the I2P
+Project, rather than a potentially altered or "fake" installer, and 2) because
+it makes I2P easier to install and work with on Apple computers by using tools
+that are familiar and built-into the operating system.
+{%- endtrans %}</p>
+
+{%- set name     = 'Windows' -%}
+{%- set icon     = 'images/download/mac-osx.png' -%}
+{%- set filename = 'I2P-%s.dmg' -%}
+{%- set hash     = '07c729c26fc8a31c0e74fe7b4de7be1f8e390d018748322ada35b29de9d' -%}
+
+{% call package_outer('osx', name, icon) %}
+    <div class = "file">
+	    <a class = "default" href="{{ url_for('downloads_redirect', version=ver(), net=def_mirror.net, protocol=def_mirror.protocol, domain=def_mirror.domain, file=ver(filename) )}}">
+		    <span class = "name">{{ ver(filename) }}</span><br/>
+		    <span class="mirror">{{ _('Mirror:') }} <img src="{{ url_for('static', filename='images/flags/'+def_mirror.country+'.png') }}" /> {{ def_mirror.org }}</span>
+	    </a>
+	    <a class="mirrors" href="{{ get_url('downloads_select', version=ver(), file=ver(filename)) }}">{{ _('select alternate mirror') }}</a>
+    </div>
+    <div class="meta">
+	    <div class="hash">
+		    <code>{{ hash }}</code>
+	    </div>
+    </div>
+    <p>{% trans -%}
+Download that file and double-click on it.  Accept the License Agreement, then
+drag the <code>I2P</code> icon on top of the <code>Applications</code> icon.
+Launch I2P from Finder.
+    {%- endtrans %}</p>
+{% endcall %}
+
+<h2>{{ _('Limitations') }}</h2>
+<p>{% trans -%}
+I2P will not install any launch agents on your Mac.  If you want I2P to start on
+system startup, you need to configure a launch agent yourself. You can configure
+I2P to launch when your user logs in by right-clicking on the I2P Dock icon.
+{%- endtrans %}</p>
+<h3>{{ _('Source Code and Issue Tracking') }}</h3>
+<div>{% trans -%}
+If you would like to examine the source code for individual components, you may
+find it on i2pgit.org.  
+{%- endtrans %}</div>
+<div><a href="https://i2pgit.org/i2p-hackers/i2p-jpackage-mac">{% trans -%}Gitlab Repository{%- endtrans %}</a></div>
+<div>{% trans -%}
+If you wish to file an issue about the DMG Bundle, please use Gitlab to
+contact us. For security-sensitive issues, please remember to check the
+"This issue is confidential and should only be visible to team members with at
+least Reporter access" option when filing the issue.
+{%- endtrans %}</div>
+<div><a href="https://i2pgit.org/i2p-hackers/i2p-jpackage-mac/issues">{% trans -%}Gitlab Repository{%- endtrans %}</a></div>
+
+{% endblock %}

i2p2www/pages/downloads/macros

@@ -1,14 +1,14 @@
-{% set i2pinstall_windows_hash = '817d52ea7662ef22a6158d62431aee44b8effe26d3883d979bbc72dac02a80d6' %}
-{% set i2pinstall_jar_hash     = '5dd5c300d3d2ca4eb7f7b33a2d4c9e54814f02c199c5176db17f214c8ab655d2' %}
-{% set i2psource_hash          = 'e8c55b17b2066d8eab82bc407128f1f0366530c5429a1413ea0cbf40f922d532' %}
-{% set i2pupdate_hash          = '4dac576536b4eaff5b4e8ff0e49d42bb2ff5167f6ead680b751c1bd2df7336c1' %}
-{% set i2p_android_hash        = '0c6ecb1b79773940bae270753dada8d32a7fc5c66a5536cdf6d45ec683a2896b' %}
+{% set i2pinstall_windows_hash = '2c9c382852e17e124d77a2bf28f95056599fd458f8de77adcf8e2aaa22b3ef81' %}
+{% set i2pinstall_jar_hash     = '8c843c90870223b4808065761d059a02b168b74daddd1773c36f0a0245e201f9' %}
+{% set i2psource_hash          = '26e5f4d95b1a0766870f97b30e57c9a8e98690279c3bf09198e30effabecc450' %}
+{% set i2pupdate_hash          = 'ea1b4b8095f4d6f5568ce879242e1d5b077de1beb4366f4a75a75cffd559ee7f' %}
+{% set i2p_android_hash        = '6ed5622ea592f4e5d24723a8525147d4bd30b94ada7b2e6613c683df583e826a' %}
 {% set i2p_macnative_hash      = '70447e8a352654afd940cfc6c05f094732de7ab05db7c42c173e49f37259d601' %}
 
 {% set i2p_windows_subver = '' %}
 {% set i2p_macosx_launcher_version = '0.1.8' %}
 
-{% set i2p_android_version = '0.9.48' %}
+{% set i2p_android_version = '1.5.0' %}
 {% set i2p_android_version_kytv = '0.9.22' %}
 {% set i2p_android_version_fdroid = '0.9.47-1' %}
 
@@ -56,7 +56,7 @@
 {%- elif type == 'docker' -%}
   {%- set name     = _('Docker') -%}
   {%- set icon     = 'images/download/docker.png' -%}
-  {%- set filename = '' -%}
+  {%- set filename = 'Dockerfile' -%}
   {%- set hash     = 'geti2p/i2p@sha256:e622209388edc49b99d8216baa731b1f54a0634c87cd47c1739f2188891daf3a' -%}
 {%- else -%}
   {%- if type == 'mac' -%}
@@ -76,6 +76,7 @@
     <div class="file">
     {%- if type == 'android' %}
       <!-- do not use url_for here -->
+      <h3>{% trans %}Download I2P for {% endtrans %}{{name}}</h3>
       <a class="default" href="https://download.i2p2.de/android/current/app.apk">{% trans %}Outside I2P{% endtrans %} ({{ i2p_android_version }})</a>
       <a class="sig" href="https://download.i2p2.de/android/current/app.apk.asc">sig</a>
       <!-- do not use i2pconv here -->
@@ -83,7 +84,16 @@
       <a class="default" href="https://play.google.com/store/apps/details?id=net.i2p.android">Google Play ({{ i2p_android_version }})</a>
       <!-- <a class="default" href="https://f-droid.i2p.io/">{% trans %}Our F-Droid repository{% endtrans %} ({{ i2p_android_version }})</a> -->
       <a class="default" href="https://f-droid.org/app/net.i2p.android.router">F-Droid ({{ i2p_android_version_fdroid }})</a>
+    {% elif type == 'source' %}
+      <h3>{% trans %}Download I2P {% endtrans %}{{name}}</h3>
+      <a class="default" href="{{ url_for('downloads_redirect', version=ver(), net=def_mirror.net, protocol=def_mirror.protocol, domain=def_mirror.domain, file=ver(filename)) }}">
+        <span class="name">{{ ver(filename) }}</span><br />
+        <span class="mirror">{{ _('Mirror:') }} <img src="{{ url_for('static', filename='images/flags/'+def_mirror.country+'.png') }}" /> {{ def_mirror.org }}</span>
+      </a>
+      <a class="mirrors" href="{{ get_url('downloads_select', version=ver(), file=ver(filename)) }}">{{ _('select alternate mirror') }}</a>
+      <a class="sig" href="{{ url_for('downloads_redirect', version=ver(), net=def_mirror.net, protocol=def_mirror.protocol, domain=def_mirror.domain, file=ver(signame)) }}">sig</a>
     {% else %}
+      <h3>{% trans %}Download I2P for {% endtrans %}{{name}}</h3>
       <a class="default" href="{{ url_for('downloads_redirect', version=ver(), net=def_mirror.net, protocol=def_mirror.protocol, domain=def_mirror.domain, file=ver(filename)) }}">
         <span class="name">{{ ver(filename) }}</span><br />
         <span class="mirror">{{ _('Mirror:') }} <img src="{{ url_for('static', filename='images/flags/'+def_mirror.country+'.png') }}" /> {{ def_mirror.org }}</span>

i2p2www/pages/downloads/mirrors

@@ -1,9 +1,11 @@
-{"net": "clearnet", "protocol": "https", "domain": "launchpad.net", "path": "/i2p/trunk/%(version)s/+download/%(file)s", "org": "Launchpad", "org_url": "https://launchpad.net", "country": "us"}
+{"net": "clearnet", "protocol": "https", "domain": "files.i2p-projekt.de", "path": "/%(version)s/%(file)s", "org": "i2p-projekt", "country": "de"}
 {"net": "clearnet", "protocol": "https", "domain": "download.i2p2.de", "path": "/releases/%(version)s/%(file)s", "org": "sigterm.no", "country": "no"}
-{"net": "i2p", "protocol": "http", "domain": "whnxvjwjhzsske5yevyokhskllvtisv5ueokw6yvh6t7zqrpra2q.b32.i2p", "path": "/releases/%(version)s/%(file)s", "org": "sigterm.no"}
+#{"net": "clearnet", "protocol": "https", "domain": "launchpad.net", "path": "/i2p/trunk/%(version)s/+download/%(file)s", "org": "Launchpad", "org_url": "https://launchpad.net", "country": "us"}
+{"net": "i2p", "protocol": "http", "domain": "mgp6yzdxeoqds3wucnbhfrdgpjjyqbiqjdwcfezpul3or7bzm4ga.b32.i2p", "path": "/releases/%(version)s/%(file)s", "org": "idk.i2p"}
 {"net": "clearnet", "protocol": "http", "domain": "download.i2p2.de", "path": "/releases/%(version)s/%(file)s", "org": "sigterm.no", "country": "no"}
 {"net": "clearnet", "protocol": "http", "domain": "download.i2p2.no", "path": "/releases/%(version)s/%(file)s", "org": "sigterm.no", "country": "no"}
-{"net": "clearnet", "protocol": "https", "domain": "dl.dropboxusercontent.com", "path": "/u/18621288/I2P/%(version)s/%(file)s", "org": "Dropbox", "country": "us"}
-{"net": "clearnet", "protocol": "https", "domain": "googledrive.com", "path": "/host/0B4jHEq5G7_EPWV9UeERwdGplZXc/%(version)s/%(file)s", "org": "Google Drive", "country": "us"}
+{"net": "clearnet", "protocol": "https", "domain": "eyedeekay.github.io", "path": "/files/releases/%(version)s/%(file)s", "org": "idk.i2p"}
+#{"net": "clearnet", "protocol": "https", "domain": "dl.dropboxusercontent.com", "path": "/u/18621288/I2P/%(version)s/%(file)s", "org": "Dropbox", "country": "us"}
+#{"net": "clearnet", "protocol": "https", "domain": "googledrive.com", "path": "/host/0B4jHEq5G7_EPWV9UeERwdGplZXc/%(version)s/%(file)s", "org": "Google Drive", "country": "us"}
 #{"net": "clearnet", "protocol": "http", "domain": "download.geti2p.com", "path": "/%(version)s/%(file)s", "org": "aargh", "country": "us"}
 #{"net": "clearnet", "protocol": "http", "domain": "download2.geti2p.com", "path": "/%(version)s/%(file)s", "org": "aargh", "country": "us"}

i2p2www/pages/downloads/windows.html

@@ -2,7 +2,14 @@
 {% 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>
+<h1>{{ _('Separately Installing I2P, its dependencies, and recommended external software on Windows 10(The Long Way)') }}</h1>
+
+<p><strong>{% trans -%}This is the long way of installing I2P for Windows, using the IzPack based
+installer and a separate Java Virtual Machine installed on the host. If you're new to I2P, you may
+want to try the Beta installer, which requires fewer total steps and automatically configures a JVM,
+I2P, and sets up a Firefox Profile in a single step.{%- endtrans %}</strong></p>
+
+<p><strong><a href="/en/download/nsis">{% trans -%}Follow this link to the beta installer{%- endtrans %}</a></strong><p>
 
 <p>{% trans -%}This is a detailed, step-by-step guide to installing and configuring I2P, including
 all dependencies and setting up a browser, on a new Windows 10 system. Many users

i2p2www/pages/global/footer.html

@@ -4,6 +4,7 @@
 
     <li><a href="https://reddit.com/r/i2p"><div class="footeritem"><img class="socialfooter" src="/_static/images/social/reddit-alien-brands.png"><span>Reddit</span></div></a></li>
     <li><a href="https://twitter.com/i2p"><div class="footeritem"><img class="socialfooter" src="/_static/images/social/twitter-brands.png"><span>Twitter</span></div></a></li>
+    <li><a href="https://i2pgit.org/"><div class="footeritem"><img class="socialfooter" src="/_static/images/social/gitlab-brands.png"><span>Gitlab</span></div></a></li>
   </ul>
 </div>
 <div id="footermenu" class="second">

i2p2www/pages/global/nav.html

@@ -39,14 +39,6 @@
               <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/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>
@@ -59,7 +51,6 @@
               <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>
             </ul>
           </li>
           <li><a href="{{ site_url('get-involved/guides/new-translators') }}"><div class="menuitem"><span>{{ _('Translate I2P into more Languages') }}</span></div></a></li>
@@ -101,6 +92,7 @@
       </li>
       <li class="has-sub"><div class="menuitem"><span>{{ _('Develop') }}</span></div>
         <ul>
+          <li><a href="https://i2pgit.org"><div class="menuitem"><span>{{ _('Gitlab') }}</span></div></a></li>
           <li class="has-sub"><div class="menuitem"><span>{{ _('Docs') }}</span></div>
             <ul>
               <li><a href="{{ site_url('docs') }}"><div class="menuitem"><span>{{ _('Documentation index') }}</span></div></a></li>
@@ -151,8 +143,9 @@
                   <li><a href="{{ site_url('docs/tunnels/old-implementation') }}"><div class="menuitem"><span>{{ _('Old implementation') }}</span></div></a></li>
                 </ul>
               </li>
-              <li><a href="{{ site_url('docs/naming') }}"><div class="menuitem"><span>{{ _('Naming and addressbook') }}</span></div></a></li>
+              <li><a href="{{ site_url('docs/naming') }}"><div class="menuitem"><span>{{ _('Naming and Address Book') }}</span></div></a></li>
               <li><a href="{{ site_url('docs/plugins') }}"><div class="menuitem"><span>{{ _('Plugins') }}</span></div></a></li>
+              <li><a href="{{ site_url('about/restrictive-countries') }}"><div class="menuitem"><span>{{ _('Strict Countries') }}</span></div></a></li>
             </ul>
           </li>
           <li class="has-sub"><div class="menuitem"><span>{{ _('API') }}</span></div>

i2p2www/pages/papers/anonbib.bib

@@ -100,6 +100,20 @@
   www_pdf_url = {https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=8537903},
 }
 
+@article{interconnection-between-darknets,
+  author={L. Ye and X. Yu and J. Zhao and D. Zhan and X. Du and M. Guizani},
+  journal={EEE INTERNET COMPUTING},
+  title={Interconnection between darknets},
+  year={2020},
+  month={December},
+  volume={1},
+  abstract={Tor and i2p networks are two of the most popular darknets. Both darknets have become an area of illegal activities highlighting the necessity to study and analyze them to identify and report illegal content to Law Enforcement Agencies (LEAs). This paper analyzes the connections between the Tor network and the i2p network. We created the first dataset that combines information from Tor and i2p networks. The dataset contains more than 49k darknet services. The process of building and analyzing the dataset shows that it is not possible to explore one of the networks without considering the other. Both networks work as an ecosystem and there are clear paths between them. Using graph analysis, we also identified the most relevant domains, the prominent types of services in each network, and their relations. Findings are relevant to LEAs and researchers aiming to crawl and investigate i2p and Tor networks.},
+  keywords={Tor, i2p, Darknet, Graph Analysis, Dataset},
+  doi={10.1109/MIC.2020.3037723},
+  ISSN={2169-3536},
+  www_section = comm,
+  www_pdf_url = {https://arxiv.org/pdf/2012.05003},
+}
 
 @mastersthesis{smits2018:i2p-enhanced-outproxy,
   title = {Risk Assessment for I2P With an Enhanced Outproxy Design},

i2p2www/pages/site/about/glossary.html

@@ -2,16 +2,80 @@
 {% block title %}{{ _('Glossary') }}{% endblock %}
 {% block content %}
 {% trans -%}
-This page lists often-used terminology when discussing I2P and cryptography.
+This table lists often-used terminology when discussing I2P and cryptography.
 {%- endtrans %}
 <table>
     <ul>
-        <li>I2P: Invisible Internet Project: a project meant to provide an anonymity layer, so user can communicate anonymously using a range of applications.</li>
-        <li>Router: The core I2P software, which routes encrypted packets on the I2P network. All routers by default participate in the network, which both helps the network and provides cover traffic for any clients or servers connecting to the I2P network through the router.</li>
-        <li>RouterIdentity: A collection of information required to communicate directly with a router, such as its IP address and listening port, public signing and encryption keys etc.</li>
-        <li>Tunnel: An anonymous communication pathway between a client or server and the I2P network. Tunnels are unidirectional, so any one client or server must have at least two Tunnels - one for inbound traffic and one for outbound traffic.</li>
-        <li>Destination: The cryptographic identity of a tunnel. These are the identities of clients and servers within the I2P network, and are analogous to the IP:port of a computer on the normal internet.</li>
-        <li>LeaseSet: A collection of information required to communicate with a client or server at a particular Destination, such as the gateways of the inbound Tunnels for that Destination.</li>
+        <li>{% trans -%}I2P: Invisible Internet Project: a project meant to
+        provide an anonymity layer, so user can communicate anonymously using a
+        range of applications.{%- endtrans %}</li>
+        <li>{% trans -%}Router: The core I2P software, which routes encrypted
+        packets on the I2P network. All routers by default participate in the
+        network, which both helps the network and provides cover traffic for any
+        clients or servers connecting to the I2P network through the
+        router.{%- endtrans %}</li>
+        <li>{% trans -%}RouterIdentity: A collection of information required to
+        communicate directly with a router, such as its IP address and listening
+        port, public signing and encryption keys etc.{%- endtrans %}</li>
+        <li>{% trans -%}Tunnel: An anonymous communication pathway between a
+        client or server and the I2P network. Tunnels are unidirectional, so any
+        one client or server must have at least two Tunnels - one for inbound
+        traffic and one for outbound traffic.{%- endtrans %}</li>
+        <li>{% trans -%}Destination: The cryptographic identity of a tunnel.
+        These are the identities of clients and servers within the I2P network,
+        and are analogous to the IP:port of a computer on the normal
+        internet.{%- endtrans %}</li>
+        <li>{% trans -%}LeaseSet: A collection of information required to
+        communicate with a client or server at a particular Destination, such as
+        the gateways of the inbound Tunnels for that
+        Destination.{%- endtrans %}</li>
+    </ul>
+</table>
+{% trans -%}This table lists definition of different networks and their components. These
+terms and the definitions provided are taken from
+<a href="https://decentpatterns.xyz/report/#key-terms">Decentralization Off The
+Shelf: 7 Maxims by Simply Secure</a>(used with permission).{%- endtrans %}
+<table>
+    <ul>
+        <li>{% trans -%}Decentralization: Network architecture that avoids
+        reliance on a single party. Encompasses peer-to-peer, blockchain,
+        federated, and distributed technologies that involve many individual
+        users.{%- endtrans %}</li>
+        <li>{% trans -%}Peer-to-Peer (p2p): Peers make a portion of their 
+        resources, such as processing power, disk storage or network bandwidth,
+        directly available to other network participants, without the need for
+        central coordination by servers or stable hosts. Popularized by
+        BitTorrent, Napster, and Bitcoin.{%- endtrans %}</li>
+        <li>{% trans -%}Federated: Federation allows separate deployments of a
+        service to communicate with each other through a common protocol, for
+        instance a mail server run by Google federates with a mail server run by
+        Microsoft when you send an email from @gmail.com to @hotmail.com.
+        Each deployment may host multiple users.{%- endtrans %}</li>
+        <li>{% trans -%}Blockchain: A distributed ledger that can record
+        transactions between multiple parties efficiently and in a verifiable
+        and permanent way.{%- endtrans %}</li>
+        <li>{% trans -%}Distributed systems: Academic topic within the
+        discipline of Computer Science which is concerned with the design of
+        computer systems that consist of many individual computers connected
+        over a network. Peer-to-peer networks and blockchains are examples of
+        distributed systems architectures.{%- endtrans %}</li>
+        <li>{% trans -%}TCP/UDP: The two foundational transport protocols used
+        on the Internet. Common protocols used to send data between two
+        computers.{%- endtrans %}</li>
+        <li>{% trans -%}DHT: Distributed hash table, used in some projects to
+        connect peers to each other by storing information in the form of
+        key-value pairs in a distributed manner.{%- endtrans %}</li>
+        <li>{% trans -%}IP address: A number of a computer or network which is
+        unique and thus can be used to address it.{%- endtrans %}</li>
+        <li>{% trans -%}WebRTC: A protocol standard for establishing connections
+        in a web browser where data passes directly between
+        users.{%- endtrans %}</li>
+        <li>{% trans -%}Hash: A number, usually displayed as a string of letters
+        and numbers. It can serve as a ‘fingerprint’ uniquely identifying
+        data.{%- endtrans %}</li>
+        <li>{% trans -%}UX: User experience, the overall experience of a person
+        using a product or a service, especially in terms of how easy it is to
+        use.{%- endtrans %}</li>
     </ul>
 </table>
 {% endblock %}

i2p2www/pages/site/about/intro.html

@@ -25,7 +25,7 @@ location and your identity.  The software ships with a router that connects you
 
 <h3>{% trans -%}About Decentralization and I2P{%- endtrans %}</h3>
 
-<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 %}The I2P network is almost completely decentralized, with exception to 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>
 
 <h3>{% trans -%}I see IP addresses of all other I2P nodes in the router console. Does that mean my IP address is visible by others?{%- endtrans %}</h3>
 

i2p2www/pages/site/about/restrictive-countries.html

@@ -0,0 +1,73 @@
+{% extends "global/layout.html" %}
+{% block title %}{{ _('Strict Countries') }}{% endblock %}
+{% block content %}
+<p>{% trans -%}This implementation of I2P (the Java implementation distributed on this site)
+includes a "Strict Countries List" which we use to decide how routers should behave 
+within regions where applications like I2P may be limited by law. For example, while
+no countries that we know of prohibit using I2P, some have broad prohibitions on
+participating in routing for others. Routers that appear to be in the "Strict"
+countries will automatically be placed into "Hidden" mode.{%- endtrans %}</p>
+
+<p>{% trans -%}
+The Project relies on the research provided by civil and digital rights organizations in order
+to make decisions that offer protections for its users. In this case the ongoing research
+provided by <a href="https://freedomhouse.org/">Freedom House</a> has been referenced. General
+guidance is to include countries with a Civil Liberties (CL) score of 16 or less or an Internet
+Freedom score of 39 or less (not free).{%- endtrans %}</p>
+
+<h4>{% trans -%}Hidden Mode Summary{%- endtrans %}</h4>
+<p>{% trans -%}When a router is placed into hidden mode, three key things change about it's behavior.
+It will no longer publish a routerInfo to the NetDB, it will no longer accept
+participating tunnels, and it will reject direct connections to routers in the same
+country that it is in. These defenses make the routers more difficult to enumerate
+reliably, and prevent them from running afoul of restrictions on routing traffic for
+others.{%- endtrans %}</p>
+
+<h4>{% trans -%}Strict Countries List as of 2020{%- endtrans %}</h4>
+<pre><code>
+    /* Afghanistan */ "AF",
+    /* Azerbaijan */ "AZ",
+    /* Bahrain */ "BH",
+    /* Belarus */ "BY",
+    /* Brunei */ "BN",
+    /* Burundi */ "BI",
+    /* Cameroon */ "CM",
+    /* Central African Republic */ "CF",
+    /* Chad */ "TD",
+    /* China */ "CN",
+    /* Cuba */ "CU",
+    /* Democratic Republic of the Congo */ "CD",
+    /* Egypt */ "EG",
+    /* Equatorial Guinea */ "GQ",
+    /* Eritrea */ "ER",
+    /* Ethiopia */ "ET",
+    /* Iran */ "IR",
+    /* Iraq */ "IQ",
+    /* Kazakhstan */ "KZ",
+    /* Laos */ "LA",
+    /* Libya */ "LY",
+    /* Myanmar */ "MM",
+    /* North Korea */ "KP",
+    /* Palestinian Territories */ "PS",
+    /* Pakistan */ "PK",
+    /* Rwanda */ "RW",
+    /* Saudi Arabia */ "SA",
+    /* Somalia */ "SO",
+    /* South Sudan */ "SS",
+    /* Sudan */ "SD",
+    /* Eswatini (Swaziland) */ "SZ",
+    /* Syria */ "SY",
+    /* Tajikistan */ "TJ",
+    /* Thailand */ "TH",
+    /* Turkey */ "TR",
+    /* Turkmenistan */ "TM",
+    /* Venezuela */ "VE",
+    /* United Arab Emirates */ "AE",
+    /* Uzbekistan */ "UZ",
+    /* Vietnam */ "VN",
+    /* Western Sahara */ "EH",
+    /* Yemen */ "YE"
+</code></pre>
+<p><a href="https://i2pgit.org/i2p/i2p.i2p/">{% trans -%}If you think a country should be added to the strict countries, file an issue on the I2P gitlab.{%- endtrans %}</a></p>
+
+{% endblock %}

i2p2www/pages/site/about/software.html

@@ -34,19 +34,19 @@ 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 
+<p>{% trans addressbook=site_url('docs/naming') -%}<strong><a href="{{ addressbook }}">The Address Book</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 
+<p><strong>The QR Code Generator</strong>: Besides the Address Book, 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>
+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 

i2p2www/pages/site/comparison/index.html

@@ -30,9 +30,9 @@ The following are discussed on the <a href="{{ othernetworks }}">other networks
   <li>Haystack</li>
 </ul>
 
-<p>{% trans trac='https://trac.i2p2.de/report/1' -%}
+<p>{% trans trac='https://i2pgit.org/i2p-hackers/i2p.www/issues' -%}
 The content of this page is subject to update, discussion and dispute, and we welcome comments and additions.
-You may contribute an analysis by entering a <a href="{{ trac }}">new ticket on Trac</a>.
+You may contribute an analysis by entering a <a href="{{ trac }}">new issue on Github</a>.
 {%- endtrans %}</p>
 
 {% endblock %}

i2p2www/pages/site/comparison/other-networks.html

@@ -14,12 +14,12 @@ The following networks are discussed on this page.
 <li>Haystack</li>
 </ul>
 
-<p>{% trans comparison=site_url('comparison'), trac='https://trac.i2p2.de/report/1' -%}
+<p>{% trans comparison=site_url('comparison'), trac='https://i2pgit.org/i2p-hackers/i2p.www/issues' -%}
 Most of the following sections are fairly old, and may not be accurate.
 For an overview of available comparisons, see the
 <a href="{{ comparison }}">main network comparisons page</a>.
 You may contribute an analysis by entering a
-<a href="{{ trac }}">new ticket on Trac</a>.
+<a href="{{ trac }}">new issue on Github</a>.
 {%- endtrans %}</p>
 
 
@@ -246,15 +246,15 @@ I2P is, of course, open source. However, that source, and our
 {%- endtrans %}</p>
 
 <h2>{{ _('Paid VPN Services') }}</h2>
-<p>{% trans trac='https://trac.i2p2.de/report/1' -%}
+<p>{% trans trac='https://i2pgit.org/i2p-hackers/i2p.www/issues' -%}
 You may contribute an analysis by entering a
-<a href="{{ trac }}">new ticket on Trac</a>.
+<a href="{{ trac }}">new issue on Github</a>.
 {%- endtrans %}</p>
 
 <h2>{{ _('Others') }}</h2>
-<p>{% trans trac='https://trac.i2p2.de/report/1' -%}
+<p>{% trans trac='https://i2pgit.org/i2p-hackers/i2p.www/issues' -%}
 You may contribute an analysis by entering a
-<a href="{{ trac }}">new ticket on Trac</a>.
+<a href="{{ trac }}">new issue on Github</a>.
 {%- endtrans %}</p>
 
 

i2p2www/pages/site/contact.html

@@ -9,7 +9,7 @@ For contact specific to research, outreach and security please use:
 <ul>
 <li>press _at_ geti2p.net - Press contact
 <br>
-GPG Key fingerprint: <tt>8736 C702 E83E E8A6 D2F1  6CF3 7EB8 9548 0027 B05F</tt>
+GPG Key fingerprint: <tt>48C7 AAAB 0B9E 4FE3 9535  9EBE 4B05 8F7D 13F6 E886</tt>
 <br>
 </li>
 <li>security _at_ geti2p.net - Vulnerability disclosure
@@ -471,4 +471,13 @@ GPG Key fingerprint: <tt>EA27 06D6 14F5 28DB 764B  F47E CFCD C461 75E6 694A</tt>
 </tr>
 </table>
 
+<h2>{{ _('Inclusion') }}</h2>
+<p>{% trans -%}
+I2P welcomes all kinds of people, as long as they are friendly and helpful to each other.<br>
+We disgrace hate, anger, racism, and bad speaking towards anyone.<br>
+We do support LBGT, suppressed minorites and other people, wether they need help in kind of our I2P software or not.<br>
+We work together to build a free world without hate, racism and violence.<br>
+The I2P router software was created in this spirit and should be used to help repressed people to regain their freedom of speech, while not suppressing others.
+{%- endtrans %}</p>
+
 {% endblock %}

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

@@ -213,7 +213,7 @@ C       A       OK Bye!
 
 <p>{% trans -%}
 Now all we need to do is telnet into 127.0.0.1, port 37337,
-send the destination key or host address from addressbook we want to contact.
+send the destination key or host address from address book we want to contact.
 In this case, we want to contact "mouth", all we do is paste in the
 key and it goes.
 {%- endtrans %}</p>

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

@@ -1,7 +1,7 @@
 {% extends "global/layout.html" %}
 {% block title %}SAM V3{% endblock %}
-{% block lastupdated %}2020-11{% endblock %}
-{% block accuratefor %}0.9.48{% endblock %}
+{% block lastupdated %}2021-05{% endblock %}
+{% block accuratefor %}0.9.50{% endblock %}
 {% block content %}
 <p>SAM is a simple client protocol for interacting with I2P.
 SAM is the recommended protocol for non-Java applications to connect to the I2P network,
@@ -18,9 +18,9 @@ Alternatives:
 <a href="streaming">Streaming</a>,
 <a href="{{ site_url('docs/protocol/i2cp') }}">I2CP</a>,
 <a href="{{ site_url('docs/api/bob') }}">BOB (deprecated)</a>.
-Older versions:
+Deprecated versions:
 <a href="{{ site_url('docs/api/sam') }}">SAM V1</a>,
-<a href="{{ site_url('docs/api/samv2') }}">SAM V2</a>,
+<a href="{{ site_url('docs/api/samv2') }}">SAM V2</a>
 </p>
 
 <h2>Known SAM libraries</h2>
@@ -176,6 +176,22 @@ Older versions:
 </table>
 
 
+<h2>Quick Start</h2>
+<p>
+To implement a basic TCP-only, peer-to-peer application, the client must support the following commands.
+<ul>
+<li> HELLO VERSION MIN=3.1 MAX=3.1 <br> Needed for all of the remaining ones
+<li> DEST GENERATE SIGNATURE_TYPE=7 <br> To generate our private key and destination
+<li> NAMING LOOKUP NAME=... <br> To convert .i2p addresses to destinations
+<li> SESSION CREATE STYLE=STREAM ID=... DESTINATION=... <br> Needed for STREAM CONNECT and STREAM ACCEPT
+<li> STREAM CONNECT ID=... DESTINATION=... <br> To make outgoing connections
+<li> STREAM ACCEPT ID=... <br> To accept incoming connections
+</ul>
+
+
+
+
+
 <h2>Version 3 Changes</h2>
 <h3>Version 3.0 Changes</h3>
 <p>
@@ -652,6 +668,11 @@ whose ID is $nickname to the specified peer.
 The target is $destination, which is the base 64 of the <a href="{{ site_url('docs/spec/common-structures') }}#type_Destination">Destination</a>,
 which is 516 or more base 64 characters (387 or more bytes in binary),
 depending on signature type.
+<b>NOTE:</b>
+Since about 2014 (SAM v3.1), Java I2P has also supported hostnames and b32 addresses for the $destination, but this was previously undocumented.
+Hostnames and b32 addresses are now officially supported by Java I2P as of release 0.9.48.
+The i2pd router will support hostnames and b32 addresses as of release 2.38.0 (0.9.50).
+For both routers, "b32" support includes support extended "b33" addresses for blinded destinations.
 </p>
 
 <h4>Connect Response</h4>
@@ -937,6 +958,10 @@ This is all on one line (space separated), shown on multiple lines for clarity:
  The target is $destination, which is the base 64 of the <a href="{{ site_url('docs/spec/common-structures') }}#type_Destination">Destination</a>,
    which is 516 or more base 64 characters (387 or more bytes in binary),
    depending on signature type.
+  <b>NOTE:</b>
+  Since about 2014 (SAM v3.1), Java I2P has also supported hostnames and b32 addresses for the $destination, but this was previously undocumented.
+  Hostnames and b32 addresses are now officially supported by Java I2P as of release 0.9.48.
+  The i2pd router does not currently support hostnames and b32 addresses; support may be added in a future release.
 </li><li>
  All options are per-datagram settings that override the defaults specified in the SESSION CREATE.
 </li><li>

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

@@ -47,7 +47,7 @@ work that simply using the existing I2P APIs.
 
 <p>{% trans -%}
 The SOCKS proxy
-supports standard addressbook names, but not Base64 destinations.
+supports standard address book names, but not Base64 destinations.
 Base32 hashes should work as of release 0.7.
 It supports outgoing connections only, i.e. an I2PTunnel Client.
 UDP support is stubbed out but not working yet.

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

@@ -0,0 +1,505 @@
+
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}DNS over I2P{% endtrans %}{% endblock %}
+{% block lastupdated %}{% trans %}October 2021{% endtrans %}{% endblock %}
+{% block accuratefor %}1.5.0/0.9.51{% endblock %}
+{% block content %}
+
+<p>{% trans -%}
+This content was adapted from content written by i2pd contributor Acetone. It
+was translated by [TODO: an unknown third party], copied from <a
+href="https://rucore.net/en/dns-over-i2p-true-privacy-of-dns-queries-2/">RuCore.
+net</a>,
+and lightly edited by idk. The original appeared at:
+<a href="https://habr.com/ru/company/itsoft/blog/572140/">habr.com</a>.
+{%- endtrans %}</p>
+
+<p>{% trans -%}
+Today it is difficult to surprise someone with the terms DoH (DNS over HTTPS),
+DoT (DNS over TLS) and other crypto-gadgets for DNS. If someone just jumped on a
+train and doesn’t understand what this is about, DNS (Domain Name System) is a
+domain name system that each of us uses hundreds and thousands of times during
+the day. All human-readable names like habr.com, cia.gov and others lead to a
+specific IP address, which a computer can find out by contacting special
+servers.
+{%- endtrans %}</p>
+
+<p>{% trans -%}
+Large enterprises, home Internet providers, as well as anyone who wants to have
+their own DNS server, because the DNS server is very simple in its device. Among
+other considerations, their servers are deployed for reasons of additional
+privacy, because the administrator of a foreign server, to which we turn, will
+see our address and will know which web resource we decided to visit.
+{%- endtrans %}</p>
+
+<p>{% trans -%}
+The DNS protocol is old (~ 1987), so it does not provide any encryption. All DNS
+requests and responses go over the network in the clear, so in the initial
+variation, not only the administrator of the DNS server, but also the operators
+of all intermediate nodes through which traffic passes, can spy on the user.
+Modern solutions like DNSCrypt, DNS over HTTPS and the like solve the
+problem of
+intercepting information along the way, as they encrypt DNS requests from the
+user to the server and in the opposite direction. But! The protocols that
+encrypt traffic do not solve one important issue – the analysis of all requests
+on the side of the server itself, which still sees both the request itself and
+the IP address from which it came. The DNSCrypt project has an additional gadget
+for that, but I was not impressed by this layering on a three-story pie. Perhaps
+because I have my own pie … I will be glad to adequate criticism, but I hope
+there will be no stupid comments that every person on the planet needs to have
+his own personal DNS server to maintain privacy.
+{%- endtrans %}</p>
+
+<p>{% trans -%}
+DNS over the anonymous network I2P is a concept in which DNS requests are
+encrypted, but also: firstly, the server administrator has no idea about the
+real IP address of the user; secondly, the user does not know the location of
+the server he is accessing (also good, in order to avoid possible pressure on
+the administrator). DNS over I2P, or DoI2P (or DoI at all) is a very
+entertaining variation on the use of hidden networks, which we will now take a
+closer look at.
+{%- endtrans %}</p>
+
+<h2>{% trans %}Theory{% endtrans %}</h2>
+
+<p>{% trans -%}The standard calls for a DNS server to run on port 53 (websites,
+for example, run on standard ports 80 and 443), but what is more interesting in
+this case is what transport protocol does DNS use. This information is required
+to create suitable tunnels over the I2P network.
+{%- endtrans %}</p>
+
+<p>{% trans -%}
+An I2P router that provides access to the I2P network provides proxies of the
+SOCKS and HTTP types at the local address. In most cases, it is a proxy that is
+used to work with the network, but to fine-tune the connection through a hidden
+network, separate tunnels are created in a special configuration file. Tunnels
+can be server and client tunnels. Their essence lies in accepting connections
+from a hidden network to a designated local port of some service, for
+example, a
+web server, or in transferring client connections from a local tunnel
+address to
+a hidden network. Tunnels are divided into two main types: TCP and UDP.
+{%- endtrans %}</p>
+
+<p>{% trans -%}
+The main working protocol of DNS is UDP, but the standard provides for the
+transfer of some information over the TCP protocol. This means that you need to
+create two server and two client tunnels: the first for UDP connections, the
+second for TCP.
+{%- endtrans %}</p>
+
+<h2>{% trans %}Server Setup{% endtrans %}</h2>
+
+<p>{% trans -%}
+The example uses a dnsmasq server that is extremely easy to install and
+configure, but you can use any server you like. The simplest configuration
+option for this server looks like this:
+{%- endtrans %}</p>
+
+<pre><code>
+port=53
+listen-address=256.257.258.259
+domain-needed
+bogus-priv
+server=8.8.8.8
+</code></pre>
+
+
+<p>{% trans -%}
+This configuration means that absolutely all requests will be sent to the
+address 8.8.8.8. Such a server does not make much sense, but as a layer of
+anonymity and just an example for an article – that’s it. The server accepts
+requests to an IP address 256.257.258.259, port 53. The fictitious IP address
+serves only as an example, as if depicting a pre-existing DNS server accessible
+from the regular Internet. In fact, you can use a local address 127.0.0.1 and
+any port at your discretion, if you serve users exclusively through a hidden
+network.
+{%- endtrans %}</p>
+
+<p>{% trans -%}
+To make the DNS server accessible from I2P, you need to create server tunnels.
+I am using i2pd on Debian 10. The default tunnels config file is in the path
+/etc/i2pd/tunnels.conf. Below is the minimum configuration required to work.
+{%- endtrans %}</p>
+
+<pre><code>
+[DNS-TCP]
+type = server
+host = 256.257.258.259
+port = 53
+keys = hidden-dns.dat
+
+[DNS-UDP]
+type = udpserver
+host = 256.257.258.259
+address = 256.257.258.259
+port = 53
+keys = hidden-dns.dat
+</code></pre>
+
+<p>{% trans -%}
+Notice the line address in the UDP tunnel section. This is a necessary
+parameter
+for a non-local address, which tells i2pd from which address incoming requests
+from the hidden network will come from. This parameter is required for UDP
+tunnels. It can be omitted if an address is used 127.0.0.1.
+{%- endtrans %}</p>
+
+<p>{% trans -%}
+The parameter keys specifies the keys that form the intranet address. By
+default, they are in the directory /var/lib/i2pd. If the file is not found, a
+new one is created.
+{%- endtrans %}</p>
+
+<p>{% trans -%}
+Restart i2pd for the changes to take effect. You can see the I2P tunnel address
+in the web console, under the “I2P Tunnels” tab. In my case, it is
+dnsgzxkak4zlrrs5tfh42ob57iley4xrp7srrltn2j2yl2ynbiaq.b32.i2p.
+{%- endtrans %}</p>
+
+<h2>{% trans %}Client Setup{% endtrans %}</h2>
+
+<p>{% trans -%}
+In my case, the client machine also uses i2pd and the Debian operating system,
+the tunnels file is located in the same place as on the server –
+/etc/i2pd/tunnels.conf. The client configuration might look like this:
+{%- endtrans %}</p>
+
+<pre><code>
+[DNS-CLIENT-TCP]
+type = client
+address = 127.0.0.1
+port = 35353
+inbound.length = 2
+outbound.length = 2
+destination = dnsgzxkak4zlrrs5tfh42ob57iley4xrp7srrltn2j2yl2ynbiaq.b32.i2p
+keys = transient-dns
+
+[DNS-CLIENT-UDP]
+type = udpclient
+address = 127.0.0.1
+port = 35353
+destination = dnsgzxkak4zlrrs5tfh42ob57iley4xrp7srrltn2j2yl2ynbiaq.b32.i2p
+keys = transient-dns
+</code></pre>
+
+<p>{% trans -%}
+The parameters inbound.length and outbound.length are responsible for the
+length of the incoming and outgoing tunnels. By default, they are three hops,
+but I have reduced these values ​​to two to minimize latency a little.
+Similar parameters are applicable for server tunnels as well. Additional
+parameters are specified only in the first section, since the very first block
+defines the parameters that apply to all tunnels using the same key (in my
+case, this transient-dns). Keys starting with a word transient are temporary
+– after each restart of i2pd, the client will contact the server from a new
+intranet address.
+{%- endtrans %}</p>
+
+<p>{% trans -%}
+For new tunnels to be created, you need to restart i2pd. On this it may seem
+that the deed is done. But no, there is one more nuance left.
+{%- endtrans %}</p>
+
+<p>{% trans -%}
+The file responsible for configuring DNS on my operating system (Debian 10)
+does not support specifying a port. Only the IP address of the server can be
+specified. All requests will be sent to the port 53, but our tunnel is hanging
+on the port 35353. If you specify a port in the client tunnels 53, an error
+will occur and no tunnels will be created, because all ports below 1024 are
+privileged – reserved for special needs. Only the superuser (root) can start
+the service on this port, and i2pd, like other applications, works without
+superuser rights. Take a deep breath before running i2pd (or some other
+third-party software) as root, and then read on.
+{%- endtrans %}</p>
+
+<h2>{% trans %}Epilogue{% endtrans %}</h2>
+
+<p>{% trans -%}
+{%- endtrans %}</p>
+
+
+
+<h2>{% trans %}Additional Information{% endtrans %}</h2>
+<ul>
+<li></li>
+</ul>
+
+
+{% endblock %}
+idk@lib14:~/Workspace/GIT_WORK/i2p.www$ find . -name dns.html -exec bash -c
+"cat {} | fold -w 80 -s - | tee {} " \;
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}DNS over I2P{% endtrans %}{% endblock %}
+{% block lastupdated %}{% trans %}October 2021{% endtrans %}{% endblock %}
+{% block accuratefor %}1.5.0/0.9.51{% endblock %}
+{% block content %}
+
+<p>{% trans -%}
+This content was adapted from content written by i2pd contributor Acetone. It
+was machine translated, copied from <a
+href="https://rucore.net/en/dns-over-i2p-true-privacy-of-dns-queries-2/">RuCore.
+net</a>,
+and lightly edited by idk.
+{%- endtrans %}</p>
+
+<p>{% trans -%}
+Today it is difficult to surprise someone with the terms DoH (DNS over HTTPS),
+DoT (DNS over TLS) and other crypto-gadgets for DNS. If someone just jumped on a
+train and doesn’t understand what this is about, DNS (Domain Name System) is a
+domain name system that each of us uses hundreds and thousands of times during
+the day. All human-readable names like habr.com, cia.gov and others lead to a
+specific IP address, which a computer can find out by contacting special
+servers.
+{%- endtrans %}</p>
+
+<p>{% trans -%}
+Large enterprises, home Internet providers, as well as anyone who wants to have
+their own DNS server, because the DNS server is very simple in its device. Among
+other considerations, their servers are deployed for reasons of additional
+privacy, because the administrator of a foreign server, to which we turn, will
+see our address and will know which web resource we decided to visit.
+{%- endtrans %}</p>
+
+<p>{% trans -%}
+The DNS protocol is old (~ 1987), so it does not provide any encryption. All DNS
+requests and responses go over the network in the clear, so in the initial
+variation, not only the administrator of the DNS server, but also the operators
+of all intermediate nodes through which traffic passes, can spy on the user.
+Modern solutions like DNSCrypt, DNS over HTTPS and the like solve the problem of
+intercepting information along the way, as they encrypt DNS requests from the
+user to the server and in the opposite direction. But! The protocols that
+encrypt traffic do not solve one important issue – the analysis of all requests
+on the side of the server itself, which still sees both the request itself and
+the IP address from which it came. The DNSCrypt project has an additional gadget
+for that, but I was not impressed by this layering on a three-story pie. Perhaps
+because I have my own pie … I will be glad to adequate criticism, but I hope
+there will be no stupid comments that every person on the planet needs to have
+his own personal DNS server to maintain privacy.
+{%- endtrans %}</p>
+
+<p>{% trans -%}
+DNS over the anonymous network I2P is a concept in which DNS requests are
+encrypted, but also: firstly, the server administrator has no idea about the
+real IP address of the user; secondly, the user does not know the location of
+the server he is accessing (also good, in order to avoid possible pressure on
+the administrator). DNS over I2P, or DoI2P (or DoI at all) is a very
+entertaining variation on the use of hidden networks, which we will now take a
+closer look at.
+{%- endtrans %}</p>
+
+<h2>{% trans %}Theory{% endtrans %}</h2>
+
+<p>{% trans -%}The standard calls for a DNS server to run on port 53 (websites,
+for example, run on standard ports 80 and 443), but what is more interesting in
+this case is what transport protocol does DNS use. This information is required
+to create suitable tunnels over the I2P network.
+{%- endtrans %}</p>
+
+<p>{% trans -%}
+An I2P router that provides access to the I2P network provides proxies of the
+SOCKS and HTTP types at the local address. In most cases, it is a proxy that is
+used to work with the network, but to fine-tune the connection through a hidden
+network, separate tunnels are created in a special configuration file. Tunnels
+can be server and client tunnels. Their essence lies in accepting connections
+from a hidden network to a designated local port of some service, for example, a
+web server, or in transferring client connections from a local tunnel address to
+a hidden network. Tunnels are divided into two main types: TCP and UDP.
+{%- endtrans %}</p>
+
+<p>{% trans -%}
+The main working protocol of DNS is UDP, but the standard provides for the
+transfer of some information over the TCP protocol. This means that you need to
+create two server and two client tunnels: the first for UDP connections, the
+second for TCP.
+{%- endtrans %}</p>
+
+<h2>{% trans %}Server Setup{% endtrans %}</h2>
+
+<p>{% trans -%}
+The example uses a dnsmasq server that is extremely easy to install and
+configure, but you can use any server you like. The simplest configuration
+option for this server looks like this:
+{%- endtrans %}</p>
+
+<pre><code>
+port=53
+listen-address=256.257.258.259
+domain-needed
+bogus-priv
+server=8.8.8.8
+</code></pre>
+
+
+<p>{% trans -%}
+This configuration means that absolutely all requests will be sent to the
+address 8.8.8.8. Such a server does not make much sense, but as a layer of
+anonymity and just an example for an article – that’s it. The server accepts
+requests to an IP address 256.257.258.259, port 53. The fictitious IP address
+serves only as an example, as if depicting a pre-existing DNS server accessible
+from the regular Internet. In fact, you can use a local address 127.0.0.1 and
+any port at your discretion, if you serve users exclusively through a hidden
+network.
+{%- endtrans %}</p>
+
+<p>{% trans -%}
+To make the DNS server accessible from I2P, you need to create server tunnels.
+I am using i2pd on Debian 10. The default tunnels config file is in the path
+/etc/i2pd/tunnels.conf. Below is the minimum configuration required to work.
+{%- endtrans %}</p>
+
+<pre><code>
+[DNS-TCP]
+type = server
+host = 256.257.258.259
+port = 53
+keys = hidden-dns.dat
+
+[DNS-UDP]
+type = udpserver
+host = 256.257.258.259
+address = 256.257.258.259
+port = 53
+keys = hidden-dns.dat
+</code></pre>
+
+<p>{% trans -%}
+Notice the line address in the UDP tunnel section. This is a necessary
+parameter
+for a non-local address, which tells i2pd from which address incoming requests
+from the hidden network will come from. This parameter is required for UDP
+tunnels. It can be omitted if an address is used 127.0.0.1.
+{%- endtrans %}</p>
+
+<p>{% trans -%}
+The parameter keys specifies the keys that form the intranet address. By
+default, they are in the directory /var/lib/i2pd. If the file is not found, a
+new one is created.
+{%- endtrans %}</p>
+
+<p>{% trans -%}
+Restart i2pd for the changes to take effect. You can see the I2P tunnel address
+in the web console, under the “I2P Tunnels” tab. In my case, it is
+dnsgzxkak4zlrrs5tfh42ob57iley4xrp7srrltn2j2yl2ynbiaq.b32.i2p.
+{%- endtrans %}</p>
+
+<h2>{% trans %}Client Setup{% endtrans %}</h2>
+
+<p>{% trans -%}
+In my case, the client machine also uses i2pd and the Debian operating system,
+the tunnels file is located in the same place as on the server –
+/etc/i2pd/tunnels.conf. The client configuration might look like this:
+{%- endtrans %}</p>
+
+<pre><code>
+[DNS-CLIENT-TCP]
+type = client
+address = 127.0.0.1
+port = 35353
+inbound.length = 2
+outbound.length = 2
+destination = dnsgzxkak4zlrrs5tfh42ob57iley4xrp7srrltn2j2yl2ynbiaq.b32.i2p
+keys = transient-dns
+
+[DNS-CLIENT-UDP]
+type = udpclient
+address = 127.0.0.1
+port = 35353
+destination = dnsgzxkak4zlrrs5tfh42ob57iley4xrp7srrltn2j2yl2ynbiaq.b32.i2p
+keys = transient-dns
+</code></pre>
+
+<p>{% trans -%}
+The parameters inbound.length and outbound.length are responsible for the
+length of the incoming and outgoing tunnels. By default, they are three hops,
+but I have reduced these values ​​to two to minimize latency a little.
+Similar parameters are applicable for server tunnels as well. Additional
+parameters are specified only in the first section, since the very first block
+defines the parameters that apply to all tunnels using the same key (in my
+case, this transient-dns). Keys starting with a word transient are temporary
+– after each restart of i2pd, the client will contact the server from a new
+intranet address.
+{%- endtrans %}</p>
+
+<p>{% trans -%}
+For new tunnels to be created, you need to restart i2pd. On this it may seem
+that the deed is done. But no, there is one more nuance left.
+{%- endtrans %}</p>
+
+<p>{% trans -%}
+The file responsible for configuring DNS on my operating system (Debian 10)
+does not support specifying a port. Only the IP address of the server can be
+specified. All requests will be sent to the port 53, but our tunnel is hanging
+on the port 35353. If you specify a port in the client tunnels 53, an error
+will occur and no tunnels will be created, because all ports below 1024 are
+privileged – reserved for special needs. Only the superuser (root) can start
+the service on this port, and i2pd, like other applications, works without
+superuser rights. Take a deep breath before running i2pd (or some other
+third-party software) as root, and then read on.
+{%- endtrans %}</p>
+
+<p>{% trans -%}
+Remove from /etc/resolv.conf the previous DNS, so that all queries were
+exclusively through I2P, and add a single server – local: nameserver
+127.0.0.1.
+This will tell the operating system to go to the address for name-to-address
+resolution 127.0.0.1:53. It remains to ask the kernel of the system to redirect
+requests from the port 53 to 35353where our TCP / UDP tunnels hang, and then
+send responses in the opposite direction. It’s time for the iptables magic
+(sorry not the newfangled netfilter, I’m an old school magician).
+{%- endtrans %}</p>
+
+<pre><code>
+iptables -t nat -A PREROUTING -i lo -p udp – dport 53 -j REDIRECT –
+to-port 35353
+iptables -t nat -I OUTPUT -p udp -d 127.0.0.1 – dport 53 -j REDIRECT –
+to-port 35353
+iptables -t nat -A PREROUTING -i lo -p tcp – dport 53 -j REDIRECT –
+to-port 35353
+iptables -t nat -I OUTPUT -p tcp -d 127.0.0.1 – dport 53 -j REDIRECT –
+to-port 35353
+</code></pre>
+
+<p>{% trans -%}
+Do you hear? Listen, this is fanfare! Check the resolving in any convenient
+way,
+I will use the utility nslookup:
+{%- endtrans %}</p>
+
+<pre><code>
+acetone@adeb:~$ nslookup habr.com
+Server: 127.0.0.1
+Address: 127.0.0.1#53
+
+Non-authoritative answer:
+Name: habr.com
+Address: 178.248.237.68
+</code></pre>
+
+<h2>{% trans %}Epilogue{% endtrans %}</h2>
+
+<p>{% trans -%}
+During the configuration, I noticed that dnsmasq only occupies a UDP socket in
+standby mode, but I decided to leave the TCP tunnel according to the DNS
+standard, which provides for the transfer of some information over TCP. Be
+that as it may, the functionality described is perfectly observed even in
+the absence of TCP tunnels.
+{%- endtrans %}</p>
+
+<p>{% trans -%}
+The above configuration takes on average 1-2 seconds to request and respond
+to the DNS server. If your result seems too slow for you, you can reduce the
+length of the server and client tunnels to 2. There are options with tunnels
+in one transit node, but this is applicable only for devices that you do
+not worry about being compromised: for example, if your DNS is not secret ,
+the length of the tunnels can be equal to one or even zero! In this case,
+you enable the user to build a longer anonymizing tunnel from his side. The
+main thing is to do everything wisely and not be lazy to get acquainted with
+the documentation , as well as consult with knowledgeable people.
+{%- endtrans %}</p>
+
+<p>{% trans -%}
+As a demonstration (and maybe for permanent use), you can use the DNS server,
+the user configs for which are given above.
+{%- endtrans %}</p>
+
+{% endblock %}

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

@@ -4,12 +4,22 @@
 {% 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>
+<b>{% trans -%} If you intend to use the service at i2pgit.org/git.idk.i2p, then you probably already have a tunnel configured and much of this
+tutorial will not apply to you.{%- endtrans %}</b>
+<h2 id="first-set-up-an-account-at-a-git-service">{% trans -%}First: Set up an account at a Git service{%- endtrans %}</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>
+<p>{% trans -%}These are generic instructions for any in-i2p Git instance with HTTP and SSH gateways.
+If you intend to contribute to I2P, you should create an account at the I2P gitlab, which is open to the
+community. Account registration may take a few days to complete, as the admin needs to sort through a large
+number of spam registrations. You can help this by getting in touch with the admin to confirm you are human
+using the instructions on the home page.{%- endtrans %}</p>
+<ul>
+<li><strong><a href="http://git.idk.i2p">{% trans %}Inside I2P - (http://git.idk.i2p){% endtrans %}</a></strong>
+</li>
+<li><strong><a href="https://i2pgit.org">{% trans %}Outside I2P - (https://i2pgit.org){% endtrans %}</a></strong>
+</li>
+</ul>
 <figure>
 <img src="/_static/images/git/register.png" alt="" /><figcaption>Registration is easy!</figcaption>
 </figure>
@@ -55,6 +65,14 @@
 </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>
+<p>{% trans -%}Git Privacy: Committing to git adds a timestamp to git commit messages, which may be configured to reflect your local time zone. To enforce the use of UTC for all commits, you are advised to use a git alias, such as: {%- endtrans %}
+<pre><code>git config --global alias.utccommit '!git commit --date="$(date --utc +%Y-%m-%dT%H:%M:%S%z)"'</code></pre>
+{% trans -%}which will allow you to substitute{%- endtrans %}
+<pre><code>git commit</code></pre>
+{% trans -%}for{%- endtrans %}
+<pre><code>git utccommit</code></pre>
+{% trans -%}in order to obscure your local time zone.{%- 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>
@@ -96,5 +114,5 @@ git pull upstream master</code></pre></li>
 <pre><code>git checkout master
 git pull upstream master</code></pre></li>
 </ol>
-
+<p>{% trans -%}The git utccommit alias solution to git timestamp issue was arrived at from the information first published here{%- endtrans %}: <a href="https://saebamini.com/Git-commit-with-UTC-timestamp-ignore-local-timezone/">saebamini.com</a>.</p>
 {% endblock %}

i2p2www/pages/site/docs/discussions/naming.html

@@ -104,7 +104,7 @@ Others have suggested asking for specific keys only (similar to what jump servic
 in a more automated fashion), possibly at a further cost in anonymity.
 {%- endtrans %}</p>
 <p>{% trans i2host=i2pconv('i2host.i2p') -%}
-Possible improvements would be a replacement or supplement to addressbook (see <a href="http://{{ i2host }}/">{{ i2host }}p</a>),
+Possible improvements would be a replacement or supplement to address book (see <a href="http://{{ i2host }}/">{{ i2host }}p</a>),
 or something simple like subscribing to http://example.i2p/cgi-bin/recenthosts.cgi rather than http://example.i2p/hosts.txt.
 If a hypothetical recenthosts.cgi distributed all hosts from the last 24 hours, for example,
 that could be both more efficient and more anonymous than the current hosts.txt with last-modified and etag.
@@ -116,7 +116,7 @@ This script returns an Etag with a timestamp.
 When a request comes in with the If-None-Match etag,
 the script ONLY returns new hosts since that timestamp, or 304 Not Modified if there are none.
 In this way, the script efficiently returns only the hosts the subscriber
-does not know about, in an addressbook-compatible manner.
+does not know about, in an address book-compatible manner.
 {%- endtrans %}</p>
 <p>{% trans -%}
 So the inefficiency is not a big issue and there are several ways to improve things without
@@ -138,7 +138,7 @@ a key, you need to have the whole set of keys stored locally, at a cost of about
 <li>
 <p>{% trans -%}
 <b>Requires configuration and "trust":</b>
-Out-of-the-box addressbook is only subscribed to http://www.i2p2.i2p/hosts.txt, which is rarely updated,
+Out-of-the-box address book is only subscribed to http://www.i2p2.i2p/hosts.txt, which is rarely updated,
 leading to poor new-user experience.
 {%- endtrans %}</p>
 <p>{% trans -%}
@@ -177,7 +177,7 @@ Sure, we could make it work, but why? It's a bad fit.
 <li>
 <p>{% trans -%}
 <b>Not reliable:</b>
-It depends on specific servers for addressbook subscriptions.
+It depends on specific servers for address book subscriptions.
 {%- endtrans %}</p>
 <p>{% trans -%}
 Yes it depends on a few servers that you have configured.
@@ -185,7 +185,7 @@ Within i2p, servers and services come and go.
 Any other centralized system (for example DNS root servers) would
 have the same problem. A completely decentralized system (everybody is authoritative)
 is possible by implementing an "everybody is a root DNS server" solution, or by
-something even simpler, like a script that adds everybody in your hosts.txt to your addressbook.
+something even simpler, like a script that adds everybody in your hosts.txt to your address book.
 {%- endtrans %}</p>
 <p>{% trans -%}
 People advocating all-authoritative solutions generally haven't thought through
@@ -257,7 +257,7 @@ See core/java/src/net/i2p/client/naming for details.
 {%- endtrans %}</p>
 <p>{% trans -%}
 Any new system should be stacked with HostsTxt, or should
-implement local storage and/or the addressbook subscription functions, since addressbook
+implement local storage and/or the address book subscription functions, since address book
 only knows about the hosts.txt files and format.
 {%- endtrans %}</p>
 
@@ -266,7 +266,7 @@ only knows about the hosts.txt files and format.
 I2P destinations contain a certificate, however at the moment that certificate
 is always null.
 With a null certificate, base64 destinations are always 516 bytes ending in "AAAA",
-and this is checked in the addressbook merge mechanism, and possibly other places.
+and this is checked in the address book merge mechanism, and possibly other places.
 Also, there is no method available to generate a certificate or add it to a
 destination. So these will have to be updated to implement certificates.
 {%- endtrans %}</p>
@@ -280,7 +280,7 @@ i2p uses a flat naming system) to be signed by the 2nd level domain's keys.
 <p>{% trans -%}
 With any certificate implementation must come the method for verifying the
 certificates.
-Presumably this would happen in the addressbook merge code.
+Presumably this would happen in the address book merge code.
 Is there a method for multiple types of certificates, or multiple certificates?
 {%- endtrans %}</p>
 <p>{% trans -%}

i2p2www/pages/site/docs/how/tech-intro.html

@@ -832,9 +832,9 @@ abstraction of TCP, with its sliding windows, congestion control algorithms
 SYN, FIN, RST, etc).
 {%- endtrans %}</p>
 
-  <h2 id="app.naming">{% trans %}Naming library and addressbook{% endtrans %}</h2>
+  <h2 id="app.naming">{% trans %}Naming library and address book{% endtrans %}</h2>
   <p><i>{% trans naming=site_url('docs/naming') -%}
-For more information see the <a href="{{ naming }}">Naming and Addressbook</a> page.
+For more information see the <a href="{{ naming }}">Naming and Address Book</a> page.
 {%- endtrans %}</i></p>
 
   <p><i>{% trans dev='mihi, Ragnarok' -%}Developed by: {{ dev }}{%- endtrans %}</i></p>
@@ -846,16 +846,16 @@ inherent demand for secure communication and decentralized operation, the
 traditional DNS-style naming system is clearly out, as are "majority rules" 
 voting systems. Instead, I2P ships with a generic naming library and a base 
 implementation designed to work off a local name to destination mapping, as 
-well as an optional add-on application called the "addressbook". The addressbook 
+well as an optional add-on application called the "Address Book". The address book 
 is a web-of-trust-driven secure, distributed, and human readable naming system, 
 sacrificing only the call for all human readable names to be globally unique 
 by mandating only local uniqueness. While all messages in I2P are cryptographically 
-addressed by their destination, different people can have local addressbook 
+addressed by their destination, different people can have local address book 
 entries for "Alice" which refer to different destinations. People can still 
-discover new names by importing published addressbooks of peers specified 
+discover new names by importing published address books of peers specified 
 in their web of trust, by adding in the entries provided through a third party, 
-or (if some people organize a series of published addressbooks using a first 
-come first serve registration system) people can choose to treat these addressbooks 
+or (if some people organize a series of published address books using a first 
+come first serve registration system) people can choose to treat these address books 
 as name servers, emulating traditional DNS.
 {%- endtrans %}</p>
 

i2p2www/pages/site/docs/how/threat-model.html

@@ -860,7 +860,7 @@ Routers rely on a single news host, but there is a hardcoded backup URL pointing
 A malicious news host could feed a huge file, need to limit the size.
 {%- endtrans %}</li>
 <li>{% trans naming=site_url('docs/naming') -%}
-<a href="{{ naming }}">Naming system services</a>, including addressbook subscription providers, add-host services,
+<a href="{{ naming }}">Naming system services</a>, including address book subscription providers, add-host services,
 and jump services, could be malicious. Substantial protections for subscriptions were implemented
 in release 0.6.1.31, with additional enhancements in subsequent releases.
 However, all naming services require some measure of trust, see

i2p2www/pages/site/docs/index.html

@@ -1,7 +1,7 @@
 {% extends "global/layout.html" %}
 {% block title %}{% trans %}Index to Technical Documentation{% endtrans %}{% endblock %}
-{% block lastupdated %}2020-11{% endblock %}
-{% block accuratefor %}0.9.48{% endblock %}
+{% block lastupdated %}2021-01{% endblock %}
+{% block accuratefor %}0.9.49{% endblock %}
 {% block content %}
 <p>{% trans -%}
 Following is an index to the technical documentation for I2P.
@@ -15,7 +15,7 @@ The interface between applications and the router is the I2CP (I2P Control
 Protocol) API.
 {%- endtrans %}</p>
 
-<p>{% trans trac='https://trac.i2p2.de/report/1' -%}
+<p>{% trans trac='https://i2pgit.org/i2p-hackers/i2p.www/issues' -%}
 The I2P Project is committed to maintaining accurate, current documentation.
 If you find any inaccuracies in the documents linked below, please
 <a href="{{ trac }}">enter a ticket identifying the problem</a>.
@@ -39,8 +39,8 @@ If you find any inaccuracies in the documents linked below, please
 <h3>{% trans %}Application-Layer Topics{% endtrans %}</h3>
 <ul>
 <li><a href="{{ site_url('get-involved/develop/applications') }}">Application Development Overview and Guide</a></li>
-<li><a href="{{ site_url('docs/naming') }}">{{ _('Naming and Addressbook') }}</a></li>
-<li><a href="{{ spec_url('subscription') }}">{{ _('Addressbook Subscription Feed Commands') }}</a></li>
+<li><a href="{{ site_url('docs/naming') }}">{{ _('Naming and Address Book') }}</a></li>
+<li><a href="{{ spec_url('subscription') }}">{{ _('Address Book Subscription Feed Commands') }}</a></li>
 <li><a href="{{ site_url('docs/plugins') }}">{{ _('Plugins Overview') }}</a></li>
 <li><a href="{{ spec_url('plugin') }}">{{ _('Plugin Specification') }}</a></li>
 <li><a href="{{ site_url('docs/applications/managed-clients') }}">{{ _('Managed Clients') }}</a></li>
@@ -117,7 +117,8 @@ Traditionally used only by Java applications and higher-level APIs.
 <h3>{% trans %}End-to-End Encryption{% endtrans %}</h3>
 {% trans %}How client messages are end-to-end encrypted by the router.{% endtrans %}
 <ul>
-<li><a href="{{ spec_url('ecies') }}">{{ _('ECIES-X25519-AEAD-Ratchet encryption') }}</a></li>
+<li><a href="{{ spec_url('ecies') }}">{{ _('ECIES-X25519-AEAD-Ratchet encryption for destinations') }}</a></li>
+<li><a href="{{ spec_url('ecies-routers') }}">{{ _('ECIES-X25519 encryption for routers') }}</a></li>
 <li><a href="{{ site_url('docs/how/elgamal-aes') }}">{{ _('ElGamal/AES+SessionTag encryption') }}</a></li>
 <li><a href="{{ site_url('docs/how/cryptography') }}">{{ _('ElGamal and AES cryptography details') }}</a></li>
 </ul>
@@ -250,15 +251,11 @@ ancient (str4d)
 </li><li>
 <a href="http://{{ i2pconv('zzz.i2p') }}/">{{ _('Developer forum inside I2P') }}</a>
 </li><li>
-<a href="https://trac.i2p2.de/report/1">{{ _('Bug tracker') }}</a>
-<!--
-</li><li>
-<a href="http://{{ i2pconv('killyourtv.i2p') }}/viewmtn/">{{ _('Viewmtn inside I2P') }}</a>.
--->
+<a href="https://i2pgit.org/i2p-hackers/i2p.i2p/issues">{{ _('Bug tracker') }}</a>
 </li><li>
 <a href="https://github.com/i2p/i2p.i2p">{{ _('I2P Source exported to GitHub') }}</a>
 </li><li>
-<a href="http://{{ i2pconv('git.repo.i2p') }}/w/i2p.i2p.git">{{ _('I2P Source Git Repo inside I2P') }}</a>
+<a href="http://git.idk.i2p/i2p/i2p.i2p.git">{{ _('I2P Source Git Repo inside I2P') }}</a>
 </li><li>
 <a href="https://www.transifex.net/projects/p/I2P/">{{ _('Source translation at Transifex') }}</a>
 </li><li>

i2p2www/pages/site/docs/naming.html

@@ -1,5 +1,5 @@
 {% extends "global/layout.html" %}
-{% block title %}{% trans %}Naming and Addressbook{% endtrans %}{% endblock %}
+{% block title %}{% trans %}Naming and Address Book{% endtrans %}{% endblock %}
 {% block lastupdated %}2020-07{% endblock %}
 {% block accuratefor %}0.9.46{% endblock %}
 {% block content %}
@@ -8,21 +8,21 @@
 <p>{% trans -%}
 I2P ships with a generic naming library and a base implementation 
 designed to work off a local name to destination mapping, as well as an
-add-on application called the <a href="#addressbook">addressbook</a>. 
+add-on application called the <a href="#addressbook">address book</a>. 
 I2P also supports <a href="#base32">Base32 hostnames</a> similar to Tor's .onion addresses.
 {%- endtrans %}</p>
 
 <p>{% trans -%}
-The addressbook is a web-of-trust
+The address book is a web-of-trust
 driven secure, distributed, and human readable naming system, sacrificing only
 the call for all human readable names to be globally unique by mandating only
 local uniqueness.  While all messages in I2P are cryptographically addressed
-by their destination, different people can have local addressbook entries for
+by their destination, different people can have local address book entries for
 "Alice" which refer to different destinations.  People can still discover new
-names by importing published addressbooks of peers specified in their web of trust,
+names by importing published address books of peers specified in their web of trust,
 by adding in the entries provided through a third party, or (if some people organize
-a series of published addressbooks using a first come first serve registration
-system) people can choose to treat these addressbooks as name servers, emulating
+a series of published address books using a first come first serve registration
+system) people can choose to treat these address books as name servers, emulating
 traditional DNS.
 {%- endtrans %}</p>
 
@@ -63,12 +63,12 @@ HTTP <a href="#add-services">host-add forms</a> which allow users to add hosts t
 HTTP <a href="#jump-services">jump services</a> which provide their own lookups and redirection.
 {%- endtrans %}</li>
 <li>{% trans -%}
-The <a href="#addressbook">addressbook</a> application which merges external
+The <a href="#addressbook">address book</a> application which merges external
 host lists, retrieved via HTTP, with the local list.
 {%- endtrans %}</li>
 <li>{% trans -%}
 The <a href="#susidns">SusiDNS</a> application which is a simple web front-end
-for addressbook configuration and viewing of the local host lists.
+for address book configuration and viewing of the local host lists.
 {%- endtrans %}</li>
 </ol>
 
@@ -114,7 +114,7 @@ The files are:
 <h3>{{ _('Blockfile Naming Service') }}</h3>
 
 <p>{% trans -%}
-The Blockfile Naming Service stores multiple "addressbooks" in a single
+The Blockfile Naming Service stores multiple "address books" in a single
 database file named hostsdb.blockfile.
 This Naming Service is the default since release 0.8.8.
 {%- endtrans %}</p>
@@ -126,7 +126,7 @@ The blockfile format is specified on the <a href="{{ blockfile }}">Blockfile pag
 It provides fast Destination lookup in a compact format. While the blockfile overhead is substantial,
 the destinations are stored in binary rather than in Base 64 as in the hosts.txt format.
 In addition, the blockfile provides the capability of arbitrary metadata storage
-(such as added date, source, and comments) for each entry to implement advanced addressbook features.
+(such as added date, source, and comments) for each entry to implement advanced address book features.
 The blockfile storage requirement is a modest increase over the hosts.txt format, and the blockfile provides
 approximately 10x reduction in lookup times.
 {%- endtrans %}</p>
@@ -180,11 +180,11 @@ an error page to the user with links to several "jump" services.
 See below for details.
 {%- endtrans %}</p>
 
-<h2 id="addressbook">{% trans %}Addressbook{% endtrans %}</h2>
+<h2 id="addressbook">{% trans %}Address Book{% endtrans %}</h2>
 <h3>{% trans %}Incoming Subscriptions and Merging{% endtrans %}</h3>
 
 <p>{% trans -%}
-The addressbook application periodically
+The address book application periodically
 retrieves other users' hosts.txt files and merges
 them with the local hosts.txt, after several checks.
 Naming conflicts are resolved on a first-come first-served
@@ -205,11 +205,11 @@ default is <code>http://i2p-projekt.i2p/hosts.txt (http://udhdrtrcetjm5sxzskjyr5
 which contains a copy of the hosts.txt included
 in the I2P release.
 Users must configure additional subscriptions in their
-local addressbook application (via subscriptions.txt or <a href="#susidns">SusiDNS</a>).
+local address book application (via subscriptions.txt or <a href="#susidns">SusiDNS</a>).
 {%- endtrans %}</p>
 
 <p>{% trans -%}
-Some other public addressbook subscription links:
+Some other public address book subscription links:
 {%- endtrans %}</p>
 <ul>
 <li><a href="http://{{ i2pconv('i2host.i2p') }}/cgi-bin/i2hostetag">http://{{ i2pconv('i2host.i2p') }}/cgi-bin/i2hostetag</a>
@@ -223,7 +223,7 @@ Presence on this list does not imply endorsement.
 <h3>{% trans %}Naming Rules{% endtrans %}</h3>
 <p>{% trans -%}
 While there are hopefully not any technical limitations within I2P on host names,
-the addressbook enforces several restrictions on host names
+the address book enforces several restrictions on host names
 imported from subscriptions.
 It does this for basic typographical sanity and compatibility with browsers,
 and for security.
@@ -308,7 +308,7 @@ Note that the '.' symbols in a host name are of no significance,
 and do not denote any actual naming or trust hierarchy.
 If the name 'host.i2p' already exists, there is nothing
 to prevent anybody from adding a name 'a.host.i2p' to their hosts.txt,
-and this name can be imported by others' addressbook.
+and this name can be imported by others' address book.
 Methods to deny subdomains to non-domain 'owners' (certificates?),
 and the desirability and feasibility of these methods,
 are topics for future discussion.
@@ -321,7 +321,7 @@ add 'network.IDN.whitelist.i2p (boolean) = true' in about:config.
 {%- endtrans %}</p>
 
 <p>{% trans -%}
-As the addressbook application does not use privatehosts.txt at all, in practice
+As the address book application does not use privatehosts.txt at all, in practice
 this file is the only place where it is appropriate to place private aliases or
 "pet names" for sites already in hosts.txt.
 {%- endtrans %}</p>
@@ -336,7 +336,7 @@ See <a href="/spec/subscription">the specification</a> for details.
 
 <h3>{% trans %}Outgoing Subscriptions{% endtrans %}</h3>
 <p>{% trans -%}
-Addressbook will publish the merged hosts.txt to a location
+Address Book will publish the merged hosts.txt to a location
 (traditionally hosts.txt in the local I2P Site's home directory) to be accessed by others
 for their subscriptions.
 This step is optional and is disabled by default.
@@ -344,7 +344,7 @@ This step is optional and is disabled by default.
 
 <h3>Hosting and HTTP Transport Issues</h3>
 <p>{% trans -%}
-The addressbook application, together with eepget, saves the Etag and/or Last-Modified
+The address book application, together with eepget, saves the Etag and/or Last-Modified
 information returned by the web server of the subscription.
 This greatly reduces the bandwidth required, as the web server will
 return a '304 Not Modified' on the next fetch if nothing has changed.
@@ -373,7 +373,7 @@ will be propagated through the network.
 {%- endtrans %}</p>
 
 <p>{% trans -%}
-It is recommended that host add services impose, at a minimum, the restrictions imposed by the addressbook application listed above.
+It is recommended that host add services impose, at a minimum, the restrictions imposed by the address book application listed above.
 Host add services may impose additional restrictions on hostnames and keys, for example:
 {%- endtrans %}</p>
 <ul>
@@ -446,15 +446,15 @@ several hosts.txt providers so that its local host list is current.
 
 <h2 id="susidns">SusiDNS</h2>
 <p>{% trans -%}
-SusiDNS is simply a web interface front-end to configuring addressbook subscriptions
-and accessing the four addressbook files.
-All the real work is done by the 'addressbook' application.
+SusiDNS is simply a web interface front-end to configuring address book subscriptions
+and accessing the four address book files.
+All the real work is done by the 'address book' application.
 {%- endtrans %}</p>
 
 <p>{% trans -%}
-Currently, there is little enforcement of addressbook naming rules within SusiDNS,
+Currently, there is little enforcement of address book naming rules within SusiDNS,
 so a user may enter hostnames locally that would be rejected by
-the addressbook subscription rules.
+the address book subscription rules.
 {%- endtrans %}</p>
 
 <h2 id="base32">{% trans %}Base32 Names{% endtrans %}</h2>

i2p2www/pages/site/docs/reseed.html

@@ -1,36 +1,61 @@
 {% extends "global/layout.html" %}
 {% block title %}{% trans %}Reseed Hosts{% endtrans %}{% endblock %}
-{% block lastupdated %}{% trans %}January 2016{% endtrans %}{% endblock %}
-{% block accuratefor %}0.9.24{% endblock %}
+{% block lastupdated %}{% trans %}September 2021{% endtrans %}{% endblock %}
+{% block accuratefor %}1.5.0{% endblock %}
 {% block content %}
 
 
 <h2 id="about">{% trans %}About Reseed hosts{% endtrans %}</h2>
 
 <p>{% trans -%}
-Reseed hosts are needed to for bootstrapping, that is, providing the initial set of I2P nodes for your I2P node to talk to. Depending on the status of your node it may need to bootstrap every now and then if many of the nodes it knows of aren't contactable.
+Reseed hosts are needed to for bootstrapping, that is, providing the initial set
+of I2P nodes for your I2P node to talk to. Depending on the status of your node
+it may need to bootstrap every now and then if many of the nodes it knows of
+aren't contactable.
 {%- endtrans %}</p>
 
 <p>{% trans -%}
-Reseeding is done over an encrypted connection and all of the bootstrap information is signed by the reseed host you connect to, making it impossible for an unauthenticated source to provide you with false information.
+Reseeding is done over an encrypted connection and all of the bootstrap
+information is signed by the reseed host you connect to, making it impossible
+for an unauthenticated source to provide you with false information.
 {%- endtrans %}</p>
 
 
 <h2 id="running">{% trans %}Running a Reseed host{% endtrans %}</h2>
 <p>
-{% trans -%}
-The more reseed hosts that are run, the more resilient the I2P network becomes, and the harder it is to prevent users of I2P from connecting to the network.
+{% trans -%}Operating a reseed server can be accessible to any sysadmin familiar
+with I2P, and we encourage new reseed operators to get in contact with us at
+<a href="http://zzz.i2p">the development forums</a>. The more reseed hosts that
+are run, the more resilient the I2P network becomes, and the harder it is to
+prevent users of I2P from connecting to the network.
 {%- endtrans %}
 </p>
-{% trans -%}
-There have also been cases where the reseed hosts we had, have been under heavy load due to botnet activities.
-{%- endtrans %}
-</p>
-<p>
-<a href="{{ site_url('get-involved/guides/reseed') }}">How to run a Reseed host</a>
-</p>
 
-<h2 id="thank you">{% trans %}Thank you{% endtrans %}</h2>
+<ul>
+<li><a href="{{ site_url('get-involved/guides/reseed') }}">Reseed Contributors Guide</a></li>
+<li><a href="https://i2pgit.org/idk/reseed-tools">Reseed Software and Documentation</a></li>
+</ul>
+
+<h2 id="other">{% trans %}Other ways of Reseeding{% endtrans %}</h2>
+
+<p>
+{% trans -%}
+In order to make I2P more reslient, other kinds of reseeding are possible. One
+important way of carrying out a reseed is the file-based reseed, where a user
+with a running I2P router generates a reseed file for a friend and transfers it
+to them as a .zip file. Others use cloud-based infrastructure to resist
+censorship. These reseed methods provide functionality which aids people in
+situations where reseeds are restricted.
+{%- endtrans %}
+</p>
+
+<ul>
+<li><a href="{{ site_url('blog/post/2020/06/07/file-based-reseed') }}">File Based Reseed</a></li>
+<li><a href="https://homepage.np-tokumei.net/post/notes-i2p-reseed-over-cloudflare/">I2P Reseed over Cloudflare</a></li>
+<li><a href="https://homepage.np-tokumei.net/post/notes-censorship-resistant-i2p-reseeding/">Censorship Resistant I2P Reseeding</a></li>
+</ul>
+
+<h2 id="thank you">{% trans %}Thank you Reseed Operators{% endtrans %}</h2>
 <p>
 {%-trans -%}
 If you are running a reseed server, We would like to thank you for helping to

i2p2www/pages/site/docs/transport/ssu.html

@@ -1,7 +1,7 @@
 {% extends "global/layout.html" %}
 {% block title %}{% trans %}Secure Semireliable UDP{% endtrans %} (SSU){% endblock %}
-{% block lastupdated %}2020-09{% endblock %}
-{% block accuratefor %}0.9.48{% endblock %}
+{% block lastupdated %}2021-04{% endblock %}
+{% block accuratefor %}0.9.50{% endblock %}
 {% block content %}
 
 <p>{% trans transports=site_url('docs/transport'), ntcp=site_url('docs/transport/ntcp'), ntcp2=site_url('docs/spec/ntcp2') -%}
@@ -43,7 +43,7 @@ The following properties are stored in the network database.
 
 <ul>
 <li><b>Transport name:</b> SSU
-</li><li><b>caps:</b> [B,C] <a href="#capabilities">{% trans %}See below{%- endtrans %}</a>.
+</li><li><b>caps:</b> [B,C,4,6] <a href="#capabilities">{% trans %}See below{%- endtrans %}</a>.
 </li><li><b>host:</b> IP (IPv4 or IPv6).
   Shortened IPv6 address (with "::") is allowed.
   May or may not be present if firewalled.
@@ -413,8 +413,14 @@ After the hole punch, the session is established between Alice and Charlie as in
 IPv6 is supported as of version 0.9.8.
 Published relay addresses may be IPv4 or IPv6, and
 Alice-Bob communication may be via IPv4 or IPv6.
-Bob-Charlie and Alice-Charlie communication is via IPv4 only.
+Through release 0.9.49, Bob-Charlie and Alice-Charlie communication is via IPv4 only.
+Relaying for IPv6 is supported as of release 0.9.50.
 See the specification for details.
+</p><p>
+While the specification was changed as of version 0.9.8, Alice-Bob communication via IPv6 was not actually supported until version 0.9.50.
+Earlier versions of Java routers erroneously published the 'C' capability for IPv6 addresses,
+even though they did not actually act as an introducer via IPv6.
+Therefore, routers should only trust the 'C' capability on an IPv6 address if the router version is 0.9.50 or higher.
 </p>
 
 
@@ -563,6 +569,12 @@ here. Implementers should add defenses where appropriate.
 
 <h2><a name="capabilities">{% trans %}Peer capabilities{% endtrans %}</a></h2>
 
+<p>
+One or more capabilities may be published in the "caps" option.
+Capabilities may be in any order, but "BC46" is the recommended order, for consistency across implementations.
+</p>
+
+
 <dl>
  <dt>B</dt>
  <dd>{% trans -%}
@@ -577,11 +589,27 @@ the presence or absense of the 'B' capability in an IPv6 address
 indicates actual support (or lack of support).
 </dd>
  <dt>C</dt>
- <dd>{% trans -%}
+ <dd>
 If the peer address contains the 'C' capability, that means
-they are willing and able to serve as an introducer - serving
-as a Bob for an otherwise unreachable Alice.
-{%- endtrans %}</dd>
+they are willing and able to serve as an introducer via that address - serving
+as an introducer Bob for an otherwise unreachable Charlie.
+Prior to release 0.9.50, Java routers incorrectly published the 'C'
+capability for IPv6 addresses, even though IPv6 introducers was not fully implemented.
+Therefore, routers should assume that versions prior to 0.9.50 cannot act as an introducer
+over IPv6, even if the 'C' capability is advertised.
+</dd>
+ <dt>4</dt><dd>
+As of 0.9.50, indicates outbound IPv4 capability.
+If an IP is published in the host field, this capability is not necessary.
+If this is an address with introducers for IPv4 introductions, '4' should be included.
+If the router is hidden, '4' and '6' may be combined in a single address.
+ </dd>
+ <dt>6</dt><dd>
+As of 0.9.50, indicates outbound IPv6 capability.
+If an IP is published in the host field, this capability is not necessary.
+If this is an address with introducers for IPv6 introductions, '6' should be included (not currently supported).
+If the router is hidden, '4' and '6' may be combined in a single address.
+ </dd>
 </dl>
 
 <h1><a name="future">{% trans %}Future Work{% endtrans %}</a></h1>

i2p2www/pages/site/faq.html

@@ -23,9 +23,9 @@
 <li><a href="#myI2P Site">{% trans %}How do I set up my own I2P Site?{% endtrans %}</a></li>
 <li><a href="#hosting">{% trans %}If I host a website at I2P at home, containing only HTML and CSS, is it dangerous?{% endtrans %}</a></li>
 <li><a href="#addresses">{% trans %}How Does I2P find ".i2p" websites?{% endtrans %}</a></li>
-<li><a href="#addressbook">{% trans %}How do I add to the AddressBook?{% endtrans %}</a></li>
+<li><a href="#addressbook">{% trans %}How do I add to the Address Book?{% endtrans %}</a></li>
 <li><a href="#ports">{% trans %}What ports does I2P use?{% endtrans %}</a></li>
-<li><a href="#subscriptions">{% trans %}I'm missing lots of hosts in my addressbook. What are some good subscription links?{% endtrans %}</a></li>
+<li><a href="#subscriptions">{% trans %}I'm missing lots of hosts in my address book. What are some good subscription links?{% endtrans %}</a></li>
 <li><a href="#remote_webconsole">{% trans %}How can I access the web console from my other machines or password protect it?{% endtrans %}</a></li>
 <li><a href="#remote_i2cp">{% trans %}How can I use applications from my other machines?{% endtrans %}</a></li>
 <li><a href="#socks">{% trans %}Is it possible to use I2P as a SOCKS proxy?{% endtrans %}</a></li>
@@ -248,12 +248,12 @@ Tahoe-LAFS, but they require additional set up and are only appropriate for some
 yourself from a real threat will take real consideration in any case.{% endtrans %}</p>
 
 <h3 id="addresses">{% trans %}How Does I2P find ".i2p" websites? {% endtrans %}</h3>
-<p>The I2P Addressbook application maps human-readable names to long-term destinations, associated with services, making it more like a hosts file or a contact list than a network database or a DNS service. It's also local-first there is no recognized global namespace, you decide what any given .i2p domain maps to in the end. The middle-ground is something called a "Jump Service" which provides a human-readable name by redirecting you to a page where you will be asked "Do you give the I2P router permission to call $SITE_CRYPTO_KEY the name $SITE_NAME.i2p" or something to that effect. Once it's in your addressbook, you can generate your own jump URL's to help share the site with others. </p>
+<p>The I2P Address Book application maps human-readable names to long-term destinations, associated with services, making it more like a hosts file or a contact list than a network database or a DNS service. It's also local-first there is no recognized global namespace, you decide what any given .i2p domain maps to in the end. The middle-ground is something called a "Jump Service" which provides a human-readable name by redirecting you to a page where you will be asked "Do you give the I2P router permission to call $SITE_CRYPTO_KEY the name $SITE_NAME.i2p" or something to that effect. Once it's in your address book, you can generate your own jump URL's to help share the site with others. </p>
 
-<h3 id="addressbook">{% trans %}How do I add addresses to the Addressbook? {% endtrans %}</h3>
+<h3 id="addressbook">{% trans %}How do I add addresses to the Address Book? {% endtrans %}</h3>
 <p>{% trans %}You cannot add an address without knowing at least the base32 or base64 of the site you want to visit. The "hostname" which is human-readable is only an alias for the cryptographic address, which corresponds to the base32 or base64. Without the cryptographic address, there is no way to access an I2P Site, this is by design. Distributing the address to people who do not know it yet is usually the responsibility of the Jump service provider. Visiting an I2P Site which is unknown will trigger the use of a Jump service. stats.i2p is the most reliable Jump service.{% endtrans %}</p>
 
-<p>{% trans %}If you're hosting a site via i2ptunnel, then it won't have a registration with a jump service yet. To give it a URL locally, then visit the configuration page and click the button that says "Add to Local Addressbook." Then go to http://127.0.0.1:7657/dns to look up the addresshelper URL and share it.{% endtrans %}</p>
+<p>{% trans %}If you're hosting a site via i2ptunnel, then it won't have a registration with a jump service yet. To give it a URL locally, then visit the configuration page and click the button that says "Add to Local Address Book." Then go to http://127.0.0.1:7657/dns to look up the addresshelper URL and share it.{% endtrans %}</p>
 
 <h3 id="ports"><span class="permalink"><a href="#ports">
 {% trans %}What ports does I2P use?{% endtrans %}</a></span>
@@ -530,22 +530,22 @@ only hurts you - don't do it).
 {%- endtrans %}</p>
 
 <h3 id="subscriptions"><span class="permalink"><a href="#subscriptions">
-{% trans %}I'm missing lots of hosts in my addressbook. What are some good subscription links?{% endtrans %}</a></span></h3>
+{% trans %}I'm missing lots of hosts in my address book. What are some good subscription links?{% endtrans %}</a></span></h3>
 <p>{% trans -%}
 This question can be answered in 3 parts:
 {%- endtrans %}</p>
 
 <ol>
-  <li>{% trans -%}My router often displays a message saying "Website Not Found In Addressbook", why do I see this message?{%- endtrans %}
+  <li>{% trans -%}My router often displays a message saying "Website Not Found In Address Book", why do I see this message?{%- endtrans %}
     <p>{% trans -%}Human-readable addresses such as <i>http://website.i2p</i> are references to a long, random string known as a <b>destination</b>. 
-    These references are registered and stored at addressbook services such as stats.i2p, which is run by zzz. 
+    These references are registered and stored at address book services such as stats.i2p, which is run by zzz. 
     You will often encounter a "b32" address. A "b32" is a hash (specifically, a <a href="https://en.wikipedia.org/wiki/SHA-2">SHA256</a> hash) of the 
-    destination. This hash is appended with ".b32.i2p" and serves as a convenient way to link to your hidden service, without requiring any registration on an addressbook service.{%- endtrans %}</p>
+    destination. This hash is appended with ".b32.i2p" and serves as a convenient way to link to your hidden service, without requiring any registration on an address book service.{%- endtrans %}</p>
     <p>{% trans -%}It is possible to add subscriptions to your router's configuration which may reduce the frequency of these messages.{%- endtrans %}</p></li>
-  <li>{% trans -%}What is an addressbook subscription?{%- endtrans %}
+  <li>{% trans -%}What is an address book subscription?{%- endtrans %}
     <p>{% trans -%}This is a list of files hosted on various I2P websites each of which contain a list of I2P hosts and their associated destinations.{%- endtrans %}</p>
-    <p>{% trans -%}The addressbook is located at <a href="http://localhost:7657/dns">http://localhost:7657/dns</a> where further information can be found.{%- endtrans %}</p></li>
-  <li>{% trans -%}What are some good addressbook subscription links?{%- endtrans %}
+    <p>{% trans -%}The address book is located at <a href="http://localhost:7657/dns">http://localhost:7657/dns</a> where further information can be found.{%- endtrans %}</p></li>
+  <li>{% trans -%}What are some good address book subscription links?{%- endtrans %}
     <p>{% trans -%}You may try the following:{%- endtrans %}</p>
 <div class="links">
 <ul>
@@ -1043,8 +1043,8 @@ either through our IRC network, IRC2P, or on Freenode.{%- endtrans %}</p>
 <ul>
 <li>{% trans -%}Our Bugtracker:{%- endtrans %}
   <ul>
-    <li>{% trans -%}Non-private internet:{%- endtrans %} <a href="https://trac.i2p2.de/report/1">https://trac.i2p2.de/report/1</a></li>
-    <li>{% trans -%}On I2P:{%- endtrans %} <a href="http://trac.i2p2.i2p/report/1">http://trac.i2p2.i2p/report/1</a></li>
+    <li>{% trans -%}Non-private internet:{%- endtrans %} <a href="https://i2pgit.org/i2p-hackers/i2p.i2p/issues">https://i2pgit.org/i2p-hackers/i2p.i2p/issues</a></li>
+    <li>{% trans -%}On I2P:{%- endtrans %} <a href="http://git.idk.i2p/i2p-hackers/i2p.i2p/issues">http://i2pgit.org/i2p-hackers/i2p.i2p/issues</a></li>
   </ul>
 <li>{% trans -%}Our forums:{%- endtrans %} <a href="http://{{ i2pconv('i2pforum.i2p') }}/">{{ i2pconv('i2pforum.i2p') }}</a></li>
 <li>{% trans -%}You may paste any interesting logs to a paste service such as the non-private internet services listed on the 

i2p2www/pages/site/get-involved/develop/licenses.html

@@ -131,7 +131,7 @@ to what licenses meet the above four guarantees for inclusion in the I2P distrib
   <td valign="top" align="left">zzz</td>
  </tr>
  <tr>
-  <td valign="top" align="left"><b>Addressbook</b></td>
+  <td valign="top" align="left"><b>Address Book</b></td>
   <td valign="top" align="left">apps/addressbook</td>
   <td valign="top" align="left">addressbook.war</td>
 

i2p2www/pages/site/get-involved/guides/dev-guidelines.html

@@ -1,6 +1,6 @@
 {% extends "global/layout.html" %}
 {% block title %}{{ _('Developer Guidelines and Coding Style') }}{% endblock %}
-{% block lastupdated %}2020-05{% endblock %}
+{% block lastupdated %}2021-01{% endblock %}
 {% block content %}
 <p>{% trans newdevs=site_url('get-involved/guides/new-developers') -%}
 Read the <a href="{{ newdevs }}">new developers guide</a> first.
@@ -75,19 +75,19 @@ Hours before release: Code review deadline.
 
 
 
-<h3>Monotone</h3>
+<h3>Git</h3>
 <ul>
 <li>{% trans -%}
 Have a basic understanding of distributed source control systems, even if you haven't
-used monotone before. Ask for help if you need it.
+used git before. Ask for help if you need it.
 Once pushed, checkins are forever, there is no undo. Please be careful.
-If you have not used monotone before, start with baby steps.
+If you have not used git before, start with baby steps.
 Check in some small changes and see how it goes.
 {%- endtrans %}</li>
 <li>{% trans -%}
 Test your changes before checking them in.
 If you prefer the checkin-before-test development model,
-use your own development branch (e.g. i2p.i2p.yourname.test)
+use your own development branch
 and propagate back to i2p.i2p once it is working well.
 Do not break the build. Do not cause regressions.
 In case you do (it happens), please do not vanish for a long period after
@@ -99,20 +99,13 @@ to know whether your change was tested or not, add a checkin comment to history.
 and increment the build revision in RouterVersion.java.
 {%- endtrans %}</li>
 <li>{% trans -%}
-Ensure that you have the latest monotonerc file in _MTN.
-Do not check in on top of untrusted revisions.
-{%- endtrans %}</li>
-<li>{% trans -%}
-Ensure that you 'mtn pull' and 'mtn update' to the latest revision before you check in and push.
+Ensure that you 'git pull' to the latest revision before you check in and push.
 If you inadvertently diverge, merge and push as soon as possible.
 Don't routinely make others merge for you.
-Yes, we know that monotone says you should push and then merge,
-but in our experience, in-workspace merge works just as well as in-database merge,
-without creating a merge revision.
 {%- endtrans %}</li>
 <li>{% trans -%}
 Do not check in major changes into the main i2p.i2p branch late in the release cycle.
-If a project will take you more than a couple days, create your own branch in monotone
+If a project will take you more than a couple days, create your own branch in git
 and do the development there so you do not block releases.
 {%- endtrans %}</li>
 </ul>

i2p2www/pages/site/get-involved/guides/monotone.html

@@ -1,5 +1,6 @@
 {% extends "global/layout.html" %}
 {% block title %}{% trans %}Monotone Guide{% endtrans %}{% endblock %}
+{% block lastupdated %}2021-01{% endblock %}
 {% block content_nav %}
   <ol>
     <li>
@@ -28,6 +29,8 @@
 {% endblock %}
 
 {% block content %}
+<p><b>Note:</b> We are no longer using monotone. The project has migrated all source repos to git.</p>
+
 <p><i>
   {% trans transitionguide=site_url('misc/transition-guide'), newdevs=site_url('get-involved/guides/new-developers') -%}
   This is a revised version of <a href="{{ transitionguide }}">Complication's original

i2p2www/pages/site/get-involved/guides/new-developers.html

@@ -1,13 +1,12 @@
 {% extends "global/layout.html" %}
 {% block title %}{% trans %}New Developer's Guide{% endtrans %}{% endblock %}
-{% block lastupdated %}{% trans %}July 2018{% endtrans %}{% endblock %}
+{% block lastupdated %}2021-01{% endblock %}
 {% block content_nav %}
   <ol>
     <li><a href="#basic-study">{% trans %}Basic study{% endtrans %}</a></li>
     <li><a href="#getting-the-i2p-code">{% trans %}Getting the I2P code{% endtrans %}</a>
     <ul>
-      <li><a href="#git">{% trans %}The easy way: Git{% endtrans %}</a></li>
-      <li><a href="#monotone">{% trans %}The proper way: Monotone{% endtrans %}</a></li>
+      <li><a href="#git">{% trans %}The new way: Git{% endtrans %}</a></li>
     </ul></li>
     <li><a href="#building-i2p">{% trans %}Building I2P{% endtrans %}</a></li>
     <li><a href="#development-ideas">{% trans %}Development ideas{% endtrans %}</a></li>
@@ -50,89 +49,35 @@ For development on the I2P router or the embedded applications,
 there are two ways to get the source code:
 {%- endtrans %}</p>
 
-<h3 id="git">{% trans %}The easy way: Git{% endtrans %}</h3>
-<ul>
-  <li>{% trans git_url='https://git-scm.com/' -%}
+<h3 id="git">{% trans %}The new way: Git{% endtrans %}</h3>
+
+<p>{% trans trac="https://i2pgit.org" -%}I2P now has official Git services and accepts contributions via Git at our own gitlab.
+Trac issues have also been migrated to <a href="{{ trac }}">gitlab</a>, however Trac still available for now. Two-way syncing of
+issues between Gitlab and Github is a work-in-progress.{%- endtrans %}</p>
+
+<li>{% trans git_url='https://git-scm.com/' -%}
 Install <a href="{{ git_url }}">Git</a>.
   {%- endtrans %}</li>
-  <li>{% trans i2p_git='https://github.com/i2p/i2p.i2p' -%}
-Get the code from <a href="{{ i2p_git }}">the GitHub mirror</a>:
+
+
+<ul>
+  <li><strong><a href="http://git.idk.i2p">{% trans %}Inside I2P - (http://git.idk.i2p){% endtrans %}</a></strong>
+  </li>
+  <li><strong><a href="https://i2pgit.org">{% trans %}Outside I2P - (https://i2pgit.org){% endtrans %}</a></strong>
+  </li>
+  <code>git clone https://i2pgit.org/i2p-hackers/i2p.i2p.git</code>
+</ul>
+
+<p>The read-only mirror is also still available at github.</p>
+
+<ul>
+  <li><strong>{% trans i2p_git='https://github.com/i2p/i2p.i2p' -%}  
+    <a href="{{ i2p_git }}">GitHub mirror</a></strong>:
   {%- endtrans %}<br>
     <code>git clone https://github.com/i2p/i2p.i2p.git</code>
   </li>
 </ul>
 
-<h4>{% trans %}Remarks{% endtrans %}</h4>
-<p>{% trans trac='http://'+i2pconv('trac.i2p2.i2p') -%}
-The Git repository is currently a read-only mirror. If you wish to use it for
-development, you will need to submit patches to <a href="{{ trac }}">our issue
-tracker</a>. We can accept GitHub pull requests, but they must be processed
-manually by turning them into patches anyway.
-{%- endtrans %}</p>
-
-<h3 id="monotone">{% trans %}The proper way: Monotone{% endtrans %}</h3>
-<ul>
-  <li>{% trans -%}
-Install <a href="http://www.monotone.ca/">monotone</a>.
-Monotone is a version control system.
-We use it because it allows us to keep track of who does what changes to the source code (and for a lot of complicated things, but 'keeping track of changes' is the basic idea).
-  {%- endtrans %}</li>
-  <li>{% trans -%}
-Skim over the <a href="http://www.monotone.ca/docs/Tutorial.html">monotone tutorial</a>, to make sure you understand the concepts.
-  {%- endtrans %}</li>
-  <li>
-    <p>{% trans -%}
-      If you want to remain anonymous, you need to do an additional step, to set up a connection to a monotone server over I2P:
-    {%- endtrans %}</p>
-    <p>{% trans i2ptunnel=site_url('docs/api/i2ptunnel') -%}
-      Enable the <a href="{{ i2ptunnel }}">i2ptunnel</a> client tunnel on port 8998 pointing to mtn.i2p-projekt.i2p.
-    {%- endtrans %}</p>
-  </li>
-  <li>{% trans -%}
-  Pick a directory where you want to put all your I2P files, and create a monotone database:{% endtrans %} <code><b>mtn -d i2p.mtn db init</b></code>
-  </li>
-  <li>{% trans -%}
-Define the trust list by creating <code>~/.monotone/monotonerc</code> (or <code>_MTN/monotonerc</code> in the i2p.i2p workspace) with the following contents:
-{%- endtrans %}
-{% include "include/monotonerc.html" %}
-</li>
-  <li>{% trans devkeys=site_url('get-involved/develop/developers-keys') -%}
-Copy and paste the <a href="{{ devkeys }}">developer's commit keys</a> into a new file (e.g. <code>keys.txt</code>) in the same directory
-  that <code>i2p.mtn</code> is in. Import the keys into your database with <br><code><pre>      mtn -d i2p.mtn read < keys.txt</pre></code>
-  {%- endtrans %}</li>
-  <li>{% trans %}Pull the I2P sources to your machine. This may take a long time, especially if you are doing this over I2P!{% endtrans %}
-    <ul>
-      <li>{% trans %}Anonymously:{% endtrans %} <code><b>mtn -d i2p.mtn -k "" pull "mtn://127.0.0.1:8998?i2p.i2p"</b></code></li>
-      <li>
-        <p>
-           {% trans %}Non-anonymously:{% endtrans %} <code><b>mtn -d i2p.mtn -k "" pull "mtn://mtn.i2p-projekt.de?i2p.i2p"</b></code>
-        </p>
-    </ul>
-  </li>
-  <li>
-    <p>
-    {% trans %}All the sources are now present on your machine, in the database file. To make them available in a directory, you need to check them out:{% endtrans %} <code><b>mtn -d i2p.mtn co --branch=i2p.i2p</b></code>
-    </p>
-    <p>{% trans %}The above command creates a directory i2p.i2p, which contains all of the I2P sources.{% endtrans %}</p>
-  </li>
-</ul>
-
-<h4>{% trans %}Remarks{% endtrans %}</h4>
-<p>{% trans %}
-To download the website files instead of the I2P source files, use 'i2p.www' instead of 'i2p.i2p'.
-{%- endtrans %}</p>
-<p>{% trans -%}
-The initial pull may take several hours using the tunnel.
-If it fails after a partial pull, simply rerun it, it will start where it left off.
-If you are in a hurry, use the non-anonymous access.
-{%- endtrans %}</p>
-<p>{% trans viewmtn='http://'+i2pconv('killyourtv.i2p')+'/viewmtn/' -%}
-A full list of branches, including i2p.i2p and i2p.www can be found on <a href="{{ viewmtn }}">viewmtn</a>.
-{%- endtrans %}</p>
-<p>{% trans monotone=site_url('get-involved/guides/monotone') -%}
-A long explanation about using monotone is available on the <a href="{{ monotone }}">monotone page</a>.
-{%- endtrans %}</p>
-
 <h2 id="building-i2p">{% trans %}Building I2P{% endtrans %}</h2>
 
 <p>{% trans sunjdk6='http://www.oracle.com/technetwork/java/javase/downloads/index.html' -%}
@@ -155,7 +100,7 @@ see the <a href="{{ apps }}">application development guide</a>.
 {%- endtrans %}</p>
 
 <h2 id="development-ideas">{% trans %}Development ideas{% endtrans %}</h2>
-<p>{% trans zzz=i2pconv('zzz.i2p'), todo=site_url('get-involved/todo'), trac='https://trac.i2p2.de/report/1' -%}
+<p>{% trans zzz=i2pconv('zzz.i2p'), todo=site_url('get-involved/todo'), trac='https://i2pgit.org/i2p-hackers/i2p.i2p/issues' -%}
 See <a href="http://{{ zzz }}/forums/3">zzz's TODO lists</a>,
 <a href="{{ todo }}">this website's TODO list</a> or
 <a href="{{ trac }}">Trac</a>
@@ -169,20 +114,6 @@ See the bottom of <a href="{{ licenses }}#commit">the licenses page</a> for
 commit privilege requirements. You need these to put code into i2p.i2p (not required for the website!).
 {%- endtrans %}</p>
 
-<p>{% trans %}Short version of how to generate and use keys if you plan to commit:{% endtrans %}
-  <ul>
-    <li>mtn genkey yourname-transport@mail.i2p <i>({% trans %}use an empty passphrase{% endtrans %})</i>
-    <li>mtn genkey yourname@mail.i2p <i>({% trans %}enter a passphrase{% endtrans %})</i>
-    <li>mtn pubkey yourname-transport@mail.i2p <i>({% trans email='echelon@mail.i2p' %}<a href="mailto:{{ email }}">send</a> this to a mtn repo operator to get push privileges{% endtrans %})</i>
-    <li>mtn pubkey yourname@mail.i2p <i>({% trans email='zzz@mail.i2p' %}send this to <a href="mailto:{{ email }}">a release manager</a> to get commit privileges - not required for website{% endtrans %})</i>
-    <li>mtn ci -k yourname@mail.i2p <i>({% trans %}check in with this key{% endtrans %})</i>
-    <li>mtn sync -k yourname-transport@mail.i2p <i>({% trans %}push with this key{% endtrans %})</i>
-  </ul>
-{% trans monotone=site_url('get-involved/guides/monotone') -%}
-Long version: see the <a href="{{ monotone }}">monotone page</a>.
-{%- endtrans %}
-</p>
-
 <h2 id="get-to-know-us">{% trans %}Get to know us!{% endtrans %}</h2>
 <p>{% trans guidelines=site_url('get-involved/guides/dev-guidelines') -%}
 The developers hang around on IRC. They can be reached on the Freenode network, OFTC, and on the I2P internal networks. The usual place to look is #i2p-dev. Join the channel and say hi!

i2p2www/pages/site/get-involved/index.html

@@ -17,6 +17,13 @@ Other contact information is maintained on <a href="{{ team }}">this page</a>.
 If you're interested in development, <a href="{{ team }}">please get in
 touch as we're always looking for new contributors.</a>
 {%- endtrans %}</p>
+<h3>{% trans %}Join us on our Gitlab{% endtrans %}</h3>
+<ul>
+<li><strong><a href="http://git.idk.i2p">{% trans %}Inside I2P - (http://git.idk.i2p){% endtrans %}</a></strong>
+</li>
+<li><strong><a href="https://i2pgit.org">{% trans %}Outside I2P - (https://i2pgit.org){% endtrans %}</a></strong>
+</li>
+</ul>
 <p>{% trans -%}
 We need help in many areas, and you don't need to know Java to contribute.
 Here's a list to help get you started.

i2p2www/pages/site/get-involved/roadmap.html

@@ -1,217 +1,212 @@
 {% extends "global/layout.html" %}
 {% block title %}{{ _('Roadmap') }}{% endblock %}
-{% block lastupdated %}2020-08{% endblock %}
+{% block lastupdated %}2021-09{% endblock %}
 {% block content %}
 
 <p>
 This is the official project roadmap for the desktop and Android Java I2P releases only.
-Some related tasks for related resources such as the website and plugins are included.
+Some related tasks for resources such as the website and plugins may be included.
 </p><p>
-For details and discussion on specific items, search on trac or zzz.i2p.
+For details and discussion on specific items, search on gitlab or zzz.i2p.
 For contents of past releases, see the release notes.
 For other project goals, see the meeting notes.
 </p><p>
-Note that we do not have a particular target for numbering a release as "1.0".
-We plan to continue numbering releases as 0.9.x for now.
 We do not maintain separate unstable and stable branches or releases.
 We have a single, stable release path.
-Our normal release cycle is 13 weeks.
+Our normal release cycle is 13 weeks, with releases in
+February, May, August, and November.
 </p><p>
 Older releases are at the bottom of the page.
 </p>
 
 
-
-
-<h2 id="0.9.45">0.9.45</h2>
-<p><b>Released: February 25, 2020</b></p>
-<ul><li>
-Hidden mode fixes
-</li><li>
-Bandwidth test fixes
-</li><li>
-ECIES Proposal 144 testing, fixes
-</li><li>
-Susimail login page improvements
-</li><li>
-LibSam - deduplication, documentation, support
-</li><li>
-Console theme modernization(Light and Dark)
-</li><li>
-Consistency with modern themes for SusiDNS, SusiMail apps
-</li><li>
-Leftover light theme nits
- <ul><li>
- border colours that are still present
- </li><li>
- download sidebar status is still gradient filled
- </li><li>
- take out network status icons? Replace with colours from style guide?
- </li><li>
- go over icons on every page and evaluate
- </li><li>
- try I2P blue icons on /home
- </li><li>
- buttons / tabs consistency
- </li></ul>
-</li><li>
-Dark Theme
- <ul><li>
- Carry over tabs/ buttons decisions
- </li><li>
- decide on theme colour
- </li></ul>
-</li><li>
-Susi Mail Light & Dark
- <ul><li>
- Remove icon bloat
- </li><li>
- make buttons rounded
- </li><li>
- remove gradient on login page
- </li><li>
- add a product description to login page
- </li><li>
- **change icon colours for themes
- </li></ul>
-</li></ul>
-
-
-
-<h2 id="0.9.46">0.9.46</h2>
-<p><b>Released: May 25, 2020</b></p>
-<ul><li>
-Replace jrobin with rrd4j
-</li><li>
-ECIES Proposal 144 testing, fixes, completion
-</li><li>
-ECIES lookup replies
-</li><li>
-i2ptunnel edit page redesign
-</li><li>
-Streaming performance improvements
-</li><li>
-Start migrating deb.i2p2.no
-</li><li>
-Android fixes
-</li><li>
-Long-term strategy for website
-</li><li>
-Identity and Values Workshops
-</li><li>
-Branding Foundations Work
-</li><li>
-Information Architecture Sprint : Console and Website
-</li><li>
-Console Interface Redesign prototypes
-</li><li>
-Console Interface Usability Testing
-</li><li>
-Reproducible build fix
-</li><li>
-Streaming fixes
-</li><li>
-UPnP fixes
-</li>
-</ul>
-
-
-
-<h2 id="0.9.47">0.9.47</h2>
--<p><b>Target release: Late August 2020</b></p>
-<ul><li>
-Require Java 8
-</li><li>
-Jetty 9.3.x
-</li><li>
-json-simple 2.3.0
-</li><li>
-RRD4j 3.6
-</li><li>
-ECIES enabled by default for some tunnels
-</li><li>
-Increase streaming MTU for ECIES connections
-</li><li>
-Enable Sybil analysis and blocking by default
-</li><li>
-Begin transition to Git
-</li><li>
-Improvements to the Bandwidth Setup/Welcome Wizard imagery and text
-</li><li>
-Ongoing refinements to new dark and light theme
-</li><li>
-Find and replace inconsistent icons from the router console
-</li><li>
-Bug Fixes on Android versions later than 8.0
-</li><li>
-Hide empty sections on router console home page
-</li><li>
-Operators guides for reseed services
-</li><li>
-Detailed install guide for the main I2P Java distribution
-</li><li>
-Begin implementing Information Architecture improvements to geti2p.net
-</li><li>
-Identify and Publish information about critical infrastructures(VCS, website, reseeds, repositories, mirrors)
-</li><li>
-Publish log retention policy Recommendations and Guidelines for service admins
-</li><li>
-In depth blog entries on: Site Hosting/Service operation, Project Services, Policy Recommendations
-</li><li>
-Release(Tag)-time "git bundle" generation and distribution by either HTTP or Bittorrent.
-</li></ul>
-
-
-
 <h2 id="0.9.48">0.9.48</h2>
--<p><b>Target release: November 2020</b></p>
+<p><b>Released: December 1, 2020</b></p>
 <ul><li>
-Start work on SSU2
+ECIES router tunnel build record
+</li><li>
+Avoid old DSA-SHA1 routers
+</li><li>
+Block same-country connections when in hidden mode
+</li><li>
+Deprecate BOB
+</li><li>
+Drop support for Xenial
+</li><li>
+Ratchet efficiency improvements and memory reduction
+</li><li>
+Randomize SSU intro key
+</li><li>
+Enable system tray for Linux KDE and LXDE
 </li><li>
 More SSU performance improvements
 </li><li>
-Readthedocs support
-</li><li>
 Continue transition to Git
 </li><li>
-Update onboarding information in router console readme
-</li><li>
 Operators guides for reseed services
 </li><li>
-Revise CSS on the default I2P Site to resemble console Light theme
-</li><li>
 Windows Installer "Install as Windows Service" bugfixes and improvements.
 </li><li>
-Snark UI improvements - Snark RPC inclusion
-</li><li>
 Implement controlled vocabuary as part of Information Architecture improvements
 </li><li>
-Thread-safe implementation of i2cp.rekeyOnIdle
-</li><li>
 Alternate destination header/meta tag for web sites offering I2P mirrors
 </li><li>
 Snark in the Browser: Use torrents as alternates sources for resources embedded in an I2P Site
 </li><li>
 Snark in the Browser: Demo a torrent-backed web page
 </li><li>
-git-remote-i2p research(gittorrent branch project, eventual feature in gittorrent)
-</li><li>
-I2PControl expansion for new console prototype
-</li><li>
 finish ji2p-cluster which adds the k8s part of the code
 </li><li>
-Donation page redesign and backend (deployment)
-</li><li>
-New console prototype
-</li><li>
-Enable setting up the Jetty I2P Site with a custom directory from the I2PTunnel Wizard (Or otherwise enable serving a static directory of files using only I2PTunnel)
-</li><li>
-Outproxy requirements
-</li><li>
 Publish reasonable contact information for infrastructure admins
 </li></ul>
 
 
+
+<h2 id="0.9.49">0.9.49</h2>
+<p><b>Released: February 17, 2021</b></p>
+<ul><li>
+SSU send individual fragments
+</li><li>
+SSU Westwood+
+</li><li>
+SSU fast retransmit
+</li><li>
+SSU fix partial acks
+</li><li>
+ECIES router encrypted messages
+</li><li>
+Start rekeying routers to ECIES
+</li><li>
+Start work on new tunnel build message (proposal 157)
+</li><li>
+More SSU performance improvements
+</li><li>
+i2psnark webseed support
+</li><li>
+Start work on i2psnark hybrid v2 support
+</li><li>
+Move web resources to wars
+</li><li>
+Move resources to jars
+</li><li>
+Fix Gradle build
+</li><li>
+Hidden mode fixes
+</li><li>
+Change DoH to RFC 8484
+</li><li>
+Fix "Start on Boot" support on Android
+</li><li>
+Add support for copying b32 addresses from the tunnels panel on I2P for Android client
+</li><li>
+Add SAMv3 Support to I2P for Android
+</li><li>
+Revise CSS on the default I2P Site to resemble console Light theme
+</li><li>
+Document setup/configuration of default I2P site on the project site
+</li><li>
+Add icons and symbols used in I2P router console Light theme to router console Dark theme
+</li><li>
+Complete transition to Git
+</li><li>
+Donation page redesign and backend (deployment)
+</li><li>
+Review and update information about VCS, Code Repositories, and Mirrors across the entire website.
+</li></ul>
+
+
+
+<h2 id="0.9.50">0.9.50</h2>
+<p><b>Released: May 18, 2021</b></p>
+<ul><li>
+Accelerate rekeying routers to ECIES
+</li><li>
+UPnP IPv6 support
+</li><li>
+4/6 router address caps (proposal 158)
+</li><li>
+IPv6 introducers (proposal 158)
+</li><li>
+NTP year 2036 fixes
+</li><li>
+Continue work on new tunnel build message (proposal 157)
+</li><li>
+Enable DoH for reseeding
+</li><li>
+Docker improvements
+</li><li>
+SSU IPv6 fixes
+</li><li>
+Persist Sybil blocklist
+</li><li>
+Tunnel bandwidth limiter fixes
+</li></ul>
+
+
+
+<h2 id="1.5.0">1.5.0 (API 0.9.51)</h2>
+<p><b>Released: Aug. 23, 2021</b></p>
+<ul><li>
+Accelerate rekeying routers to ECIES
+</li><li>
+Start work on SSU2
+</li><li>
+Implement new tunnel build messages (proposal 157)
+</li><li>
+Support dmg and exe automatic updates
+</li><li>
+New native OSX installer
+</li><li>
+X-I2P-Location(alt-svc) locations for built-in I2P Site
+</li><li>
+RRD4J 3.8
+</li><li>
+Create C, CGo, SWIG bindings for libi2pd
+</li></ul>
+
+
+
+
+<h2 id="1.6.0">1.6.0 (API 0.9.52)</h2>
+<p><b>Target release: November 2021</b></p>
+<ul><li>
+Accelerate rekeying routers to ECIES
+</li><li>
+Continue work on SSU2
+</li><li>
+Send new tunnel build messages (proposal 157)
+</li><li>
+Include automatic browser configuration tool in IzPack installer
+</li><li>
+Make Fork-and-Exec Plugins Managable
+</li><li>
+Add I2P-Location Support to HTTP Proxy
+</li><li>
+Create Debian/Ubuntu Package of I2P Browser Profile
+</li><li>
+Create Plugin of I2P Browser Profile
+</li><li>
+Document I2P for Android applications
+</li><li>
+Document jpackage install processes
+</li><li>
+Complete, document Go/Java Plugin Generation Tools
+</li><li>
+Reseed Plugin - Run a self-signed HTTPS reseed as a Java router plugin with no configuration.
+</li></ul>
+
+
+
+
+
+<h2 id="1.7.0">1.7.0 (API 0.9.53)</h2>
+<p><b>Target release: February 2021</b></p>
+<ul><li>
+TBD
+</li></ul>
+
+
+
 <p>{% trans todo=site_url('get-involved/todo') -%}
 Please see the <a href="{{ todo }}">TODO</a> list for more detailed info about some of these tasks.
 {%- endtrans %}</p>
@@ -770,4 +765,146 @@ ECIES Proposal 144 initial implementation
 Donation page redesign and backend (development)
 </li></ul>
 
+
+
+<h2 id="0.9.45">0.9.45</h2>
+<p><b>Released: February 25, 2020</b></p>
+<ul><li>
+Hidden mode fixes
+</li><li>
+Bandwidth test fixes
+</li><li>
+ECIES Proposal 144 testing, fixes
+</li><li>
+Susimail login page improvements
+</li><li>
+LibSam - deduplication, documentation, support
+</li><li>
+Console theme modernization(Light and Dark)
+</li><li>
+Consistency with modern themes for SusiDNS, SusiMail apps
+</li><li>
+Leftover light theme nits
+ <ul><li>
+ border colours that are still present
+ </li><li>
+ download sidebar status is still gradient filled
+ </li><li>
+ take out network status icons? Replace with colours from style guide?
+ </li><li>
+ go over icons on every page and evaluate
+ </li><li>
+ try I2P blue icons on /home
+ </li><li>
+ buttons / tabs consistency
+ </li></ul>
+</li><li>
+Dark Theme
+ <ul><li>
+ Carry over tabs/ buttons decisions
+ </li><li>
+ decide on theme colour
+ </li></ul>
+</li><li>
+Susi Mail Light & Dark
+ <ul><li>
+ Remove icon bloat
+ </li><li>
+ make buttons rounded
+ </li><li>
+ remove gradient on login page
+ </li><li>
+ add a product description to login page
+ </li><li>
+ **change icon colours for themes
+ </li></ul>
+</li></ul>
+
+
+
+<h2 id="0.9.46">0.9.46</h2>
+<p><b>Released: May 25, 2020</b></p>
+<ul><li>
+Replace jrobin with rrd4j
+</li><li>
+ECIES Proposal 144 testing, fixes, completion
+</li><li>
+ECIES lookup replies
+</li><li>
+i2ptunnel edit page redesign
+</li><li>
+Streaming performance improvements
+</li><li>
+Start migrating deb.i2p2.no
+</li><li>
+Android fixes
+</li><li>
+Long-term strategy for website
+</li><li>
+Identity and Values Workshops
+</li><li>
+Branding Foundations Work
+</li><li>
+Information Architecture Sprint : Console and Website
+</li><li>
+Console Interface Redesign prototypes
+</li><li>
+Console Interface Usability Testing
+</li><li>
+Reproducible build fix
+</li><li>
+Streaming fixes
+</li><li>
+UPnP fixes
+</li>
+</ul>
+
+
+
+<h2 id="0.9.47">0.9.47</h2>
+<p><b>Released: August 24, 2020</b></p>
+<ul><li>
+Require Java 8
+</li><li>
+Jetty 9.3.x
+</li><li>
+json-simple 2.3.0
+</li><li>
+RRD4j 3.6
+</li><li>
+ECIES enabled by default for some tunnels
+</li><li>
+Increase streaming MTU for ECIES connections
+</li><li>
+Enable Sybil analysis and blocking by default
+</li><li>
+Begin transition to Git
+</li><li>
+Improvements to the Bandwidth Setup/Welcome Wizard imagery and text
+</li><li>
+Ongoing refinements to new dark and light theme
+</li><li>
+Find and replace inconsistent icons from the router console
+</li><li>
+Bug Fixes on Android versions later than 8.0
+</li><li>
+Hide empty sections on router console home page
+</li><li>
+Operators guides for reseed services
+</li><li>
+Detailed install guide for the main I2P Java distribution
+</li><li>
+Begin implementing Information Architecture improvements to geti2p.net
+</li><li>
+Identify and Publish information about critical infrastructures(VCS, website, reseeds, repositories, mirrors)
+</li><li>
+Publish log retention policy Recommendations and Guidelines for service admins
+</li><li>
+In depth blog entries on: Site Hosting/Service operation, Project Services, Policy Recommendations
+</li><li>
+Release(Tag)-time "git bundle" generation and distribution by either HTTP or Bittorrent.
+</li></ul>
+
+
+
 {% endblock %}

i2p2www/pages/site/index.html

@@ -14,10 +14,11 @@
   <div class="aside">
     <h1>{% trans %}What is I2P?{% endtrans %}</h1>
     <ul>
-      <li>{% 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 %}</li>
+      <li>{% trans %}
+        The Invisible Internet Project (I2P) is a fully encrypted private network layer.
+        It protects your activity and location. Every day people use the network to connect
+        with people without worry of being tracked or their data being collected. In some
+        cases people rely on the network when they need to be discrete or are doing sensitive work.{%- endtrans %}</li>
     </ul>
     <h1>{% trans %}I2P Cares About Privacy{% endtrans %}</h1>
     <ul>
@@ -28,15 +29,15 @@
     </ul>
   </div>
   <div class="aside">
-    <h1>Peer-to-Peer</h1>
-    <p>Everyday, people use the I2P network to connect with other people without the worry of being tracked or their data being collected. In some cases people rely on the network when they cannot safely communicate or while doing sensitive work. The network is P2P - people powered, and always growing. <a href="https://geti2p.net/en/docs/protocol">Learn more about the Protocol Stack</a>.</p>
+    <h1>{% trans %}Peer-to-Peer{% endtrans %}</h1>
+    <p>{% trans %}The network is people powered . Peers make a portion of their resources, particularly bandwidth, available to other network participants. This allows the network to function without relying on centralized servers.{% endtrans %} <a href="{{ site_url('docs/protocol') }}">{% trans %}Learn more about the Protocol Stack{% endtrans %}</a>.</p>
 
-    <h1>Privacy and Security By Design</h1>
-    <p>I2P has created transport protocols that resist DPI censorship, and continuously improves its end to end encryption.
-    <a href="https://geti2p.net/en/docs/transport">Read the I2P Transport Overview</a></p>
+    <h1>{% trans %}Privacy and Security By Design{% endtrans %}</h1>
+    <p>{% trans %}I2P has created transport protocols that resist DPI censorship, and continuously improves its end to end encryption.{% endtrans %}
+    <a href="{{ site_url('docs/transport') }}">{% trans %}Read the I2P Transport Overview{% endtrans %}</a>.</p>
 
-    <h1>Built For Communication</h1>
-    <p>I2P has an application layer with easy to use <a href="https://geti2p.net/en/docs/api/i2ptunnel">API’s for creating your own privacy - aware apps.</a></p>
+    <h1>{% trans %}Built For Communication{% endtrans %}</h1>
+    <p>{% trans %}I2P has an application layer with easy to use {% endtrans %}<a href="{{ site_url('docs/api/i2ptunnel') }}">{% trans %}APIs for creating your own privacy - aware apps.{% endtrans %}</a></p>
   </div>
   <div class="aside">
     <a href="{{ url_for('blog_atom', lang=g.lang) }}" class="feed-icon" title="{{ _('I2P Blog ATOM Feed') }}">{{ _('I2P Blog ATOM Feed') }}</a>
@@ -44,7 +45,8 @@
       {% include "blog/latest.html" %}
   </div>
   <div id="herocredit">
-    <a href="https://pixabay.com/users/montevideo-5677795/?utm_source=link-attribution&amp;utm_medium=referral&amp;utm_campaign=image&amp;utm_content=3621630%22%3EMontevideo">Hero Image courtesy of Pixabay artist Montevideo</a>
+    <a href="https://pixabay.com/users/montevideo-5677795/?utm_source=link-attribution&amp;utm_medium=referral&amp;utm_campaign=image&amp;utm_content=3621630%22%3EMontevideo">Hero Image courtesy of Pixabay artist Montevideo</a></br>
+    <!--<a href="https://decentpatterns.xyz/report/#key-terms">*Further information about decentralized principles collated by DOTS(Decentralization Off-The-Shelf) study</a>-->
   </div>
 </div>
 

i2p2www/pages/spec/index.html

@@ -22,7 +22,7 @@ in during the course of development. Periodic reviews are conducted to update
 the "accurate for" information.
 </li></ul>
 
-<p>{% trans trac='https://trac.i2p2.de/report/1' -%}
+<p>{% trans trac='https://i2pgit.org/i2p-hackers/i2p.www/issues' -%}
 The I2P Project is committed to maintaining accurate, current documentation.
 If you find any inaccuracies in the documents linked below, please
 <a href="{{ trac }}">enter a ticket identifying the problem</a>.
@@ -61,6 +61,6 @@ These will eventually be migrated to the new specifications system.
 <li><a href="{{ site_url('docs/api/samv3') }}">SAM v3</a></li>
 <li><a href="{{ site_url('docs/api/bob') }}">BOB</a></li>
 <li><a href="{{ site_url('docs/applications/bittorrent') }}">{{ _('Bittorrent') }}</a></li>
-<li><a href="{{ site_url('docs/naming') }}">{{ _('Naming and Addressbook') }}</a></li>
+<li><a href="{{ site_url('docs/naming') }}">{{ _('Naming and Address Book') }}</a></li>
 </ul>
 {% endblock %}

i2p2www/sitemap.py

@@ -115,7 +115,15 @@ def render_sitemap():
     urls.append({
         'path': '/download/lab',
         })
-
+    urls.append({
+        'path': '/download/mac',
+        })
+    urls.append({
+        'path': '/download/easyinstall',
+        })
+    urls.append({
+        'path': '/download/windows',
+        })
     # Render and return the sitemap
     response = make_response(render_template('global/sitemap.xml', url_root=url_root, langs=LANG_FRAGS,
                                              curlang=to_url(g.lang), urls=urls))

i2p2www/spec/common-structures.rst

@@ -3,8 +3,8 @@ Common structures Specification
 ===============================
 .. meta::
     :category: Design
-    :lastupdated: 2020-09
-    :accuratefor: 0.9.47
+    :lastupdated: 2021-04
+    :accuratefor: 0.9.49
 
 .. contents::
 
@@ -79,6 +79,11 @@ The default type is ElGamal.  As of release
 0.9.38, other types may be supported, depending on context.
 Keys are big-endian unless otherwise noted.
 
+X25519 keys are supported in Destinations and LeaseSet2 as of release 0.9.44.
+X25519 keys are supported in RouterIdentities as of release 0.9.48.
+
+
+
 =======  ==============  ======  =====
  Type    Length (bytes)  Since   Usage
 =======  ==============  ======  =====
@@ -86,7 +91,7 @@ ElGamal       256                All Router Identities and Destinations
 P256           64         TBD    Reserved, see proposal 145
 P384           96         TBD    Reserved, see proposal 145
 P521          132         TBD    Reserved, see proposal 145
-X25519         32        0.9.38  Little-endian. See [ECIES]_ and proposal 156
+X25519         32        0.9.38  Little-endian. See [ECIES]_ and [ECIES-ROUTERS]_
 =======  ==============  ======  =====
 
 JavaDoc: http://{{ i2pconv('echelon.i2p/javadoc') }}/net/i2p/data/PublicKey.html
@@ -105,8 +110,8 @@ Other encryption schemes are in the process of being defined, see the table belo
 
 Contents
 ````````
-Key type and length are inferred from context or are specified in the Key
-Certificate of a Destination or RouterInfo, or the fields in a LeaseSet2_ or other data structure.
+Key type and length are inferred from context or are stored separately
+in a data structure or a private key file.
 The default type is ElGamal.  As of release
 0.9.38, other types may be supported, depending on context.
 Keys are big-endian unless otherwise noted.
@@ -118,7 +123,7 @@ ElGamal       256                All Router Identities and Destinations
 P256           32         TBD    Reserved, see proposal 145
 P384           48         TBD    Reserved, see proposal 145
 P521           66         TBD    Reserved, see proposal 145
-X25519         32        0.9.38  Little-endian. See [ECIES]_ and proposal 156
+X25519         32        0.9.38  Little-endian. See [ECIES]_ and [ECIES-ROUTERS]_
 =======  ==============  ======  =====
 
 JavaDoc: http://{{ i2pconv('echelon.i2p/javadoc') }}/net/i2p/data/PrivateKey.html
@@ -280,6 +285,9 @@ JavaDoc: http://{{ i2pconv('echelon.i2p/javadoc') }}/net/i2p/data/Hash.html
 Session Tag
 -----------
 
+Note: Session Tags for ECIES-X25519 destinations (ratchet) and ECIES-X25519 routers
+are 8 bytes. See [ECIES]_ and [ECIES-ROUTERS]_.
+
 Description
 ```````````
 A random number
@@ -668,6 +676,10 @@ Notes
 * The Crypto Public Key is aligned at the start and the Signing Public Key is
   aligned at the end. The padding (if any) is in the middle.
 
+* RouterIdentities with a key certificate and a ECIES_X25519 public key
+  are supported as of release 0.9.48.
+  Prior to that, all RouterIdentities were ElGamal.
+
 JavaDoc: http://{{ i2pconv('echelon.i2p/javadoc') }}/net/i2p/data/router/RouterIdentity.html
 
 .. _struct-Destination:
@@ -867,6 +879,10 @@ Notes
 * The signature may be verified using the signing public key of the
   destination.
 
+* A LeaseSet with zero Leases is allowed but is unused.
+  It was intended for LeaseSet revocation, which is unimplemented.
+  All LeaseSet2 variants require at least one Lease.
+
 * The signing_key is currently unused. It was intended for LeaseSet revocation,
   which is unimplemented. It is currently generated anew at every router
   startup, it is not persistent. The signing key type is always the same as the
@@ -1068,8 +1084,8 @@ Notes
 `````
 * Total size: 395 bytes minimum
 
-* Maximum actual expires time is TBD, will be about 11 minutes for
-  LeaseSet2_ and the full 18.2 hours for MetaLeaseSet_.
+* Maximum actual expires time is about 660 (11 minutes) for
+  LeaseSet2_ and 65535 (the full 18.2 hours) for MetaLeaseSet_.
 
 
 
@@ -1084,9 +1100,8 @@ Contained in a I2NP DatabaseStore message of type 3.
 Supported as of 0.9.38; see proposal 123 for more information.
 
 Contains all of the currently authorized Lease2_ for a particular Destination_,
-the PublicKey_ to which garlic messages can be encrypted, and then the
-SigningPublicKey_ that can be used to revoke this particular version of the
-structure. The LeaseSet is one of the two structures stored in the network
+and the PublicKey_ to which garlic messages can be encrypted.
+A LeaseSet is one of the two structures stored in the network
 database (the other being RouterInfo_), and is keyed under the SHA256 of the
 contained Destination_.
 
@@ -1285,9 +1300,8 @@ Defined as of 0.9.38; scheduled to be working as of 0.9.40;
 see proposal 123 for more information.
 
 Contains all of the currently authorized MetaLease_ for a particular Destination_,
-the PublicKey_ to which garlic messages can be encrypted, and then the
-SigningPublicKey_ that can be used to revoke this particular version of the
-structure. The LeaseSet is one of the two structures stored in the network
+and the PublicKey_ to which garlic messages can be encrypted.
+A LeaseSet is one of the two structures stored in the network
 database (the other being RouterInfo_), and is keyed under the SHA256 of the
 contained Destination_.
 
@@ -1504,7 +1518,7 @@ Notes
 
 * This structure does not use the LeaseSet2Header_.
 
-* Maximum actual expires time is about 11 minutes, unless
+* Maximum actual expires time is about 660 (11 minutes), unless
   it is an encrypted MetaLeaseSet_.
 
 * See proposal 123 for notes on using offline signatures
@@ -1714,6 +1728,9 @@ References
 .. [ECIES]
    {{ spec_url('ecies') }}
 
+.. [ECIES-ROUTERS]
+   {{ spec_url('ecies-routers') }}
+
 .. [ELGAMAL]
     {{ site_url('docs/how/cryptography', True) }}#elgamal
 

i2p2www/spec/ecies-routers.rst

@@ -0,0 +1,370 @@
+=============================
+ECIES-X25519 Router Messages
+=============================
+
+.. meta::
+    :category: Protocols
+    :lastupdated: 2021-01
+    :accuratefor: 0.9.49
+
+.. contents::
+
+
+Note
+====
+Supported as of release 0.9.49.
+Network deployment and testing in progress.
+Subject to minor revision.
+See proposal 156 [Prop156]_.
+
+
+Overview
+========
+
+This document specifies Garlic message encryption to ECIES routers,
+using crypto primitives introduced by [ECIES-X25519]_.
+It is a portion of the overall proposal
+[Prop156]_ for converting routers from ElGamal to ECIES-X25519 keys.
+This specification is implemented as of release 0.9.49.
+
+For an overview of all changes required for ECIES routers, see proposal 156 [Prop156]_.
+For Garlic Messages to ECIES-X25519 destinations, see [ECIES-X25519]_.
+
+
+Cryptographic Primitives
+------------------------
+
+The primitives required to implement this specification are:
+
+- AES-256-CBC as in [Cryptography]_
+- STREAM ChaCha20/Poly1305 functions:
+  ENCRYPT(k, n, plaintext, ad) and DECRYPT(k, n, ciphertext, ad) - as in [NTCP2]_ [ECIES-X25519]_ and [RFC-7539]_
+- X25519 DH functions - as in [NTCP2]_ and [ECIES-X25519]_
+- HKDF(salt, ikm, info, n) - as in [NTCP2]_ and [ECIES-X25519]_
+
+Other Noise functions defined elsewhere:
+
+- MixHash(d) - as in [NTCP2]_ and [ECIES-X25519]_
+- MixKey(d) - as in [NTCP2]_ and [ECIES-X25519]_
+
+
+
+Design
+======
+
+The ECIES Router SKM does not need a full Ratchet SKM as specified in [ECIES]_ for Destinations.
+There is no requirement for non-anonymous messages using the IK pattern.
+The threat model does not require Elligator2-encoded ephemeral keys.
+
+Therefore, the router SKM will use the Noise "N" pattern, same as specified
+in [Prop152]_ for tunnel building.
+It will use the same payload format as specified in [ECIES]_ for Destinations.
+The zero static key (no binding or session) mode of IK specified in [ECIES]_ will not be used.
+
+Replies to lookups will be encrypted with a ratchet tag if requested in the lookup.
+This is as documented in [Prop154]_,  now specified in [I2NP]_.
+
+The design enables the router to have a single ECIES Session Key Manager.
+There is no need to run "dual key" Session Key Managers as
+described in [ECIES]_ for Destinations.
+Routers only have one public key.
+
+An ECIES router does not have an ElGamal static key.
+The router still needs an implementation of ElGamal to build tunnels
+through ElGamal routers and send encrypted messages to ElGamal routers.
+
+An ECIES router MAY require a partial ElGamal Session Key Manager to
+receive ElGamal-tagged messages received as replies to NetDB lookups
+from pre-0.9.46 floodfill routers, as those routers do not
+have an implementation of ECIES-tagged replies as specified in [Prop152]_.
+If not, an ECIES router may not request an encrypted reply from a
+pre-0.9.46 floodfill router.
+
+This is optional. Decision may vary in various I2P implementations
+and may depend on the amount of the network that has upgraded to
+0.9.46 or higher.
+As of this date, approximately 85% of the network is 0.9.46 or higher.
+
+
+Noise Protocol Framework
+------------------------
+
+This specification provides the requirements based on the Noise Protocol Framework
+[NOISE]_ (Revision 34, 2018-07-11).
+In Noise parlance, Alice is the initiator, and Bob is the responder.
+
+It is based on the Noise protocol Noise_N_25519_ChaChaPoly_SHA256.
+This Noise protocol uses the following primitives:
+
+- One-Way Handshake Pattern: N
+  Alice does not transmit her static key to Bob (N)
+
+- DH Function: X25519
+  X25519 DH with a key length of 32 bytes as specified in [RFC-7748]_.
+
+- Cipher Function: ChaChaPoly
+  AEAD_CHACHA20_POLY1305 as specified in [RFC-7539]_ section 2.8.
+  12 byte nonce, with the first 4 bytes set to zero.
+  Identical to that in [NTCP2]_.
+
+- Hash Function: SHA256
+  Standard 32-byte hash, already used extensively in I2P.
+
+
+Handshake Patterns
+------------------
+
+Handshakes use [Noise]_ handshake patterns.
+
+The following letter mapping is used:
+
+- e = one-time ephemeral key
+- s = static key
+- p = message payload
+
+The build request is identical to the Noise N pattern.
+This is also identical to the first (Session Request) message in the XK pattern used in [NTCP2]_.
+
+
+.. raw:: html
+
+  {% highlight lang='dataspec' %}
+<- s
+  ...
+  e es p ->
+
+{% endhighlight %}
+
+
+Message encryption
+-----------------------
+
+Messages are created and asymmetrically encrypted to the target router.
+This asymmetric encryption of messages is currently ElGamal as defined in [Cryptography]_
+and contains a SHA-256 checksum. This design is not forward-secret.
+
+The ECIES design uses the one-way Noise pattern "N" with ECIES-X25519 ephemeral-static DH, with an HKDF, and
+ChaCha20/Poly1305 AEAD for forward secrecy, integrity, and authentication.
+Alice is the anonymous message sender, a router or destination.
+The target ECIES router is Bob.
+
+
+
+Reply encryption
+-----------------------
+
+Replies are not part of this protocol, as Alice is anonymous. The reply keys, if any,
+are bundled in the request message. See the I2NP specification [I2NP]_ for Database Lookup Messages.
+
+Replies to Database Lookup messages are Database Store or Database Search Reply messages.
+They are encrypted as Existing Session messages with
+the 32-byte reply key and 8-byte reply tag
+as specified in [I2NP]_ and [Prop154]_.
+
+There are no explicit replies to Database Store messages. The sender may bundle its
+own reply as a Garlic Message to itself, containing a Delivery Status message.
+
+
+
+Specification
+=========================
+
+X25519: See [ECIES]_.
+
+Router Identity and Key Certificate: See [Common]_.
+
+
+Request Encryption
+---------------------
+
+The request encryption is the same as that specified in [Tunnel-Creation-ECIES]_ and [Prop152]_,
+using the Noise "N" pattern.
+
+Replies to lookups will be encrypted with a ratchet tag if requested in the lookup.
+Database Lookup request messages contain the 32-byte reply key and 8-byte reply tag
+as specified in [I2NP]_ and [Prop154]_. The key and tag are used to encrypt the reply.
+
+Tag sets are not created.
+The zero static key scheme specified in
+ECIES-X25519-AEAD-Ratchet [Prop144]_ and [ECIES]_ will not be used.
+Ephemeral keys will not be Elligator2-encoded.
+
+Generally, these will be New Session messages and will be sent with a zero static key
+(no binding or session), as the sender of the message is anonymous.
+
+
+KDF for Initial ck and h
+````````````````````````
+
+This is standard [NOISE]_ for pattern "N" with a standard protocol name.
+This is the same as specified in [Tunnel-Creation-ECIES]_ and [Prop152]_ for tunnel build messages.
+
+
+.. raw:: html
+
+  {% highlight lang='text' %}
+This is the "e" message pattern:
+
+  // Define protocol_name.
+  Set protocol_name = "Noise_N_25519_ChaChaPoly_SHA256"
+  (31 bytes, US-ASCII encoded, no NULL termination).
+
+  // Define Hash h = 32 bytes
+  // Pad to 32 bytes. Do NOT hash it, because it is not more than 32 bytes.
+  h = protocol_name || 0
+
+  Define ck = 32 byte chaining key. Copy the h data to ck.
+  Set chainKey = h
+
+  // MixHash(null prologue)
+  h = SHA256(h);
+
+  // up until here, can all be precalculated by all routers.
+
+{% endhighlight %}
+
+
+KDF for Message
+````````````````````````
+
+Message creators generate an ephemeral X25519 keypair for each message.
+Ephemeral keys must be unique per message.
+This is the same as specified in [Tunnel-Creation-ECIES]_ and [Prop152]_ for tunnel build messages.
+
+
+.. raw:: html
+
+  {% highlight lang='dataspec' %}
+
+// Target router's X25519 static keypair (hesk, hepk) from the Router Identity
+  hesk = GENERATE_PRIVATE()
+  hepk = DERIVE_PUBLIC(hesk)
+
+  // MixHash(hepk)
+  // || below means append
+  h = SHA256(h || hepk);
+
+  // up until here, can all be precalculated by each router
+  // for all incoming messages
+
+  // Sender generates an X25519 ephemeral keypair
+  sesk = GENERATE_PRIVATE()
+  sepk = DERIVE_PUBLIC(sesk)
+
+  // MixHash(sepk)
+  h = SHA256(h || sepk);
+
+  End of "e" message pattern.
+
+  This is the "es" message pattern:
+
+  // Noise es
+  // Sender performs an X25519 DH with receiver's static public key.
+  // The target router
+  // extracts the sender's ephemeral key preceding the encrypted record.
+  sharedSecret = DH(sesk, hepk) = DH(hesk, sepk)
+
+  // MixKey(DH())
+  //[chainKey, k] = MixKey(sharedSecret)
+  // ChaChaPoly parameters to encrypt/decrypt
+  keydata = HKDF(chainKey, sharedSecret, "", 64)
+  // Chain key is not used
+  //chainKey = keydata[0:31]
+
+  // AEAD parameters
+  k = keydata[32:64]
+  n = 0
+  plaintext = 464 byte build request record
+  ad = h
+  ciphertext = ENCRYPT(k, n, plaintext, ad)
+
+  End of "es" message pattern.
+
+  // MixHash(ciphertext) is not required
+  //h = SHA256(h || ciphertext)
+
+{% endhighlight %}
+
+
+
+Payload
+````````````````````````
+
+The payload is the same block format as defined in [ECIES]_ and [Prop144]_.
+All messages must contain a DateTime block for replay prevention.
+
+
+
+
+Implementation Notes
+=====================
+
+* Older routers do not check the encryption type of the router and will send ElGamal-encrypted
+  messages. Some recent routers are buggy and will send various types of malformed messages.
+  Implementers should detect and reject these records prior to the DH operation
+  if possible, to reduce CPU usage.
+
+
+
+References
+==========
+
+.. [Common]
+    {{ spec_url('common-structures') }}
+
+.. [Cryptography]
+   {{ spec_url('cryptography') }}
+
+.. [ECIES]
+   {{ spec_url('ecies') }}
+
+.. [ECIES-X25519]
+   {{ spec_url('ecies') }}
+
+.. [I2NP]
+   {{ spec_url('i2np') }}
+
+.. [NOISE]
+    https://noiseprotocol.org/noise.html
+
+.. [NTCP2]
+   {{ spec_url('ntcp2') }}
+
+.. [Prop119]
+   {{ proposal_url('119') }}
+
+.. [Prop143]
+   {{ proposal_url('143') }}
+
+.. [Prop144]
+    {{ proposal_url('144') }}
+
+.. [Prop152]
+    {{ proposal_url('152') }}
+
+.. [Prop153]
+    {{ proposal_url('153') }}
+
+.. [Prop154]
+    {{ proposal_url('154') }}
+
+.. [Prop156]
+    {{ proposal_url('156') }}
+
+.. [Prop157]
+    {{ proposal_url('157') }}
+
+.. [RFC-7539]
+   https://tools.ietf.org/html/rfc7539
+
+.. [RFC-7748]
+   https://tools.ietf.org/html/rfc7748
+
+.. [Tunnel-Creation]
+   {{ spec_url('tunnel-creation') }}
+
+.. [Tunnel-Creation-ECIES]
+   {{ spec_url('tunnel-creation-ecies') }}
+
+
+

i2p2www/spec/i2np.rst

@@ -3,8 +3,8 @@ I2NP Specification
 ==================
 .. meta::
     :category: Protocols
-    :lastupdated: 2020-11
-    :accuratefor: 0.9.48
+    :lastupdated: 2021-07
+    :accuratefor: 0.9.51
 
 .. contents::
 
@@ -12,11 +12,12 @@ I2NP Specification
 Overview
 ========
 
-The I2P Network Protocol (I2NP), which is sandwiched between I2CP and the
-various I2P transport protocols, manages the routing and mixing of messages
-between routers, as well as the selection of what transports to use when
-communicating with a peer for which there are multiple common transports
-supported.
+The I2P Network Protocol (I2NP) is the layer above the
+I2P transport protocols. It is a router-to-router protocol.
+It is used for network database lookups and replies, for creating
+tunnels, and for encrypted router and client data messages.
+I2NP messages may be sent point-to-point to another router,
+or sent anonymously through tunnels to that router.
 
 
 .. _versions:
@@ -25,7 +26,8 @@ Protocol Versions
 =================
 
 All routers must publish their I2NP protocol version in the "router.version"
-field in the RouterInfo properties.  This version field indicates their level
+field in the RouterInfo properties.
+This version field is the API version, indiciating the level
 of support for various I2NP protocol features, and is not necessarily the
 actual router version.
 
@@ -33,20 +35,27 @@ If alternative (non-Java) routers wish to publish any version information about
 the actual router implementation, they must do so in another property.
 Versions other than those listed below are allowed. Support will be determined
 through a numeric comparison; for example, 0.9.13 implies support for 0.9.12
-features.  Note that the "coreVersion" property is not used for determination
+features.  Note that the "coreVersion" property is no longer published
+in the router info, and was never used for determination
 of the I2NP protocol version.
 
 A basic summary of the I2NP protocol versions is as follows. For details, see
 below.
 
 ==============  ================================================================
-   Version      Required I2NP Features
+ API Version    Required I2NP Features
 ==============  ================================================================
-   0.9.48       ECIES-X25519 Build Request/Response records
+   0.9.51       Short tunnel build messages for ECIES-X25519 routers
+
+   0.9.49       Garlic messages to ECIES-X25519 routers
+
+   0.9.48       ECIES-X25519 Routers
+
+                ECIES-X25519 Build Request/Response records
 
    0.9.46       DatabaseLookup flag bit 4 for AEAD reply
 
-   0.9.44       X25519 keys in LeaseSet2
+   0.9.44       ECIES-X25519 keys in LeaseSet2
 
    0.9.40       MetaLeaseSet may be sent in a DSM
 
@@ -229,7 +238,7 @@ One Record in a set of multiple records to request the creation of one hop in
 the tunnel. For more details see the tunnel overview [TUNNEL-IMPL]_ and the
 ElGamal tunnel creation specification [TUNNEL-CREATION]_.
 
-For ECIES-X25519 BuildRequestRecords, see [TUNNEL-CREATION-ECIES].
+For ECIES-X25519 BuildRequestRecords, see [TUNNEL-CREATION-ECIES]_.
 
 
 Contents (ElGamal)
@@ -406,7 +415,7 @@ One Record in a set of multiple records with responses to a build request.
 For more details see the tunnel overview [TUNNEL-IMPL]_ and the
 ElGamal tunnel creation specification [TUNNEL-CREATION]_.
 
-For ECIES-X25519 BuildResponseRecords, see [TUNNEL-CREATION-ECIES].
+For ECIES-X25519 BuildResponseRecords, see [TUNNEL-CREATION-ECIES]_.
 
 
 Contents (ElGamal)
@@ -452,6 +461,29 @@ Notes
 * See the tunnel creation specification [TUNNEL-CREATION]_ for details on the
   reply field.
 
+
+
+.. _struct-ShortBuildRequestRecord:
+
+ShortBuildRequestRecord
+-----------------------
+
+For ECIES-X25519 routers only, as of API version 0.9.51.
+218 bytes when encrypted.
+See [TUNNEL-CREATION-ECIES]_.
+
+
+.. _struct-ShortBuildResponseRecord:
+
+ShortBuildResponseRecord
+------------------------
+
+For ECIES-X25519 routers only, as of API version 0.9.51.
+218 bytes when encrypted.
+See [TUNNEL-CREATION-ECIES]_.
+
+
+
 .. _struct-GarlicClove:
 .. _Garlic Cloves:
 
@@ -576,7 +608,7 @@ Delivery Instructions!
   Tunnel ID :: `TunnelId`
          4 bytes
          Optional, present if delivery type is TUNNEL
-         The destination tunnel ID
+         The destination tunnel ID, nonzero
 
   Delay :: `Integer`
          4 bytes
@@ -593,9 +625,9 @@ Delivery Instructions!
 Messages
 ========
 
-==================================  =======
-             Message                 Type
-==================================  =======
+==================================  =======  =======
+             Message                 Type     Since
+==================================  =======  =======
 DatabaseStore_                         1
 DatabaseLookup_                        2
 DatabaseSearchReply_                   3
@@ -606,12 +638,14 @@ TunnelGateway_                         19
 Data_                                  20
 TunnelBuild_                           21
 TunnelBuildReply_                      22
-VariableTunnelBuild_                   23
-VariableTunnelBuildReply_              24
+VariableTunnelBuild_                   23     0.7.12
+VariableTunnelBuildReply_              24     0.7.12
+ShortTunnelBuild_                      25     0.9.51
+OutboundTunnelBuildReply_              26     0.9.51
 Reserved                               0
 Reserved for experimental messages  224-254
 Reserved for future expansion         255
-==================================  =======
+==================================  =======  =======
 
 .. _msg-DatabaseStore:
 
@@ -862,7 +896,7 @@ Contents
   reply_tunnelId ::
                  4 byte `TunnelID`
                  only included if deliveryFlag == 1
-                 tunnelId of the tunnel to send the reply to
+                 tunnelId of the tunnel to send the reply to, nonzero
 
   size ::
        2 byte `Integer`
@@ -898,14 +932,21 @@ Reply Encryption
 
 Flag bit 4 is used in combination with bit 1 to determine the reply encryption mode.
 Flag bit 4 must only be set when sending to routers with version 0.9.46 or higher.
-See proposal 154 for details.
+See proposals 154 and 156 for details.
+
+In the table below,
+"DH n/a" means that the reply is not encrypted.
+"DH no" means that the reply keys are included in the request.
+"DH yes" means that the reply keys are derived from the DH operation.
 
 =============  =========  =========  ======  ===  =======
-Flag bits 4,1  From Dest  To Router  Reply   DH?  notes
+Flag bits 4,1  From       To Router  Reply   DH?  notes
 =============  =========  =========  ======  ===  =======
-0 0            Any        Any        no enc  no   
+0 0            Any        Any        no enc  n/a  no encryption
 0 1            ElG        ElG        AES     no   As of 0.9.7
 1 0            ECIES      ElG        AEAD    no   As of 0.9.46
+1 0            ECIES      ECIES      AEAD    no   As of 0.9.49
+1 1            ElG        ECIES      AES     yes  TBD
 1 1            ECIES      ECIES      AEAD    yes  TBD
 =============  =========  =========  ======  ===  =======
 
@@ -1043,12 +1084,24 @@ tag :: 8 byte reply_tag
 {% endhighlight %}
 
 
-ECIES to ECIES
-``````````````
+ECIES to ECIES (0.9.49)
+-----------------------------
+
+ECIES destination or router sends a lookup to a ECIES router.
+Supported as of 0.9.49.
+
+ECIES routers were introduced in 0.9.48, see [Prop156]_.
+ECIES destinations and routers may use the same format as in
+the "ECIES to ElG" section above, with reply keys included in the request.
+The lookup message encryption is specified in [ECIES-ROUTERS]_.
+The requester is anonymous.
+
+
+ECIES to ECIES (future)
+-----------------------------
+
 This option is not yet fully defined.
-ECIES routers do not yet exist and there is no documented proposal
-for ECIES routers at this time.
-See proposal 154.
+See [Prop156]_.
 
 
 Notes
@@ -1313,6 +1366,7 @@ Contents
   tunnelId ::
            4 byte `TunnelId`
            identifies the tunnel this message is directed at
+           nonzero
 
   data ::
        1024 bytes
@@ -1347,6 +1401,7 @@ Contents
   tunnelId ::
            4 byte `TunnelId`
            identifies the tunnel this message is directed at
+           nonzero
 
   length ::
          2 byte `Integer`
@@ -1529,6 +1584,74 @@ Notes
 * Typical number of records in today's network is 4, for a total size of 2113.
 
 
+
+
+.. _msg-ShortTunnelBuild:
+
+ShortTunnelBuild
+-------------------
+
+Description
+```````````
+As of API version 0.9.51, for ECIES-X25519 routers only.
+
+
+.. raw:: html
+
+  {% highlight lang='dataspec' %}
++----+----+----+----+----+----+----+----+
+  | num| ShortBuildRequestRecords...
+  +----+----+----+----+----+----+----+----+
+
+  Same format as `VariableTunnelBuildMessage`,
+  except that the record size is 218 bytes instead of 528
+
+  num ::
+         1 byte `Integer`
+         Valid values: 1-8
+
+  record size: 218 bytes
+  total size: 1+$num*218
+{% endhighlight %}
+
+Notes
+`````
+* As of 0.9.51. See [TUNNEL-CREATION-ECIES]_.
+
+* This message was introduced in router version 0.9.51, and may not be sent to
+  tunnel participants earlier than that version.
+
+* Typical number of records in today's network is 4, for a total size of 873.
+
+
+
+.. _msg-OutboundTunnelBuildReply:
+
+OutboundTunnelBuildReply
+------------------------
+
+Description
+```````````
+Sent from the outbound gateway of a new tunnel to the originator.
+As of API version 0.9.51, for ECIES-X25519 routers only.
+
+.. raw:: html
+
+  {% highlight lang='dataspec' %}
++----+----+----+----+----+----+----+----+
+  | num| ShortBuildResponseRecords...
+  +----+----+----+----+----+----+----+----+
+
+  Same format as `ShortTunnelBuildMessage`, with `ShortBuildResponseRecord`s.
+{% endhighlight %}
+
+Notes
+`````
+* As of 0.9.51. See [TUNNEL-CREATION-ECIES]_.
+
+* Typical number of records in today's network is 4, for a total size of 873.
+
+
 References
 ==========
 
@@ -1541,6 +1664,9 @@ References
 .. [ECIES]
    {{ spec_url('ecies') }}
 
+.. [ECIES-ROUTERS]
+   {{ spec_url('ecies-routers') }}
+
 .. [ElG-AES]
     {{ site_url('docs/how/elgamal-aes', True) }}
 
@@ -1559,6 +1685,12 @@ References
 .. [NTCP2]
     {{ spec_url('ntcp2') }}
 
+.. [Prop156]
+    {{ proposal_url('156') }}
+
+.. [Prop157]
+    {{ proposal_url('157') }}
+
 .. [RouterIdentity]
     {{ ctags_url('RouterIdentity') }}
 

i2p2www/spec/ntcp2.rst

@@ -3,8 +3,8 @@ NTCP 2
 ======
 .. meta::
     :category: Transports
-    :lastupdated: August 2019
-    :accuratefor: 0.9.42
+    :lastupdated: 2021-03
+    :accuratefor: 0.9.50
 
 .. contents::
 
@@ -1790,6 +1790,24 @@ symmetric crypto keys, and related information.
 Published Router Info
 =====================
 
+Capabilities
+------------
+
+As of release 0.9.50, the "caps" option is supported in NTCP2 addresses,
+similar to SSU.
+One or more capabilities may be published in the "caps" option.
+Capabilities may be in any order, but "46" is the recommended order, for consistency across implementations.
+There are two capabilities defined:
+
+4: Indicates outbound IPv4 capability.
+If an IP is published in the host field, this capability is not necessary.
+If the router is hidden, or NTCP2 is outbound only, '4' and '6' may be combined in a single address.
+
+6: Indicates outbound IPv6 capability.
+If an IP is published in the host field, this capability is not necessary.
+If the router is hidden, or NTCP2 is outbound only, '4' and '6' may be combined in a single address.
+
+
 
 Published Addresses
 -------------------

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-12-09
+    :lastupdated: 2021-03-21
     :status: Closed
     :target: 0.9.48
     :implementedin: 0.9.48
@@ -455,7 +455,7 @@ bytes   0-31: SHA-256 Hash of bytes 32-527
 
 Reply Record Unencrypted (ECIES)
 `````````````````````````````````````
-This is the proposed specification of the tunnel BuildRequestRecord for ECIES-X25519 routers.
+This is the proposed specification of the tunnel BuildReplyRecord for ECIES-X25519 routers.
 Summary of changes:
 
 - Add Mapping for build reply options

i2p2www/spec/proposals/154-ecies-lookups.rst

@@ -5,7 +5,7 @@ Database Lookups from ECIES Destinations
     :author: zzz
     :created: 2020-03-23
     :thread: http://zzz.i2p/topics/2856
-    :lastupdated: 2020-05-07
+    :lastupdated: 2021-01-08
     :status: Closed
     :target: 0.9.46
     :implementedin: 0.9.46
@@ -15,11 +15,11 @@ Database Lookups from ECIES Destinations
 
 Note
 ====
-ECIES to ElG is implemented and the proposal phase is closed.
+ECIES to ElG is implemented in 0.9.46 and the proposal phase is closed.
 See [I2NP]_ for the official specification.
 This proposal may still be referenced for background information.
-ECIES to ECIES is not fully specified or implemented at this time.
-The ECIES-to-ECIES section may be reopened or incorporated
+ECIES to ECIES with included keys is implemented as of 0.9.48.
+The ECIES-to-ECIES (derived keys) section may be reopened or incorporated
 in a future proposal.
 
 
@@ -146,14 +146,21 @@ Flag bit 4 is used in combination with bit 1 to determine the reply encryption m
 Flag bit 4 must only be set when sending to routers with version 0.9.46 or higher.
 
 
+In the table below,
+"DH n/a" means that the reply is not encrypted.
+"DH no" means that the reply keys are included in the request.
+"DH yes" means that the reply keys are derived from the DH operation.
+
+
 =============  =========  =========  ======  ===  =======
 Flag bits 4,1  From Dest  To Router  Reply   DH?  notes
 =============  =========  =========  ======  ===  =======
-0 0            Any        Any        no enc  no   current
+0 0            Any        Any        no enc  n/a  current
 0 1            ElG        ElG        AES     no   current
 0 1            ECIES      ElG        AES     no   i2pd workaround
-1 0            ECIES      ElG        AEAD    no   new, no DH
-1 1            ECIES      ECIES      AEAD    yes  future, with DH
+1 0            ECIES      ElG        AEAD    no   this proposal
+1 0            ECIES      ECIES      AEAD    no   0.9.49
+1 1            ECIES      ECIES      AEAD    yes  future
 =============  =========  =========  ======  ===  =======
 
 
@@ -262,11 +269,28 @@ tag :: 8 byte reply_tag
 
 
 
-ECIES to ECIES
---------------
+ECIES to ECIES (0.9.49)
+-----------------------------
 
-ECIES destination sends a lookup to a ECIES router.
-Supported as of 0.9.TBD.
+ECIES destination or router sends a lookup to a ECIES router, with bundled reply keys.
+Supported as of 0.9.49.
+
+ECIES routers were introduced in 0.9.48, see [Prop156]_.
+As of 0.9.49, ECIES destinations and routers may use the same format as in
+the "ECIES to ElG" section above, with reply keys included in the request.
+The lookup will use the "one time format" in [ECIES]_
+as the requester is anonymous.
+
+For a new method with derived keys, see the next section.
+
+
+
+
+ECIES to ECIES (future)
+-----------------------------
+
+ECIES destination or router sends a lookup to a ECIES router, and the reply keys are derived from the DH.
+Not fully defined or supported, implementation is TBD.
 
 The lookup will use the "one time format" in [ECIES]_
 as the requester is anonymous.
@@ -275,8 +299,6 @@ Redefine reply_key field as follows. There are no associated tags.
 The tags will be generated in the KDF below.
 
 This section is incomplete and requires further study.
-ECIES routers do not yet exist and there is no documented proposal
-for ECIES routers at this time.
 
 
 .. raw:: html
@@ -428,3 +450,5 @@ References
 .. [I2NP]
     {{ spec_url('i2np') }}
 
+.. [Prop156]
+    {{ proposal_url('156') }}

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

@@ -5,13 +5,26 @@ ECIES Routers
     :author: zzz, orignal
     :created: 2020-09-01
     :thread: http://zzz.i2p/topics/2950
-    :lastupdated: 2020-12-09
+    :lastupdated: 2021-07-31
     :status: Open
     :target: 0.9.51
 
 .. contents::
 
 
+Note
+====
+Network deployment and testing in progress.
+Subject to revision.
+Status:
+
+- ECIES Routers implemented as of 0.9.48, see [Common]_.
+- Tunnel building implemented as of 0.9.48, see [Tunnel-Creation-ECIES]_.
+- Encrypted messages to ECIES routers implemented as of 0.9.49, see [ECIES-ROUTERS]_.
+- New tunnel build messages implemented as of 0.9.51.
+
+
+
 
 Overview
 ========
@@ -469,17 +482,14 @@ 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.
 
-Preliminary support: 0.9.49, early 2021.
-ECIES routers will not automatically become floodfill; must be manually configured.
-
-Target release: 0.9.50, mid-2021
+Target release: 0.9.49, early 2021.
 ECIES routers may automatically become floodfill.
 
 
 Rekeying and New Installs
 ---------------------------
 
-New installs will default to ECIES at some point.
+New installs will default to ECIES as of release 0.9.49.
 
 Gradually rekey all routers to minimize risk and disruption to the network.
 Use existing code that did the rekeying for sig type migration years ago.
@@ -491,12 +501,15 @@ perhaps 50%, can build tunnels through ECIES routers (0.9.48 or higher).
 
 Before aggressively rekeying the entire network, the vast majority
 (perhaps 90% or more) must be able to build tunnels through ECIES routers (0.9.48 or higher)
-AND send messages to ECIES floodfills.
+AND send messages to ECIES floodfills (0.9.49 or higher).
+This target will probably be reached for the 0.9.52 release.
 
 Rekeying will take several releases.
 
-Target release: 0.9.50 or 0.9.51 to start rekeying;
-0.9.50 or 0.9.51 for new routers to default to ECIES;
+Target release:
+0.9.49 for new routers to default to ECIES;
+0.9.49 to slowly start rekeying;
+0.9.50 - 0.9.52 to repeatedly increase the rekeying rate;
 late 2021 for the majority of the network to be rekeyed.
 
 
@@ -504,8 +517,8 @@ New Tunnel Build Message (Phase 2)
 ------------------------------------
 
 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.
+Roll the support out in release 0.9.51.
+Do additional testing, then enable in release 0.9.52.
 
 Testing will be difficult.
 Before this can be widely tested, a good subset of the network must support it.
@@ -513,9 +526,7 @@ Before it is broadly useful, a majority of the network must support it.
 If specification or implementation changes are required after testing,
 that would delay the rollout for an additional release.
 
-Probably mid- or late-2021.
-
-Target release: TBD; proposal 157 is incomplete.
+Target release: 0.9.52, late 2021.
 
 
 Rekeying Complete
@@ -524,8 +535,7 @@ Rekeying Complete
 At this point, routers older than some version TBD will
 not be able to build tunnels through most peers.
 
-Target release: TBD
-Probably early-mid 2022.
+Target release: 0.9.53, early 2022.
 
 
 
@@ -538,6 +548,9 @@ References
 .. [ECIES]
    {{ spec_url('ecies') }}
 
+.. [ECIES-ROUTERS]
+   {{ spec_url('ecies-routers') }}
+
 .. [I2NP]
     {{ spec_url('i2np') }}
 

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

@@ -5,13 +5,21 @@ Smaller Tunnel Build Messages
     :author: zzz, orignal
     :created: 2020-10-09
     :thread: http://zzz.i2p/topics/2957
-    :lastupdated: 2020-10-09
+    :lastupdated: 2021-07-31
     :status: Open
     :target: 0.9.51
 
 .. contents::
 
 
+Note
+====
+Implemented as of API version 0.9.51.
+Network deployment and testing in progress.
+Subject to minor revision.
+See [I2NP]_ and [Tunnel-Creation-ECIES]_ for the final specification.
+
+
 
 Overview
 ========
@@ -20,12 +28,12 @@ Overview
 Summary
 -------
 
-The current size of the encrypted tunnel Build Request and Response records is 528.
+The current size of the encrypted tunnel Build Request and Reply 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
+the total size is 2113 bytes. This message is fragmented into three 1KB tunnel
 messages for the reverse path.
 
-Changes to the 528-byte record format for ECIES-X25519 routers are specified in [Prop152]_.
+Changes to the 528-byte record format for ECIES-X25519 routers are specified in [Prop152]_ and [Tunnel-Creation-ECIES]_.
 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
@@ -34,7 +42,11 @@ 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.
+This proposal defines new request and reply records and new Build Request and Build Reply messages.
+
+The tunnel creator and all hops in the created tunnel must ECIES-X25519, and at least version 0.9.51.
+This proposal will not be useful until a majority of the routers in the network are ECIES-X25519.
+This is expected to happen by year-end 2021.
 
 
 Goals
@@ -43,11 +55,13 @@ Goals
 See [Prop152]_ and [Prop156]_ for additional goals.
 
 - Smaller records and messages
-- Maintain sufficient space for future options, as in [Prop152]_
+- Maintain sufficient space for future options, as in [Prop152]_ and [Tunnel-Creation-ECIES]_
 - Fit in one tunnel message for the reverse path
 - Support ECIES hops only
-- Maintain improvements implemented in [Prop152]_
+- Maintain improvements implemented in [Prop152]_ and [Tunnel-Creation-ECIES]_
 - Maximize compatibility with current network
+- Hide inbound build messages from the OBEP
+- Hide outbound build reply messages from the IBGW
 - Do not require "flag day" upgrade to entire network
 - Gradual rollout to minimize risk
 - Reuse existing cryptographic primitives
@@ -60,7 +74,8 @@ 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.
+- No speedups of crypto operations. It's assumed that ChaCha20 and AES are similar,
+  even with AESNI, at least for the small data sizes in question.
 
 
 Design
@@ -72,19 +87,18 @@ Records
 
 See appendix for calculations.
 
-Encrypted request and reply records will be 236 bytes, compared to 528 bytes now.
+Encrypted request and reply records will be 218 bytes, compared to 528 bytes now.
 
-The plaintext request records will be either 160 or 172 bytes,
+The plaintext request records will be 154 bytes,
 compared to 222 bytes for ElGamal records,
-and 464 bytes for ECIES records as defined in [Prop152]_.
+and 464 bytes for ECIES records as defined in [Prop152]_ and [Tunnel-Creation-ECIES]_.
 
-The plaintext response records will be either 160 or 172 bytes,
+The plaintext response records will be 202 bytes,
 compared to 496 bytes for ElGamal records,
-and 512 bytes for ECIES records as defined in [Prop152]_.
+and 512 bytes for ECIES records as defined in [Prop152]_ and [Tunnel-Creation-ECIES]_.
 
-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.
+The reply encryption will be ChaCha20 (NOT ChaCha20/Poly1305),
+so the plaintext records do not need to be a multiple of 16 bytes.
 
 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.
@@ -96,19 +110,127 @@ Tunnel Build Messages
 Both will be "variable" with a one-byte number of records field,
 as with the existing Variable messages.
 
-Build: Type 25
+ShortTunnelBuild: Type 25
+````````````````````````````````
 
-Reply: Type 26
+Typical length (with 4 records): 873 bytes
+
+When used for inbound tunnel builds,
+it is recommended (but not required) that this message be garlic encrypted by the originator,
+targeting the inbound gateway (delivery instructions ROUTER),
+to hide inbound build messages from the OBEP.
+The IBGW decrypts the message,
+puts the reply into the correct slot,
+and sends the ShortTunnelBuildMessage to the next hop.
+
+The record length is selected so that a garlic-encrypted STBM will fit
+in a single tunnel message. See the appendix below.
+
+
+
+OutboundTunnelBuildReply: Type 26
+``````````````````````````````````````
+
+We define a new OutboundTunnelBuildReply message.
+This is used for outbound tunnel builds only.
+The purpose is to hide outbound build reply messages from the IBGW.
+It must be garlic encrypted by the OBEP, targeting the originator
+(delivery instructions TUNNEL).
+The OBEP decrypts the tunnel build message,
+constructs a OutboundTunnelBuildReply message,
+and puts the reply into the cleartext field.
+The other records go into the other slots.
+It then garlic encrypts the message to originator with the derived symmetric keys.
+
+
+Notes
+```````
+
+By garlic encrypting the OTBRM and STBM, we also avoid any potential
+issues with compatibility at the IBGW and OBEP of the paired tunnels.
+
+
+
+
+Message Flow
+------------------
+
+.. raw:: html
+
+  {% highlight %}
+STBM: Short tunnel build message (type 25)
+  OTBRM: Outbound tunnel build reply message (type 26)
+
+  Outbound Build A-B-C
+  Reply through existing inbound D-E-F
+
+
+                  New Tunnel
+           STBM      STBM      STBM
+  Creator ------> A ------> B ------> C ---\
+                                     OBEP   \
+                                            | Garlic wrapped
+                                            | OTBRM
+                                            | (TUNNEL delivery)
+                                            | from OBEP to
+                                            | creator
+                Existing Tunnel             /
+  Creator <-------F---------E-------- D <--/
+                                     IBGW
+
+
+
+  Inbound Build D-E-F
+  Sent through existing outbound A-B-C
+
+
+                Existing Tunnel
+  Creator ------> A ------> B ------> C ---\
+                                    OBEP    \
+                                            | Garlic wrapped (optional)
+                                            | STBM
+                                            | (ROUTER delivery)
+                                            | from creator
+                  New Tunnel                | to IBGW
+            STBM      STBM      STBM        /
+  Creator <------ F <------ E <------ D <--/
+                                     IBGW
+
+
+
+{% endhighlight %}
 
-Total length: 641 or 689 bytes
 
 
 Record Encryption
 ------------------
 
-Request and reply record encryption: as defined in [Prop152]_.
+Request and reply record encryption: as defined in [Prop152]_ and [Tunnel-Creation-ECIES]_.
+
+Reply record encryption for other slots: ChaCha20.
+
+
+Layer Encryption
+------------------
+
+Currently there is no plan to change layer encryption for tunnels built with
+this specification; it would remain AES, as currently used for all tunnels.
+
+Changing layer encryption to ChaCha20 is a topic for additional research.
+
+
+
+New Tunnel Data Message
+-------------------------
+
+Currently there is no plan to change the 1KB Tunnel Data Message used for tunnels built with
+this specification.
+
+It may be useful to introduce a new I2NP message that is larger or variable-sized, concurrent with this proposal,
+for use over these tunnels.
+This would reduce overhead for large messages.
+This is a topic for additional research.
 
-Reply record encryption for other slots: AES or ChaCha20?
 
 
 
@@ -116,28 +238,281 @@ Specification
 =============
 
 
-Request Record
+Short Request Record
 -----------------------
 
-TBD
 
 
-Response Record
+Short Request Record Unencrypted
+```````````````````````````````````````
+
+This is the proposed specification of the tunnel BuildRequestRecord for ECIES-X25519 routers.
+Summary of changes from [Tunnel-Creation-ECIES]_:
+
+- Change unencrypted length from 464 to 154 bytes
+- Change encrypted length from 528 to 218 bytes
+- Remove layer and reply keys and IVs, they will be generated from split() and a KDF
+
+
+The request record does not contain any ChaCha reply keys.
+Those keys are derived from a KDF. See below.
+
+All fields are big-endian.
+
+Unencrypted size: 154 bytes.
+
+.. raw:: html
+
+  {% highlight lang='dataspec' %}
+
+bytes     0-3: tunnel ID to receive messages as, nonzero
+  bytes     4-7: next tunnel ID, nonzero
+  bytes    8-39: next router identity hash
+  byte       40: flags
+  bytes   41-42: more flags, unused, set to 0 for compatibility
+  byte       43: layer encryption type
+  bytes   44-47: request time (in minutes since the epoch, rounded down)
+  bytes   48-51: request expiration (in seconds since creation)
+  bytes   52-55: next message ID
+  bytes    56-x: tunnel build options (Mapping)
+  bytes     x-x: other data as implied by flags or options
+  bytes   x-153: random padding (see below)
+
+{% endhighlight %}
+
+
+The flags field is the same as defined in [Tunnel-Creation]_ and contains the following::
+
+ Bit order: 76543210 (bit 7 is MSB)
+ bit 7: if set, allow messages from anyone
+ bit 6: if set, allow messages to anyone, and send the reply to the
+        specified next hop in a Tunnel Build Reply Message
+ bits 5-0: Undefined, must set to 0 for compatibility with future options
+
+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.
+
+Layer encryption type: 0 for AES (as in current tunnels);
+1 for future (ChaCha?)
+
+The request exipration is for future variable tunnel duration.
+For now, the only supported value is 600 (10 minutes).
+
+The creator ephemeral public key is an ECIES key, big-endian.
+It is used for the KDF for the IBGW layer and reply keys and IVs.
+This is only included in the plaintext record in an Inbound Tunnel Build message.
+It is required because there is no DH at this layer for the build record.
+
+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.
+The maximum size of the Mapping (including the length field) is 98 bytes,
+and the maximum value of the Mapping length field is 96.
+
+
+
+Short Request Record Encrypted
+`````````````````````````````````````
+
+All fields are big-endian except for the ephemeral public key which is little-endian.
+
+Encrypted size: 218 bytes
+
+.. raw:: html
+
+  {% highlight lang='dataspec' %}
+
+bytes    0-15: Hop's truncated identity hash
+  bytes   16-47: Sender's ephemeral X25519 public key
+  bytes  48-201: ChaCha20 encrypted ShortBuildRequestRecord
+  bytes 202-217: Poly1305 MAC
+
+{% endhighlight %}
+
+
+
+Short Reply Record
 -----------------------
 
-TBD
+
+Short Reply Record Unencrypted
+`````````````````````````````````````
+This is the proposed specification of the tunnel ShortBuildReplyRecord for ECIES-X25519 routers.
+Summary of changes from [Tunnel-Creation-ECIES]_:
+
+- Change unencrypted length from 512 to 202 bytes
+- Change encrypted length from 528 to 218 bytes
+
+
+ECIES replies are encrypted with ChaCha20/Poly1305.
+
+All fields are big-endian.
+
+Unencrypted size: 202 bytes.
+
+.. raw:: html
+
+  {% highlight lang='dataspec' %}
+
+bytes    0-x: Tunnel Build Reply Options (Mapping)
+  bytes    x-x: other data as implied by options
+  bytes  x-200: Random padding (see below)
+  byte     201: Reply byte
+
+{% endhighlight %}
+
+The tunnel build reply 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.
+The maximum size of the Mapping (including the length field) is 201 bytes,
+and the maximum value of the Mapping length field is 199.
+
+The reply byte is one of the following values
+as defined in [Tunnel-Creation]_ to avoid fingerprinting:
+
+- 0x00 (accept)
+- 30 (TUNNEL_REJECT_BANDWIDTH)
+
+
+Short Reply Record Encrypted
+```````````````````````````````````
+
+Encrypted size: 218 bytes
+
+.. raw:: html
+
+  {% highlight lang='dataspec' %}
+
+bytes   0-201: ChaCha20 encrypted ShortBuildReplyRecord
+  bytes 202-217: Poly1305 MAC
+
+{% endhighlight %}
+
 
 
 KDF
 -----------------------
 
-TBD
+See KDF section below.
+
+
+
+.. _msg-ShortTunnelBuild:
+
+ShortTunnelBuild
+-------------------
+I2NP Type 25
+
+This message is sent to middle hops, OBEP, and IBEP (creator).
+It may not be sent to the IBGW (use garlic wrapped InboundTunnelBuild instead).
+When received by the OBEP, it is transformed to an OutboundTunnelBuildReply,
+garlic wrapped, and sent to the originator.
+
+
+.. raw:: html
+
+  {% highlight lang='dataspec' %}
++----+----+----+----+----+----+----+----+
+  | num| ShortBuildRequestRecords...
+  +----+----+----+----+----+----+----+----+
+
+  num ::
+         1 byte `Integer`
+         Valid values: 1-8
+
+  record size: 218 bytes
+  total size: 1+$num*218
+{% endhighlight %}
+
+Notes
+`````
+* Typical number of records is 4, for a total size of 873.
+
+
+
+.. _msg-OutboundTunnelBuildReply:
+
+OutboundTunnelBuildReply
+---------------------------
+I2NP Type 26
+
+This message is only sent by the OBEP to the IBEP (creator) via an existing inbound tunnel.
+It may not be sent to any other hop.
+It is always garlic encrypted.
+
+.. raw:: html
+
+  {% highlight lang='dataspec' %}
++----+----+----+----+----+----+----+----+
+  | num|                                  |
+  +----+                                  +
+  |      ShortBuildReplyRecords...        |
+  +----+----+----+----+----+----+----+----+
+
+  num ::
+         Total number of records,
+         1 byte `Integer`
+         Valid values: 1-8
+
+  ShortBuildReplyRecords ::
+         Encrypted records
+         length: num * 218
+
+  encrypted record size: 218 bytes
+  total size: 1+$num*218
+{% endhighlight %}
+
+Notes
+`````
+* Typical number of records is 4, for a total size of 873.
+* This message should be garlic encrypted.
+
+
+
+KDF
+---
+
+We use ck from Noise state after tunnel build record encryption/decrytion
+to derive following keys: reply key, AES layer key, AES IV key and garlic reply key/tag for OBEP.
+
+Reply key:
+Unlike long records we can't use left part of ck for reply key, because it's not last and will be used later.
+Reply key is used to encypt reply that record using AEAD/Chaha20/Poly1305 and Chacha20 to reply other records.
+Both use the same key, nonce is record's position in the message starting from 0.
+
+.. raw:: html
+
+  {% highlight lang='dataspec' %}
+keydata = HKDF(ck, ZEROLEN, "SMTunnelReplyKey", 64)
+  replyKey = keydata[32:63]
+  ck = keydata[0:31]
+
+  Layer key:
+  Layer key is always AES for now, but same KDF can be used from Chacha20
+
+  keydata = HKDF(ck, ZEROLEN, "SMTunnelLayerKey", 64)
+  layerKey = keydata[32:63]
+
+  IV key for non-OBEP record:
+  ivKey = keydata[0:31]
+  because it's last
+
+  IV key for OBEP record:
+  ck = keydata[0:31]
+  keydata = HKDF(ck, ZEROLEN, "TunnelLayerIVKey", 64)
+  ivKey = keydata[32:63]
+  ck = keydata[0:31]
+
+  OBEP garlic reply key/tag:
+  keydata = HKDF(ck, ZEROLEN, "RGarlicKeyAndTag", 64)
+  replyKey = keydata[32:63]
+  replyTag = keydata[0:7]
+
+{% endhighlight %}
 
 
-Tunnel Build Messages
------------------------
 
-TBD
 
 
 Justification
@@ -147,21 +522,26 @@ This design maximizes reuse of existing cryptographic primitives, protocols, and
 
 This design minimizes risk.
 
-
+ChaCha20 is slightly faster than AES for small records, in Java testing.
+ChaCha20 avoids a requirement for data size multiples of 16.
 
 
 Implementation Notes
 =====================
 
+- As with the existing variable tunnel build message,
+  messages smaller than 4 records are not recommended.
+  The typical default is 3 hops.
+  Inbound tunnels must be built with an extra record for
+  the originator, so the last hop does not know it is last.
+  So that middle hops don't know if a tunnel is inbound or outbound,
+  outbound tunnels should be built with 4 records also.
 
 
 
 Issues
 ======
 
-- HKDF details
-- AES or ChaCha for reply encryption?
-- Should we do additional hiding from the paired OBEP or IBGW? Garlic?
 
 
 Migration
@@ -175,25 +555,33 @@ 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.
+Tunnel creator must ensure that all hops in the created tunnel 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.
+It should NOT be necessary for the paired tunnel OBEP or IBGW is ECIES or
+of any particular version.
+The new messages are garlic-wrapped and not visible at the OBEP or IBGW
+of the paired tunnel.
 
 Phase 1: Implementation, not enabled by default
 
 Phase 2 (next release): Enable by default
 
+There are no backward-compatibility issues. The new messages may only be sent to routers that support them.
+
+
+
 
 Appendix
 ==========
 
 
+Without garlic overhead for unencrypted inbound STBM,
+if we don't use ITBM:
+
+
 .. raw:: html
 
   {% highlight lang='text' %}
@@ -205,34 +593,97 @@ Current 4-slot size: 4 * 528 + overhead = 3 tunnel messages
   - 21 fragment header
   ----
   1003
-  - 39 unfragmented instructions
+  - 35 unfragmented ROUTER delivery instructions
   ----
-  964
+  968
   - 16 I2NP header
   ----
-  948
+  952
   - 1 number of slots
   ----
-  947
+  951
   / 4 slots
   ----
-  236 New encrypted build record size (vs. 528 now)
+  237 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)
+  173 cleartext build record max (vs. 222 now)
 
 
 
 {% endhighlight %}
 
 
+With garlic overhead for 'N' noise pattern to encrypt inbound STBM,
+if we don't use ITBM:
+
+.. raw:: html
+
+  {% highlight lang='text' %}
+Current 4-slot size: 4 * 528 + overhead = 3 tunnel messages
+
+  4-slot garlic-encrypted build message to fit in one tunnel message, ECIES-only:
+
+  1024
+  - 21 fragment header
+  ----
+  1003
+  - 35 unfragmented ROUTER delivery instructions
+  ----
+  968
+  - 16 I2NP header
+  -  4 length
+  ----
+  948
+  - 32 byte eph. key
+  ----
+  916
+  - 7 byte DateTime block
+  ----
+  909
+  - 3 byte Garlic block overhead
+  ----
+  906
+  - 9 byte I2NP header
+  ----
+  897
+  - 1 byte Garlic LOCAL delivery instructions
+  ----
+  896
+  - 16 byte Poly1305 MAC
+  ----
+  880
+  - 1 number of slots
+  ----
+  879
+  / 4 slots
+  ----
+  219 New encrypted build record size (vs. 528 now)
+  - 16 trunc. hash
+  - 32 eph. key
+  - 16 MAC
+  ----
+  155 cleartext build record max (vs. 222 now)
+
+
+{% endhighlight %}
+
+Notes:
+
+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 58 bytes (without any options).
+
+The garlic-wrapped OTBRM will be slightly smaller than the garlic-wrapped STBM,
+because the delivery instructions are LOCAL not ROUTER,
+there's no DATETIME block included, and
+it uses an 8-byte tag rather than the 32-byte ephemeral key for a full 'N' message.
+
+
+
 References
 ==========
 
@@ -269,3 +720,6 @@ References
 .. [Tunnel-Creation]
     {{ spec_url('tunnel-creation') }}
 
+.. [Tunnel-Creation-ECIES]
+    {{ spec_url('tunnel-creation-ecies') }}
+

i2p2www/spec/proposals/158-ipv6-transport-enhancements.rst

@@ -0,0 +1,336 @@
+================================
+IPv6 Transport Enhancements
+================================
+.. meta::
+    :author: zzz, orignal
+    :created: 2021-03-19
+    :thread: http://zzz.i2p/topics/3060
+    :lastupdated: 2021-04-26
+    :status: Closed
+    :target: 0.9.50
+
+.. contents::
+
+
+Note
+====
+Network deployment and testing in progress.
+Subject to minor revisions.
+
+
+Overview
+========
+
+This proposal is to implement enhancements to the SSU and NTCP2 transports for IPv6.
+
+
+Motivation
+==========
+
+As IPv6 grows around the world and IPv6-only setups (especially on mobile) becomes more common,
+we need to improve our support for IPv6 and remove the assumptions that
+all routers are IPv4-capable.
+
+
+
+Connectivity Checking
+-----------------------
+
+When selecting peers for tunnels, or selecting OBEP/IBGW paths for routing messages,
+it helps to calculate whether router A can connect to router B.
+In general, this means determining if A has outbound capability for a transport and address type (IPv4/v6)
+that matches one of B's advertised inbound addresses.
+
+However, in many cases we don't know A's capabilites and have to make assumptions.
+If A is hidden or firewalled, the addresses are not published, and we don't have direct knowledge -
+so we assume it's IPv4 capable, and not IPv6 capable.
+The solution is adding two new "caps" or capabilities to the Router Info to indicate outbound capability for IPv4 and IPv6.
+
+
+IPv6 Introducers
+----------------------------------
+
+Our specifications [SSU]_ and [SSU-SPEC]_ contain errors and inconsistencies about whether
+IPv6 introducers are supported for IPv4 introductions.
+In any case, this has never been implemented in either Java I2P or i2pd.
+This needs to be corrected.
+
+
+IPv6 Introdutions
+----------------------------------
+
+Our specifications [SSU]_ and [SSU-SPEC]_ make clear that
+IPv6 introductions are not supported.
+This was under the assumption that IPv6 is never firewalled.
+This is clearly not true, and we need to improve support for firewalled IPv6 routers.
+
+
+Introduction Diagrams
+-------------------------
+
+Legend: ----- is IPv4, ====== is IPv6
+
+Current IPv4-only:
+
+.. raw:: html
+
+  {% highlight %}
+        Alice                         Bob                  Charlie
+    RelayRequest ---------------------->
+         <-------------- RelayResponse    RelayIntro ----------->
+         <-------------------------------------------- HolePunch
+    SessionRequest -------------------------------------------->
+         <-------------------------------------------- SessionCreated
+    SessionConfirmed ------------------------------------------>
+    Data <--------------------------------------------------> Data
+{% endhighlight %}
+
+
+IPv4 introduction, IPv6 introducer
+
+.. raw:: html
+
+  {% highlight %}
+Alice                         Bob                  Charlie
+    RelayRequest ======================>
+         <============== RelayResponse    RelayIntro ----------->
+         <-------------------------------------------- HolePunch
+    SessionRequest -------------------------------------------->
+         <-------------------------------------------- SessionCreated
+    SessionConfirmed ------------------------------------------>
+    Data <--------------------------------------------------> Data
+{% endhighlight %}
+
+IPv6 introduction, IPv6 introducer
+
+
+.. raw:: html
+
+  {% highlight %}
+Alice                         Bob                  Charlie
+    RelayRequest ======================>
+         <============== RelayResponse    RelayIntro ===========>
+         <============================================ HolePunch
+    SessionRequest ============================================>
+         <============================================ SessionCreated
+    SessionConfirmed ==========================================>
+    Data <==================================================> Data
+{% endhighlight %}
+
+IPv6 introduction, IPv4 introducer
+
+.. raw:: html
+
+  {% highlight %}
+Alice                         Bob                  Charlie
+    RelayRequest ---------------------->
+         <-------------- RelayResponse    RelayIntro ===========>
+         <============================================ HolePunch
+    SessionRequest ============================================>
+         <============================================ SessionCreated
+    SessionConfirmed ==========================================>
+    Data <==================================================> Data
+{% endhighlight %}
+
+
+Design
+======
+
+There are three changes to be implemented.
+
+- Add "4" and "6" capabilities to Router Address capabilities to indicate outbound IPv4 and IPv6 support
+- Add support for IPv4 introductions via IPv6 introducers
+- Add support for IPv6 introductions via IPv4 and IPv6 introducers
+
+
+
+Specification
+=============
+
+4/6 Caps
+--------
+
+This was originally implemented without a formal proposal, but it is required for
+IPv6 introductions, so we include it here.
+See also [CAPS]_.
+
+
+Two new capabilities "4" and "6" are defined.
+These new capabilities will be added to the "caps" property in the Router Address, not in the Router Info caps.
+We currently don't have a "caps" property defined for NTCP2.
+An SSU address with introducers is, by definition, ipv4 right now. We don't support ipv6 introduction at all.
+However, this proposal is compatible with a IPv6 introductions. See below.
+
+Additionally, a router may support connectivity via an overlay network such as I2P-over-Yggdrasil,
+but does not wish to publish an address, or that address does not have a standard IPv4 or IPv6 format.
+This new capability system should be flexible enough to support these networks as well.
+
+We define the following changes:
+
+NTCP2: Add "caps" property
+
+SSU: Add support for a Router Address without a host or introducers, to indicate outbound support
+for IPv4, IPv6, or both.
+
+Both transports: Define the following caps values:
+
+- "4": IPv4 support
+- "6": IPv6 support
+
+Multiple values may be supported in a single address. See below.
+At least one of these caps are mandatory if no "host" value is included in the Router Address.
+At most one of these caps is optional if a "host" value is included in the Router Address.
+Additional transport caps may be defined in the future to indicate support for overlay networks or other connectivity.
+
+
+Use cases and examples
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+SSU:
+
+SSU with host: 4/6 optional, never more than one.
+Example: SSU caps="4" host="1.2.3.4" key=... port="1234"
+
+SSU outbound only for one, other is published: Caps only, 4/6.
+Example: SSU caps="6"
+
+SSU with introducers: never combined. 4 or 6 is required.
+Example: SSU caps="4" iexp0=... ihost0=... iport0=... itag0=... key=...
+
+SSU hidden: Caps only, 4, 6, or 46. Multiple is allowed.
+No need for two addresses one with 4 and one with 6.
+Example: SSU caps="46"
+
+NTCP2:
+
+NTCP2 with host: 4/6 optional, never more than one.
+Example: NTCP2 caps="4" host="1.2.3.4" i=... port="1234" s=... v="2"
+
+NTCP2 outbound only for one, other is published: Caps, s, v only, 4/6/y, multiple is allowed.
+Example: NTCP2 caps="6" i=... s=... v="2"
+
+NTCP2 hidden: Caps, s, v only 4/6, multiple is allowed No need for two addresses one with 4 and one with 6.
+Example: NTCP2 caps="46" i=... s=... v="2"
+
+
+
+IPv6 Introducers for IPv4
+----------------------------
+
+The following changes are required to correct errors and inconsistencies in the specs.
+We have also described this as "part 1" of the proposal.
+
+Spec Changes
+~~~~~~~~~~~~~~~~
+
+[SSU]_ currently says (IPv6 notes):
+
+IPv6 is supported as of version 0.9.8. Published relay addresses may be IPv4 or IPv6, and Alice-Bob communication may be via IPv4 or IPv6.
+
+Add the following:
+
+While the specification was changed as of version 0.9.8, Alice-Bob communication via IPv6 was not actually supported until version 0.9.50.
+Earlier versions of Java routers erroneously published the 'C' capability for IPv6 addresses,
+even though they did not actually act as an introducer via IPv6.
+Therefore, routers should only trust the 'C' capability on an IPv6 address if the router version is 0.9.50 or higher.
+
+
+
+[SSU-SPEC]_ currently says (Relay Request):
+
+The IP address is only included if it is be different than the packet's source address and port.
+In the current implementation, the IP length is always 0 and the port is always 0,
+and the receiver should use the packet's source address and port.
+This message may be sent via IPv4 or IPv6. If IPv6, Alice must include her IPv4 address and port.
+
+Add the following:
+
+The IP and port must be included to introduce an IPv4 address when sending this message over IPv6.
+This is supported as of release 0.9.50.
+
+
+
+IPv6 Introductions
+----------------------------
+
+All three of the SSU relay messages (RelayRequest, RelayResponse, and RelayIntro) contain IP length fields
+to indicate the length of the (Alice, Bob, or Charlie) IP address to follow.
+
+Therefore, no change to the format of the messages is required.
+Only textual changes to the specifications, indicating that 16-byte IP addresses are allowed.
+
+The following changes are required to the specs.
+We have also described this as "part 2" of the proposal.
+
+
+Spec Changes
+~~~~~~~~~~~~~~~~
+
+[SSU]_ currently says (IPv6 notes):
+
+Bob-Charlie and Alice-Charlie communication is via IPv4 only.
+
+[SSU-SPEC]_ currently says (Relay Request):
+
+There are no plans to implement relaying for IPv6.
+
+Change to say:
+
+Relaying for IPv6 is supported as of release 0.9.xx
+
+[SSU-SPEC]_ currently says (Relay Response):
+
+Charlie's IP address must be IPv4, as that is the address that Alice will send the SessionRequest to after the Hole Punch.
+There are no plans to implement relaying for IPv6.
+
+Change to say:
+
+Charlie's IP address may be IPv4 or, as of release 0.9.xx, IPv6.
+That is the address that Alice will send the SessionRequest to after the Hole Punch.
+Relaying for IPv6 is supported as of release 0.9.xx
+
+[SSU-SPEC]_ currently says (Relay Intro):
+
+Alice's IP address is always 4 bytes in the current implementation, because Alice is trying to connect to Charlie via IPv4.
+This message must be sent via an established IPv4 connection,
+as that's the only way that Bob knows Charlie's IPv4 address to return to Alice in the RelayResponse.
+
+Change to say:
+
+For IPv4, Alice's IP address is always 4 bytes, because Alice is trying to connect to Charlie via IPv4.
+As of release 0.9.xx, IPv6 is supported, and Alice's IP address may be 16 bytes.
+
+For IPv4, this message must be sent via an established IPv4 connection,
+as that's the only way that Bob knows Charlie's IPv4 address to return to Alice in the RelayResponse.
+As of release 0.9.xx, IPv6 is supported, and this message may be sent via an established IPv6 connection.
+
+Also add:
+
+As of release 0.9.xx, any SSU address published with introducers must contain "4" or "6" in the "caps" option.
+
+
+Migration
+=========
+
+All old routers should ignore the caps property in NTCP2, and unknown capability characters in the SSU caps property.
+
+Any SSU address with introducers that does not contain a "4" or "6" cap is assumed to be for IPv4 introduction.
+
+
+
+
+
+References
+==========
+
+.. [CAPS]
+    http://zzz.i2p/topics/3050
+
+.. [NTCP2]
+    {{ spec_url('ntcp2') }}
+
+.. [SSU]
+    {{ site_url('docs/transport/ssu', True) }}
+
+.. [SSU-SPEC]
+    {{ spec_url('ssu') }}

i2p2www/spec/spectags

@@ -4,81 +4,85 @@
 !_TAG_PROGRAM_NAME	Exuberant Ctags	//
 !_TAG_PROGRAM_URL	http://ctags.sourceforge.net	/official site/
 !_TAG_PROGRAM_VERSION	5.9~svn20110310	//
-BandwidthLimits	i2cp.rst	467;"	m
-BlindingInfo	i2cp.rst	496;"	m
-BuildRequestRecord	i2np.rst	214;"	s
-BuildResponseRecord	i2np.rst	390;"	s
-Certificate	common-structures.rst	310;"	t
-CreateLeaseSet	i2cp.rst	585;"	m
-CreateLeaseSet	i2cp.rst	622;"	m
-CreateSession	i2cp.rst	679;"	m
-Data	i2np.rst	1337;"	m
-DatabaseLookup	i2np.rst	718;"	m
-DatabaseSearchReply	i2np.rst	1045;"	m
-DatabaseStore	i2np.rst	596;"	m
+BandwidthLimits	i2cp.rst	469;"	m
+BlindingInfo	i2cp.rst	498;"	m
+BuildRequestRecord	i2np.rst	230;"	s
+BuildResponseRecord	i2np.rst	407;"	s
+Certificate	common-structures.rst	318;"	t
+CreateLeaseSet	i2cp.rst	587;"	m
+CreateLeaseSet	i2cp.rst	624;"	m
+CreateSession	i2cp.rst	681;"	m
+Data	i2np.rst	1419;"	m
+DatabaseLookup	i2np.rst	779;"	m
+DatabaseSearchReply	i2np.rst	1125;"	m
+DatabaseStore	i2np.rst	650;"	m
 Date	common-structures.rst	32;"	t
-DeliveryInstructions	common-structures.rst	1699;"	s
-DeliveryStatus	i2np.rst	1119;"	m
-DestLookup	i2cp.rst	711;"	m
-DestReply	i2cp.rst	733;"	m
-Destination	common-structures.rst	673;"	s
-DestroySession	i2cp.rst	756;"	m
-Disconnect	i2cp.rst	775;"	m
-EncryptedLeaseSet	common-structures.rst	1394;"	s
-Garlic	i2np.rst	1162;"	m
-GarlicClove	i2np.rst	435;"	s
-GarlicCloveDeliveryInstructions	i2np.rst	497;"	s
-GetBandwidthLimits	i2cp.rst	795;"	m
-GetDate	i2cp.rst	818;"	m
-Hash	common-structures.rst	263;"	t
-HostLookup	i2cp.rst	851;"	m
-HostReply	i2cp.rst	891;"	m
-I2CPMessageHeader	i2cp.rst	315;"	s
-I2NPMessageHeader	i2np.rst	116;"	s
+DeliveryInstructions	common-structures.rst	1713;"	s
+DeliveryStatus	i2np.rst	1199;"	m
+DestLookup	i2cp.rst	713;"	m
+DestReply	i2cp.rst	735;"	m
+Destination	common-structures.rst	685;"	s
+DestroySession	i2cp.rst	758;"	m
+Disconnect	i2cp.rst	777;"	m
+EncryptedLeaseSet	common-structures.rst	1408;"	s
+Garlic	i2np.rst	1242;"	m
+GarlicClove	i2np.rst	487;"	s
+GarlicCloveDeliveryInstructions	i2np.rst	549;"	s
+GetBandwidthLimits	i2cp.rst	797;"	m
+GetDate	i2cp.rst	820;"	m
+Hash	common-structures.rst	268;"	t
+HostLookup	i2cp.rst	853;"	m
+HostReply	i2cp.rst	893;"	m
+I2CPMessageHeader	i2cp.rst	317;"	s
+I2NPMessageHeader	i2np.rst	132;"	s
 Integer	common-structures.rst	19;"	t
-KeysAndCert	common-structures.rst	573;"	s
-Lease	common-structures.rst	706;"	s
-Lease2	common-structures.rst	891;"	s
-LeaseSet	common-structures.rst	754;"	s
-LeaseSet2	common-structures.rst	1076;"	s
-LeaseSet2Header	common-structures.rst	1000;"	s
-Mapping	common-structures.rst	495;"	t
-MessageId	i2cp.rst	335;"	s
-MessagePayload	i2cp.rst	927;"	m
-MessageStatus	i2cp.rst	948;"	m
-MetaLease	common-structures.rst	1211;"	s
-MetaLeaseSet	common-structures.rst	1276;"	s
-OfflineSignature	common-structures.rst	944;"	s
-Payload	i2cp.rst	354;"	s
-PrivateKey	common-structures.rst	94;"	t
+KeysAndCert	common-structures.rst	581;"	s
+Lease	common-structures.rst	718;"	s
+Lease2	common-structures.rst	907;"	s
+LeaseSet	common-structures.rst	766;"	s
+LeaseSet2	common-structures.rst	1092;"	s
+LeaseSet2Header	common-structures.rst	1016;"	s
+Mapping	common-structures.rst	503;"	t
+MessageId	i2cp.rst	337;"	s
+MessagePayload	i2cp.rst	929;"	m
+MessageStatus	i2cp.rst	950;"	m
+MetaLease	common-structures.rst	1226;"	s
+MetaLeaseSet	common-structures.rst	1291;"	s
+OfflineSignature	common-structures.rst	960;"	s
+OutboundTunnelBuildReply	i2np.rst	1628;"	m
+Payload	i2cp.rst	356;"	s
+PrivateKey	common-structures.rst	99;"	t
 PublicKey	common-structures.rst	62;"	t
-ReceiveMessageBegin	i2cp.rst	1090;"	m
-ReceiveMessageEnd	i2cp.rst	1116;"	m
-ReconfigureSession	i2cp.rst	1141;"	m
-ReportAbuse	i2cp.rst	1171;"	m
-RequestLeaseSet	i2cp.rst	1199;"	m
-RequestVariableLeaseSet	i2cp.rst	1227;"	m
-RouterAddress	common-structures.rst	1519;"	s
-RouterIdentity	common-structures.rst	644;"	s
-RouterInfo	common-structures.rst	1591;"	s
-SendMessage	i2cp.rst	1253;"	m
-SendMessageExpires	i2cp.rst	1296;"	m
-SessionConfig	i2cp.rst	374;"	s
-SessionId	i2cp.rst	409;"	s
-SessionKey	common-structures.rst	126;"	t
-SessionStatus	i2cp.rst	1439;"	m
-SessionTag	common-structures.rst	278;"	t
-SetDate	i2cp.rst	1484;"	m
-Signature	common-structures.rst	222;"	t
-SigningPrivateKey	common-structures.rst	182;"	t
-SigningPublicKey	common-structures.rst	141;"	t
+ReceiveMessageBegin	i2cp.rst	1100;"	m
+ReceiveMessageEnd	i2cp.rst	1126;"	m
+ReconfigureSession	i2cp.rst	1151;"	m
+ReportAbuse	i2cp.rst	1181;"	m
+RequestLeaseSet	i2cp.rst	1209;"	m
+RequestVariableLeaseSet	i2cp.rst	1237;"	m
+RouterAddress	common-structures.rst	1533;"	s
+RouterIdentity	common-structures.rst	652;"	s
+RouterInfo	common-structures.rst	1605;"	s
+SendMessage	i2cp.rst	1263;"	m
+SendMessageExpires	i2cp.rst	1306;"	m
+SessionConfig	i2cp.rst	376;"	s
+SessionId	i2cp.rst	411;"	s
+SessionKey	common-structures.rst	131;"	t
+SessionStatus	i2cp.rst	1449;"	m
+SessionTag	common-structures.rst	283;"	t
+SetDate	i2cp.rst	1496;"	m
+ShortBuildRequestRecord	i2np.rst	466;"	s
+ShortBuildResponseRecord	i2np.rst	476;"	s
+ShortTunnelBuild	i2np.rst	1589;"	m
+Signature	common-structures.rst	227;"	t
+SigningPrivateKey	common-structures.rst	187;"	t
+SigningPublicKey	common-structures.rst	146;"	t
 String	common-structures.rst	46;"	t
 Tunnel	tunnel-message.rst	36;"	m
-TunnelBuild	i2np.rst	1371;"	m
-TunnelBuildReply	i2np.rst	1412;"	m
-TunnelData	i2np.rst	1259;"	m
-TunnelGateway	i2np.rst	1302;"	m
-TunnelId	common-structures.rst	293;"	t
+TunnelBuild	i2np.rst	1453;"	m
+TunnelBuildReply	i2np.rst	1496;"	m
+TunnelData	i2np.rst	1339;"	m
+TunnelGateway	i2np.rst	1383;"	m
+TunnelId	common-structures.rst	301;"	t
 TunnelMessageDeliveryInstructions	tunnel-message.rst	164;"	s
-VariableTunnelBuild	i2np.rst	1434;"	m
-VariableTunnelBuildReply	i2np.rst	1469;"	m
+VariableTunnelBuild	i2np.rst	1520;"	m
+VariableTunnelBuildReply	i2np.rst	1557;"	m

i2p2www/spec/ssu.rst

@@ -3,8 +3,8 @@ SSU Protocol Specification
 ==========================
 .. meta::
     :category: Transports
-    :lastupdated: 2020-09
-    :accuratefor: 0.9.48
+    :lastupdated: 2021-06
+    :accuratefor: 0.9.50
 
 .. contents::
 
@@ -542,8 +542,9 @@ required if the Router Identity must be fragmented.
   +----+----+----+----+----+----+----+----+
 {% endhighlight %}
  
-Typical size including header, in current implementation: 480 bytes (before
-non-mod-16 padding)
+Typical size including header, in current implementation: 512 bytes (with Ed25519 signature)
+or 480 bytes (with DSA-SHA1 signature)
+(before non-mod-16 padding)
 
 Notes
 `````
@@ -662,12 +663,13 @@ included) or 112 bytes (4-byte Alice IP included) (before non-mod-16 padding)
 Notes
 `````
 * The IP address is only included if it is be different than the packet's
-  source address and port. In the current implementation, the IP length is
-  always 0 and the port is always 0, and the receiver should use the packet's
   source address and port.
 
-* This message may be sent via IPv4 or IPv6. If IPv6, Alice must include her
-  IPv4 address and port.
+* This message may be sent via IPv4 or IPv6.
+  If the message is over IPv6 for an IPv4 introduction,
+  or (as of release 0.9.50) over IPv4 for an IPv6 introduction,
+  Alice must include her introduction address and port.
+  This is supported as of release 0.9.50.
 
 * If Alice includes her address/port, Bob may perform additional validation
   before continuing.
@@ -677,7 +679,7 @@ Notes
 
 * Challenge is unimplemented, challenge size is always zero
 
-* There are no plans to implement relaying for IPv6.
+* Relaying for IPv6 is supported as of release 0.9.50.
 
 * Prior to release 0.9.12, Bob's intro key was always used. As of release
   0.9.12, the session key is used if there is an established session between
@@ -737,10 +739,11 @@ Notes
   RelayRequest on (not necessarily the IP Alice included in the RelayRequest),
   and may be IPv4 or IPv6. Alice currently ignores these on receive.
 
-* Charlie's IP address must be IPv4, as that is the address that Alice will
+* Charlie's IP address may be IPv4, or, as of release 0.9.50, IPv6.
+  as that is the address that Alice will
   send the SessionRequest to after the Hole Punch.
 
-* There are no plans to implement relaying for IPv6.
+* Relaying for IPv6 is supported as of release 0.9.50.
 
 * Prior to release 0.9.12, Alice's intro key was always used. As of release
   0.9.12, the session key is used if there is an established session between
@@ -788,12 +791,17 @@ non-mod-16 padding)
 
 Notes
 `````
-* Alice's IP address is always 4 bytes in the current implementation, because
-  Alice is trying to connect to Charlie via IPv4.
+* For IPv4, Alice's IP address is always 4 bytes, because Alice is trying to connect to Charlie via IPv4.
+  As of release 0.9.xx, IPv6 is supported, and Alice's IP address may be 16 bytes.
 
 * This message must be sent via an established IPv4 connection, as that's the
   only way that Bob knows Charlie's IPv4 address to return to Alice in the
   RelayResponse_.
+* For IPv4, this message must be sent via an established IPv4 connection,
+  as that's the only way that Bob knows Charlie's IPv4 address to return to Alice in the RelayResponse_.
+  As of release 0.9.50, IPv6 is supported, and this message may be sent via an established IPv6 connection.
+
+* As of release 0.9.50, any SSU address published with introducers must contain "4" or "6" in the "caps" option.
 
 * Challenge is unimplemented, challenge size is always zero
 
@@ -982,6 +990,7 @@ PeerTest (type 7)
 -----------------
 
 See [SSU-PEERTEST]_ for details.
+Note: IPv6 peer testing is supported as of release 0.9.27.
 
 ====================  ==========================================================
 **Peer:**             Any
@@ -1073,8 +1082,7 @@ Notes
   Alice thinks her address is.
 
 * When sent by Bob or Charlie, IP and port are present, and IP address is
-  always 4 bytes in the current implementation. IPv6 testing is not currently
-  supported.
+  4 or 16 bytes. IPv6 testing is supported as of release 0.9.27.
 
 * IPv6 Notes: Through release 0.9.26, only testing of IPv4 addresses is supported. Therefore, all
   Alice-Bob and Alice-Charlie communication must be via IPv4. Bob-Charlie

i2p2www/spec/subscription.rst

@@ -2,8 +2,8 @@
 Addressbook Subscription Feed Commands
 ======================================
 .. meta::
-    :lastupdated: 2020-07
-    :accuratefor: 0.9.46
+    :lastupdated: 2021-01
+    :accuratefor: 0.9.49
 
 .. contents::
 
@@ -258,7 +258,7 @@ sig
 
 Example::
 
-  #!action=removeall#name=example.i2p#dest=b64destsig=b64sig
+  #!action=remove#name=example.i2p#dest=b64destsig=b64sig
 
 Remove all with this destination
 ````````````````````````````````

i2p2www/spec/tunnel-creation-ecies.rst

@@ -4,8 +4,8 @@ ECIES-X25519 Tunnel Creation
 
 .. meta::
     :category: Protocols
-    :lastupdated: 2020-11
-    :accuratefor: 0.9.48
+    :lastupdated: 2021-07
+    :accuratefor: 0.9.51
 
 .. contents::
 
@@ -16,23 +16,27 @@ This document specifies Tunnel Build message encryption
 using crypto primitives introduced by [ECIES-X25519]_.
 It is a portion of the overall proposal
 [Prop156]_ for converting routers from ElGamal to ECIES-X25519 keys.
+
+There are two versions specified.
+The first uses the existing build messages and build record size, for compatibility with ElGamal routers.
 This specification is implemented as of release 0.9.48.
+The second uses two new build messages and a smaller build record size, and may only be used with ECIES routers.
+This specification is implemented as of release 0.9.51.
 
 For the purposes of transitioning the network from ElGamal + AES256 to ECIES + ChaCha20,
 tunnels with mixed ElGamal and ECIES routers are necessary.
 Specifications for handling mixed tunnel hops are provided.
 No changes will be made to the format, processing, or encryption of ElGamal hops.
+This format maintains the same size for tunnel build records,
+as required for compatibility.
 
 ElGamal tunnel creators will generate ephemeral X25519 keypairs per-hop, and
 follow this spec for creating tunnels containing ECIES hops.
 
 This document specifies ECIES-X25519 Tunnel Building.
 For an overview of all changes required for ECIES routers, see proposal 156 [Prop156]_.
-For additional background on the development of this specification, see proposal 152 [Prop152]_.
-
-This format maintains the same size for tunnel build records,
-as required for compatibility. Smaller build records and messages will be
-implemented later - see [Prop157]_.
+For additional background on the development of the long record specification, see proposal 152 [Prop152]_.
+For additional background on the development of the short record specification, see proposal 157 [Prop157]_.
 
 
 Cryptographic Primitives
@@ -41,6 +45,8 @@ Cryptographic Primitives
 The primitives required to implement this specification are:
 
 - AES-256-CBC as in [Cryptography]_
+- STREAM ChaCha20 functions:
+  ENCRYPT(k, iv, plaintext) and DECRYPT(k, iv, ciphertext) - as in [EncryptedLeaseSet]_ and [RFC-7539]_
 - STREAM ChaCha20/Poly1305 functions:
   ENCRYPT(k, n, plaintext, ad) and DECRYPT(k, n, ciphertext, ad) - as in [NTCP2]_ [ECIES-X25519]_ and [RFC-7539]_
 - X25519 DH functions - as in [NTCP2]_ and [ECIES-X25519]_
@@ -130,7 +136,7 @@ ECIES replies use ChaCha20/Poly1305 AEAD for integrity, and authentication.
 
 
 
-Specification
+Long Record Specification
 =========================
 
 
@@ -238,7 +244,7 @@ Encrypted BuildReplyRecords are 528 bytes for both ElGamal and ECIES, for compat
 
 Reply Record Unencrypted
 `````````````````````````````````````
-This is the specification of the tunnel BuildRequestRecord for ECIES-X25519 routers.
+This is the specification of the tunnel BuildReplyRecord for ECIES-X25519 routers.
 Summary of changes:
 
 - Add Mapping for build reply options
@@ -524,6 +530,372 @@ The reply record is ChaCha20/Poly1305 encrypted.
 
 
 
+Short Record Specification
+===========================
+
+This specification uses two new I2NP tunnel build messages,
+Short Tunnel Build Message (type 25) and Outbound Tunnel Build Reply Message (type 26).
+
+The tunnel creator and all hops in the created tunnel must ECIES-X25519, and at least version 0.9.51.
+The hops in the reply tunnel (for an outbound build) or the outbound tunnel (for an inbound build)
+do not have any requirements.
+
+Encrypted request and reply records will be 218 bytes, compared to 528 bytes for all other build messages.
+
+The plaintext request records will be 154 bytes,
+compared to 222 bytes for ElGamal records,
+and 464 bytes for ECIES records as defined above.
+
+The plaintext response records will be 202 bytes,
+compared to 496 bytes for ElGamal records,
+and 512 bytes for ECIES records as defined above.
+
+The reply encryption will be ChaCha20/Poly1305 for the hop's own record,
+and ChaCha20 (NOT ChaCha20/Poly1305) for the other records in the build message.
+
+Request records will be made smaller by using HKDF to create the
+layer and reply keys, so they are not explicitly included in the request.
+
+
+
+Message Flow
+------------------
+
+.. raw:: html
+
+  {% highlight %}
+STBM: Short tunnel build message (type 25)
+  OTBRM: Outbound tunnel build reply message (type 26)
+
+  Outbound Build A-B-C
+  Reply through existing inbound D-E-F
+
+
+                  New Tunnel
+           STBM      STBM      STBM
+  Creator ------> A ------> B ------> C ---\
+                                     OBEP   \
+                                            | Garlic wrapped (optional)
+                                            | OTBRM
+                                            | (TUNNEL delivery)
+                                            | from OBEP to
+                                            | creator
+                Existing Tunnel             /
+  Creator <-------F---------E-------- D <--/
+                                     IBGW
+
+
+
+  Inbound Build D-E-F
+  Sent through existing outbound A-B-C
+
+
+                Existing Tunnel
+  Creator ------> A ------> B ------> C ---\
+                                    OBEP    \
+                                            | Garlic wrapped (optional)
+                                            | STBM
+                                            | (ROUTER delivery)
+                                            | from creator
+                  New Tunnel                | to IBGW
+            STBM      STBM      STBM        /
+  Creator <------ F <------ E <------ D <--/
+                                     IBGW
+
+
+
+{% endhighlight %}
+
+
+Notes
+`````
+Garlic wrapping of the messages hides them from the OBEP (for an inbound build)
+or the IBGW (for an outbound build). This is recommended but not required.
+If the OBEP and IBGW are the same router, it is not necessary.
+
+
+
+Short Build Request Records
+-------------------------------------
+
+Short encrypted BuildRequestRecords are 218 bytes.
+
+
+Short Request Record Unencrypted
+```````````````````````````````````````
+
+Summary of changes from long records:
+
+- Change unencrypted length from 464 to 154 bytes
+- Change encrypted length from 528 to 218 bytes
+- Remove layer and reply keys and IVs, they will be generated from a KDF
+
+
+The request record does not contain any ChaCha reply keys.
+Those keys are derived from a KDF. See below.
+
+All fields are big-endian.
+
+Unencrypted size: 154 bytes.
+
+.. raw:: html
+
+  {% highlight lang='dataspec' %}
+
+bytes     0-3: tunnel ID to receive messages as, nonzero
+  bytes     4-7: next tunnel ID, nonzero
+  bytes    8-39: next router identity hash
+  byte       40: flags
+  bytes   41-42: more flags, unused, set to 0 for compatibility
+  byte       43: layer encryption type
+  bytes   44-47: request time (in minutes since the epoch, rounded down)
+  bytes   48-51: request expiration (in seconds since creation)
+  bytes   52-55: next message ID
+  bytes    56-x: tunnel build options (Mapping)
+  bytes     x-x: other data as implied by flags or options
+  bytes   x-153: random padding (see below)
+
+{% endhighlight %}
+
+
+The flags field is the same as defined in [Tunnel-Creation]_ and contains the following::
+
+ Bit order: 76543210 (bit 7 is MSB)
+ bit 7: if set, allow messages from anyone
+ bit 6: if set, allow messages to anyone, and send the reply to the
+        specified next hop in a Tunnel Build Reply Message
+ bits 5-0: Undefined, must set to 0 for compatibility with future options
+
+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.
+
+Layer encryption type: 0 for AES (as in current tunnels);
+1 for future (ChaCha?)
+
+The request exipration is for future variable tunnel duration.
+For now, the only supported value is 600 (10 minutes).
+
+The creator ephemeral public key is an ECIES key, big-endian.
+It is used for the KDF for the IBGW layer and reply keys and IVs.
+This is only included in the plaintext record in an Inbound Tunnel Build message.
+It is required because there is no DH at this layer for the build record.
+
+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.
+The maximum size of the Mapping (including the length field) is 98 bytes,
+and the maximum value of the Mapping length field is 96.
+
+
+Short Request Record Encrypted
+`````````````````````````````````````
+
+All fields are big-endian except for the ephemeral public key which is little-endian.
+
+Encrypted size: 218 bytes
+
+.. raw:: html
+
+  {% highlight lang='dataspec' %}
+
+bytes    0-15: Hop's truncated identity hash
+  bytes   16-47: Sender's ephemeral X25519 public key
+  bytes  48-201: ChaCha20 encrypted ShortBuildRequestRecord
+  bytes 202-217: Poly1305 MAC
+
+{% endhighlight %}
+
+
+Short Build Reply Records
+-------------------------------------
+
+Short encrypted BuildReplyRecords are 218 bytes.
+
+
+Short Reply Record Unencrypted
+`````````````````````````````````````
+
+Summary of changes from long records:
+
+- Change unencrypted length from 512 to 202 bytes
+- Change encrypted length from 528 to 218 bytes
+
+
+ECIES replies are encrypted with ChaCha20/Poly1305.
+
+All fields are big-endian.
+
+Unencrypted size: 202 bytes.
+
+.. raw:: html
+
+  {% highlight lang='dataspec' %}
+
+bytes    0-x: Tunnel Build Reply Options (Mapping)
+  bytes    x-x: other data as implied by options
+  bytes  x-200: Random padding (see below)
+  byte     201: Reply byte
+
+{% endhighlight %}
+
+The tunnel build reply 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.
+The maximum size of the Mapping (including the length field) is 201 bytes,
+and the maximum value of the Mapping length field is 199.
+
+The reply byte is one of the following values
+as defined in [Tunnel-Creation]_ to avoid fingerprinting:
+
+- 0x00 (accept)
+- 30 (TUNNEL_REJECT_BANDWIDTH)
+
+An additional reply value may be defined in the future to
+represent rejection for unsupported options.
+
+
+Short Reply Record Encrypted
+```````````````````````````````````
+
+Encrypted size: 218 bytes
+
+.. raw:: html
+
+  {% highlight lang='dataspec' %}
+
+bytes   0-201: ChaCha20 encrypted ShortBuildReplyRecord
+  bytes 202-217: Poly1305 MAC
+
+{% endhighlight %}
+
+
+
+KDF
+---
+
+We use the chaining key (ck) from Noise state after tunnel build record encryption/decrytion
+to derive following keys: reply key, AES layer key, AES IV key and garlic reply key/tag for the OBEP.
+
+Reply keys:
+Note that the KDF is slightly different for the OBEP and non-OBEP hops.
+Unlike long records we can't use left part of ck for reply key, because it's not last and will be used later.
+The reply key is used to encypt reply that record using AEAD/Chaha20/Poly1305 and Chacha20 to reply other records.
+Both use the same key. The nonce is the record's position in the message starting from 0.
+See below for details.
+
+
+.. raw:: html
+
+  {% highlight lang='dataspec' %}
+keydata = HKDF(ck, ZEROLEN, "SMTunnelReplyKey", 64)
+  replyKey = keydata[32:63]
+  ck = keydata[0:31]
+
+  AES Layer key:
+  keydata = HKDF(ck, ZEROLEN, "SMTunnelLayerKey", 64)
+  layerKey = keydata[32:63]
+
+  IV key for non-OBEP record:
+  ivKey = keydata[0:31]
+  because it's last
+
+  IV key for OBEP record:
+  ck = keydata[0:31]
+  keydata = HKDF(ck, ZEROLEN, "TunnelLayerIVKey", 64)
+  ivKey = keydata[32:63]
+  ck = keydata[0:31]
+
+  OBEP garlic reply key/tag:
+  keydata = HKDF(ck, ZEROLEN, "RGarlicKeyAndTag", 64)
+  garlicReplyKey = keydata[32:63]
+  garlicReplyTag = keydata[0:7]
+
+{% endhighlight %}
+
+Note: The KDF for the IV key at the OBEP is different from that for the other hops,
+even if the reply is not garlic encrypted.
+
+
+Record Encryption
+```````````````````````
+
+The hop's own reply record is encrypted with ChaCha20/Poly1305.
+This is the same as for the long record specification above,
+EXCEPT that 'n' is the record number 0-7, instead of always being 0.
+See [RFC-7539]_.
+
+.. raw:: html
+
+  {% highlight lang='dataspec' %}
+
+// AEAD parameters
+  k = replyKey from KDF above
+  n = record number 0-7
+  plaintext = 202 byte build reply record
+  ad = h from build request
+
+  ciphertext = ENCRYPT(k, n, plaintext, ad)
+
+{% endhighlight %}
+
+
+The other records are iteratively and symmetrically encrypted at each hop with ChaCha20 (NOT ChaCha20/Poly1305).
+This is different from the long record specification above, which
+uses AES and does not use the record number.
+
+The record number is put in the IV at byte 4, because ChaCha20
+uses a 12-byte IV with a little-endian nonce at bytes 4-11.
+See [RFC-7539]_.
+
+
+.. raw:: html
+
+  {% highlight lang='dataspec' %}
+
+// Parameters
+  k = replyKey from KDF above
+  n = record number 0-7
+  iv = 12 bytes, all zeros except iv[4] = n
+  plaintext = 218 byte encrypted record
+
+  ciphertext = ENCRYPT(k, iv, plaintext)
+
+{% endhighlight %}
+
+
+Garlic Encryption
+```````````````````````
+
+Garlic wrapping of the messages hides them from the OBEP (for an inbound build)
+or the IBGW (for an outbound build). This is recommended but not required.
+If the OBEP and IBGW are the same router, it is not necessary.
+
+Garlic encryption of an inbound Short Tunnel Build Message,
+by the creator, encrypted to the ECIES IBGW, uses Noise 'N' encryption,
+as defined in [ECIES-ROUTERS]_.
+
+Garlic encryption of an Outbound Tunnel Build Reply Message,
+by the OBEP, encrypted to the creator, uses
+They are encrypted as Existing Session messages with
+the 32-byte garlic reply key and 8-byte garlic reply tag from the KDF above.
+The format is as specified for replies to Database Lookups in [I2NP]_,
+[ECIES-ROUTERS]_, and [ECIES-X25519]_.
+
+
+Layer Encryption
+``````````````````
+
+This specification includes a layer encryption type field in the build request record.
+The only layer encryption currently supported is type 0, which is AES.
+This is unchanged from previous specifications, except that the layer key and IV key
+are derived from the KDF above rather than being included in the build request record.
+
+Adding new layer encryption types, for example ChaCha20, is a topic for additional research,
+and is not currently a part of this specification.
+
+
+
 Implementation Notes
 =====================
 
@@ -543,9 +915,15 @@ References
 .. [Cryptography]
    {{ spec_url('cryptography') }}
 
+.. [ECIES-ROUTERS]
+   {{ spec_url('ecies-routers') }}
+
 .. [ECIES-X25519]
    {{ spec_url('ecies') }}
 
+.. [EncryptedLeaseSet]
+   {{ site_url('docs/spec/encryptedleaseset') }}
+
 .. [I2NP]
    {{ spec_url('i2np') }}
 

i2p2www/spec/tunnel-message.rst

@@ -3,8 +3,8 @@ Tunnel Message Specification
 ============================
 .. meta::
     :category: Design
-    :lastupdated: September 2016
-    :accuratefor: 0.9.26
+    :lastupdated: 2021-01
+    :accuratefor: 0.9.49
 
 .. contents::
 
@@ -60,7 +60,7 @@ These are the contents of a tunnel data message after encryption.
 
   Tunnel ID :: `TunnelId`
          4 bytes
-         the ID of the next hop
+         the ID of the next hop, nonzero
 
   IV ::
          16 bytes
@@ -121,7 +121,7 @@ These are the contents of a tunnel data message when decrypted.
 
   Tunnel ID :: `TunnelId`
          4 bytes
-         the ID of the next hop
+         the ID of the next hop, nonzero
 
   IV ::
          16 bytes
@@ -225,7 +225,7 @@ or a complete (unfragmented) I2NP message, and the instructions are:
   Tunnel ID :: `TunnelId`
          4 bytes
          Optional, present if delivery type is TUNNEL
-         The destination tunnel ID
+         The destination tunnel ID, nonzero
 
   To Hash ::
          32 bytes

i2p2www/spec/updates.rst

@@ -2,8 +2,8 @@
 Software Update Specification
 =============================
 .. meta::
-    :lastupdated: August 2019
-    :accuratefor: 0.9.42
+    :lastupdated: June 2021
+    :accuratefor: 0.9.51
 
 .. contents::
 
@@ -238,6 +238,8 @@ Bytes   Contents
         * 0x02 = html file (as of 0.9.17)
         * 0x03 = xml.gz file (as of 0.9.17)
         * 0x04 = txt.gz file (as of 0.9.28)
+        * 0x05 = dmg file (as of 0.9.51)
+        * 0x06 = exe file (as of 0.9.51)
 
  26     unused = 0
 

i2p2www/static/hosts.txt

@@ -52,3 +52,4 @@ idk.i2p=spHxea2xhPjKH9yyEeFJ96aqtvKidH-GiWxs8dH6RWS2FrDoWFhuEkfw77pF~Hv57lLhMaMB
 git.idk.i2p=80oPWkYFSfbnZvb~9uDtoFvmchhH4CJ1qDmFfXvp-PtEFS8gIaUmN2d4eLiS8NGt-LS-kfJvyiezxUEjK1myFR2C~IIvY~UwPiIe2d2d-VrkFg3dt2FA2qGnf7YBDsgSby~TMjNREyL9lvNznlPu00E1bUpMS09l6llQ7f-xTYloQQzasmR3xTXLe4XEDAhXfGC-KsOhLVhT2BlTHNU0cTaxtZP50K-2grAi~xwA7bUp5Br9TQvdBNyWH1fbzZax50ooPxwdW6wdC3eMbI7qHCiEtF0pexTQ-2~BbALNoFU6HRXoYZwaYNwuDsPSo0XsguUJXOa6eQT90bXkbStqwPrA6p0WvRHUb3wgLug-s7FY~4ncz3lKPOX~zX-adCvXpYgHFgiJas-9i9KyaniNa0SWUEozOaah3TtAdXGRpufUlPm~jwBdFD2kYj~xgI5FGcBxA1OVyTwuWQRmisjf-1eJfsItr1944TKCu2kwgCTsBwX4Lu48ojjKqInpLV61BQAEAAcAAA==#!action=addsubdomain#date=1580498845#olddest=spHxea2xhPjKH9yyEeFJ96aqtvKidH-GiWxs8dH6RWS2FrDoWFhuEkfw77pF~Hv57lLhMaMB3qqWjCtYXOjL48Q1zYbr3MAcTO44wwVPjOU1hU77vbJcUuwBeRvaSr2dZx-FiTSOdQuhPD1EozYNRIMFwZ0fZwKf~3Gj4dEWccOLKs~NbiPsj-~tc5tmhAs8yBeoZEqEBe40X75SfSHY-EnstcZevVAwIXYk3zX3KF0mji3bo2QXuTFcMZHHLiLd2AHLRANzWyvQ9DC1rnCsHJM4xxV4dVp0pHkP1hwBo7E0NJvN4nFkQcj-FI2RJ~cFUCk7qc86PRHwvKCjzSlrgjtDsMUwd83Dz1PfpzCqHNLUFWI7uPKbKcJZhasFm4kEhUyupd85q75Ch2IZE9J2JXodSxmseO5ZKcHK6pFtfR-HbzKjIe92TWHsNkmvtoHiUaOVrWnk-cmo2I1W1VxfL08teDxQ13P80uFaMcameRzuFM2F8pSOpoyEJUDRGLEeBQAEAAcAAA==#oldname=idk.i2p#oldsig=nqvkqfrlNYhJw0lxgkJKJtKC1McbHwo9J8DheCWJ5YbydUnq2iS2VOGj2rDMA5b1uw-uVEP2FRgV1yNzK~ETCw==#sig=sXTy7cMqA-4~q9YBXzr188sjC65I0GugcsxwPeMQ-CT6zKIByWbzLu0HXVWp98fs7fV7gVbHZDpiokn8npZBAQ==
 gitssh.idk.i2p=Q2ivHumt3AxJuYWAob4-NGvQbQ5P05QSL6B0kIgDurRclYgxNcBhnLxjUSiROP4hQOFkAd9OqZL00~b66iWSOlTAxxC1lOwHqpRw0UJFUwiNMZYskUIrg9r6eDohYQg~1Gxb50hMLp46myspm9jUuzhh8VdW5h6U7F8XksZnip16HwHJcPRqVHjI-6V6FHYfxsXj~bJO-uIFgLx4K9Mr65GQDPhpuzVwPSo5ytRWidxs6BFituAoduANhrDH2rztacHUVuiF8J3OXugLiqqrOemccbCf3jS~3Ed7euJvv3Jf46WyqETjGgjyE8L2CHJeiteFql0AYVcFqw-ufOCxm3yBahZFTnhu5QEEYEn~9izifdFqB78tKkjmGsCcdGLiTIcyYmZYycgIFrZ3P3gRdkGZI4OM5RfpWShdp5FxirIFxIsYMS4mpxGs~PAxJZGR7StIvp4lHYHBmErtzHKMsl55Vam2IZYzJ52ng0q3YRyFfqeM5GqxjGO1hgig4vQ6BQAEAAcAAA==#!action=addsubdomain#date=1588471458#olddest=spHxea2xhPjKH9yyEeFJ96aqtvKidH-GiWxs8dH6RWS2FrDoWFhuEkfw77pF~Hv57lLhMaMB3qqWjCtYXOjL48Q1zYbr3MAcTO44wwVPjOU1hU77vbJcUuwBeRvaSr2dZx-FiTSOdQuhPD1EozYNRIMFwZ0fZwKf~3Gj4dEWccOLKs~NbiPsj-~tc5tmhAs8yBeoZEqEBe40X75SfSHY-EnstcZevVAwIXYk3zX3KF0mji3bo2QXuTFcMZHHLiLd2AHLRANzWyvQ9DC1rnCsHJM4xxV4dVp0pHkP1hwBo7E0NJvN4nFkQcj-FI2RJ~cFUCk7qc86PRHwvKCjzSlrgjtDsMUwd83Dz1PfpzCqHNLUFWI7uPKbKcJZhasFm4kEhUyupd85q75Ch2IZE9J2JXodSxmseO5ZKcHK6pFtfR-HbzKjIe92TWHsNkmvtoHiUaOVrWnk-cmo2I1W1VxfL08teDxQ13P80uFaMcameRzuFM2F8pSOpoyEJUDRGLEeBQAEAAcAAA==#oldname=idk.i2p#oldsig=XtsKWRWdi~eYdRNxBuSpipQP5dMvugVnUjn5JRIfpfbixSTw9OZf~yi7wjh~~8DjXYJ7OU8pgJDogx8n7r~qAg==#sig=PET3WoFCEiADgJWUWVlAtC3qYc5xVS~-NuCKqxThzXNfEaDfMpWPcRnx6huz9qri7qp3ItBED05~aNSZ20YTCQ==
 paste.idk.i2p=5cg1fY7BdIZmlpp2xcnlHB3BcxIRrYb3OuvDvYxOwP8Dm5M35FDNLIbu81I-8wVj8MoSsyLFQd9Rt~lBelN2hC1Yr12Gy52CpUNntPFb30KRgQqLit~a2NdiGJu134ig6niPcB2XBCF2ehR0ME6RlPLLkwZX8WjOkMp35kzppZ5O2MIiQaf9WrxMKPZbQLcvKgEVoRP6yegefWDPl89u7Y5cVRVHX6kP2uy-g1TB5KP5ER9RpHwcoCn8n9ZjeGb48xT-KjRLu1MjJyxno2Hsifi26Cp9vj8CpAtvOh~25w~a8-6BpCQMjpWPxH2dWkqd6KzT~diqJ6XIXf8pWLqNQmadDMCVxbHA0uKDW0ba4iCkdGcyt1-hZdjN3zzfb4R9hBn1yMC1q0JDN5Ka4TPbN8clfaEx5DB5MwTqFVvzkk4w6CemkzE7fEoxukJqC3g0hJSn6CuuF3kEFyQclViYvkLJ1rbQCf4pyNL8exdeNemoo7OML-BeFHZU9P4L5~4NBQAEAAcAAA==#!action=addsubdomain#date=1583511995#olddest=spHxea2xhPjKH9yyEeFJ96aqtvKidH-GiWxs8dH6RWS2FrDoWFhuEkfw77pF~Hv57lLhMaMB3qqWjCtYXOjL48Q1zYbr3MAcTO44wwVPjOU1hU77vbJcUuwBeRvaSr2dZx-FiTSOdQuhPD1EozYNRIMFwZ0fZwKf~3Gj4dEWccOLKs~NbiPsj-~tc5tmhAs8yBeoZEqEBe40X75SfSHY-EnstcZevVAwIXYk3zX3KF0mji3bo2QXuTFcMZHHLiLd2AHLRANzWyvQ9DC1rnCsHJM4xxV4dVp0pHkP1hwBo7E0NJvN4nFkQcj-FI2RJ~cFUCk7qc86PRHwvKCjzSlrgjtDsMUwd83Dz1PfpzCqHNLUFWI7uPKbKcJZhasFm4kEhUyupd85q75Ch2IZE9J2JXodSxmseO5ZKcHK6pFtfR-HbzKjIe92TWHsNkmvtoHiUaOVrWnk-cmo2I1W1VxfL08teDxQ13P80uFaMcameRzuFM2F8pSOpoyEJUDRGLEeBQAEAAcAAA==#oldname=idk.i2p#oldsig=IxJ1B5U8U2zMCwTbMVps-BRobeY3MJ4GihkGxxzOS5Mewbcc0ugSpknbGGZvCHHR4Wd1wvfJ5Y4fK1Jkc4CoAg==#sig=YG149yexd-Ihx-pXuYxaHF0tTVJ6zopMxxp14cxWKQN1ZShF5vLq6-Dw-CgYYjxVHNBek6HqeG7z7qJyKc0UDQ==
+notbob.i2p=gOSToOvSkRewCcwl5mWXbnn1IElEBlGH92vAe0TI8C-Z4tC1DVMNdNlcnUTRcB7znjFTP0vQ42dIDs1dN2Co1kSJ~nXaef4QUS-Ou5kDogPLwJxI1Hj0djktSLKWJSL40FdQvWZ1rwQ7dnaRSyOm8lrgo~HbVlh682CM1JHmEGapQaYiF6zaP4uOpeTFlkk6wEYevQ3Pn4pctJD4XElVLrS2slEsbzim3O5FzFrIVYyskEbnpyMpyffwvsq0R~RF6bhDhQ15rAmJuju91WZ8iUlORQKipougCwBP9DxQ5zdXQWxxhSJ~h604dKhxncetl0skdErLHjwhSI2gl4o66juP9wsjaczBZo4RSil2uWMWApMgvan~9FSRtxriI5f6-X2fTopWa9KlUwMCBTiqYAy9bIdVVhS-xSdFhM~IGPEZ-rlIscdb3Z5Gh1osoO-~SglUcOpj7E-8XjjvsmLkUu9VBxscdD4p3aiyaHGSljkd3WPvlfaOBmqejqEgEWwqBQAEAAEAAA==#!date=1588638092#sig=VNP~TSUOVu~tZ-WriZEkWdLhJDUejOOj7PChbbANU~RG~2qYJpJqCZppI3zmVid8rFzalay0MYwIZNRUSzhvJQ==

i2p2www/static/i2p-debian-repo.key.asc

@@ -153,18 +153,18 @@ WfCRfqwo1HQTH0lxbvJCO9kohMN9gxHDC8UU/kP6CMoNrZPvErjWaGOIoqwXwE/w
 orfCYjIEN2xNAQ8PQzf8zbP/mDBczggAJCiCM/MXAPOaVq+asuqN1SDh0PWOQni9
 K74JNZay+yT+Yqj93AlsjcJH0ztKIfEL6BPyWZRVfToVUNoNTwqvYhljvP528IkC
 VAQTAQoAPgIbAwULCQgHAwUVCgkICwUWAgMBAAIeAQIXgBYhBHhA52EPKLkEdTVJ
-12fs5WBbzxNGBQJdhjV1BQkPC8aTAAoJEGfs5WBbzxNGFTUP/iN2Pp2gcOxWA9dW
-ctrp4V36uxpWWdKZ8mG9HlvXBmCdkgftcikKlq5iWVFf1uI/7m5SfMcLj2EXpEuB
-/lRRgdDFwKACVCsrjDqedfBOP2XH+sA2kgXKdeJ9JcXRM5vHzJ3/gz09HNWrMnbb
-lp7jDZ46T/rDsGxYKjvPsE9/y3MqS3Go0HbILIJJ5eVUE9KzmrT9/KGN1qjSyuZ4
-AMq+3qf+/RfUwgI3Li7FIitqvagz+aq5+5KiEQu3zwU3TjWNKImxWWEjtGfx0RTS
-zDxWhgqPMx5EY5RbbJ5FN6QzR7AcN65dc8SdqklQ0rmon04GyhW7U1CWyqLb+I4q
-x/O50L6rTg+BL2CwNrA9SDbc4NiZEp8WjyQeu6AxW9z6dvF4ICQD4OCETQXbya1J
-c8Cnu9Skglr9aI+oAW5ISxoug8OoQ3bj0JZi8jttdt4P38d6ECQ7uzG8x1s7pViX
-lznlXoMSS331mpDwUzgjnb+HxcwtDrMbrKbfY3zjDWBtORQI46oXO0eC1BHUJsSg
-kbe8hm3F62iVzGgIccSxKoxQTqS0sVbwpsP/wWPX9nbn0QC5KGh4T4jVxEsDVPvQ
-/WfRExyI6ORJy6FvV6WsXxm1cpQHTFfTMLtYEFk1jNJYw5rTwhsIH4lyMA5cz12M
-IIE41ilOTjCFOHPz4SnbqcLim0GkiQI9BBMBCgAnAhsDBQsJCAcDBRUKCQgLBRYC
+12fs5WBbzxNGBQJhO2zUBQkSwP3yAAoJEGfs5WBbzxNGRw4P/1J5jBaTt0Qc9HSM
+B4Db+ig8Zlg79D7MqFjg1TMiTfGuwd5jxPoJIxgWL6wuMsP1Huqomvup9qVbJjt7
+19iiWsXTSNRybiPyaa5q6WquCdrethoU77yeOy+OB5W7ylYU03SQUZ2t+vr8VF7X
+Rn4UY+XNx3+SlwkWkAhy1j2LaPFWTZ+NZyCBsGfq+vJ8Jhn62mwyVDEuBtLtcvWt
+5PMwoP/UXzdEQQGeS9VYhNp0kzeLZRdH7AexWWCX2JxI2gQ1sqO4I6EWgm9BwpJM
+rVGvYSJiQW/OzUTXgi2MiyJ2rwYD+MbiuV8r7xuHTbgQLc/D0OSH/JZbavxfmaGp
+zAkyzLCCCRcxSA33pVeqKPSS05VlGSjtXGF0DKVAI6zRkGqgLdkkQhyBgth+HyQ3
+n0BnSy5jpet0xWq641WwJci+W7hL+x8pBYBGaZ04GoIMpX5GBDTLrs39Va4K86c7
+h5KenvGXq8ZsPaE78o8cvlglHW0hIvLCY/uJUxOMWH3zIPkXnsbaFmqo/+u/FfSo
+NjF0gCyxLJSog63UbY7+0nq3jDk3uHQMGzvFCSEVGhz8lMnJKqvKe7N7hLW8jjA3
+XPmEs08EXNc+7y34YBC8xB+bBKq2NMh95FEapD20L07KRYuD/tDpkRg74Mya9LSS
+0Io2/ypdNiIwFPDf+1yU4M55GP4oiQI9BBMBCgAnAhsDBQsJCAcDBRUKCQgLBRYC
 AwEAAh4BAheABQJUJE28BQkDz0LHAAoJEGfs5WBbzxNGxj4P/jKOcNcBje4ffmu6
 +m2F1lOShT4VCtliIAnZNAgFrAaRRJsBddaSbF7IvPphUYD2wnhLkHpSmhvD54ee
 qUGZo1ohrRKyiELWUXyDpL4B+u/AiegXotFLkWBDz0ENv0CS2KgdK/k0cE3e0cYY
@@ -206,63 +206,75 @@ CAJRf/VHUMQ2XbwEEA8mGKk6u97Zvr48e5OVgnCxn+70d9473q++2+cblR+SSufW
 yT+jjTmUh7M7//L1sx/6u0tD+Ej8vKHHwfD0EO2Jj6oRmlPmQXYue1xzoiy+K8wv
 N0MRDEF9FvLKJfSdZeRRixcwPFZ14j3SLmXcX/VXGQPW594Ts7gi8+todJHfhV0G
 2eSiDARJ6Qh3CE8sUTYBOxxRTWzWZqMr8lwjTislGTqJINeir4MZ6k2rgeBJJKyp
-p8EDcWH7UYI74q/4V9jRteaX4rW5Ag0EUyx+NgEQANWzAFIGgVIJiKOv2VNjpaiW
-hkIEJVQHud/yGLKwjRMTc+oh25fH2moYOIXGbEQ4xbDnlysi7UuEGNq2iQsUFhdI
-JD/EcYmiWDysd0QuCvXegofGohMztWuXw6sJ3LY9Cq13foEthcLob5ZrJuSdvNxr
-sU/M3wUC0+ArihhKahRUpKdR4PNYz4x+hkduYl+gUaJtpvRAhJeKUfudvjPISJbD
-R0cr28tTNugs0F7VAuAWITQvmvqMBuQy3OBUMXdqDTnwhn82jLIylmZM2dXJbzC5
-Nanp4BKmI9DX8W+LWoN5GhUUVRRxE+6xk4pWDSnyLdbbYpyHRaUvrDEs2+NiQ4Yw
-JeNtCjNerQLBchQ2rZklmyj3KCCYqLWsJot68BDIxdPj6ahRljwkVJ2VJDsQZqW7
-YDHODE51rrBwrFkJ+4xR1qh4SNVtwLOGvYyRjswVqcpxEOXPdluxlR17M6MUztU4
-DVwdpGy1o+15+Z8VAYyJeuG9MX+1x50dW3g+jM7+cxKIMU6vcQcn6b2/Pjrq8K+f
-Anv5ib+HJgnYPk5znUsnPHUB8eoGVnqn+wcaG8UK4SnGF6Slh1PRIjAeq/tD118h
-zpYsSKLkF3jh7E1IlDQzVZ2us3i9RMYELwaljhb7Vne8KcNr4J6y3YjxWPPysRU3
-Ey1YkNdltAx8Y0JwFsvdABEBAAGJBEQEGAEKAA8CGwIFAlYN684FCQTCoRUCKcFd
-IAQZAQoABgUCUyx+NgAKCRDSQc6/PKteBgkmD/sFBqCRfPi7Eu7XB8wcPRlSteNU
-CA2r6YpQMawJU8jpQs+w+XOm3KXq/s0khHXYpvtgqtNeWYZIE2zJQ1pgdc9GfYRh
-PHuLH4kLHUqrd46U6hvce18p13eGXR3jzRdQuAT6JLCxvnZHCRWKdfnb6986zQPk
-A+YTB3j5rlChRlu0LAe9Y4qBUNBWvg1AdXpYa0n6GU14xELsMaT64OZerV1AVYfi
-gRwWQ40/bS+xHWiTZ93vX97+hAVN4N0aOHZDaKy0uStCdrP7uKD5yJe1d8AYXYqe
-Ci1cTixbq8BjnAZbHHpiGEKPOCiE8PPEay9RLLtY83VwV2oOjhr/ro+NcC/zPU7M
-hssWfkAhd+1/xGmtGfbQhlA44AJxmRU81HORRHn/LwmgRhts0weBmQ02Fgf0NGqZ
-d2OdM9gSXcxxlwsrB9wSiP36YY4VStlIo0eJR1PQgZbjd0yowwqKSLWwsdfiTGVW
-1JeBfO15mI4RvLRyivJJ932mrHJB60I9Z+37INQwBf8DHW7n7hsGwPmrObgwV9wz
-f3cDbmvCi7wGrhExaaEpCHMlcbgOcGWCuEl6DjiznW5yl9jQ8Z9gV7kxEYAJGDyO
-Lr+9l7/JTzC57rQFS1N2OnTWfnUFv2ZlMnNJWMKSDt/sUf2F3JOAmWMvE8u6797R
-/6ipLtuhBfgbfZfqRQkQZ+zlYFvPE0agtQ//boWLm6a0WgnFOy2pcWqVrn/ytDr2
-dAnpQ9zqP8Uu8kpEbJ31o/+W7dopYboICbqglH/uawAwUNs+XiKvNCoK1NYavlyI
-AHXqeKarJBho+eqjayAoZWWAyXAnbgXN8NAPYcFXK9i9bY1YbULxwneCYbitfbzE
-PbzrcgjQo9AfwCpVvxWxvYVhBTHQvw4OovTRnCohWYTeSK85vKI1kRoUrvLBh8j+
-aX/C6QDmTio7sek+lj46BZnjHYeM4v4vJPwDi2A8qiFtq2UvPF8yLmo1t2KdrX6W
-oYj3c531WbSqK1PRcqNl6QnSIfHoGUc8trnfLeIe+p+hZmcBzcy+pVpUG/yLnAut
-Mjo5z8OAE9wKq+i6a8FWTPjBKQk+aSoHWzxvfMVW2uC5WKiraDi/P7mP7sKSuIWE
-i4zbVr3051aiZTX9FE6ci+tKkWDZSfx2roTCLl4awV2KIHl2gIbw5g4IX+H7z7C0
-P5nKVpuyp354kQHrowdo9SHM/Dyc4drmfDzUHFnM5DDbOxIoAgU42eJQwtBE7f8W
-Bcu4jupXIGTOrSCgzkzc1rh+bFNI3Twe9bj50QH9oCCyw/Q1eHT8nqU54wm9byRV
-VMmMEDCwpPahx30tdGoC/PxwauPbYWq7C9P4L69f/rkd8aEhwGT/xqIxphXe2Id6
-IF1zopWyYbHYJ4yJBFsEGAEKACYCGwIWIQR4QOdhDyi5BHU1Sddn7OVgW88TRgUC
-XYY1gQUJDjZ8SwIpwV0gBBkBCgAGBQJTLH42AAoJENJBzr88q14GCSYP+wUGoJF8
-+LsS7tcHzBw9GVK141QIDavpilAxrAlTyOlCz7D5c6bcper+zSSEddim+2Cq015Z
-hkgTbMlDWmB1z0Z9hGE8e4sfiQsdSqt3jpTqG9x7XynXd4ZdHePNF1C4BPoksLG+
-dkcJFYp1+dvr3zrNA+QD5hMHePmuUKFGW7QsB71jioFQ0Fa+DUB1elhrSfoZTXjE
-QuwxpPrg5l6tXUBVh+KBHBZDjT9tL7EdaJNn3e9f3v6EBU3g3Ro4dkNorLS5K0J2
-s/u4oPnIl7V3wBhdip4KLVxOLFurwGOcBlscemIYQo84KITw88RrL1Esu1jzdXBX
-ag6OGv+uj41wL/M9TsyGyxZ+QCF37X/Eaa0Z9tCGUDjgAnGZFTzUc5FEef8vCaBG
-G2zTB4GZDTYWB/Q0apl3Y50z2BJdzHGXCysH3BKI/fphjhVK2UijR4lHU9CBluN3
-TKjDCopItbCx1+JMZVbUl4F87XmYjhG8tHKK8kn3faasckHrQj1n7fsg1DAF/wMd
-bufuGwbA+as5uDBX3DN/dwNua8KLvAauETFpoSkIcyVxuA5wZYK4SXoOOLOdbnKX
-2NDxn2BXuTERgAkYPI4uv72Xv8lPMLnutAVLU3Y6dNZ+dQW/ZmUyc0lYwpIO3+xR
-/YXck4CZYy8Ty7rv3tH/qKku26EF+Bt9l+pFCRBn7OVgW88TRjHVD/9PCbycUE4U
-IQIe5wAZaxw3GxgiIbewGhl2pfHtSpopzSkcglXl+u/G9kFd3beyHA6TFOPUrxXH
-+Y0phQTg5iM4CLayIX6O+PeZYcftiKw5VOB7vR/4NqA54rbY2w1czMws1Fvwi77k
-i9C/EKr3zi21aHdz87UrDxPoGh464kUBJDHiGdIlYK3le7bzMWu9Cp93S4ptfM8F
-2hSdS7mJ69F+lFXts6aBkOaCkagxRMar9q3uGqhpRzF3pZkFYVgqwdjszxps2Ykb
-fICm0Pw+tHCnBZU9N6y4xzoWynYVgGh5+IGyHyFYKuYfyNfIINg5my/rmUkksklU
-k8tdNIODg6KDPXMyBiJkeYiD9FD0mO4ONfvCw08eue+4qOdRCLG+8QcSffO7DvDT
-8sL/0RZL922Sk4q+yZkqTIXqckvSuhV4sXUcHXUnnu6j2V4PL+kOAh0WGZvDu60v
-ETXzOZldaX9KoeWtmjLoj9KQd23uyJMh1z6Epw4DcsFBntUElHL5j0Veo3qMztAj
-SgrTHH89lh7QZ8ZtU8TbwKROJOuyBL2A4uN+dMO3obKpLFfAFj+pQDj3hWeK45yl
-UWEXwzYXlo6htZDOuMazEHajVDiUoEDh5BBSNC8NhAKw6yFexQacySw30UhxcF/4
-GI5fntTjhyu6d6NJ0xVcWa/w+hTyPDjQGQ==
-=KZp7
+p8EDcWH7UYI74q/4V9jRteaX4rWJAlQEEwEKAD4CGwMFCwkIBwMFFQoJCAsFFgID
+AQACHgECF4AWIQR4QOdhDyi5BHU1Sddn7OVgW88TRgUCW57GFAUJC0m7MgAKCRBn
+7OVgW88TRhKKD/9WC4Dsq26eEkkEecqIoeqz33UhrLPrd2YpynQQhtrXnzkulQrE
+rRRYBm/4Z+9n4QaR/RDukcvjQ2oleHbAS8ysbqSsUXEfbORQTjD4iTojA4ebKdfq
+ymFrjEiJeb9grxyPE6gYb/rt14cvTzHfPQxkmJ0a4a+hcaMJPC24AXTUJ03pC/Iy
+L/ukHJYzCGVPLUaaED6xk5tGwAEu21i6RFBwDIeMZeBk+0DMRuiVX7Mok4WwADSi
+QNBRJjhG6aLYf7OP6TCKxk8a+doUeP4J9w+Sni/7zAHI24tKUQp96Lr7JJflSUlb
+7ligPSDlgeZ/j68iVRyvTlKsCN4QJnxTZMgy/79cziyR7uevTO0W4e68Ay2RQnz0
+ZYSrASNeylB/B4ogSygCAi+DuLAkHAcSPcGVGC2koF2Za7Dd+n27tWCYgIM2U5Y/
+VHTpWYsL179ADxqMresFcWzO4vo95/yiioHcs97ggFtaH0cgiyBhXewTnvh6beYF
+hYWP0xvHaKVIfUrLDItWaEP85lpBotwOdprnsxODOZIqSm+VeAlOwr3RRYSHLwYc
+NSJkuddqEKrGMUzVNuKnohu84/pKl31grTC+6935UiydFOEiJQTAOa1bKr0L4xDA
+kAe7GmEdVfKpKtJUfQtzaIw5kRrLTMxeGm/o0WdzG3qZNs7nFqveHmZzjbkCDQRT
+LH42ARAA1bMAUgaBUgmIo6/ZU2OlqJaGQgQlVAe53/IYsrCNExNz6iHbl8faahg4
+hcZsRDjFsOeXKyLtS4QY2raJCxQWF0gkP8RxiaJYPKx3RC4K9d6Ch8aiEzO1a5fD
+qwnctj0KrXd+gS2Fwuhvlmsm5J283GuxT8zfBQLT4CuKGEpqFFSkp1Hg81jPjH6G
+R25iX6BRom2m9ECEl4pR+52+M8hIlsNHRyvby1M26CzQXtUC4BYhNC+a+owG5DLc
+4FQxd2oNOfCGfzaMsjKWZkzZ1clvMLk1qengEqYj0Nfxb4tag3kaFRRVFHET7rGT
+ilYNKfIt1ttinIdFpS+sMSzb42JDhjAl420KM16tAsFyFDatmSWbKPcoIJiotawm
+i3rwEMjF0+PpqFGWPCRUnZUkOxBmpbtgMc4MTnWusHCsWQn7jFHWqHhI1W3As4a9
+jJGOzBWpynEQ5c92W7GVHXszoxTO1TgNXB2kbLWj7Xn5nxUBjIl64b0xf7XHnR1b
+eD6Mzv5zEogxTq9xByfpvb8+Ourwr58Ce/mJv4cmCdg+TnOdSyc8dQHx6gZWeqf7
+BxobxQrhKcYXpKWHU9EiMB6r+0PXXyHOlixIouQXeOHsTUiUNDNVna6zeL1ExgQv
+BqWOFvtWd7wpw2vgnrLdiPFY8/KxFTcTLViQ12W0DHxjQnAWy90AEQEAAYkERAQY
+AQoADwIbAgUCVg3rzgUJBMKhFQIpwV0gBBkBCgAGBQJTLH42AAoJENJBzr88q14G
+CSYP+wUGoJF8+LsS7tcHzBw9GVK141QIDavpilAxrAlTyOlCz7D5c6bcper+zSSE
+ddim+2Cq015ZhkgTbMlDWmB1z0Z9hGE8e4sfiQsdSqt3jpTqG9x7XynXd4ZdHePN
+F1C4BPoksLG+dkcJFYp1+dvr3zrNA+QD5hMHePmuUKFGW7QsB71jioFQ0Fa+DUB1
+elhrSfoZTXjEQuwxpPrg5l6tXUBVh+KBHBZDjT9tL7EdaJNn3e9f3v6EBU3g3Ro4
+dkNorLS5K0J2s/u4oPnIl7V3wBhdip4KLVxOLFurwGOcBlscemIYQo84KITw88Rr
+L1Esu1jzdXBXag6OGv+uj41wL/M9TsyGyxZ+QCF37X/Eaa0Z9tCGUDjgAnGZFTzU
+c5FEef8vCaBGG2zTB4GZDTYWB/Q0apl3Y50z2BJdzHGXCysH3BKI/fphjhVK2Uij
+R4lHU9CBluN3TKjDCopItbCx1+JMZVbUl4F87XmYjhG8tHKK8kn3faasckHrQj1n
+7fsg1DAF/wMdbufuGwbA+as5uDBX3DN/dwNua8KLvAauETFpoSkIcyVxuA5wZYK4
+SXoOOLOdbnKX2NDxn2BXuTERgAkYPI4uv72Xv8lPMLnutAVLU3Y6dNZ+dQW/ZmUy
+c0lYwpIO3+xR/YXck4CZYy8Ty7rv3tH/qKku26EF+Bt9l+pFCRBn7OVgW88TRqC1
+D/9uhYubprRaCcU7LalxapWuf/K0OvZ0CelD3Oo/xS7ySkRsnfWj/5bt2ilhuggJ
+uqCUf+5rADBQ2z5eIq80KgrU1hq+XIgAdep4pqskGGj56qNrIChlZYDJcCduBc3w
+0A9hwVcr2L1tjVhtQvHCd4JhuK19vMQ9vOtyCNCj0B/AKlW/FbG9hWEFMdC/Dg6i
+9NGcKiFZhN5Irzm8ojWRGhSu8sGHyP5pf8LpAOZOKjux6T6WPjoFmeMdh4zi/i8k
+/AOLYDyqIW2rZS88XzIuajW3Yp2tfpahiPdznfVZtKorU9Fyo2XpCdIh8egZRzy2
+ud8t4h76n6FmZwHNzL6lWlQb/IucC60yOjnPw4AT3Aqr6LprwVZM+MEpCT5pKgdb
+PG98xVba4LlYqKtoOL8/uY/uwpK4hYSLjNtWvfTnVqJlNf0UTpyL60qRYNlJ/Hau
+hMIuXhrBXYogeXaAhvDmDghf4fvPsLQ/mcpWm7KnfniRAeujB2j1Icz8PJzh2uZ8
+PNQcWczkMNs7EigCBTjZ4lDC0ETt/xYFy7iO6lcgZM6tIKDOTNzWuH5sU0jdPB71
+uPnRAf2gILLD9DV4dPyepTnjCb1vJFVUyYwQMLCk9qHHfS10agL8/HBq49tharsL
+0/gvr1/+uR3xoSHAZP/GojGmFd7Yh3ogXXOilbJhsdgnjIkEWwQYAQoAJgIbAhYh
+BHhA52EPKLkEdTVJ12fs5WBbzxNGBQJhO2zlBQkR67OvAinBXSAEGQEKAAYFAlMs
+fjYACgkQ0kHOvzyrXgYJJg/7BQagkXz4uxLu1wfMHD0ZUrXjVAgNq+mKUDGsCVPI
+6ULPsPlzptyl6v7NJIR12Kb7YKrTXlmGSBNsyUNaYHXPRn2EYTx7ix+JCx1Kq3eO
+lOob3HtfKdd3hl0d480XULgE+iSwsb52RwkVinX52+vfOs0D5APmEwd4+a5QoUZb
+tCwHvWOKgVDQVr4NQHV6WGtJ+hlNeMRC7DGk+uDmXq1dQFWH4oEcFkONP20vsR1o
+k2fd71/e/oQFTeDdGjh2Q2istLkrQnaz+7ig+ciXtXfAGF2KngotXE4sW6vAY5wG
+Wxx6YhhCjzgohPDzxGsvUSy7WPN1cFdqDo4a/66PjXAv8z1OzIbLFn5AIXftf8Rp
+rRn20IZQOOACcZkVPNRzkUR5/y8JoEYbbNMHgZkNNhYH9DRqmXdjnTPYEl3McZcL
+KwfcEoj9+mGOFUrZSKNHiUdT0IGW43dMqMMKiki1sLHX4kxlVtSXgXzteZiOEby0
+corySfd9pqxyQetCPWft+yDUMAX/Ax1u5+4bBsD5qzm4MFfcM393A25rwou8Bq4R
+MWmhKQhzJXG4DnBlgrhJeg44s51ucpfY0PGfYFe5MRGACRg8ji6/vZe/yU8wue60
+BUtTdjp01n51Bb9mZTJzSVjCkg7f7FH9hdyTgJljLxPLuu/e0f+oqS7boQX4G32X
+6kUJEGfs5WBbzxNGogkP/RL1fYK3cC0CvYZF1NqqPAXcFp5hSifsLRqKfCJHZn4P
+SfaYmlq6kvBjtduMbWXzfzzMpbtAd4HQxgSBh22O+C38K8LhOHgtafiU961Iw8Es
+N8OyTE4IVs8T5aWa9F/Y1Kra5AX9eOB4Jlwo74yMKQbNBTjbFvO86sPRB1Ny/Uih
+LyYNiy7YTmmPrDryj+F9i8wYsi/X7hsIOTKk1NrFlGgNy1we4ltI3z1Yp1TVGB7C
+ZbOExL5yavgB9Hjlh3oN/aIUNoJhPjCCgQ172W5awni6TOkhlICmVzJZ20QWyF/C
+7XAiHiTCovw1yUXF0QsSErvh8AsRkYni/AMGQRc9QbLQjFvFd7swlgzIL0mvsTec
+sCltksPh2jRNWm+MyrkREOZNX+r6weLhPCPm/3cphBXz/PG/JV3Cj/wAAYRroKhN
+3DNMRM7AonvLnE1PuvFROgBvci8VVShDmNRl27SIxCLKS1syO1cP9BZaFvzuvK99
+uPJvLJoWZIJt5h0bgFC5vb5sVLQPYt0CfWsc+nyhamc6IiRuHKGcP79FqMMp+KJ9
+W6ZoTWO7urfPGLtyHXCSprr9VGy0n+RswFeK3bpCVtGZvBSmIoF0XfqosfWFCwxI
+f1tXwL7zv4M93RY/kcwEJeDTDTs168VrLkpASaTqJ6BGaxbsn0Q2/d0p8nzBPUSa
+=DSs3
 -----END PGP PUBLIC KEY BLOCK-----