kytv/I2P_Website
1
0
Fork 0
forked from I2P_Developers/i2p.www
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Added translation tags to get-involved/develop/* and get-involved/*.html

Browse Source
This commit is contained in:
str4d
2013-01-20 03:24:37 +00:00
parent af00580342
commit 637123d387
10 changed files with 924 additions and 666 deletions
Download Patch File Download Diff File Expand all files Collapse all files

442
i2p2www/pages/site/get-involved/develop/applications.html
View File

@@ -1,120 +1,130 @@
{% extends "global/layout.html" %}
{% block title %}Application Development{% endblock %}
{% block title %}{{ _('Application Development') }}{% endblock %}
{% block content %}
<h1>Application Development Guide</h1>
<h1>{{ _('Application Development Guide') }}</h1>
<h2>Contents</h2>
<h2>{{ _('Contents') }}</h2>
<ul>
<li><a href="#why">Why write I2P-specific code?</a></li>
<li><a href="#concepts">Important concepts</a></li>
<li><a href="#options">Development options</a></li>
<li><a href="#start"><b>Start developing - a simple guide</b></a></li>
<li><a href="#why">{{ _('Why write I2P-specific code?') }}</a></li>
<li><a href="#concepts">{{ _('Important concepts') }}</a></li>
<li><a href="#options">{{ _('Development options') }}</a></li>
<li><a href="#start"><b>{{ _('Start developing - a simple guide') }}</b></a></li>
</ul>
<h2 id="why">Why write I2P-specific code?</h2>
<h2 id="why">{{ _('Why write I2P-specific code?') }}</h2>
<p>
There are multiple ways to use applications in I2P.
Using <a href="/i2ptunnel.html">I2PTunnel</a>,
you can use regular applications without needing to program explicit I2P support.
This is very effective for client-server scenario's,
where you need to connect to a single website.
You can simply create a tunnel using I2PTunnel to connect to that website, as shown in <a href="#tunnel.serverclient">Figure 1</a>.
</p>
<p>
If your application is distributed, it will require connections to a large amount of peers.
Using I2PTunnel, you will need to create a new tunnel for each peer you want to contact,
as shown in <a href="#tunnel.peertopeer">Figure 2</a>.
This process can of course be automated, but running a lot of I2PTunnel instances creates a large amount of overhead.
In addition, with many protocols you will need to force everyone to
use the same set of ports for all peers - e.g. if you want to reliably run DCC
chat, everyone needs to agree that port 10001 is Alice, port 10002 is Bob, port
10003 is Charlie, and so on, since the protocol includes TCP/IP specific information
(host and port).
</p>
<p>
General network applications often send a lot of additional data that could be used to identify users.
Hostnames, port numbers, time zones, character sets, etc. are often sent without informing the user.
As such, designing the network protocol specifically with anonymity in mind
can avoid compromising user identities.
</p>
<p>
There are also efficiency considerations to review when determining how to
interact on top of I2P. The streaming library and things built on top of it
operate with handshakes similar to TCP, while the core I2P protocols (I2NP and I2CP)
are strictly message based (like UDP or in some instances raw IP). The important
distinction is that with I2P, communication is operating over a long fat network -
each end to end message will have nontrivial latencies, but may contain payloads
of up to 32KB. An application that needs a simple request and response can get rid
of any state and drop the latency incurred by the startup and teardown handshakes
by using (best effort) datagrams without having to worry about MTU detection or
fragmentation of messages under 32KB.
</p>
<p>{% trans i2ptunnel=site_url('docs/api/i2ptunnel') -%}
There are multiple ways to use applications in I2P.
Using <a href="{{ i2ptunnel }}">I2PTunnel</a>,
you can use regular applications without needing to program explicit I2P support.
This is very effective for client-server scenario's,
where you need to connect to a single website.
You can simply create a tunnel using I2PTunnel to connect to that website, as shown in <a href="#tunnel.serverclient">Figure 1</a>.
{%- endtrans %}</p>
<p>{% trans -%}
If your application is distributed, it will require connections to a large amount of peers.
Using I2PTunnel, you will need to create a new tunnel for each peer you want to contact,
as shown in <a href="#tunnel.peertopeer">Figure 2</a>.
This process can of course be automated, but running a lot of I2PTunnel instances creates a large amount of overhead.
In addition, with many protocols you will need to force everyone to
use the same set of ports for all peers - e.g. if you want to reliably run DCC
chat, everyone needs to agree that port 10001 is Alice, port 10002 is Bob, port
10003 is Charlie, and so on, since the protocol includes TCP/IP specific information
(host and port).
{%- endtrans %}</p>
<p>{% trans -%}
General network applications often send a lot of additional data that could be used to identify users.
Hostnames, port numbers, time zones, character sets, etc. are often sent without informing the user.
As such, designing the network protocol specifically with anonymity in mind
can avoid compromising user identities.
{%- endtrans %}</p>
<p>{% trans -%}
There are also efficiency considerations to review when determining how to
interact on top of I2P. The streaming library and things built on top of it
operate with handshakes similar to TCP, while the core I2P protocols (I2NP and I2CP)
are strictly message based (like UDP or in some instances raw IP). The important
distinction is that with I2P, communication is operating over a long fat network -
each end to end message will have nontrivial latencies, but may contain payloads
of up to 32KB. An application that needs a simple request and response can get rid
of any state and drop the latency incurred by the startup and teardown handshakes
by using (best effort) datagrams without having to worry about MTU detection or
fragmentation of messages under 32KB.
{%- endtrans %}</p>
<div class="box" id="tunnel.serverclient" style="text-align:center">
<img src="{{ url_for('static', filename='images/i2ptunnel_serverclient.png') }}" alt="Creating a server-client connection using I2PTunnel only requires creating a single tunnel." title="Creating a server-client connection using I2PTunnel only requires creating a single tunnel." />
<img src="{{ url_for('static', filename='images/i2ptunnel_serverclient.png') }}" alt="{{ _('Creating a server-client connection using I2PTunnel only requires creating a single tunnel.') }}" title="{{ _('Creating a server-client connection using I2PTunnel only requires creating a single tunnel.') }}" />
<br /><br />
Figure 1: Creating a server-client connection using I2PTunnel only requires creating a single tunnel.
{{ _('Figure 1:') }} {{ _('Creating a server-client connection using I2PTunnel only requires creating a single tunnel.') }}
</div>
<br/>
<div class="box" id="tunnel.peertopeer" style="text-align:center">
<img src="{{ url_for('static', filename='images/i2ptunnel_peertopeer.png') }}" alt="Setting up connections for a peer-to-peer applications requires a very large amount of tunnels." title="Setting up connections for a peer-to-peer applications requires a very large amount of tunnels." />
<img src="{{ url_for('static', filename='images/i2ptunnel_peertopeer.png') }}" alt="{{ _('Setting up connections for a peer-to-peer applications requires a very large amount of tunnels.') }}" title="{{ _('Setting up connections for a peer-to-peer applications requires a very large amount of tunnels.') }}" />
<br /><br />
Figure 2: Setting up connections for a peer-to-peer applications requires a very large amount of tunnels.
{{ _('Figure 2:') }} {{ _('Setting up connections for a peer-to-peer applications requires a very large amount of tunnels.') }}
</div>
<br/>
In summary, a number of reasons to write I2P-specific code:
<ul>
<li>
Creating a large amount of I2PTunnel instances consumes a non-trivial amount of resources,
which is problematic for distributed applications (a new tunnel is required for each peer).
</li>
<li>
General network protocols often send a lot of additional data that can be used to identify users.
Programming specifically for I2P allows the creation of a network protocol
that does not leak such information, keeping users anonymous and secure.
</li>
<li>
Network protocols designed for use on the regular internet can be inefficient
on I2P, which is a network with a much higher latency.
</li>
</ul>
{% trans -%}
In summary, a number of reasons to write I2P-specific code:
{%- endtrans %}
<ul>
<li>{% trans -%}
Creating a large amount of I2PTunnel instances consumes a non-trivial amount of resources,
which is problematic for distributed applications (a new tunnel is required for each peer).
{%- endtrans %}</li>
<li>{% trans -%}
General network protocols often send a lot of additional data that can be used to identify users.
Programming specifically for I2P allows the creation of a network protocol
that does not leak such information, keeping users anonymous and secure.
{%- endtrans %}</li>
<li>{% trans -%}
Network protocols designed for use on the regular internet can be inefficient
on I2P, which is a network with a much higher latency.
{%- endtrans %}</li>
</ul>
<p>
Applications written in Java and accessible/runnable
using an HTML interface via the standard webapps/app.war
may be considered for inclusion in the i2p distribution.
</p>
<p>{% trans -%}
Applications written in Java and accessible/runnable
using an HTML interface via the standard webapps/app.war
may be considered for inclusion in the i2p distribution.
{%- endtrans %}</p>
<h2 id="concepts">Important concepts</h2>
<h2 id="concepts">{{ _('Important concepts') }}</h2>
<p>There are a few changes that require adjusting to when using I2P:</p>
<p>{% trans -%}
There are a few changes that require adjusting to when using I2P:
{%- endtrans %}</p>
<h3>Destination ~= host+port</h3>
<h3>{{ _('Destination ~= host+port') }}</h3>
<p>An application running on I2P sends messages from and receives messages to a
<p>{% trans -%}
An application running on I2P sends messages from and receives messages to a
unique cryptographically secure end point - a "destination". In TCP or UDP
terms, a destination could (largely) be considered the equivalent of a hostname
plus port number pair, though there are a few differences. </p>
plus port number pair, though there are a few differences.
{%- endtrans %}</p>
<ul>
<li>An I2P destination itself is a cryptographic construct - all data sent to one is
<li>{% trans -%}
An I2P destination itself is a cryptographic construct - all data sent to one is
encrypted as if there were universal deployment of IPsec with the (anonymized)
location of the end point signed as if there were universal deployment of DNSSEC. </li>
<li>I2P destinations are mobile identifiers - they can be moved from one I2P router
location of the end point signed as if there were universal deployment of DNSSEC.
{%- endtrans %}</li>
<li>{% trans -%}
I2P destinations are mobile identifiers - they can be moved from one I2P router
to another (or with some special software, it can even operate on multiple routers at
once). This is quite different from the TCP or UDP world where a single end point (port)
must stay on a single host.</li>
must stay on a single host.
{%- endtrans %}</li>
<li>
<p>
<p>{% trans -%}
I2P destinations are ugly and large - behind the scenes, they contain a 2048bit ElGamal
public key for encryption, a 1024bit DSA public key for signing, and a variable size
certificate, which may contain proof of work or blinded data.
</p>
<p>
{%- endtrans %}</p>
<p>{% trans naming=site_url('docs/naming') -%}
There are existing ways to refer to these large and ugly destinations by short
and pretty names (e.g. "irc.duck.i2p"), but at the moment those techniques do not guarantee
globally uniqueness (since they're stored locally at each person's machine as "hosts.txt")
@@ -123,146 +133,174 @@ manually managed within Monotone, and as such, anyone with commit rights on the
change the destinations). There may be some secure, human readable, scalable, and globally
unique, naming system some day, but applications shouldn't depend upon it being in place,
since there are those who don't think such a beast is possible.
<a href="naming.html">Further information on the naming system</a> is available.
</p>
<a href="{{ naming }}">Further information on the naming system</a> is available.
{%- endtrans %}</p>
</li>
</ul>
<h3>Anonymity and confidentiality</h3>
<h3>{{ _('Anonymity and confidentiality') }}</h3>
<p>A useful thing to remember is that I2P has transparent end to end encryption
<p>{% trans -%}
A useful thing to remember is that I2P has transparent end to end encryption
and authentication for all data passed over the network - if Bob sends to Alice's destination,
only Alice's destination can receive it, and if Bob is using the datagrams or streaming
library, Alice knows for certain that Bob's destination is the one who sent the data. </p>
library, Alice knows for certain that Bob's destination is the one who sent the data.
{%- endtrans %}</p>
<p>Of course, another useful thing to remember is that I2P transparently anonymizes the
<p>{% trans -%}
Of course, another useful thing to remember is that I2P transparently anonymizes the
data sent between Alice and Bob, but it does nothing to anonymize the content of what they
send. For instance, if Alice sends Bob a form with her full name, government IDs, and
credit card numbers, there is nothing I2P can do. As such, protocols and applications should
keep in mind what information they are trying to protect and what information they are willing
to expose.</p>
to expose.
{%- endtrans %}</p>
<h3>I2P datagrams can be up to 32KB</h3>
<h3>{{ _('I2P datagrams can be up to 32KB') }}</h3>
<p>Applications that use I2P datagrams (either raw or repliable ones) can essentially be thought
<p>{% trans -%}
Applications that use I2P datagrams (either raw or repliable ones) can essentially be thought
of in terms of UDP - the datagrams are unordered, best effort, and connectionless - but unlike
UDP, applications don't need to worry about MTU detection and can simply fire off 32KB datagrams
(31KB when using the repliable kind). For many applications, 32KB of data is sufficient for an
entire request or response, allowing them to transparently operate in I2P as a UDP-like
application without having to write fragmentation, resends, etc.</p>
application without having to write fragmentation, resends, etc.
{%- endtrans %}</p>
<h2 id="options">Development options</h2>
<h2 id="options">{{ _('Development options') }}</h2>
<p>There are several means of sending data over I2P, each with their own pros and cons.
<p>{% trans -%}
There are several means of sending data over I2P, each with their own pros and cons.
The streaming lib is the recommended interface, used by the majority of I2P applications.
</p>
{%- endtrans %}</p>
<h3>Streaming Lib</h3>
<p>
The <a href="streaming.html">full streaming library</a> is now the standard
<h3>{{ _('Streaming Lib') }}</h3>
<p>{% trans streaming=site_url('docs/api/streaming') -%}
The <a href="{{ streaming }}">full streaming library</a> is now the standard
interface. It allows programming using TCP-like sockets, as explained in the <a href="#start.streaming">Streaming development guide</a>.
</p>
{%- endtrans %}</p>
<h3>BOB</h3>
<p>BOB is the <a href="BOB.html">Basic Open Bridge</a>,
<p>{% trans bob=site_url('docs/api/bob'), boburl=i2pconv('bob.i2p') -%}
BOB is the <a href="{{ bob }}">Basic Open Bridge</a>,
allowing an application in any language to make streaming connections
to and from I2P. At this point in time it lacks UDP support, but UDP support
is planned in the near future. BOB also contains several tools, such as
destination key generation, and verification that an address conforms to
I2P specifications. Up to date info and applications that use BOB can be
found at this <a href="http://{{ i2pconv('bob.i2p') }}/">eepsite</a>.</p>
found at this <a href="http://{{ boburl }}/">eepsite</a>.
{%- endtrans %}</p>
<h3>SAM, SAM V2, SAM V3</h3>
<p><i>SAM is not recommended. SAM V2 is okay, SAM V3 is beta.</i></p>
<p>SAM is the <a href="sam">Simple Anonymous Messaging</a> protocol, allowing an
<p><i>{{ _('SAM is not recommended. SAM V2 is okay, SAM V3 is beta.') }}</i></p>
<p>{% trans sam=site_url('docs/api/sam') -%}
SAM is the <a href="{{ sam }}">Simple Anonymous Messaging</a> protocol, allowing an
application written in any language to talk to a SAM bridge through a plain TCP socket and have
that bridge multiplex all of its I2P traffic, transparently coordinating the encryption/decryption
and event based handling. SAM supports three styles of operation:</p>
and event based handling. SAM supports three styles of operation:
{%- endtrans %}</p>
<ul>
<li>streams, for when Alice and Bob want to send data to each other reliably and in order</li>
<li>repliable datagrams, for when Alice wants to send Bob a message that Bob can reply to</li>
<li>raw datagrams, for when Alice wants to squeeze the most bandwidth and performance as possible,
and Bob doesn't care whether the data's sender is authenticated or not (e.g. the data transferred
is self authenticating)</li>
<li>{% trans -%}
streams, for when Alice and Bob want to send data to each other reliably and in order
{%- endtrans %}</li>
<li>{% trans -%}
repliable datagrams, for when Alice wants to send Bob a message that Bob can reply to
{%- endtrans %}</li>
<li>{% trans -%}
raw datagrams, for when Alice wants to squeeze the most bandwidth and performance as possible,
and Bob doesn't care whether the data's sender is authenticated or not (e.g. the data transferred
is self authenticating)
{%- endtrans %}</li>
</ul>
<p>SAM V3 aims at the same goal as SAM and SAM V2, but does not require
<p>{% trans -%}
SAM V3 aims at the same goal as SAM and SAM V2, but does not require
multiplexing/demultiplexing. Each I2P stream is handled by its own socket between the application
and the SAM bridge. Besides, datagrams can be sent and received by the application through datagram
communications with the SAM bridge.
{%- endtrans %}</p>
</p>
<p>
<a href="samv2.html">SAM V2</a> is a new version used by imule
that fixes some of the problems in <a href="sam.html">SAM</a>.
<p>{% trans sam=site_url('docs/api/sam'), samv2=site_url('docs/api/samv2'), samv3=site_url('docs/api/samv3') -%}
<a href="{{ samv2 }}">SAM V2</a> is a new version used by imule
that fixes some of the problems in <a href="{{ sam }}">SAM</a>.
<br />
<a href="samv3.html">SAM V3</a> is used by imule since version 1.4.0.
</p>
<a href="{{ samv3 }}">SAM V3</a> is used by imule since version 1.4.0.
{%- endtrans %}</p>
<h3>I2PTunnel</h3>
<p>The I2PTunnel application allows applications to build specific TCP-like tunnels to peers
<p>{% trans -%}
The I2PTunnel application allows applications to build specific TCP-like tunnels to peers
by creating either I2PTunnel 'client' applications (which listen on a specific port and connect
to a specific I2P destination whenever a socket to that port is opened) or I2PTunnel 'server'
applications (which listen to a specific I2P destination and whenever it gets a new I2P
connection it outproxies to a specific TCP host/port). These streams are 8bit clean and are
authenticated and secured through the same streaming library that SAM uses, but there is a
nontrivial overhead involved with creating multiple unique I2PTunnel instances, since each have
their own unique I2P destination and their own set of tunnels, keys, etc.</p>
their own unique I2P destination and their own set of tunnels, keys, etc.
{%- endtrans %}</p>
<h3>Ministreaming</h3>
<p><i>Not recommended</i></p>
<p>
<p><i>{{ _('Not recommended') }}</i></p>
<p>{% trans -%}
It was possible to write I2P applications in Java using the ministreaming library.
However, the Streaming library has superceded this, and provides better functionality.
</p>
{%- endtrans %}</p>
<h3>Datagrams</h3>
<p><i>Not recommended</i></p>
The <a href="datagrams">Datagram library</a> allows sending UDP-like packets.
<h3>{{ _('Datagrams') }}</h3>
<p><i>{{ _('Not recommended') }}</i></p>
<p>{% trans datagrams=site_url('docs/spec/datagrams') -%}
The <a href="{{ datagrams }}">Datagram library</a> allows sending UDP-like packets.
It's possible to use:
{%- endtrans %}</p>
<ul>
<li>Repliable datagrams</li>
<li>Raw datagrams</li>
<li>{{ _('Repliable datagrams') }}</li>
<li>{{ _('Raw datagrams') }}</li>
</ul>
<h3>I2CP</h3>
<p><i>Not recommended</i></p>
<p><a href="i2cp">I2CP</a> itself is a language independent protocol, but to implement an I2CP library
<p><i>{{ _('Not recommended') }}</i></p>
<p>{% trans i2cp=site_url('docs/protocol/i2cp') -%}
<a href="{{ i2cp }}">I2CP</a> itself is a language independent protocol, but to implement an I2CP library
in something other than Java there is a significant amount of code to be written (encryption routines,
object marshalling, asynchronous message handling, etc). While someone could write an I2CP library in
C or something else, it would most likely be more useful to use the C SAM library instead.
</p>
{%- endtrans %}</p>
<h3>Web Applications</h3>
<h3>{{ _('Web Applications') }}</h3>
<p>{% trans -%}
I2P comes with the Jetty webserver, and configuring to use the Apache server instead is straightforward.
Any standard web app technology should work.
{%- endtrans %}</p>
<h2 id="start">Start developing - a simple guide</h2>
<h2 id="start">{{ _('Start developing - a simple guide') }}</h2>
<p>{% trans -%}
Developing using I2P requires a working I2P installation and a development environment of your own choice.
If you are using Java, you can start development with the <a href="#start.streaming">streaming library</a> or datagram library.
Using another programming language, SAM or BOB can be used.
{%- endtrans %}</p>
<h3 id="start.streaming">Developing with the streaming library</h3>
<h3 id="start.streaming">{{ _('Developing with the streaming library') }}</h3>
Development using the streaming library requires the following libraries in your classpath:
<ul>
<li>$I2P/lib/streaming.jar: the streaming library itself.</li>
<li>$I2P/lib/mstreaming.jar: the ministreaming library is used as the base for the streaming library.</li>
<li>$I2P/lib/i2p.jar: some standard I2P classes (like the Destination class) are very convenient when developing.</li>
</ul>
<p>{% trans -%}
Development using the streaming library requires the following libraries in your classpath:
{%- endtrans %}</p>
<ul>
<li>$I2P/lib/streaming.jar: {{ _('the streaming library itself.') }}</li>
<li>$I2P/lib/mstreaming.jar: {{ _('the ministreaming library is used as the base for the streaming library.') }}</li>
<li>$I2P/lib/i2p.jar: {{ _('some standard I2P classes (like the Destination class) are very convenient when developing.') }}</li>
</ul>
<p>
Network communication requires the usage of I2P network sockets.
To demonstrate this, we will create an application where a client can send text messages to a server,
who will print the messages and send them back to the client. In other words, the server will function as an echo.
</p>
<p>
We will start by initializing the server application. This requires getting an I2PSocketManager
and creating an I2PServerSocket.
In addition, we will ask the I2PSocketManager for an I2PSession, so we can find out the Destination we use.
</p>
<p>{% trans -%}
Network communication requires the usage of I2P network sockets.
To demonstrate this, we will create an application where a client can send text messages to a server,
who will print the messages and send them back to the client. In other words, the server will function as an echo.
{%- endtrans %}</p>
<p>{% trans -%}
We will start by initializing the server application. This requires getting an I2PSocketManager
and creating an I2PServerSocket.
In addition, we will ask the I2PSocketManager for an I2PSession, so we can find out the Destination we use.
{%- endtrans %}</p>
<div class="box">
<pre>
package i2p.echoserver;
@@ -286,16 +324,16 @@ Using another programming language, SAM or BOB can be used.
}
</pre>
<br /><br />
<p style="text-align:center">Code example 1: initializing the server application.</p>
<p style="text-align:center">{{ _('Code example 1: initializing the server application.') }}</p>
</div>
<p>
Once we have an I2PServerSocket, we can create I2PSocket instances to accept connections from clients.
In this example, we will create a single I2PSocket instance, that can only handle one client at a time.
A real server would have to be able to handle multiple clients.
To do this, multiple I2PSocket instances would have to be created, each in separate threads.
Once we have created the I2PSocket instance, we read data, print it and send it back to the client.
The bold code is the new code we add.
</p>
<p>{% trans -%}
Once we have an I2PServerSocket, we can create I2PSocket instances to accept connections from clients.
In this example, we will create a single I2PSocket instance, that can only handle one client at a time.
A real server would have to be able to handle multiple clients.
To do this, multiple I2PSocket instances would have to be created, each in separate threads.
Once we have created the I2PSocket instance, we read data, print it and send it back to the client.
The bold code is the new code we add.
{%- endtrans %}</p>
<div class="box">
<pre>
package i2p.echoserver;
@@ -374,12 +412,14 @@ Using another programming language, SAM or BOB can be used.
}
</b></pre>
<br /><br />
<p style="text-align:center">Code example 2: accepting connections from clients and handling messages.</p>
<p style="text-align:center">{{ _('Code example 2: accepting connections from clients and handling messages.') }}</p>
</div>
When you run the above server code, it should print something like this (but without the line endings, it should just be
one huge block of characters):
<p>{% trans -%}
When you run the above server code, it should print something like this (but without the line endings, it should just be
one huge block of characters):
{%- endtrans %}
<pre id="start.streaming.destination">
y17s~L3H9q5xuIyyynyWahAuj6Jeg5VC~Klu9YPquQvD4vlgzmxn4yy~5Z0zVvKJiS2Lk
poPIcB3r9EbFYkz1mzzE3RYY~XFyPTaFQY8omDv49nltI2VCQ5cx7gAt~y4LdWqkyk3au
@@ -390,16 +430,18 @@ Using another programming language, SAM or BOB can be used.
BOF6kbxV7NPRPnivbNekd1E1GUq08ltDPVMO1pKJuGMsFyZC4Q~osZ8nI59ryouXgn97Q
5ZDEO8-Iazx50~yUQTRgLMOTC5hqnAAAA
</pre>
This is the base64-representation of the server Destination. The client will need this string to reach the server.
{% trans -%}
This is the base64-representation of the server Destination. The client will need this string to reach the server.
{%- endtrans %}</p>
<p>
Now, we will create the client application. Again, a number of steps are required for initialization.
Again, we will need to start by getting an I2PSocketManager.
We won't use an I2PSession and an I2PServerSocket this time.
Instead, we will use the server Destination string to start our connection.
We will ask the user for the Destination string, and create an I2PSocket using this string.
Once we have an I2PSocket, we can start sending and receiving data to and from the server.
</p>
<p>{% trans -%}
Now, we will create the client application. Again, a number of steps are required for initialization.
Again, we will need to start by getting an I2PSocketManager.
We won't use an I2PSession and an I2PServerSocket this time.
Instead, we will use the server Destination string to start our connection.
We will ask the user for the Destination string, and create an I2PSocket using this string.
Once we have an I2PSocket, we can start sending and receiving data to and from the server.
{%- endtrans %}</p>
<div class="box">
<pre>
package i2p.echoclient;
@@ -474,20 +516,22 @@ Using another programming language, SAM or BOB can be used.
}
</pre>
<br /><br />
<p style="text-align:center">Code example 3: starting the client and connecting it to the server application.</p>
<p style="text-align:center">{{ _('Code example 3: starting the client and connecting it to the server application.') }}</p>
</div>
<p>
Finally, you can run both the server and the client application.
First, start the server application. It will print a Destination string (like shown <a href="#start.streaming.destination">above</a>).
Next, start the client application. When it requests a Destination string, you can enter the string printed by the server.
The client will then send 'Hello I2P!' (along with a newline) to the server, who will print the message and send it back to the client.
</p>
<p>
Congratulations, you have successfully communicated over I2P!
</p>
<p>{% trans -%}
Finally, you can run both the server and the client application.
First, start the server application. It will print a Destination string (like shown <a href="#start.streaming.destination">above</a>).
Next, start the client application. When it requests a Destination string, you can enter the string printed by the server.
The client will then send 'Hello I2P!' (along with a newline) to the server, who will print the message and send it back to the client.
{%- endtrans %}</p>
<p>{% trans -%}
Congratulations, you have successfully communicated over I2P!
{%- endtrans %}</p>
<h2>Existing Applications in Development</h2>
<h2>{{ _('Existing Applications in Development') }}</h2>
<p>{% trans -%}
Contact us if you would like to help.
{%- endtrans %}</p>
<ul>
<li>
<a href="http://{{ i2pconv('i2pbote.i2p') }}/">I2P-Bote</a> - contact HungryHobo
@@ -502,24 +546,40 @@ Contact us if you would like to help.
</li><li><a href="http://{{ i2pconv('bob.i2p') }}">BOB</a> - contact sponge
</li></ul>
<h2>Application Ideas</h2>
<h2>{{ _('Application Ideas') }}</h2>
<ul>
<li>NNTP server - there have been some in the past, none at the moment
</li><li>Jabber server - there have been some in the past, and there is one at the moment, with access to the public internet
</li><li>PGP Key server and/or proxy
</li><li>Download manager / eepget scheduler -
<li>{% trans -%}
NNTP server - there have been some in the past, none at the moment
{%- endtrans %}</li>
<li>{% trans -%}
Jabber server - there have been some in the past, and there is one at the moment, with access to the public internet
{%- endtrans %}</li>
<li>{% trans -%}
PGP Key server and/or proxy
{%- endtrans %}</li>
<li>{% trans -%}
Download manager / eepget scheduler -
We use eepget to fetch lots of things reliably over i2p, and there's already an
implementation of a sequential download manager (net.i2p.util.EepGetScheduler),
but there isn't any sort of user interface to it. A web based UI would be
great.
</li><li>Content Distribution / DHT applications - help out with <a href="http://{{ i2pconv('feedspace.i2p') }}/">feedspace</a>,
{%- endtrans %}</li>
<li>{% trans feedspace=i2pconv('feedspace.i2p') -%}
Content Distribution / DHT applications - help out with <a href="http://{{ feedspace }}">feedspace</a>,
port dijjer, look for alternatives
</li><li>Help out with <a href="http://syndie.i2p2.de/">Syndie</a> development
</li><li>Web-based applications - The sky is the limit for hosting web-server-based
{%- endtrans %}</li>
<li>{% trans -%}
Help out with <a href="http://syndie.i2p2.de/">Syndie</a> development
{%- endtrans %}</li>
<li>{% trans -%}
Web-based applications - The sky is the limit for hosting web-server-based
applications such as blogs, pastebins, storage, tracking, feeds, etc.
Any web or CGI technology such as Perl, PHP, Python, or Ruby will work.
</li><li>Resurrect some old apps - in the i2p source package -
{%- endtrans %}</li>
<li>{% trans -%}
Resurrect some old apps - in the i2p source package -
bogobot, pants, proxyscript, q, stasher, socks proxy, i2ping
</li></ul>
{%- endtrans %}</li>
</ul>
{% endblock %}

29
i2p2www/pages/site/get-involved/develop/developers-keys.html
View File

@@ -1,17 +1,23 @@
{% extends "global/layout.html" %}
{% block title %}I2P Developer's MTN Keys{% endblock %}
{% block title %}{% trans %}I2P Developer's MTN Keys{% endtrans %}{% endblock %}
{% block content %}
<h1>MTN Keys</h1>
<p>Monotone servers used by the I2P project require two types of keys to be used.
<h1>{{ _('MTN Keys') }}</h1>
<p>{% trans -%}
Monotone servers used by the I2P project require two types of keys to be used.
{%- endtrans %}</p>
<ul>
<li><a href="#commit">Commit Keys</a> to sign changes checked-in to the respository; and</li>
<li><a href="#transport">Transport Keys</a> to push changes to remote servers.</li>
<li>{% trans %}<a href="#commit">Commit Keys</a> to sign changes checked-in to the respository; and{% endtrans %}</li>
<li>{% trans %}<a href="#transport">Transport Keys</a> to push changes to remote servers.{% endtrans %}</li>
</ul>
<p>Everyone that uses Monotone to checkout the I2P codebase will need to <a href="monotone#obtaining-and-deploying-developers-keys">import</a> the
developer commit keys, but only Monotone <a href="monotone#operating-a-monotone-server">server operators</a> will need to import the <a href="#transport">transport keys</a>.</p>
<p>{% trans monotone=site_url('get-involved/guides/monotone') -%}
Everyone that uses Monotone to checkout the I2P codebase will need to
<a href="{{ monotone }}#obtaining-and-deploying-developers-keys">import</a> the
developer commit keys, but only Monotone <a href="{{ monotone }}#operating-a-monotone-server">
server operators</a> will need to import the <a href="#transport">transport keys</a>.
{%- endtrans %}</p>
<h3 id="commit">Developer Commit keys</h3>
<h3 id="commit">{{ _('Developer Commit keys') }}</h3>
<pre>
[pubkey jrandom@i2p.net]
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOLw05kZbux5KLdp
@@ -223,8 +229,11 @@ rIeB7/2uVOpe+3FrFgUzIiWsx6I2yiNI3TscDvQsa5wG0Z2G4BbHXj
ONyiUzzO+j2TWPs3x35r2LCy8plRzPAswCF1GaIEjJCce5zwIDAQAB
[end]
</pre>
<h3 id="transport">Developer Transport Keys</h3>
<p><b>Note:</b> Transport keys are only needed for setting up a <a href="monotone#operating-a-monotone-server">Monotone server</a>.</p>
<h3 id="transport">{{ _('Developer Transport Keys') }}</h3>
<p>{% trans monotone=site_url('get-involved/guides/monotone') -%}
<b>Note:</b> Transport keys are only needed for setting up a
<a href="{{ monotone }}#operating-a-monotone-server">Monotone server</a>.
{%- endtrans %}</p>
<pre>
[pubkey zzz-transport@mail.i2p]

13
i2p2www/pages/site/get-involved/develop/license-agreements.html
View File

@@ -1,15 +1,20 @@
{% extends "global/layout.html" %}
{% block title %}License Agreements{% endblock %}
{% block title %}{{ _('License Agreements') }}{% endblock %}
{% block content %}
<p>For more information see <a href="{{ site_url('develop/licenses') }}">licenses.html</a>.
</p><p>Following is a monotonerc file defining the current trust list.
<p>{% trans licenses=site_url('get-involved/develop/licenses') -%}
For more information see <a href="{{ licenses }}">the licenses page</a>.
{%- endtrans %}</p>
<p>{% trans -%}
Following is a monotonerc file defining the current trust list.
Developers must use this file in ~/.monotone/monotonerc or
_MTN/montonerc in their i2p.i2p workspace.
{%- endtrans %}
{% include "include/monotonerc.html" %}
</p><p>Agreements:
</p>
<p>{{ _('Agreements') }}:
<pre>
Complication:

105
i2p2www/pages/site/get-involved/develop/licenses.html
View File

@@ -1,30 +1,34 @@
{% extends "global/layout.html" %}
{% block title %}Licenses{% endblock %}
{% block title %}{{ _('Licenses') }}{% endblock %}
{% block content %}
<h1>I2P Software Licenses</h1>
<p>
<h1>{{ _('I2P Software Licenses') }}</h1>
<p>{% trans threatmodel=site_url('docs/how/threat-model') -%}
As required by our
<a href="{{ site_url('docs/how/threatmodel') }}">threat model</a> (among other reasons), the
<a href="{{ threatmodel }}">threat model</a> (among other reasons), the
software developed to support the anonymous communication
network we call I2P must be freely available, open source,
and user modifiable. To meet these criteria, we make use of
a variety of legal and software engineering techniques so
as to remove as many barriers to entry for those considering
making use of or contributing to the I2P effort.</p>
making use of or contributing to the I2P effort.
{%- endtrans %}</p>
<p>While the information below may be more confusing than just simply
<p>{% trans -%}
While the information below may be more confusing than just simply
stating "I2P is BSD", "I2P is GPL", or "I2P is public domain",
the short answer to the question "How is I2P licensed?" is this:</p>
the short answer to the question "How is I2P licensed?" is this:
{%- endtrans %}</p>
<h2>All software bundled in the I2P distributions will allow:</h2>
<h2>{{ _('All software bundled in the I2P distributions will allow:') }}</h2>
<ol>
<li>use without fee</li>
<li>use with no restrictions on how, when, where, why, or by whom is running it</li>
<li>access to the source code without fee</li>
<li>modifications to the source</li>
<li>{{ _('use without fee') }}</li>
<li>{{ _('use with no restrictions on how, when, where, why, or by whom is running it') }}</li>
<li>{{ _('access to the source code without fee') }}</li>
<li>{{ _('modifications to the source') }}</li>
</ol>
<p>Most of the software guarantees much more - the ability of <b>anyone</b> to
<p>{% trans -%}
Most of the software guarantees much more - the ability of <b>anyone</b> to
distribute the modified source however they choose. However, not all of the
software bundled provides this freedom - the GPL restricts the ability of
developers who wish to integrate I2P with their own applications that are not
@@ -33,26 +37,29 @@ increasing the resources in the commons, I2P is best served by removing any
barriers that stand in the way of its adoption - if a developer considering whether
they can integrate I2P with their application has to stop and check with their lawyer,
or conduct a code audit to make sure their own source can be released as GPL-compatible,
we lose out.</p>
we lose out.
{%- endtrans %}</p>
<h2>Component licenses</h2>
<p>The I2P distribution contains several resources, reflecting the partitioning of
<h2>{{ _('Component licenses') }}</h2>
<p>{% trans -%}
The I2P distribution contains several resources, reflecting the partitioning of
the source code into components. Each component has its own license, which all
developers who contribute to it agree to - either by explicitly declaring the release
of code committed under a license compatible with that component, or by implicitly
releasing the code committed under the component's primary license. Each of these
components has a lead developer who has the final say as to what license is compatible
with the component's primary license, and the I2P project manager has the final say as
to what licenses meet the above four guarantees for inclusion in the I2P distribution.</p>
to what licenses meet the above four guarantees for inclusion in the I2P distribution.
{%- endtrans %}</p>
<table border="1">
<tr>
<td valign="top" align="left"><b>Component</b></td>
<td valign="top" align="left"><b>Source path</b></td>
<td valign="top" align="left"><b>Resource</b></td>
<td valign="top" align="left"><b>Primary license</b></td>
<td valign="top" align="left"><b>Alternate licenses</b></td>
<td valign="top" align="left"><b>Lead developer</b></td>
<td valign="top" align="left"><b>{{ _('Component') }}</b></td>
<td valign="top" align="left"><b>{{ _('Source path') }}</b></td>
<td valign="top" align="left"><b>{{ _('Resource') }}</b></td>
<td valign="top" align="left"><b>{{ _('Primary license') }}</b></td>
<td valign="top" align="left"><b>{{ _('Alternate licenses') }}</b></td>
<td valign="top" align="left"><b>{{ _('Lead developer') }}</b></td>
</tr>
<tr>
<td valign="top" align="left"><b>I2P SDK</b></td>
@@ -261,11 +268,13 @@ to what licenses meet the above four guarantees for inclusion in the I2P distrib
</tr>
</table>
<h3><a id="java_exception">GPL + java exception</a></h3>
<p>While it may be redundant, just for clarity the
<h3><a id="java_exception">{{ _('GPL + java exception') }}</a></h3>
<p>{% trans -%}
While it may be redundant, just for clarity the
<a href="http://www.fsf.org/licenses/gpl.html">GPL</a>'ed code included within
I2PTunnel and other apps must be released under the GPL with an additional "exception"
explicitly authorizing the use of Java's standard libraries:</p>
explicitly authorizing the use of Java's standard libraries:
{%- endtrans %}</p>
<p><code>In addition, as a special exception, XXXX gives permission to link the
code of this program with the proprietary Java implementation provided by Sun
@@ -276,36 +285,46 @@ file, you may extend this exception to your version of the file, but you are not
obligated to do so. If you do not wish to do so, delete this exception statement
from your version.</code></p>
<p>All source code under each component will by default be licensed under the
<p>{% trans -%}
All source code under each component will by default be licensed under the
primary license, unless marked otherwise in the code. All of the above is
summary of the license terms - please see the specific license for the component
or source code in question for authoritative terms. Component source locations and
resource packaging may be changed if the repository is reorganized.</p>
resource packaging may be changed if the repository is reorganized.
{%- endtrans %}</p>
<h2><a id="commit">Commit privileges</a></h2>
<p>
<h2><a id="commit">{{ _('Commit privileges') }}</a></h2>
<p>{% trans monotone=site_url('get-involved/guides/monotone') -%}
Developers may push changes to a distributed monotone repository if you
receive permission from the person running that repository.
See the <a href="monotone.html">Monotone Page</a> for details.
</p>
See the <a href="{{ monotone }}">Monotone Page</a> for details.
{%- endtrans %}</p>
<p>
<p>{% trans -%}
However, to have changes included in a release, developers
must be trusted by the release manager (currently zzz).
In addition, they must explicitly agree with the above terms to be trusted.
That means that they must send one of the release managers a signed message affirming that:</p>
That means that they must send one of the release managers a signed message affirming that:
{%- endtrans %}</p>
<ul>
<li>Unless marked otherwise, all code I commit is implicitly licensed under
the component's primary license</li>
<li>If specified in the source, the code may be explicitly licensed under one
of the component's alternate licenses</li>
<li>I have the right to release the code I commit under the terms I
am committing it</li>
<li>{% trans -%}
Unless marked otherwise, all code I commit is implicitly licensed under
the component's primary license
{%- endtrans %}</li>
<li>{% trans -%}
If specified in the source, the code may be explicitly licensed under one
of the component's alternate licenses
{%- endtrans %}</li>
<li>{% trans -%}
I have the right to release the code I commit under the terms I
am committing it
{%- endtrans %}</li>
</ul>
<p>If anyone is aware of any instances where the above conditions are not met,
<p>{% trans licenseagreements=site_url('get-involved/develop/license-agreements') -%}
If anyone is aware of any instances where the above conditions are not met,
please contact the component lead and/or an I2P release manager with further
information.
<a href="{{ site_url('develop/license-agreements') }}">See developers' license agreements</a>.
</p>
<a href="{{ licenseagreements }}">See developers' license agreements</a>.
{%- endtrans %}</p>
{% endblock %}

7
i2p2www/pages/site/get-involved/develop/release-signing-key.html
View File

@@ -1,7 +1,9 @@
{% extends "global/layout.html" %}
{% block title %}Release Signing Key{% endblock %}
{% block title %}{{ _('Release Signing Key') }}{% endblock %}
{% block content %}
<p>{% trans -%}
Releases 0.7.6 and later are signed by zzz. His public key is:
{%- endtrans %}</p>
<p>
<pre>
-----BEGIN PGP PUBLIC KEY BLOCK-----
@@ -35,8 +37,9 @@ njMu9ueCFbsjme7nwsz96PdazJcHAKCce17hGI25QNXDZyHohrjha6IxDg==
-----END PGP PUBLIC KEY BLOCK-----
</pre>
<p>
<p>{% trans -%}
Releases 0.6.1.31 through 0.7.5 were signed by Complication. His public key is:
{%- endtrans %}</p>
<p>
<pre>
-----BEGIN PGP SIGNED MESSAGE-----

110
i2p2www/pages/site/get-involved/develop/signed-keys.html
View File

@@ -1,22 +1,24 @@
{% extends "global/layout.html" %}
{% block title %}Signed Developer Keys{% endblock %}
{% block title %}{{ _('Signed Developer Keys') }}{% endblock %}
{% block content %}
<p>Keys for zzz, Complication and welterde are provided clearsigned. The key for jrandom must be
verified differently, since he's away, and only left a binary detached
signature for his key.
<p>{% trans -%}
Keys for zzz, Complication and welterde are provided clearsigned. The key for jrandom must be
verified differently, since he's away, and only left a binary detached
signature for his key.
{%- endtrans %}</p>
<ol>
<li><a href="signedkeys#monotone-keys-for-zzz">Monotone keys for zzz</a></li>
<li><a href="#monotone-keys-for-welterde">Monotone keys for welterde</a></li>
<li><a href="#monotone-keys-for-complication">Monotone keys for Complication</a></li>
<li><a href="#monotone-keys-for-jrandom">Monotone keys for jrandom</a></li>
<li><a href="#other-developer-keys">Others</a></li>
<li><a href="signedkeys#monotone-keys-for-zzz">{{ _('Monotone keys for zzz') }}</a></li>
<li><a href="#monotone-keys-for-welterde">{{ _('Monotone keys for welterde') }}</a></li>
<li><a href="#monotone-keys-for-complication">{{ _('Monotone keys for Complication') }}</a></li>
<li><a href="#monotone-keys-for-jrandom">{{ _('Monotone keys for jrandom') }}</a></li>
<li><a href="#other-developer-keys">{{ _('Others') }}</a></li>
</ol>
<h3 id="monotone-keys-for-zzz">Monotone keys for zzz</h3>
<p>
<u>Tip:</u> To find zzz's GPG key, on his eepsite locate the key `0xA76E0BED`, with
the name `zzz@mail.i2p` and the fingerprint `4456 EBBE C805 63FE 57E6 B310 4155
76BA A76E 0BED`.
</p>
<h3 id="monotone-keys-for-zzz">{{ _('Monotone keys for zzz') }}</h3>
<p>{% trans -%}
<u>Tip:</u> To find zzz's GPG key, on his eepsite locate the key `0xA76E0BED`, with
the name `zzz@mail.i2p` and the fingerprint `4456 EBBE C805 63FE 57E6 B310 4155
76BA A76E 0BED`.
{%- endtrans %}</p>
<code><pre>
-----BEGIN PGP SIGNED MESSAGE-----
@@ -42,13 +44,13 @@
</pre></code>
<h3 id="monotone-keys-for-welterde">Monotone keys for welterde</h3>
<h3 id="monotone-keys-for-welterde">{{ _('Monotone keys for welterde') }}</h3>
<p>
<b>Tip:</b> To find welterde's GPG key, on public keyservers locate the key
`0x62E011A1`, with the name `welterde@arcor.de` and the fingerprint `6720 FD81
3872 6DFC 6016 64D1 EBBC 0374 62E0 11A1`.
</p>
<p>{% trans -%}
<b>Tip:</b> To find welterde's GPG key, on public keyservers locate the key
`0x62E011A1`, with the name `welterde@arcor.de` and the fingerprint `6720 FD81
3872 6DFC 6016 64D1 EBBC 0374 62E0 11A1`.
{%- endtrans %}</p>
<code><pre>
-----BEGIN PGP SIGNED MESSAGE-----
@@ -74,13 +76,13 @@
</pre></code>
<h3 id="monotone-keys-for-complication">Monotone keys for Complication</h3>
<h3 id="monotone-keys-for-complication">{{ _('Monotone keys for Complication') }}</h3>
<p>
<b>Tip:</b> To find Complication's GPG key, on his eepsite locate the key
`0x79FCCE33`, with the name `complication@mail.i2p` and the fingerprint `73CF
2862 87A7 E7D2 19FF DB66 FA1D FC6B 79FC CE33`.
</p>
<p>{% trans -%}
<b>Tip:</b> To find Complication's GPG key, on his eepsite locate the key
`0x79FCCE33`, with the name `complication@mail.i2p` and the fingerprint `73CF
2862 87A7 E7D2 19FF DB66 FA1D FC6B 79FC CE33`.
{%- endtrans %}</p>
<code><pre>
-----BEGIN PGP SIGNED MESSAGE-----
@@ -109,27 +111,27 @@
-----END PGP SIGNATURE-----
</pre></code>
<h3 id="monotone-keys-for-jrandom">Monotone keys for jrandom</h3>
<h3 id="monotone-keys-for-jrandom">{{ _('Monotone keys for jrandom') }}</h3>
<p>
<b>Tip:</b> To find jrandom's GPG key for Syndie releases, on public keyservers locate
the key `0x393F2DF9`, with the name `syndie-dist-key@i2p.net` and the
fingerprint `AE89 D080 0E85 72F0 B777 B2ED C2FA 68C0 393F 2DF9`.
</p>
<p>{% trans -%}
<b>Tip:</b> To find jrandom's GPG key for Syndie releases, on public keyservers locate
the key `0x393F2DF9`, with the name `syndie-dist-key@i2p.net` and the
fingerprint `AE89 D080 0E85 72F0 B777 B2ED C2FA 68C0 393F 2DF9`.
{%- endtrans %}</p>
<p>
Jrandom had to leave unexpectedly in the end of 2007. His commit key was
deployed in the Syndie Monotone repository, in a file named `mtn-committers`.
That file also had a GPG signature, `mtn-committers.sig`, but it was a binary
detached signature. I am going to supply both files in GPG ASCII-armoured form
below.
</p>
<p>{% trans -%}
Jrandom had to leave unexpectedly in the end of 2007. His commit key was
deployed in the Syndie Monotone repository, in a file named `mtn-committers`.
That file also had a GPG signature, `mtn-committers.sig`, but it was a binary
detached signature. I am going to supply both files in GPG ASCII-armoured form
below.
{%- endtrans %}</p>
<p>
First, the file `mtn-committers` containing jrandom's Monotone key. Save as
`mtn-committers.asc` and unpack it using `gpg --output mtn-committers --dearmor
mtn-committers.asc`:
</p>
<p>{% trans -%}
First, the file `mtn-committers` containing jrandom's Monotone key. Save as
`mtn-committers.asc` and unpack it using `gpg --output mtn-committers --dearmor
mtn-committers.asc`:
{%- endtrans %}</p>
<code><pre>
-----BEGIN PGP ARMORED FILE-----
@@ -146,12 +148,12 @@
-----END PGP ARMORED FILE-----
</pre></code>
<p>
Now the file `mtn-committers.sig`, containing the GPG signature. Save as
`mtn-committers.sig.asc` and unpack it using `gpg --output mtn-committers.sig
--dearmor mtn-committers.sig.asc`. Use it to verify the above supplied
`mtn-committers` file:
</p>
<p>{% trans -%}
Now the file `mtn-committers.sig`, containing the GPG signature. Save as
`mtn-committers.sig.asc` and unpack it using `gpg --output mtn-committers.sig
--dearmor mtn-committers.sig.asc`. Use it to verify the above supplied
`mtn-committers` file:
{%- endtrans %}</p>
<code><pre>
-----BEGIN PGP ARMORED FILE-----
@@ -164,8 +166,10 @@
-----END PGP ARMORED FILE-----
</pre></code>
<h3 id="other-developer-keys">Others</h3>
Some of the developers have included their Monotone keys in their <a href="license-agreements">signed license agreement</a>.
<h3 id="other-developer-keys">{{ _('Others') }}</h3>
<p>{% trans licenseagreements=site_url('get-involved/develop/license-agreements') -%}
Some of the developers have included their Monotone keys in their <a href="{{ licenseagreements }}">signed license agreement</a>.
{%- endtrans %}</p>
{% endblock %}