2013-10-25 21:27:34 +00:00
|
|
|
{% extends "global/layout.html" %}
|
|
|
|
{% block title %}{{ _('Open research questions') }}{% endblock %}
|
2018-05-06 04:15:29 +00:00
|
|
|
{% block lastupdated %}{% trans %}May 2018{% endtrans %}{% endblock %}
|
2013-10-25 21:27:34 +00:00
|
|
|
{% block content %}
|
2013-11-21 23:37:48 +00:00
|
|
|
<h2>{{ _('Network database') }}</h2>
|
2018-05-06 04:15:29 +00:00
|
|
|
<h3>{{ _('Floodfills') }}</h3>
|
|
|
|
<ul>
|
|
|
|
<li>
|
|
|
|
Are there any other ways to mitigate network brute-forcing via significant
|
|
|
|
floodfill control?
|
|
|
|
</li>
|
|
|
|
<li>
|
|
|
|
Is there any way to detect, flag and potentially remove 'bad floodfills'
|
|
|
|
similar to the Tor relay authorities, without actually needing to rely on a
|
2018-05-06 04:41:47 +00:00
|
|
|
form of central authority?
|
2018-05-06 04:15:29 +00:00
|
|
|
</li>
|
|
|
|
</ul>
|
2013-11-21 23:37:48 +00:00
|
|
|
|
2014-07-14 14:22:36 +00:00
|
|
|
<h2>{{ _('Transports') }}</h2>
|
|
|
|
<ul>
|
2018-05-06 04:15:29 +00:00
|
|
|
<li>
|
|
|
|
How could packet retransmission strategies and timeouts be improved?
|
|
|
|
</li>
|
|
|
|
<li>
|
|
|
|
Is there a way for I2P to obfuscate packets and reduce traffic analysis
|
|
|
|
more efficiently than other proposed ideas? (Padding transport layer,
|
|
|
|
developing mimic protocols, etc.)
|
|
|
|
</li>
|
2014-07-14 14:22:36 +00:00
|
|
|
</ul>
|
|
|
|
|
2013-11-21 23:37:48 +00:00
|
|
|
<h2>{{ _('Tunnels and Destinations') }}</h2>
|
|
|
|
|
2014-02-18 10:42:49 +00:00
|
|
|
<h3>{{ _('Peer selection') }}</h3>
|
2018-05-06 04:15:29 +00:00
|
|
|
<ul>
|
|
|
|
<li>
|
|
|
|
Is there a way that I2P could perform peer selection more efficiently or
|
|
|
|
securely?
|
|
|
|
</li>
|
|
|
|
<li>
|
|
|
|
Would it negatively impact anonymity to use geoip in order to prioritise
|
|
|
|
physically nearby peers for tunnel building? The primary goal would be to
|
|
|
|
increase tunnel success and reduce breakage.
|
|
|
|
</li>
|
|
|
|
</ul>
|
2014-02-18 10:42:49 +00:00
|
|
|
|
2013-11-21 23:37:48 +00:00
|
|
|
<h3>{{ _('Unidirectional tunnels') }}</h3>
|
2013-10-25 21:27:34 +00:00
|
|
|
<ul>
|
|
|
|
<li>What are the benefits of unidirectional tunnels over bidirectional tunnels? What are the tradeoffs?</li>
|
|
|
|
<li>More details are available <a href="{{ site_url('docs/tunnels/unidirectional') }}">here</a>.</li>
|
|
|
|
</ul>
|
2013-11-21 23:37:48 +00:00
|
|
|
|
|
|
|
<h3>{{ _('Multihoming') }}</h3>
|
|
|
|
<ul>
|
|
|
|
<li>How effective is multihoming at load-balancing?</li>
|
|
|
|
<li>How does it scale? What happens as more routers host the same Destination?</li>
|
|
|
|
<li>The benefit for anonymity is less correlation of router uptime to Destination uptime. Are there tradeoffs?</li>
|
2014-02-18 10:42:49 +00:00
|
|
|
</ul>
|
|
|
|
|
|
|
|
<h3>{{ _('Message routing') }}</h3>
|
|
|
|
<ul>
|
|
|
|
<li>How much is the effectiveness of timing attacks reduced by fragmentation and mixing of messages?</li>
|
|
|
|
<li>What mixing strategies could I2P benefit from?</li>
|
|
|
|
<li>How can high-latency techniques (e.g. message-dependent routing delays) be effectively employed within or alongside our low-latency network?</li>
|
|
|
|
</ul>
|
2018-05-06 04:15:29 +00:00
|
|
|
|
|
|
|
<h2>{{ _('Anonymity') }}</h2>
|
|
|
|
<ul>
|
|
|
|
<li>
|
|
|
|
How significantly does browser fingerprinting impact the anonymity of I2P
|
|
|
|
users? Would developing a browser package be beneficial for the average
|
|
|
|
user?
|
|
|
|
</li>
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
<h2>{{ _('Network Related') }}</h2>
|
|
|
|
<ul>
|
|
|
|
<li>
|
|
|
|
What is the overall impact on the network created by 'greedy users' (users
|
|
|
|
who take bandwidth from the network without contributing any back
|
|
|
|
themselves)? Would additional steps for encouraging bandwidth
|
|
|
|
participation be valuable?
|
|
|
|
</li>
|
|
|
|
</ul>
|
2013-10-25 21:27:34 +00:00
|
|
|
{% endblock %}
|