Next batch of proposal migrations

i2p2www/spec/proposals/106-ntcp-obfuscation.rst

@@ -6,7 +6,7 @@ NTCP Obfuscation
     :created: 2010-11-23
     :thread: http://zzz.i2p/topics/774
     :lastupdated: 2014-01-03
-    :status: Draft
+    :status: Rejected
 
 .. contents::
 
@@ -14,12 +14,21 @@ NTCP Obfuscation
 Introduction
 ============
 
-This is fairly heavyweight but it prevents any detection by DPI equipment.
+NTCP data is encrypted after the first message (and the first message appears to
+be random data), thus preventing protocol identification through "payload
+analysis". It is still vulnerable to protocol identification through "flow
+analysis". That's because the first 4 messages (i.e. the handshake) are fixed
+length (288, 304, 448, and 48 bytes).
+
+By adding random amounts of random data to each of the messages, we can make it
+a lot harder.
 
 
 Modifications to NTCP
 =====================
 
+This is fairly heavyweight but it prevents any detection by DPI equipment.
+
 The following data will be added to the end of the 288-byte message 1:
 
 - A 514-byte ElGamal encrypted block

i2p2www/spec/proposals/108-pt-transport.rst

@@ -0,0 +1,35 @@
+============
+PT Transport
+============
+.. meta::
+    :author: zzz
+    :created: 2014-01-09
+    :thread: http://zzz.i2p/topics/1551
+    :lastupdated: 2014-09-28
+    :status: Draft
+
+.. contents::
+
+
+Introduction
+============
+
+The general idea is to use Pluggable Transports (PTs) as an I2P transport for
+communication between routers. It would be an easy way to experiment with
+alternative protocols, and get ready for I2P blocking resistance.
+
+
+Thoughts
+========
+
+There are a few potential layers of implementation:
+
+1. A generic PT that implements SOCKS and ExtORPort and configures and forks the
+   in and out processes, and registers with the comm system. This layer knows
+   nothing about NTCP, and it may or may not use NTCP. Good for testing.
+
+2. Building on 1), a generic NTCP PT that builds on the NTCP code and funnels
+   NTCP to 1).
+
+3. Building on 2), a specific NTCP-xxxx PT configured to run a given external in
+   and out process.

i2p2www/spec/proposals/109-leaseset-2.rst

@@ -0,0 +1,46 @@
+==========
+LeaseSet 2
+==========
+.. meta::
+    :author: zzz
+    :created: 2014-01-22
+    :thread: http://zzz.i2p/topics/1560
+    :lastupdated: 2016-04-04
+    :status: Draft
+
+.. contents::
+
+
+Introduction
+============
+
+The end-to-end cryptography used through I2P tunnels has separate encryption and
+signing keys. The signing keys are in the tunnel Destination, which has already
+been extended with KeyCertificates to support newer signature types. However,
+the encryption keys are part of the LeaseSet, which doesn't contain any
+Certificates. It is therefore necessary to implement a new LeaseSet format, and
+add support for storing it in the netDb.
+
+A silver lining is that once LS2 is implemented, all existing Destinations can
+make use of more modern encryption types; routers that can fetch and read a LS2
+will be guaranteed to have support for any encryption types introduced alongside
+it.
+
+
+Format
+======
+
+The basic LS2 format would be like this:
+
+- dest
+- published timestamp (8 bytes)
+- expires (8 bytes)
+- subtype (1 byte) (regular, encrypted, meta, or service)
+- flags (2 bytes)
+
+- subtype-specific part:
+  - encryption type, encryption key, and leases for regular
+  - blob for encrypted
+  - properties, hashes, ports, revocations, etc. for service
+
+- signature

i2p2www/spec/proposals/110-ntcp-2.rst

@@ -0,0 +1,208 @@
+======
+NTCP 2
+======
+.. meta::
+    :author: zzz
+    :created: 2014-02-13
+    :thread: http://zzz.i2p/topics/1577
+    :lastupdated: 2014-09-21
+    :status: Draft
+
+.. contents::
+
+
+Introduction
+============
+
+NTCP data is encrypted after the first message (and the first message appears to
+be random data), thus preventing protocol identification through "payload
+analysis". It is still vulnerable to protocol identification through "flow
+analysis". That's because the first 4 messages (i.e. the handshake) are fixed
+length (288, 304, 448, and 48 bytes).
+
+By adding random amounts of random data to each of the messages, we can make it
+a lot harder.
+
+
+Goals
+=====
+
+- Support NTCP 1 and 2 on a single port, auto-detect.
+- Add random padding to all NTCP messages including handshake and data messages
+  (i.e. length obfuscation so all messages aren't a multiple of 16 bytes)
+- Obfuscate the contents of messages that aren't encrypted (1 and 2), sufficiently
+  so that DPI boxes can't classify them. Also ensure that the messages going to
+  a single peer or set of peers do not have a similar pattern of bits
+- Fix loss of bits in DH due to Java format (ticket #1112)
+- Add "probing resistance" (as Tor calls it), this includes replay resistance
+- Add options/version in handshake for future extensibility
+- Add resistance to malicious MitM segmentation if possible
+- Don't add significantly to CPU required for connection setup
+- Minimize changes
+
+
+
+Router Address
+==============
+
+Transport identifier is "NTCP" as before.
+
+Routers would publish "ver=1,2" in the Router Address (not the Router Info)
+if they support both NTCP 1 and NTCP 2 on the same port.
+That's what we would do in Java.
+
+"ver=1" is NTCP 1 only. This is the default if no "ver" is present.
+
+"ver=2" is NTCP 2 only. This can't be used for a long time, as it's not
+backwards-compatible. But sometime in the future, implementers could
+support version 2 only.
+
+Alternative: Make it something easier to parse, where it's the integer
+representation of a bitfield. ver=3 means you support version 1 and 2.
+ver=7 means you support versions 1, 2, and 3.
+
+
+Messages
+========
+
+1) Session Request
+------------------
+
+Message 1 is obfuscated with random padding,
+and the options block is AES-encrypted with Bob's (publicly known) router hash
+as a cheap form of obfuscation.
+There is no requirement that the session request be unbreakably encrypted,
+e.g. with Bob's encryption key, as there's nothing secret in here and that would be
+too expensive.
+
+
+current:
+- 256 byte X
+- 32 byte H(x) ^ H(RI)
+
+proposed:
+
+- 16 byte MAC
+- 16 byte AES-encrypted options block
+  - 1 byte protocol version (2)
+  - 3 bytes options (nothing now, all 0)
+  - 2 byte DH type (implies length of X)
+
+    0. Old ElG with leading zero (256 bytes) (unused in NTCP 2)
+    1. New ElG without leading zero (256 bytes)
+    2. ECDH? 25519?
+
+  - 2 byte block/stream cipher type
+
+    0. AES CBC
+    1. Salsa20? ChaCha?
+
+  - 4 byte timestamp (seconds since epoch, wrap around in 2038)
+  - 2 bytes unused, set to 0
+  - 2 byte padding count beyond X, to a minimum packet size of 289 bytes
+- DH X (256 bytes or as implied by DH type)
+- Random padding bytes as specified, to a minimum of 289 bytes.
+  No requirement for total message size to be a multiple of 16.
+
+Options block is AES ECB encrypted with Bob's 32-byte router hash as the key.
+This is the only portion of the message that is encrypted.
+
+MAC: Standard 16-byte HMAC-MD5 (not the nonstandard one we use in SSU)
+MAC covers only the options block.
+MAC key is the first 16 bytes of Bob's router hash.
+Encrypt-then-MAC.
+
+To determine if incoming message is version 1 or version 2:
+
+  Method 1
+	Read 32 bytes.
+	If the MAC is good then assume it is version 2, otherwise it is version 1.
+        There's a tiny chance the MAC could be good but it's really version 1.
+
+  Method 2
+	Read 288 bytes.
+	If there is a 289th byte pending, assume it is version 2, otherwise it is version 1.
+	This method is vulnerable to MiTM segmentation at 288 bytes.
+
+Timestamp is used for replay detection. Keep a cache of recent MACs for a time period,
+reject duplicates, and reject timestamps beyond the cache lifetime or too far in future.
+
+
+2) Session Created
+------------------
+
+The only change is adding a variable amount of padding at the end.
+TODO: Replace this with the full spec
+
+- Y type and length as specified in message 1
+- The last 16 bytes of Y are used as the IV.
+- Take the (former) first two padding bytes and make them the number
+  of padding bytes to follow, 0 - 65535
+- Padding up to the first multiple of 16 (0-15 bytes) is required and encrypted.
+- Padding after that is not encrypted, not used for next IV,
+  no requirement for total message size to be a multiple of 16.
+- The last 16 encrypted bytes are used as the next IV in message 4
+
+
+3) Session Confirm A
+--------------------
+
+The only change is adding a variable amount of padding at the end.
+TODO: Replace this with the full spec
+
+- The last 16 bytes of X from message 1 are used as the IV.
+- Take the (former) first two padding bytes and make them the number
+  of padding bytes to follow after the sig, 0 - 65535
+- Then pad with 0-15 bytes so that the message through the signature is a multiple of 16 bytes.
+- Then the signature
+- Padding after that is not encrypted, not used for next IV,
+  no requirement for total message size to be a multiple of 16.
+- The last 16 encrypted bytes are used as the next IV in the first data transfer.
+
+
+4) Session Confirm B
+--------------------
+
+The only change is adding a variable amount of padding at the end.
+TODO: Replace this with the full spec
+
+- The last 16 bytes of the encrypted contents of message 2 are used as the IV.
+- Take the (former) first two padding bytes and make them the number
+  of padding bytes to follow, 0 - 65535
+- Padding up to the first multiple of 16 (0-15 bytes) is required and encrypted.
+- Padding after that is not encrypted, not used for next IV,
+  no requirement for total message size to be a multiple of 16.
+- The last 16 encrypted bytes are used as the next IV in the first data transfer.
+
+
+5) Data Packets
+---------------
+
+Add non-mod-16 padding after the checksum:
+
+
+- Old:
+  - 2 byte data length
+  - Data
+  - Padding to multiple of 16 (including checksum)
+  - 4 byte checksum
+
+- New:
+  - 2 byte data length
+  - Data
+  - 2 byte post-checksum padding count, 0-65535
+  - 0-15 bytes Padding to multiple of 16 (including checksum)
+  - 4 byte checksum
+  - Random Padding (unencrypted, not used in IV, not covered by checksum)
+
+
+Alternatives
+============
+
+- Poly1305 instead of HMAC-MD5?
+- Something else instead of AES for obfuscating the options block in message 1?
+- ECDH or 25519 DH instead of ElG DH?
+- Salsa20 (or derivatives) instead of AES?
+
+When we add support for any new DH or block/stream cipher types,
+we will have to bump the advertised version in the Router Address.

i2p2www/spec/proposals/111-leaseset-key-persistence.rst

@@ -0,0 +1,28 @@
+========================
+LeaseSet Key Persistence
+========================
+.. meta::
+    :author: zzz
+    :created: 2014-12-13
+    :thread: http://zzz.i2p/topics/1770
+    :lastupdated: 2014-12-13
+    :status: Draft
+
+.. contents::
+
+
+Introduction
+============
+
+In 0.9.17 persistence was added for the netDb slicing key, stored in
+i2ptunnel.config. This helps prevent some attacks by keeping the same slice
+after restart, and it also prevents possible correlation with a router restart.
+
+There's two other things that are even easier to correlate with router restart:
+the leaseset encryption and signing keys. These are not currently persisted.
+
+
+Proposed Changes
+================
+
+TBD

i2p2www/spec/proposals/112-encrypted-streaming-flag.rst

@@ -0,0 +1,28 @@
+==========================
+'Encrypted' Streaming Flag
+==========================
+.. meta::
+    :author: orignal
+    :created: 2015-01-21
+    :thread: http://zzz.i2p/topics/1795
+    :lastupdated: 2015-01-21
+    :status: Draft
+
+.. contents::
+
+
+Introduction
+============
+
+High-loaded apps can encounter a shortage of ElGamal/AES+SessionTags tags.
+
+
+Proposal
+========
+
+Add a new flag somewhere within the streaming protocol. If a packets comes with
+this flag it means payload is AES encrypted by key from private key and peer's
+public key. That would allow to eliminated garlic (ElGamal/AES) encryption and
+shortage of tags problem.
+
+May be set per packet or per stream through SYN.

i2p2www/spec/proposals/113-batch-multiple-data-cloves-in-garlic.rst

@@ -0,0 +1,45 @@
+====================================
+Batch Multiple Data Cloves in Garlic
+====================================
+.. meta::
+    :author: orignal
+    :created: 2015-01-22
+    :thread: http://zzz.i2p/topics/1797
+    :lastupdated: 2015-01-22
+    :status: Draft
+
+.. contents::
+
+
+Introduction
+============
+
+
+
+
+Required Changes
+================
+
+The changes would be in OCMOSJ and related helper classes, and in
+ClientMessagePool. As there is no queue now, a new queue and some delay would be
+necessary. Any batching would have to honor a max garlic size to minimize
+dropping. Perhaps 3KB? Would want to instrument things first to measure how
+often this would get used.
+
+This is backward-compatible, as the garlic receiver will already process all
+cloves it receives.
+
+
+Thoughts
+========
+
+It is unclear whether this will have any useful effect, as streaming already
+does batching and selects optimum MTU. Batching would increase message size and
+exponential drop probability.
+
+The exception is uncompressed content, gzipped at the I2CP layer. But HTTP
+traffic is already compressed at higher layer, and Bittorrent data is usually
+uncompressible. What does this leave? I2pd doesn't currently do the x-i2p-gzip
+compression so it may help there a lot more. But stated goal of not running out
+of tags is better fixed with proper windowing implementation in his streaming
+library.

i2p2www/spec/proposals/114-prefer-near-in-keyspace.rst

@@ -0,0 +1,60 @@
+=================================
+Prefer Nearby Routers in Keyspace
+=================================
+.. meta::
+    :author: chisquare
+    :created: 2015-04-25
+    :thread: http://zzz.i2p/topics/1874
+    :lastupdated: 2015-04-25
+    :status: Draft
+
+.. contents::
+
+
+Introduction
+============
+
+This is an idea to improve tunnel build success, by organizing peers so that
+they prefer connecting to other peers that are close to them in keyspace.
+
+
+Required Changes
+================
+
+This change would require:
+
+1. Every router prefer connections near them in the keyspace.
+2. Every router be aware that every router prefers connections near them in
+   the keyspace.
+
+
+Advantages for Tunnel Building
+==============================
+
+If you build a tunnel::
+
+    A -long-> B -short-> C -short-> D
+
+(long/random vs short hop in keyspace), you can guess where the tunnel build
+probably failed and try a different peer at that point. In addition, it would
+allow you to detect denser parts in key space and have routers just not use them
+since it may be someone colluding.
+
+If you build a tunnel::
+
+    A -long-> B -long-> C -short-> D
+
+and it fails, you can infer that it was more likely failing at C -> D and you
+can choose another D hop.
+
+You can also build tunnels so that the OBEP is closer to the IBGW and use those
+tunnels with OBEP that are closer to the given IBGW in a LeaseSet.
+
+
+Security Implications
+=====================
+
+If you randomize the placement of short vs long hops in the keyspace, an
+attacker probably won't get much of an advantage.
+
+The biggest downside though is it may make user enumeration a bit easier.

i2p2www/spec/proposals/115-opt-in-statistics-collection.rst

@@ -0,0 +1,31 @@
+============================
+Opt-in Statistics Collection
+============================
+.. meta::
+    :author: zab
+    :created: 2015-11-04
+    :thread: http://zzz.i2p/topics/1981
+    :lastupdated: 2015-11-04
+    :status: Draft
+
+.. contents::
+
+
+Introduction
+============
+
+Currently there are several network parameters which have been determined by
+educated guessing. It is suspected that some of those can be tweaked to improve
+the overall performance of the network in terms of speed, reliability and so on.
+However, changing them without proper research is very risky.
+
+
+Proposal
+========
+
+The router supports vast collection of stats which can be used to analyze
+network-wide properties. What we need is an automated reporting system which
+collects those stats in a centralized place. Naturally, this would be opt-in as
+it pretty much destroys anonymity. (The privacy-friendly stats are already
+reported to stats.i2p) As a ballpark figure, for a network of size 30,000 a
+sample of 300 reporting routers should be representative enough.

i2p2www/spec/proposals/116-i2pcontrol-api-2.rst

@@ -0,0 +1,458 @@
+================
+I2PControl API 2
+================
+.. meta::
+    :author: hottuna
+    :created: 2016-01-23
+    :thread: http://zzz.i2p/topics/2030
+    :lastupdated: 2016-02-01
+    :status: Draft
+
+.. contents::
+
+
+Introduction
+============
+
+This page will outline the API2 for i2pcontrol
+
+
+Developer headsup!
+------------------
+
+All RPC paramters will now be lower case. This *will* break backwards
+compatibility with API1 implementations. The reasons for this is to provide
+users of >=API2 with simplest most coherent possible API.
+
+
+API 2
+=====
+
+.. raw:: html
+
+  {% highlight lang='json' -%}
+{
+    "id": "id",
+    "method": "method_name",
+    "params": {
+      "token": "auth_token",
+      "method_param": "method_parameter_value",
+    },
+    "jsonrpc": "2.0"
+  }
+
+  {
+    "id": "id",
+    "result": "result_value",
+    "jsonrpc": "2.0"
+  }
+{% endhighlight %}
+
+Parameters
+----------
+
+"id"
+  The id number or the request.
+
+  Used to identify which reply was spawn by which request.
+
+"method_name"
+  The name of the RPC that is being invoked.
+
+"auth_token"
+  The session authentication token.
+
+  Needs to be supplied with every RPC except for the 'authenticate' call.
+
+"method_parameter_value"
+  The method parameter.
+
+  Used to offer a different flavors of a method.  Like 'get', 'set' and flavors
+  like that.
+
+"result_value"
+  The value that the RPC returns. Its type and contents depends on the method
+  and which method.
+
+
+Prefixes
+--------
+
+The RPC naming scheme is similar to how it's done in CSS, with vendor prefixes
+for the different API implementations (i2p, kovri, i2pd)::
+
+    XXX.YYY.ZZZ
+    i2p.XXX.YYY.ZZZ
+    i2pd.XXX.YYY.ZZZ
+    kovri.XXX.YYY.ZZZ
+
+The overall idea with vendor-specific prefixes is to allow for some wiggle room
+and let implementations innovate without having to wait for every other
+implementation to catch up. If a RPC is implemented by all implementations its
+multiple prefixes can be removed and it can be included as a core RPC in the
+next API version.
+
+
+Method reading guide
+--------------------
+
+ * **rpc.method**
+
+   * *parameter* [type of parameter]:  [null], [number], [string], [boolean],
+     [array] or [object]. [object] being a {key:value} map.
+
+::
+
+  "return_value" [string] // This is the value returned by the RPC call
+
+
+Methods
+-------
+
+* **authenticate** - Given that a correct password is provided, this method provides you with a token for further access and a list of supported API levels.
+
+  * *password* [string]:  The password for this i2pcontrol implementation
+
+  ::
+
+    [object]
+    {
+      "token" : [string], // The token to be used be supplied with all other RPC methods
+      "api" : [[int],[int], ...]  // A list of supported API levels.
+    }
+
+
+* **control.** - Control i2p
+
+  * **control.reseed** - Start reseeding
+
+    * [nil]: No parameter needed
+
+    ::
+
+      [nil]
+
+  * **control.restart** - Restart i2p instance
+
+    * [nil]: No parameter needed
+
+    ::
+
+      [nil]
+
+  * **control.restart.graceful** - Restart i2p instance gracefully
+
+    * [nil]: No parameter needed
+
+    ::
+
+      [nil]
+
+  * **control.shutdown** - Shut down i2p instance
+
+    * [nil]: No parameter needed
+
+    ::
+
+      [nil]
+
+  * **control.shutdown.graceful** - Shut down i2p instance gracefully
+
+    * [nil]: No parameter needed
+
+    ::
+
+      [nil]
+
+  * **control.update.find** - **BLOCKING** Search for signed updates
+
+    * [nil]: No parameter needed
+
+    ::
+
+      true [boolean] // True iff signed update is available
+
+  * **control.update.start** - Start update process
+
+    * [nil]: No parameter needed
+
+    ::
+
+      [nil]
+
+
+* **i2pcontrol.** - Configure i2pcontrol
+
+  * **i2pcontrol.address** - Get/Set the ip address that i2pcontrol listens to.
+
+    * *get* [null]: This parameter does not need to be set.
+
+    ::
+
+      "0.0.0.0" [string]
+
+    * *set* [string]: This will be an ip address like "0.0.0.0" or "192.168.0.1"
+
+    ::
+
+      [nil]
+
+  * **i2pcontrol.password** - Change the i2pcontrol password.
+
+    * *set* [string]: Set the new password to this string
+
+    ::
+
+      [nil]
+
+  * **i2pcontrol.port** - Get/Set the port that i2pcontrol listens to.
+
+    * *get* [null]: This parameter does not need to be set.
+
+    ::
+
+      7650 [number]
+
+    * *set* [number]: Change the port that i2pcontrol listens to to this port
+
+    ::
+
+      [nil]
+
+
+* **settings.** - Get/Set i2p instance settings
+
+  * **settings.advanced** - Advanced settings
+
+    * *get*  [string]: Get the value of this setting
+
+    ::
+
+      "setting-value" [string]
+
+    * *getAll* [null]:
+
+    ::
+
+      [object]
+      {
+        "setting-name" : "setting-value", [string]
+        ".." : ".." 
+      }
+
+    * *set* [string]: Set the value of this setting
+    * *setAll* [object] {"setting-name" : "setting-value", ".." : ".." }
+
+    ::
+
+      [nil]
+
+  * **settings.bandwidth.in** - Inbound bandwidth settings
+  * **settings.bandwidth.out** - Outbound bandwidth settings
+
+    * *get* [nil]: This parameter does not need to be set.
+
+    ::
+
+      0 [number]
+
+    * *set* [number]: Set the bandwidth limit
+
+    ::
+
+     [nil]
+
+  * **settings.ntcp.autoip** - Get IP auto detection setting for NTCP
+
+    * *get* [null]: This parameter does not need to be set.
+
+    ::
+
+      true [boolean]
+
+  * **settings.ntcp.hostname** - Get NTCP hostname
+
+    * *get* [null]: This parameter does not need to be set.
+
+    ::
+
+      "0.0.0.0" [string]
+
+    * *set* [string]: Set new hostname
+
+    ::
+
+      [nil]
+
+  * **settings.ntcp.port** - NTCP port
+
+    * *get* [null]: This parameter does not need to be set.
+
+    ::
+
+      0 [number]
+
+    * *set* [number]: Set new NTCP port.
+
+    ::
+
+      [nil]
+
+    * *set* [boolean]: Set NTCP IP auto detection
+
+    ::
+
+      [nil]
+
+  * **settings.ssu.autoip** - Configure IP auto detection setting for SSU
+
+    * *get* [nil]: This parameter does not need to be set.
+
+    ::
+
+      true [boolean]
+
+  * **settings.ssu.hostname** - Configure SSU hostname
+
+    * *get* [null]: This parameter does not need to be set.
+
+    ::
+
+      "0.0.0.0" [string]
+
+    * *set* [string]: Set new SSU hostname
+
+    ::
+
+      [nil]
+
+  * **settings.ssu.port** - SSU port
+
+    * *get* [null]: This parameter does not need to be set.
+
+    ::
+
+      0 [number]
+
+    * *set* [number]: Set new SSU port.
+
+    ::
+
+      [nil]
+
+    * *set* [boolean]: Set SSU IP auto detection
+
+    ::
+
+      [nil]
+
+  * **settings.share** - Get bandwidth share percentage
+
+    * *get* [null]: This parameter does not need to be set.
+
+    ::
+
+      0 [number] // Bandwidth share percentage (0-100)
+
+    * *set* [number]: Set bandwidth share percentage (0-100)
+
+  * **settings.upnp** - Enable or disable UPNP
+
+    * *get* [nil]: This parameter does not need to be set.
+
+    ::
+
+      true [boolean]
+
+    * *set* [boolean]: Set SSU IP auto detection
+
+    ::
+
+      [nil]
+
+
+
+* **stats.** - Get stats from the i2p instance
+
+  * **stats.advanced** - This method provides access to all stats kept within the instance.
+
+    * *get* [string]:  Name of the advanced stat to be provided
+    * *Optional:* *period* [number]:  The period for the requested stat
+
+  * **stats.knownpeers** - Returns the number of known peers
+  * **stats.uptime** - Returns the time in ms since the router started
+  * **stats.bandwidth.in** - Returns the inbound bandwidth (ideally for the last second)
+  * **stats.bandwidth.in.total** - Returns the number of bytes received since last restart
+  * **stats.bandwidth.out** - Returns the outbound bandwidth (ideally for the last second)'
+  * **stats.bandwidth.out.total** - Returns the number of bytes sent since last restart'
+  * **stats.tunnels.participating** - Returns the number of tunnels participated in currently
+  * **stats.netdb.peers.active** - Returns the number of peers we've recently communicated with
+  * **stats.netdb.peers.fast** - Returns the number of 'fast' peers
+  * **stats.netdb.peers.highcapacity** - Returns the number of 'high capacity' peers
+  * **stats.netdb.peers.known** - Returns the number of known peers
+
+    * *get* [null]: This parameter does not need to be set.
+
+    ::
+
+      0.0 [number]
+
+
+* **status.** - Get i2p instance status
+
+  * **status.router** - Get router status
+
+    * *get* [null]: This parameter does not need to be set.
+
+    ::
+
+      "status" [string]
+
+  * **status.net** - Get router network status
+
+    * *get* [null]: This parameter does not need to be set.
+
+    ::
+
+      0 [number]
+      /**
+       *    0 – OK
+       *    1 – TESTING
+       *    2 – FIREWALLED
+       *    3 – HIDDEN
+       *    4 – WARN_FIREWALLED_AND_FAST
+       *    5 – WARN_FIREWALLED_AND_FLOODFILL
+       *    6 – WARN_FIREWALLED_WITH_INBOUND_TCP
+       *    7 – WARN_FIREWALLED_WITH_UDP_DISABLED
+       *    8 – ERROR_I2CP
+       *    9 – ERROR_CLOCK_SKEW
+       *   10 – ERROR_PRIVATE_TCP_ADDRESS
+       *   11 – ERROR_SYMMETRIC_NAT
+       *   12 – ERROR_UDP_PORT_IN_USE
+       *   13 – ERROR_NO_ACTIVE_PEERS_CHECK_CONNECTION_AND_FIREWALL
+       *   14 – ERROR_UDP_DISABLED_AND_TCP_UNSET
+       */
+
+  * **status.isfloodfill** - Is the i2p instance currently a floodfill
+
+    * *get* [null]: This parameter does not need to be set.
+
+    ::
+
+      true [boolean]
+
+  * **status.isreseeding** - Is the i2p instance currently reseeding
+
+    * *get* [null]: This parameter does not need to be set.
+
+    ::
+
+      true [boolean]
+
+  * **status.ip** - Public IP detected of this i2p instance
+
+    * *get* [null]: This parameter does not need to be set.
+
+    ::
+
+      "0.0.0.0" [string]

runserver.py

@@ -2,4 +2,4 @@
 from i2p2www import app
 
 if __name__ == '__main__':
-    app.run(host='127.0.0.1', port=5000, debug=False)
+    app.run(host='127.0.0.1', port=5000, debug=True)