update language on BOB and SAMv3 pages

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

@@ -1,43 +1,31 @@
 {% extends "global/layout.html" %}
 {% block title %}{{ _('BOB - Basic Open Bridge') }}{% endblock %}
-{% block lastupdated %}{% trans %}August 2016{% endtrans %}{% endblock %}
+{% block lastupdated %}{% trans %}June 2019{% endtrans %}{% endblock %}
 {% block content %}
 <h2>Language libraries for the BOB API</h2>
 <ul>
 <li>Go - <a href="https://bitbucket.org/kallevedin/ccondom">ccondom</a></li>
 <li>Python - <a href="http://{{ i2pconv('git.repo.i2p') }}/w/i2py-bob.git">i2py-bob</a></li>
 <li>Twisted - <a href="https://pypi.python.org/pypi/txi2p">txi2p</a></li>
+<li>C++ - <a href="https://gitlab.com/rszibele/bobcpp">bobcpp</a></n></li>
 </ul>
 
-<h2>{% trans %}Technical differences from SAM (for the better?){% endtrans %}</h2>
+<h2>{% trans %}Technical differences from SAMv3{% endtrans %}</h2>
 
 <p>{% trans -%}
-BOB has separate command and data channels. 
+At this point, most of the good ideas from BOB have been incorporated into
-One, an application command channel socket to router to configure.
+SAMv3, which has more features and more real-world use. BOB still works, but it
-Two, the application data sockets to/from router that carry only data.
+is not gaining the advanced features available to SAMv3 and is essentially
-The command channel is only needed for making or setting the initial
+unsupported at this time.
-destination key, and to set the destination key to port bindings. 
-All connections run in parallel.
 {%- endtrans %}</p>
 
-<p>{% trans -%}
+<p>
-SAM has one connection that does everything, and you need to parse every packet.
+Alternatives:
-{%- endtrans %}</p>
+<a href="{{ site_url('docs/api/samv3') }}">SAM V3</a>.
-
+Older versions:
-<p>{% trans -%}
+<a href="{{ site_url('docs/api/sam') }}">SAM V1</a>,
-BOB does not hold keypair values, nor does the router.
+<a href="{{ site_url('docs/api/samv2') }}">SAM V2</a>,
-Your application holds the keypair values. 
+</p>
-This is to reduce any extra complexity in the router code, it also adds to
-your privacy.
-{%- endtrans %}</p>
-
-<p>{% trans -%}
-SAM router stores every keypair you ever make.
-{%- endtrans %}</p>
-
-<p>{% trans -%}
-Those are the important differences.
-{%- endtrans %}</p>
 
 <h2>{% trans %}Overview{% endtrans %}</h2>
 
@@ -105,8 +93,8 @@ Version history
 
 <p>{% trans -%}
 <b>PLEASE NOTE:</b>
-For CURRENT details on the commands PLEASE use the built-in help command. 
+For CURRENT details on the commands PLEASE use the built-in help command.
-Just telnet to localhost 2827 and type help and you can get full documentation on each command. 
+Just telnet to localhost 2827 and type help and you can get full documentation on each command.
 {%- endtrans %}</p>
 
 <p>{% trans -%}
@@ -143,20 +131,20 @@ zap                                             nothing, quits BOB
 {% endhighlight %}
 
 <p>{% trans -%}
-Once set up, all TCP sockets can and will block as needed, and there is no need for any 
+Once set up, all TCP sockets can and will block as needed, and there is no need for any
 additional messages to/from the command channel. This allows the router to pace the
-stream without exploding with OOM like SAM does as it chokes on attempting to shove 
+stream without exploding with OOM like SAM does as it chokes on attempting to shove
 many streams in or out one socket -- that can't scale when you have alot of connections!
 {%- endtrans %}</p>
 
 <p>{% trans -%}
-What is also nice about this particular interface is that writing anything to interface 
+What is also nice about this particular interface is that writing anything to interface
 to it, is much much easier than SAM. There is no other processing to do after the set up.
-It's configuration is so simple, that very simple tools, such as nc (netcat) can be used 
+It's configuration is so simple, that very simple tools, such as nc (netcat) can be used
-to point to some application. The value there is that one could schedule up and down times 
+to point to some application. The value there is that one could schedule up and down times
-for an application, and not have to change the application to do that, or to even have 
+for an application, and not have to change the application to do that, or to even have
-to stop that application. Instead, you can literally "unplug" the destination, and 
+to stop that application. Instead, you can literally "unplug" the destination, and
-"plug it in" again. As long as the same IP/port addresses and destination keys are used 
+"plug it in" again. As long as the same IP/port addresses and destination keys are used
 when bringing the bridge up, the normal TCP application won't care, and won't notice.
 It will simply be fooled -- the destinations are not reachable, and that nothing is coming in.
 {%- endtrans %}</p>
@@ -164,8 +152,8 @@ It will simply be fooled -- the destinations are not reachable, and that nothing
 <h2>{% trans %}Examples{% endtrans %}</h2>
 
 <p>{% trans -%}
-For the following example, we'll setup a very simple local loopback connection, 
+For the following example, we'll setup a very simple local loopback connection,
-with two destinations. Destination "mouth" will be the CHARGEN service from 
+with two destinations. Destination "mouth" will be the CHARGEN service from
 the INET superserver daemon. Destination "ear" will be a local port that you
 can telnet into, and watch the pretty ASCII test puke forth.
 {%- endtrans %}</p>
@@ -199,8 +187,8 @@ C       A     OK tunnel starting
 {% endhighlight %}
 
 <p>{% trans -%}
-At this point, there was no error, a destination with a nickname of "mouth" 
+At this point, there was no error, a destination with a nickname of "mouth"
-is set up. When you contact the destination provided, you actually connect 
+is set up. When you contact the destination provided, you actually connect
 to the <code>CHARGEN</code> service on <code>19/TCP</code>.
 {%- endtrans %}</p>
 
@@ -304,9 +292,9 @@ $
 {% endhighlight %}
 
 <p>{% trans -%}
-Pretty cool isn't it? Try some other well known EEPSITES if you like, nonexistent ones, 
+Pretty cool isn't it? Try some other well known EEPSITES if you like, nonexistent ones,
-etc, to get a feel for what kind of output to expect in different situations. 
+etc, to get a feel for what kind of output to expect in different situations.
-For the most part, it is suggested that you ignore any of the error messages. 
+For the most part, it is suggested that you ignore any of the error messages.
 They would be meaningless to the application, and are only presented for human debugging.
 {%- endtrans %}</p>
 

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

@@ -1,6 +1,6 @@
 {% extends "global/layout.html" %}
 {% block title %}SAM V3{% endblock %}
-{% block lastupdated %}February 2019{% endblock %}
+{% block lastupdated %}June 2019{% endblock %}
 {% block accuratefor %}0.9.39{% endblock %}
 {% block content %}
 <p>Specified below is a simple client protocol for interacting with I2P.
@@ -8,9 +8,10 @@
 <p>SAM version 3
 was introduced in I2P release 0.7.3.
 Alternatives:
+<a href="{{ site_url('docs/api/bob') }}">BOB(unsupported)</a>.
+Older 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/bob') }}">BOB</a>.
 </p>
 
 <h2>Version 3 Language Libraries</h2>
@@ -19,10 +20,15 @@ Alternatives:
 <li>C++ - <a href="https://github.com/i2p/i2psam">i2psam</a></li>
 <li>Go - <a href="https://bitbucket.org/kallevedin/sam3">sam3</a>,
          <a href="https://github.com/cryptix/goSam">goSam</a> (<a href="http://git.repo.i2p/w/goSam.git">in I2P</a>)</li>
+<li>Haskell - <a href="https://github.com/solatis/haskell-network-anonymous-i2p">haskell-network-anonymous-i2p</a></li>
+<li>.NET - <a href="https://github.com/SamuelFisher/i2pdotnet">i2pdotnet</a></li>
 <li>Nodejs - <a href="https://github.com/redhog/node-i2p">node-i2p</a></li>
+<li>Java - <a href="https://github.com/eyedeekay/Jsam">Jsam</a></li>
 <li>Python - <a href="https://github.com/l-n-s/i2plib">i2plib</a>,
     <a href="https://github.com/majestrate/i2p.socket">i2p.socket</a>,
     <a href="https://github.com/str4d/txi2p">txi2p</a></li>
+<li>Ruby - <a href="https://github.com/dryruby/i2p.rb">and i2p.rb for ruby</a></li>
+<li>Rust - <a href="https://github.com/stallmanifold/rust-i2p">rust-i2p</a></li>
 </ul>
 
 <h2>Version 3 Changes</h2>
@@ -120,7 +126,7 @@ Version 3.3 was introduced in I2P release 0.9.25.
 <h3>Simple Anonymous Messaging (SAM) Version 3.3 Specification Overview</h3>
 <p>
 The client application talks to the SAM bridge, which deals with
-all of the I2P functionality (using the streaming 
+all of the I2P functionality (using the streaming
 library for virtual streams, or I2CP directly for datagrams).
 
 </p><p>
@@ -160,7 +166,7 @@ Any UTF8-encoded keys or values should work.
 The formatting shown in this specification
 below is merely for readability, and while the first two words in
 each message must stay in their specific order, the ordering of
-the key=value pairs can change (e.g. "ONE TWO A=B C=D" or 
+the key=value pairs can change (e.g. "ONE TWO A=B C=D" or
 "ONE TWO C=D A=B" are both perfectly valid constructions).
 In addition, the protocol is case-sensitive.
 In the following, message examples are preceded by "-&gt; " for
@@ -208,12 +214,12 @@ Do not map keys or values to upper case, as this would corrupt I2CP options.
 </p>
 
 
-  
+
 <h3>SAM Connection Handshake</h3>
 <p>
 No SAM communication can occur until after the client and bridge have
 agreed on a protocol version, which is done by the client sending
-a HELLO and the bridge sending a HELLO REPLY: 
+a HELLO and the bridge sending a HELLO REPLY:
 <pre>
 -&gt;  HELLO VERSION
           [MIN=$min]            # Optional as of SAM 3.1, required for 3.0 and earlier
@@ -300,8 +306,8 @@ See the I2CP specification for more information.
 
 <h3>SAM Sessions</h3>
 <p>
-A SAM session is created by a client opening a socket to the SAM 
+A SAM session is created by a client opening a socket to the SAM
-bridge, operating a handshake, and sending a SESSION CREATE message, 
+bridge, operating a handshake, and sending a SESSION CREATE message,
 and the session terminates when the socket is disconnected.
 
 </p><p>
@@ -319,11 +325,11 @@ its ID (or nickname)
 
 <h4>Session Creation Request</h4>
 <p>
-The session creation message can only use one of these forms (messages 
+The session creation message can only use one of these forms (messages
 received through other forms are answered with an error message) :
 
 <pre>
--&gt;  SESSION CREATE 
+-&gt;  SESSION CREATE
           STYLE={STREAM,DATAGRAM,RAW}
           ID=$nickname
           DESTINATION={$privkey,TRANSIENT}
@@ -338,7 +344,7 @@ received through other forms are answered with an error message) :
 </pre>
 
 </p><p>
-DESTINATION specifies what destination should be used for 
+DESTINATION specifies what destination should be used for
 sending and receiving messages/streams.
 The $privkey is the base 64 of the concatenation of the <a href="{{ site_url('docs/spec/common-structures') }}#type_Destination">Destination</a>
 followed by the <a href="{{ site_url('docs/spec/common-structures') }}#type_PrivateKey">Private Key</a>
@@ -380,14 +386,14 @@ The default is DSA_SHA1.
 $nickname is the choice of the client. No whitespace is allowed.
 
 </p><p>
-Additional options given are passed to the I2P session 
+Additional options given are passed to the I2P session
-configuration if not interpreted by the SAM bridge (e.g. 
+configuration if not interpreted by the SAM bridge (e.g.
 outbound.length=0). These options <a href="#options">are documented below</a>.
 
 </p><p>
-The SAM bridge itself should already be configured with what router 
+The SAM bridge itself should already be configured with what router
 it should communicate over I2P through (though if need be there may
-be a way to provide an override, e.g. i2cp.tcp.host=localhost and 
+be a way to provide an override, e.g. i2cp.tcp.host=localhost and
 i2cp.tcp.port=7654).
 </p>
 
@@ -461,7 +467,7 @@ failure and success notification as soon as it is available.
 
 </p><p>
 Streams are bidirectional communication sockets between two I2P
-destinations, but their opening has to be requested by one of them. 
+destinations, but their opening has to be requested by one of them.
 Hereafter, CONNECT commands are used by the SAM client for such a
 request. FORWARD / ACCEPT commands are used by the SAM client when
 he wants to listen to requests coming from other I2P destinations.
@@ -477,7 +483,7 @@ opening a new socket with the SAM bridge
 </li><li>
 passing the same HELLO handshake as above
 </li><li>
-sending the STREAM CONNECT command  
+sending the STREAM CONNECT command
 </li></ul>
 
 <h4>Connect Request</h4>
@@ -515,7 +521,7 @@ last message to its client before forwarding or shutting down the
 socket:
 
 <pre>
-&lt;-  STREAM STATUS 
+&lt;-  STREAM STATUS
          RESULT=$result
          [MESSAGE=...]
 </pre>
@@ -550,7 +556,7 @@ opening a new socket with the SAM bridge
 </li><li>
 passing the same HELLO handshake as above
 </li><li>
-sending the STREAM ACCEPT command  
+sending the STREAM ACCEPT command
 </li></ul>
 
 <h4>Accept Request</h4>
@@ -577,7 +583,7 @@ If SILENT=true is passed, the SAM bridge won't issue any other message
 on the socket. If the accept fails, the socket will be closed.
 If the accept succeeds, all remaining data passing through the
 current socket is forwarded from and to the connected I2P destination
-peer. 
+peer.
 For reliability, and to receive the destination for incoming connections,
 SILENT=false is recommended.
 
@@ -587,7 +593,7 @@ If SILENT=false, which is the default value,
 the SAM bridge answers with:
 
 <pre>
-&lt;-  STREAM STATUS 
+&lt;-  STREAM STATUS
          RESULT=$result
          [MESSAGE=...]
 </pre>
@@ -625,7 +631,7 @@ of the requesting peer, and additional information for SAM 3.2 only:
     \n
 </pre>
 
-After this '\n' terminated line, all remaining data 
+After this '\n' terminated line, all remaining data
 passing through the current socket is forwarded from and to the connected
 I2P destination peer, until one of the peer closes the socket.
 </p>
@@ -670,7 +676,7 @@ when SILENT=true.
 The STREAM STATUS message is:
 
 <pre>
-&lt;-  STREAM STATUS 
+&lt;-  STREAM STATUS
          RESULT=$result
          [MESSAGE=...]
 </pre>
@@ -716,7 +722,7 @@ destination key of the requesting peer, and additional information for SAM 3.2 o
 </pre>
 
 After this '\n' terminated line,
-all remaining data passing through the socket is forwarded from and to 
+all remaining data passing through the socket is forwarded from and to
 the connected I2P destination peer, until one of the sides closes the
 socket.
 
@@ -735,9 +741,9 @@ soon as the "forwarding" socket is closed.
 <p>
 While I2P doesn't inherently contain a FROM address, for ease of use
 an additional layer is provided as repliable datagrams - unordered
-and unreliable messages of up to 31744 bytes that include a FROM 
+and unreliable messages of up to 31744 bytes that include a FROM
-address (leaving up to 1KB for header material).  This FROM address 
+address (leaving up to 1KB for header material).  This FROM address
-is authenticated internally by SAM (making use of the destination's 
+is authenticated internally by SAM (making use of the destination's
 signing key to verify the source) and includes replay prevention.
 
 </p><p>
@@ -829,7 +835,7 @@ depending on signature type.
 
 </p><p>
 The SAM bridge never exposes to the client the authentication headers
-or other fields, merely the data that the sender provided.  This 
+or other fields, merely the data that the sender provided.  This
 continues until the session is closed (by the client dropping the
 connection).
 
@@ -840,7 +846,7 @@ incoming messages to a specified ip:port. It does so by issuing the
 CREATE command with PORT and HOST options:
 
 <pre>
--&gt; SESSION CREATE 
+-&gt; SESSION CREATE
           STYLE={DATAGRAM,RAW}
           ID=$nickname
           DESTINATION={$privkey,TRANSIENT}
@@ -877,8 +883,8 @@ See the SESSION CREATE section above for details.
  in the v1/v2-compatible way.
 
 </p><p>
-Additional options given are passed to the I2P session 
+Additional options given are passed to the I2P session
-configuration if not interpreted by the SAM bridge (e.g. 
+configuration if not interpreted by the SAM bridge (e.g.
 outbound.length=0). These options <a href="#options">are documented below</a>.
 
 </p><p>
@@ -926,8 +932,8 @@ depending on signature type.
 <h3>SAM Anonymous (Raw) Datagrams</h3>
 <p>
 Squeezing the most out of I2P's bandwidth, SAM allows clients to send
-and receive anonymous datagrams, leaving authentication and reply 
+and receive anonymous datagrams, leaving authentication and reply
-information up to the client themselves.  These datagrams are 
+information up to the client themselves.  These datagrams are
 unreliable and unordered, and may be up to 32768 bytes.
 
 </p><p>
@@ -960,7 +966,7 @@ command. This is the v1/v2-compatible way of receiving datagrams.
 
 </p><p>
 When anonymous datagrams are to be forwarded to some host:port,
-the bridge sends to the specified host:port a message containing 
+the bridge sends to the specified host:port a message containing
 the following data:
 
 <pre>
@@ -1038,7 +1044,7 @@ for DHT communication.
 <h4>Creating a MASTER Session</h4>
 
 <pre>
--&gt;  SESSION CREATE 
+-&gt;  SESSION CREATE
           STYLE=MASTER
           ID=$nickname
           DESTINATION={$privkey,TRANSIENT}
@@ -1157,7 +1163,7 @@ The following message can be used by the client to query the SAM
 bridge for name resolution:
 
 <pre>
- NAMING LOOKUP 
+ NAMING LOOKUP
         NAME=$name
 </pre>
 
@@ -1165,9 +1171,9 @@ bridge for name resolution:
 which is answered by
 
 <pre>
- NAMING REPLY 
+ NAMING REPLY
         RESULT=$result
-        NAME=$name 
+        NAME=$name
         [VALUE=$destination]
         [MESSAGE=$message]
 </pre>

i2p2www/static/styles/duck/desktop.css

@@ -272,10 +272,6 @@ div#content .aside:first-child {
  * The .inner class is for the content wrapper on inner pages (as opposed to the home page)
  */
 
-.fluid img {
-    max-width: 100%;
-}
-
 div#content .inner .fluid {
     background-repeat: repeat-y;
     border-left: 1px solid #abcc71;