diff --git a/i2p2www/spec/proposals/106-ntcp-obfuscation.rst b/i2p2www/spec/proposals/106-ntcp-obfuscation.rst
index fefbe2f7799c898c6af33aee6139af5db523179e..1da6692e2ff190300ce37830e52673569887d289 100644
--- a/i2p2www/spec/proposals/106-ntcp-obfuscation.rst
+++ b/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
diff --git a/i2p2www/spec/proposals/108-pt-transport.rst b/i2p2www/spec/proposals/108-pt-transport.rst
new file mode 100644
index 0000000000000000000000000000000000000000..44ac53428ffc13c9baf1b708481433c79f9c62be
--- /dev/null
+++ b/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.
diff --git a/i2p2www/spec/proposals/109-leaseset-2.rst b/i2p2www/spec/proposals/109-leaseset-2.rst
new file mode 100644
index 0000000000000000000000000000000000000000..16150ea73319d2feb1f0637ae7a70efc14883fe0
--- /dev/null
+++ b/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
diff --git a/i2p2www/spec/proposals/110-ntcp-2.rst b/i2p2www/spec/proposals/110-ntcp-2.rst
new file mode 100644
index 0000000000000000000000000000000000000000..f8fc9af0bc92d4b1a3578759f4ec382ac4de205f
--- /dev/null
+++ b/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.
diff --git a/i2p2www/spec/proposals/111-leaseset-key-persistence.rst b/i2p2www/spec/proposals/111-leaseset-key-persistence.rst
new file mode 100644
index 0000000000000000000000000000000000000000..03882b6bc22d77d6578bb084b8fd9246432c3134
--- /dev/null
+++ b/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
diff --git a/i2p2www/spec/proposals/112-encrypted-streaming-flag.rst b/i2p2www/spec/proposals/112-encrypted-streaming-flag.rst
new file mode 100644
index 0000000000000000000000000000000000000000..a632bce9eaa6a08833110d188f78655f453fb73a
--- /dev/null
+++ b/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.
diff --git a/i2p2www/spec/proposals/113-batch-multiple-data-cloves-in-garlic.rst b/i2p2www/spec/proposals/113-batch-multiple-data-cloves-in-garlic.rst
new file mode 100644
index 0000000000000000000000000000000000000000..7591b3007178ae658e6ffb7eff31229fb338a2b3
--- /dev/null
+++ b/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.
diff --git a/i2p2www/spec/proposals/114-prefer-near-in-keyspace.rst b/i2p2www/spec/proposals/114-prefer-near-in-keyspace.rst
new file mode 100644
index 0000000000000000000000000000000000000000..c2877a5f0317321d1ee256f771e2513bcb8b72b5
--- /dev/null
+++ b/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.
diff --git a/i2p2www/spec/proposals/115-opt-in-statistics-collection.rst b/i2p2www/spec/proposals/115-opt-in-statistics-collection.rst
new file mode 100644
index 0000000000000000000000000000000000000000..3c06c40a778a2bf4eaae63ec9c604483a82b0010
--- /dev/null
+++ b/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.
diff --git a/i2p2www/spec/proposals/116-i2pcontrol-api-2.rst b/i2p2www/spec/proposals/116-i2pcontrol-api-2.rst
new file mode 100644
index 0000000000000000000000000000000000000000..a0e33821a3c3c6165e6ea70587db6bb334f1bfb5
--- /dev/null
+++ b/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]
diff --git a/runserver.py b/runserver.py
index 2d1a4c9f8b59442c57570456e62636c2303e6faf..5589fd4fdfb478fad0b0952116c889a416e84525 100755
--- a/runserver.py
+++ b/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)