mirror of
https://github.com/go-i2p/www.git
synced 2025-07-01 19:04:46 -04:00
81 lines
2.8 KiB
HTML
81 lines
2.8 KiB
HTML
|
<pre>-----BEGIN PGP SIGNED MESSAGE-----
|
||
|
|
Hash: SHA1
|
||
|
|
|
||
|
|
Hi y'all, weekly update time
|
||
|
|
|
||
|
|
* Index
|
||
|
|
1) 0.5
|
||
|
|
2) Next steps
|
||
|
|
3) azneti2p
|
||
|
|
4) ???
|
||
|
|
|
||
|
|
* 1) 0.5
|
||
|
|
|
||
|
|
As y'all have heard, we finally got 0.5 out the door, and for the
|
||
|
|
most part, its been doing pretty well. I really appreciate how
|
||
|
|
quickly people have updated - within the first day, 50-75% of the
|
||
|
|
net was up to 0.5! Because of the fast adoption, we've been able
|
||
|
|
to see the impact of the various changes more quickly, and in turn
|
||
|
|
have found a bunch of bugs. While there are still some outstanding
|
||
|
|
issues, we will be putting out a new 0.5.0.1 release later this
|
||
|
|
evening to address the most important ones.
|
||
|
|
|
||
|
|
As a side benefit of the bugs, its been neat to see that routers can
|
||
|
|
handle thousands of tunnels ;)
|
||
|
|
|
||
|
|
* 2) Next steps
|
||
|
|
|
||
|
|
After the 0.5.0.1 release, there may be another build to experiment
|
||
|
|
with some changes in the exploratory tunnel building (such as using
|
||
|
|
only one or two not-failing peers, the rest being high capacity,
|
||
|
|
instead of all of the peers being not-failing). After that, we'll
|
||
|
|
be jumping towards 0.5.1, which will improve the tunnel throughput
|
||
|
|
(by batching multiple small messages into a single tunnel message)
|
||
|
|
and allow the user more control over their suceptability to the
|
||
|
|
predecessor attack.
|
||
|
|
|
||
|
|
Those controls will take the form of per-client peer ordering and
|
||
|
|
selection strategies, one for the inbound gateway and outbound
|
||
|
|
endpoint, and one for the rest of the tunnel. Current thumbnail
|
||
|
|
sketch of strategies I forsee:
|
||
|
|
= random (what we have now)
|
||
|
|
= balanced (explicitly try to reduce how often we use each peer)
|
||
|
|
= strict (if we ever use A-->B-->C, they stay in that order
|
||
|
|
during subsequent tunnels [bounded by time])
|
||
|
|
= loose (generate a random key for the client, calculate the XOR
|
||
|
|
from that key and each peer, and always order the peers
|
||
|
|
selected by the distance from that key [bounded by time])
|
||
|
|
= fixed (always use the same peers per MBTF)
|
||
|
|
|
||
|
|
Anyway, thats the plan, though I'm not sure which strategies will be
|
||
|
|
rolled out first. Suggestions more than welcome :)
|
||
|
|
|
||
|
|
* 3) azneti2p
|
||
|
|
|
||
|
|
The folks over at azureus have been working hard with a slew of
|
||
|
|
updates, and their latest b34 snapshot [1] seems to have some I2P
|
||
|
|
related bugfixes. While I havent had time to audit the source since
|
||
|
|
that last anonymity issue I raised, they have fixed that particular
|
||
|
|
bug, so if you're feeling adventurous, go snag their update and give
|
||
|
|
'er a try!
|
||
|
|
|
||
|
|
[1] <a rel="nofollow" href="http://azureus.sourceforge.net/index_CVS.php">http://azureus.sourceforge.net/index_CVS.php</a>
|
||
|
|
|
||
|
|
* 4) ???
|
||
|
|
|
||
|
|
Lots and lots of stuff going on, and I'm sure I haven't come close
|
||
|
|
to covering things. Swing on by the meeting in a few minutes and
|
||
|
|
see whats up!
|
||
|
|
|
||
|
|
=jr
|
||
|
|
-----BEGIN PGP SIGNATURE-----
|
||
|
|
Version: GnuPG v1.2.4 (GNU/Linux)
|
||
|
|
|
||
|
|
iD8DBQFCG5uVGnFL2th344YRAqaGAJ9HqYx8unEZn57ZCd04mSG4hMPO1QCgsXBY
|
||
|
|
nNdoN5D/aKLL0XdusZcigTA=
|
||
|
|
=rhto
|
||
|
|
-----END PGP SIGNATURE-----
|
||
|
|
|
||
|
|
|
||
|
|
</pre>
|