diff --git a/i2p2www/pages/global/nav.html b/i2p2www/pages/global/nav.html index 6f965f29..fa384a81 100644 --- a/i2p2www/pages/global/nav.html +++ b/i2p2www/pages/global/nav.html @@ -53,6 +53,18 @@
  • {{ _('SSU') }}
  • +
  • {{ _('Specifications') }} + +
  • {{ _('Papers and presentations') }}
  • diff --git a/www.i2p2/pages/blockfile.html b/i2p2www/pages/site/docs/specs/blockfile.html similarity index 94% rename from www.i2p2/pages/blockfile.html rename to i2p2www/pages/site/docs/specs/blockfile.html index ec25cf56..d10902c2 100644 --- a/www.i2p2/pages/blockfile.html +++ b/i2p2www/pages/site/docs/specs/blockfile.html @@ -1,4 +1,4 @@ -{% extends "_layout.html" %} +{% extends "global/layout.html" %} {% block title %}I2P Blockfile Specification{% endblock %} {% block content %}

    @@ -166,7 +166,7 @@ The maximum number of entries per span is 16. "%%__INFO__%%" is the master database skiplist with String/Properties key/value entries containing only one entry:

    -    "info": a Properties (UTF-8 String/String Map), serialized as a Mapping:
    +    "info": a Properties (UTF-8 String/String Map), serialized as a Mapping:
                 "version":   "2"
                 "created":   Java long time (ms)
                 "upgraded":  Java long time (ms) (as of database version 2)
    @@ -181,7 +181,7 @@ The maximum number of entries per span is 16.
     

         The skiplist keys are 4-byte Integers, the first 4 bytes of the hash of the Destination.
    -    The skiplist values are each a Properties (a UTF-8 String/String Map) serialized as a Mapping
    +    The skiplist values are each a Properties (a UTF-8 String/String Map) serialized as a Mapping
             There may be multiple entries in the properties, each one is a reverse mapping,
                as there may be more than one hostname for a given destination,
                or there could be collisions with the same first 4 bytes of the hash.
    @@ -197,8 +197,8 @@ The keys/values in these skiplists are as follows:
     

          key:    a UTF-8 String (the hostname)
    -     value:  a DestEntry, which is a Properties (a UTF-8 String/String Map) serialized as a Mapping
    -             followed by a binary Destination (serialized as usual).
    +     value:  a DestEntry, which is a Properties (a UTF-8 String/String Map) serialized as a Mapping
    +             followed by a binary Destination (serialized as usual).
     

    diff --git a/www.i2p2/pages/common_structures_spec.html b/i2p2www/pages/site/docs/specs/common_structures.html similarity index 94% rename from www.i2p2/pages/common_structures_spec.html rename to i2p2www/pages/site/docs/specs/common_structures.html index 83e0352c..ca582871 100644 --- a/www.i2p2/pages/common_structures_spec.html +++ b/i2p2www/pages/site/docs/specs/common_structures.html @@ -1,4 +1,4 @@ -{% extends "_layout.html" %} +{% extends "global/layout.html" %} {% block title %}Common structure Specification{% endblock %} {% block content %} Updated March 2012, current as of router version 0.8.13 @@ -7,7 +7,7 @@ Updated March 2012, current as of router version 0.8.13 This document describes some data types common to all I2P protocols, like I2NP, I2CP, - SSU, + SSU, etc.

    @@ -61,7 +61,7 @@ Deprecated - unused

    Description

    This structure is used in ElGamal encryption, representing only the exponent, not the primes, which are constant and defined in - the cryptography specification. + the cryptography specification.

    Contents

    @@ -74,7 +74,7 @@ Deprecated - unused

    Description

    This structure is used in ElGamal decryption, representing only the exponent, not the primes which are constant and defined in - the cryptography specification. + the cryptography specification.

    Contents

    @@ -98,7 +98,7 @@ Deprecated - unused

    SigningPublicKey

    Description

    - This structure is used for verifying DSA signatures. + This structure is used for verifying DSA signatures.

    Contents

    @@ -110,7 +110,7 @@ Deprecated - unused

    SigningPrivateKey

    Description

    - This structure is used for creating DSA signatures. + This structure is used for creating DSA signatures.

    Contents

    @@ -122,7 +122,7 @@ Deprecated - unused

    Signature

    Description

    - This structure represents the DSA signature of some data. + This structure represents the DSA signature of some data.

    Contents

    @@ -204,9 +204,9 @@ payload :: data

  • For Router Identities, the Certificate is always NULL, no others are currently implemented.
  • -For Garlic Cloves, the Certificate is always NULL, no others are currently implemented. +For Garlic Cloves, the Certificate is always NULL, no others are currently implemented.
  • -For Garlic Messages, the Certificate is always NULL, no others are currently implemented. +For Garlic Messages, the Certificate is always NULL, no others are currently implemented.
  • For Destinations, the Certificate may be non-NULL, however non-NULL certs are not widely used, and any checking is left to the application-level. @@ -518,7 +518,7 @@ signature :: Signature The public key of the destination was used for the old i2cp-to-i2cp encryption which was disabled in version 0.6, it is currently unused?
  • -The encryption key is used for end-to-end ElGamal/AES+SessionTag encryption. +The encryption key is used for end-to-end ElGamal/AES+SessionTag encryption. It is currently generated anew at every router startup, it is not persistent.
  • The signature may be verified using the signing public key of the destination. @@ -680,6 +680,6 @@ The signature may be verified using the signing public key of the router_ident.

    Delivery Instructions

    -Defined in the Tunnel Message Specification. +Defined in the Tunnel Message Specification. {% endblock %} diff --git a/www.i2p2/pages/configuration.html b/i2p2www/pages/site/docs/specs/configuration.html similarity index 93% rename from www.i2p2/pages/configuration.html rename to i2p2www/pages/site/docs/specs/configuration.html index ed3b75c1..ce440846 100644 --- a/www.i2p2/pages/configuration.html +++ b/i2p2www/pages/site/docs/specs/configuration.html @@ -1,4 +1,4 @@ -{% extends "_layout.html" %} +{% extends "global/layout.html" %} {% block title %}Configuration File Specification{% endblock %} {% block content %} Updated September 2012, current as of router version 0.9.2 @@ -40,7 +40,7 @@ Reads and writes are implemented in DataHelper loadProps() and storeProps(). Note that the file format is significantly different than the serialized format for I2P protocols specified in -Mapping. +Mapping.

    Core library and router

    @@ -57,7 +57,7 @@ Configured via /configlogging in the router console.

    Individual Plugin (xxx/plugin.config)

    -See the plugin specification. +See the plugin specification.

    Plugins (plugins.config)

    diff --git a/www.i2p2/pages/datagrams.html b/i2p2www/pages/site/docs/specs/datagrams.html similarity index 82% rename from www.i2p2/pages/datagrams.html rename to i2p2www/pages/site/docs/specs/datagrams.html index 6af812b0..41f446df 100644 --- a/www.i2p2/pages/datagrams.html +++ b/i2p2www/pages/site/docs/specs/datagrams.html @@ -1,4 +1,4 @@ -{% extends "_layout.html" %} +{% extends "global/layout.html" %} {% block title %}Datagram Specification{% endblock %} {% block content %} @@ -12,9 +12,9 @@ message. This is necessary for some applications since the base I2P message is completely raw - it has no "from" address (unlike IP packets). In addition, the message and sender are authenticated by signing the payload.

    -Datagrams, like streaming library packets, +Datagrams, like streaming library packets, are an application-level construct. -These protocols are independent of the low-level transports; +These protocols are independent of the low-level transports; the protocols are converted to I2NP messages by the router, and either protocol may be carried by either transport.

    @@ -23,8 +23,8 @@ either protocol may be carried by either transport.

    Applications written in Java may use the datagram API, while applications in other languages -can use SAM's datagram support. -There is also limited support in i2ptunnel in the SOCKS proxy, +can use SAM's datagram support. +There is also limited support in i2ptunnel in the SOCKS proxy, the 'streamr' tunnel types, and udpTunnel classes.

    @@ -37,7 +37,7 @@ by an intermediate hop. Messages larger than a few KB are not recommended.

    Also note that the various overheads added by lower layers, in particular asymmetric -ElGamal/AES, place a large burden on intermittent messages +ElGamal/AES, place a large burden on intermittent messages such as used by a Kademlia-over-UDP application. The implementations are currently tuned for frequent traffic using the streaming library. There are a high number of session tags delivered, and a short session tag lifetime, for example. @@ -78,11 +78,11 @@ There is no checksum field in the datagram protocol.

    Packet Encapsulation

    Each datagram is sent through I2P as a single message (or as an individual clove in a -Garlic Message). +Garlic Message). Message encapsulation is implemented in the underlying I2CP, I2NP, and -tunnel message layers. +tunnel message layers. There is no packet delimiter mechanism or length field in the datagram protocol. @@ -107,9 +107,9 @@ Length: 0 - unlimited (see notes)

    Notes

    The practical length is limited by lower layers of protocols - the -tunnel message spec +tunnel message spec limits messages to about 61.2 KB and the -transports +transports currently limit messages to about 32 KB, although this may be raised in the future. @@ -143,13 +143,13 @@ Repliable datagrams contain a 'from' address and a signature. These add 427 byte -from :: a Destination +from :: a Destination length: 387+ bytes The originator and signer of the datagram -signature :: a Signature +signature :: a Signature length: 40 bytes - The DSA signature of the SHA256 hash of the payload, which may be verified by the + The DSA signature of the SHA256 hash of the payload, which may be verified by the DSA signing public key of the 'from' Destination payload :: The data @@ -162,7 +162,7 @@ Total length: Payload length + 427+

    Notes

    The practical length is limited by lower layers of protocols - the -transports +transports currently limit messages to about 32 KB, so the data length here is limited to about 31.5 KB. diff --git a/www.i2p2/pages/i2cp_spec.html b/i2p2www/pages/site/docs/specs/i2cp.html similarity index 85% rename from www.i2p2/pages/i2cp_spec.html rename to i2p2www/pages/site/docs/specs/i2cp.html index fc0ff53a..ef6424dc 100644 --- a/www.i2p2/pages/i2cp_spec.html +++ b/i2p2www/pages/site/docs/specs/i2cp.html @@ -1,4 +1,4 @@ -{% extends "_layout.html" %} +{% extends "global/layout.html" %} {% block title %}I2CP Specification{% endblock %} {% block content %} Updated November 2012, current as of router version 0.9.3 @@ -158,9 +158,9 @@ as they generally disconnect the session upon reception of an unsupported messag

    Contents

    1. - 4 byte Integer specifying the length of the message body + 4 byte Integer specifying the length of the message body
    2. - 1 byte Integer specifying the message type. + 1 byte Integer specifying the message type.
    3. The I2CP message body, 0 or more bytes
    @@ -181,7 +181,7 @@ point in time.

    Contents

    1. -4 byte Integer +4 byte Integer

    Notes

    @@ -200,7 +200,7 @@ Destination to another.

    Contents

    1. -4 byte Integer length +4 byte Integer length
    2. That many bytes
    @@ -221,14 +221,14 @@ Defines the configuration options for a particular client session.

    Contents

    1. -Destination +Destination
    2. -Mapping of options +Mapping of options
    3. -Creation Date +Creation Date
    4. -DSA Signature of the previous 3 fields, signed by the -Signing Private Key +DSA Signature of the previous 3 fields, signed by the +Signing Private Key

    Notes

    @@ -249,7 +249,7 @@ time.

    Contents

    1. -2 byte Integer +2 byte Integer

    Notes

    @@ -396,28 +396,28 @@ Sent from Router to Client in response to a Get Bandwidth Limits Message.

    Contents

    1. -4 byte Integer +4 byte Integer Client inbound limit (KBps)
    2. -4 byte Integer +4 byte Integer Client outbound limit (KBps)
    3. -4 byte Integer +4 byte Integer Router inbound limit (KBps)
    4. -4 byte Integer +4 byte Integer Router inbound burst limit (KBps)
    5. -4 byte Integer +4 byte Integer Router outbound limit (KBps)
    6. -4 byte Integer +4 byte Integer Router outbound burst limit (KBps)
    7. -4 byte Integer +4 byte Integer Router burst time (seconds)
    8. -Nine 4-byte Integers +Nine 4-byte Integers undefined
    @@ -441,11 +441,11 @@ Sent from Client to Router.
    1. Session ID
    2. -Signing Private Key +Signing Private Key
    3. -Private Key +Private Key
    4. -LeaseSet +LeaseSet

    Notes

    @@ -497,7 +497,7 @@ The router responds with a Dest Reply Message.

    Contents

    1. -SHA-256 Hash +SHA-256 Hash

    Notes

    @@ -516,9 +516,9 @@ Sent from Router to Client in response to a Dest Lookup Message.

    Contents

    1. -Destination +Destination on success, or -Hash +Hash on failure
    @@ -561,7 +561,7 @@ Sent either from router to client or from client to router.

    Contents

    1. -Reason String +Reason String

    Notes

    @@ -599,7 +599,7 @@ The router responds with a Set Date Message.

    Contents

    1. -I2CP Version String +I2CP Version String

    Notes

    @@ -651,11 +651,11 @@ For an outgoing message, this is a response to a
  • Message ID
  • -1 byte Integer status +1 byte Integer status
  • -4 byte Integer size +4 byte Integer size
  • -4 byte Integer nonce +4 byte Integer nonce
  • Notes

    @@ -760,10 +760,10 @@ Sent either from router to client or from client to router.
    1. Session ID
    2. -1 byte Integer abuse severity +1 byte Integer abuse severity (0 is minimally abusive, 255 being extremely abusive)
    3. -Reason String +Reason String
    4. Message ID
    @@ -789,16 +789,16 @@ The client responds with a Create LeaseSet Message<
    1. Session ID
    2. -1 byte Integer number of tunnels +1 byte Integer number of tunnels
    3. That many pairs of:
      1. - Router Identity + Router Identity
      2. - Tunnel ID + Tunnel ID
    4. -End Date +End Date

    Notes

    @@ -821,11 +821,11 @@ The router responds with a Message Status Message
  • Session ID
  • -Destination +Destination
  • Payload
  • -4 byte Integer nonce +4 byte Integer nonce
  • Notes

    @@ -858,15 +858,15 @@ Sent from Client to Router. Same as Send Message Message, except includes an exp
    1. Session ID
    2. -Destination +Destination
    3. Payload
    4. -4 byte Integer nonce +4 byte Integer nonce
    5. 2 bytes of flags (options)
    6. -Expiration Date +Expiration Date truncated from 8 bytes to 6 bytes
    @@ -961,7 +961,7 @@ Sent from Router to Client.
    1. Session ID
    2. -1 byte Integer status +1 byte Integer status

    Notes

    @@ -981,9 +981,9 @@ Sent from Router to Client as a part of the initial handshake.

    Contents

    1. -Date +Date
    2. -I2CP Version String +I2CP Version String

    Notes

    diff --git a/www.i2p2/pages/i2np_spec.html b/i2p2www/pages/site/docs/specs/i2np.html similarity index 92% rename from www.i2p2/pages/i2np_spec.html rename to i2p2www/pages/site/docs/specs/i2np.html index 56df4a8d..4f8dde68 100644 --- a/www.i2p2/pages/i2np_spec.html +++ b/i2p2www/pages/site/docs/specs/i2np.html @@ -1,4 +1,4 @@ -{% extends "_layout.html" %} +{% extends "global/layout.html" %} {% block title %}I2NP Specification{% endblock %} {% block content %} @@ -24,11 +24,11 @@ They are not complete messages.

    Contents

    - 1 byte Integer specifying the type of this message, - followed by a 4 byte Integer specifying the message-id. - After that there is an expiration Date, - followed by a 2 byte Integer specifying - the length of the message payload, followed by a Hash, + 1 byte Integer specifying the type of this message, + followed by a 4 byte Integer specifying the message-id. + After that there is an expiration Date, + followed by a 2 byte Integer specifying + the length of the message payload, followed by a Hash, which is truncated to the first byte. After that the actual message data follows.

    @@ -90,7 +90,7 @@ data :: Data
     

    Notes

    • -When transmitted over SSU, +When transmitted over SSU, the 16-byte standard header is not used. Only a 1-byte type and a 4-byte expiration in seconds is included. The message id and size are @@ -116,7 +116,7 @@ where the far-end router's version is known and checksum generation can be disab

      Contents

      - TunnelId to receive messages on, followed by the Hash of our RouterIdentity. After that the TunnelId and the Hash of the next router's RouterIdentity follow. + TunnelId to receive messages on, followed by the Hash of our RouterIdentity. After that the TunnelId and the Hash of the next router's RouterIdentity follow.

      Definition

      @@ -272,7 +272,7 @@ total length: 528
       
      • In the 512-byte encrypted record, the ElGamal data contains bytes 1-256 and 258-513 of the -514-byte ElGamal encrypted block. +514-byte ElGamal encrypted block. The two padding bytes from the block (the zero bytes at locations 0 and 257) are removed.
      • See the tunnel creation specification for details on field contents. @@ -341,7 +341,7 @@ unencrypted:

        Definition

         unencrypted:
        -Delivery Instructions :: as defined here
        +Delivery Instructions :: as defined here
                Length varies but is typically 39, 43, or 47 bytes
         
         I2NP Message :: Any I2NP Message
        @@ -363,9 +363,9 @@ Certificate :: Always NULL in the current implementation (3 bytes total, all zer
           If 1, the clove is encrypted, and a 32 byte Session Key immediately follows the flag byte.
           Clove encryption is not fully implemented.
         
      • - See also the garlic routing specification. + See also the garlic routing specification.
      • - See also Delivery Instructions definition + See also Delivery Instructions definition
      • Maximum length is a function of the total length of all the cloves and the maximum length of the GarlicMessage. @@ -509,7 +509,7 @@ reply token: reply tunnelId: 4 byte Tunnel ID only included if reply token > 0 - This is the tunnel ID of the inbound gateway of the tunnel the response should be sent to + This is the tunnel ID of the inbound gateway of the tunnel the response should be sent to reply gateway: 32 bytes @@ -714,7 +714,7 @@ time stamp: Date It appears that the time stamp is always set by the creator to the current time. However there are several uses of this in the code, and more may be added in the future.
      • - This message is also used as a session established confirmation in SSU. + This message is also used as a session established confirmation in SSU. In this case, the message ID is set to a random number, and the "arrival time" is set to the current network-wide ID, which is 2 (i.e. 0x0000000000000002). @@ -804,9 +804,9 @@ Expiration :: Date (8 bytes)
      • Actual max length is less than 64 KB; see the I2NP Overview.
      • - See also the ElGamal/AES specification. + See also the ElGamal/AES specification.
      • - See also the garlic routing specification. + See also the garlic routing specification.
      • The 128 byte minimum size of the AES encrypted block is not currently configurable, however the minimum size of a DataMessage in a GarlicClove in a GarlicMessage, with @@ -852,7 +852,7 @@ data:

        Notes

        diff --git a/www.i2p2/pages/plugin_spec.html b/i2p2www/pages/site/docs/specs/plugin.html similarity index 98% rename from www.i2p2/pages/plugin_spec.html rename to i2p2www/pages/site/docs/specs/plugin.html index 06690b66..49d5ca5a 100644 --- a/www.i2p2/pages/plugin_spec.html +++ b/i2p2www/pages/site/docs/specs/plugin.html @@ -1,4 +1,4 @@ -{% extends "_layout.html" %} +{% extends "global/layout.html" %} {% block title %}I2P Plugin Specification{% endblock %} {% block content %}

        @@ -59,7 +59,7 @@ system, the router, executing external programs, etc. foo.xpi2p is a sud file containing the following:
         	Standard .sud header prepended to the zip file, containing the following:
        -	        40-byte DSA signature
        +	        40-byte DSA signature
         		16-byte plugin version in UTF-8, padded with trailing zeroes if necessary
         
         	Zip file containing the following:
        @@ -74,7 +74,7 @@ foo.xpi2p is a sud file containing the following:
         			*name (will be installed in this directory name)
         				For native plugins, you may want separate names in different packages -
         				foo-windows and foo-linux, for example
        -			*key (DSA public key as 172 B64 chars ending with '=')
        +			*key (DSA public key as 172 B64 chars ending with '=')
         			*signer (yourname@mail.i2p recommended)
         
         			*version (must be in a format VersionComparator can parse, e.g. 1.2.3-4)
        diff --git a/www.i2p2/pages/tunnel_message_spec.html b/i2p2www/pages/site/docs/specs/tunnel_message.html
        similarity index 96%
        rename from www.i2p2/pages/tunnel_message_spec.html
        rename to i2p2www/pages/site/docs/specs/tunnel_message.html
        index 3dbc8881..85a31dce 100644
        --- a/www.i2p2/pages/tunnel_message_spec.html
        +++ b/i2p2www/pages/site/docs/specs/tunnel_message.html
        @@ -1,4 +1,4 @@
        -{% extends "_layout.html" %}
        +{% extends "global/layout.html" %}
         {% block title %}Tunnel Message Specification{% endblock %}
         {% block content %}
         
        @@ -166,11 +166,11 @@ set, this is a follow on fragment.

        Note that Delivery Instructions are also used inside -Garlic Cloves, +Garlic Cloves, where the format is slightly different. In a Garlic Clove, messages are not fragmented, and the fragment bit in the flag byte is redefined. See the -Garlic Clove documentation +Garlic Clove documentation for more details. @@ -238,7 +238,7 @@ Message ID: 4 bytes Optional, present if this message is the first of 2 or more fragments An ID that uniquely identifies all fragments as belonging to a single message - (the current implementation uses the I2NP Message ID) + (the current implementation uses the I2NP Message ID) Extended Options: 2 or more bytes