gmane.network.freenet.technical

Re: China Tor bridge blocking details

Matthew Toseland — 2012-04-04T22:57:58

Right. This was carried through into 0.7: 0.7 doesn't respond AT ALL unless you have the noderef so can use the outer (symmetric) encryption layer. (Strictly this is obfuscation). And also, our traffic is not identifiable by any fixed bytes. (But there may be other ways to identify it, and the below suggests that the chinese will deploy such as soon as they see us as a threat again).
_______________________________________________
Tech mailing list
Tech-RdDMkVZAZeuJnvDnx1genB2eb7JE58TQ< at >public.gmane.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech

Re: This domain has been seized by US

DJ Amireh — 2012-04-04T21:50:10

It was likely done deliberately. You can access an old version of the page
using an SSK, like so: SSK< at >fZJH1Ps03jbBwM3Xuyn1YSTrhUu61EWCcZZcFL0-qeQ
,SYbkVkROwzX7O-sSNqjZoLLrLd4xe9V6qn1pQws8HE8,AQACAAE/celery-227/

On Wed, Apr 4, 2012 at 4:09 PM, Mindaugas Gapsevicius <mi_ga-poEZSwPaQRM< at >public.gmane.org> wrote:

_______________________________________________
Tech mailing list
Tech-RdDMkVZAZeuJnvDnx1genB2eb7JE58TQ< at >public.gmane.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech

This domain has been seized by US

Mindaugas Gapsevicius — 2012-04-04T20:09:15

Hello

recently I landed up at this location:
/USK< at >fZJH1Ps03jbBwM3Xuyn1YSTrhUu61EWCcZZcFL0-qeQ,SYbkVkROwzX7O-sSNqjZoLLrLd4xe9V6qn1pQws8HE8,AQACAAE/celery/228/

indicating, that "This domain has been seized by US Immigration and
Customs Enforcement..". The message pops up time to time on www and
I guess the site should have dealt with some copyrighted material. Does
someone know the issue?
I came up to the site through AFKIndex
/USK< at >2L-k2U32b3yIl2~YjBU7--QJPTtixSwHZxYOuGjS3A0,QJBd6zpJgEsijJGQNNcwUhsrW5vJ8VtlmNX5ka2~dlU,AQACAAE/AFKindex/170/

Best,
miga

Re: China Tor bridge blocking details

Ian Clarke — 2012-04-04T19:34:02

This is the motivation behind "silent bob", something we were talking about
way back in 2002-2003.

Ian.

On Wed, Apr 4, 2012 at 2:19 PM, Matthew Toseland
<toad-EI5O+8PHWbJeeLb3ft/vUmD2FQJk+8+b< at >public.gmane.org>wrote:

China Tor bridge blocking details

Matthew Toseland — 2012-04-04T19:19:27

http://www.v3.co.uk/v3-uk/news/2165733/swedish-researchers-uncover-key-chinas-tor-blocking

Looks like they look for a header that looks like a connection to a bridge, then try to do a handshake. This is surprisingly sophisticated - I had expected they just created thousands of gmail accounts and harvested all the bridges by email.

Also, they appear to be able to create unidentifiable IP addresses on demand, meaning that the opennet protection schemes based on IP scarcity are not going to work.

This won't work as-is with Freenet because Freenet doesn't do handshakes unless you have the keys. However there may be (more complicated) ways to identify the traffic, and the above implies they may be sophisticated enough to implement them. It does mean that obfuscation (stego) is increasingly important.
_______________________________________________
Tech mailing list
Tech-RdDMkVZAZeuJnvDnx1genB2eb7JE58TQ< at >public.gmane.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech

Re: Freenet compared to Tahoe-LAFS

Ian Clarke — 2012-03-25T15:49:08

On Sat, Mar 24, 2012 at 10:49 AM, Florent Daigniere <
nextgens-RdDMkVZAZeuJnvDnx1genB2eb7JE58TQ< at >public.gmane.org> wrote:



Ah yes, this is true.  We employ a whitelist approach so that only parts of
the HTML DOM that we know to be safe get through.  So, for example,
anything that might cause the user's browser to ping a remote server is
verboten.  It seems to work well enough in practice (I don't recall anyone
ever finding a vulnerability in it).

But our threat model is quite different to Tahoe's, this type of thing may
not be a concern for you.

Ian.

Re: Freenet compared to Tahoe-LAFS

Florent Daigniere — 2012-03-24T15:49:30

Hi Zooko,

It was me... And the difference in betweek fproxy (the freenet web-gateway)
 and what Tahoe-LAFS does is that we attempt to parse and filter the content.

Florent

Re: Freenet compared to Tahoe-LAFS

Zooko Wilcox-O'Hearn — 2012-03-24T14:42:33

Haha! I know what you mean.


Hm, yes, Freenet has always had some sort of gateway which would serve
up documents from Freenet to an unextended web browser, hasn't it? I
wonder what that Freenet developer and I were disagreeing about at
Google Summer of Code Mentor Summit 2010 then. It was a one-hour
meeting during the 2-day summit, on the topic, I think, of "security
and distributed systems". There were about 20 GSoC mentors in
attendance.

I remember the Freenet hacker (and I'm sorry that I've forgotten his
name) saying emphatically that the description I gave of Tahoe-LAFS
sounded insecure because the user was constantly using a web browser
to load content.

Perhaps the difference he was thinking about was that I made it sound
as though the web interface was the primary or only way to access
content in Tahoe-LAFS, and perhaps in Freenet the web interface is
considered secondary or optional.

Do people commonly browse hypertext documents loaded from Freenet
which contain links to other documents also loaded from Freenet? In
Tahoe-LAFS, we embed the "caps" (which are similar to, and partially
inspired by, Freenet CHKs and SSKs) into URIs and use them as
references to documents.

Regards,

Zooko

Re: Freenet compared to Tahoe-LAFS

Ian Clarke — 2012-03-24T13:48:35

Thanks Zooko, I didn't catch this the first time around, very interesting.

I too have observed that being less ambitious can dramatically increase the
chances of success, and I seem to re-learn it about once a year :-)

I think Freenet has repeatedly aimed for the stars, but we've scaled things
back at times too - for example by making node specialization explicit in
0.7, rather than relying on emergent specialization which, while being very
cool, also made things much more difficult to reason about.

Oskar's PhD thesis was useful here as it provided a degree of theoretical
backing to the mountain of intuition that Freenet's original design was
based on.

I'm not quite sure if I understand your point about web integration,
Freenet has had a web interface from the earliest days, perhaps if I were
more familar with Tahoe-LAFS I'd understand what you mean here.

Lastly, the name, yes I think I hit it out of the park with "Freenet", but
I've had some doozies too - remember "Thoof"? ;-)

Ian.
 On Mar 23, 2012 1:28 PM, "Zooko Wilcox-O&apos;Hearn" <zooko-F7hWHBaSm8MAvxtiuMwx3w< at >public.gmane.org>
wrote:

_______________________________________________
Tech mailing list
Tech-RdDMkVZAZeuJnvDnx1genB2eb7JE58TQ< at >public.gmane.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech

Freenet compared to Tahoe-LAFS

Zooko Wilcox-O'Hearn — 2012-03-23T18:28:16

Folks:

Almost a year ago I wrote a letter to the tahoe-dev mailing list
comparing Tahoe-LAFS and Freenet. Just now I was reminded of this
letter (because it is referenced from the Tahoe-LAFS FAQ ¹ which was I
was editing), and on re-reading it, I think it is still relevant.

Below is the text of this letter, which is visible on the tahoe-dev
mailing list archives here:
https://tahoe-lafs.org/pipermail/tahoe-dev/2011-July/006560.html

I hope you find it interesting! Comparing and contrasting complex
things like these can help everyone understand them better. Obviously,
writing generic criticisms about which is better than the other would
be a waste of time.

Regards,

Zooko

¹ https://tahoe-lafs.org/trac/tahoe-lafs/wiki/FAQ


Folks:

The topic has come up on the IRC channel and trac about "What's the
difference between Tahoe-LAFS and Freenet?". I will try to answer that
question here, but there are probably other important differences than
the ones I'm thinking of, so this answer shouldn't be treated as
definitive. If you have insight into this topic, please reply!

Also, of course, I know way more about Tahoe-LAFS than I do about
Freenet, and I'm biasing towards thinking that Tahoe-LAFS is the
greatest thing in the universe, so those are other reasons why this
answer shouldn't be taken as definitive.

First a bit of history-and-culture stuff. I was working on Mojo
Nation, in its secret pre-launch mode in early 2000, with Jim McCoy,
Doug Barnes, Greg Smith, and Bram Cohen, when I heard about the
announcement of this new thing called Freenet. The description I read
of it (I think it might have been Ian Clarke's master's thesis) was
surprisingly similar to what we had already designed and were
currently implementing for Mojo Nation. There were differences, too,
but on that day I realized that what we had in mind at Mojo Nation was
not solely a novel invention of our own, but was also a product of
"ideas being in the air" and of the economic and cultural context of
the time. I think we got the idea of secure distributed mutable files
mostly from Freenet (which is why the URI format for Tahoe-LAFS's
secure distributed mutable files has the string "SSK" in it, which is
what Freenet called their secure distributed mutable files).

Mojo Nation was the great+-grand-father of Tahoe-LAFS, so in a sense
Freenet and Tahoe-LAFS grew up together—we shared similar technical
and social values, and we occasionally met on IRC channels or at
conferences in real life to exchange design review and ideas. Over the
ensuing eleven years the Freenet hackers worked continuously on
improving Freenet while making the occasional major shift in design
strategy, most notably the addition of the so-called "Darknet"
strategy in roughly 2009 or so. Over the same time period the Mojo
Nation lineage went through a series of restarts and a changing lineup
of performers. Err, I mean of programmers. During this time, Bram
Cohen left Mojo Nation and invented BitTorrent. The goals of
BitTorrent can be seen as a subset of the goals of Mojo Nation. I
learned from the success of BitTorrent that it can help to limit the
scope of features you are trying to combine into one software project.

Tahoe-LAFS itself was born on the 4th restart (Mojo Nation, Mnet,
Allmydata "Mountain View", Tahoe-LAFS), with the addition of Brian
Warner as chief engineer, in, let's see...

http://tahoe-lafs.org/trac/tahoe-lafs/changeset/1/trunk

In October of 2006. Hey! We should have a 5th Birthday Party for
Tahoe-LAFS this October. :-)

Now for the technical part. The biggest architectural difference
between Tahoe-LAFS and Freenet is that Tahoe-LAFS makes no attempt to
let you discover and use random strangers as storage servers. This was
also the big difference between Tahoe-LAFS and its predecessors. When
we started the Tahoe-LAFS project, we decided to make a simplifying
assumption that you would use some mechanism outside of Tahoe-LAFS
itself to find a somewhat stable set of moderately reliable servers
that would agree to give you storage service.

Such mechanisms include paying a company to run those servers for you
(which was what allmydata.com offered), getting a few of your friends
to run storage servers for you, joining a club of people who share
Tahoe-LAFS storage service (such as our Volunteer Grids), etc.. In the
future we would like to add to the possible mechanisms—maybe you could
pay people in Bitcoin to run storage servers for you (#1408).

In any case, the thing that we rejected at that point was having your
Tahoe-LAFS client meet some previously unknown Tahoe-LAFS server over
some automated protocol and decide to entrust some of your ciphertext
to that server. We concluded that while we could use math in your
client to provide confidentiality, integrity, and access control
without requiring the server to provide those things, we could *not*
use math in your client to provide availability or longevity without
relying on the server to provide those things. (This was after we
tried repeatedly to do just that from about 1999 to about 2006,
without success.) Therefore, you have to do the legwork yourself of
finding highly available, long-lived servers.

That's the biggest architectural point of departure between Freenet
and Tahoe-LAFS. There are more.

Another big one is, as Gwern pointed out on the #1427, is that
Tahoe-LAFS makes no attempt to obscure the source or destination of
requests, but Freenet does attempt to do that. Again, this was a
deliberate decision on our part not to include this feature. Brian and
I both had some knowledge about anonymity systems like Chaumian mixes,
private information retrieval, and Dining Cryptographers, and we knew
that it would be very hard, if not impossible, to guarantee anonymity
against sophisticated attackers, and that trying to do that within the
scope of our storage protocol would greatly complicate it. This
architectural departure from Freenet has subsequently proved less
consequential than the first one, because people have subsequently
wrapped Tahoe-LAFS's storage protocol inside Tor and I2P, thus letting
those systems provide their anonymity/privacy protections while
Tahoe-LAFS provides its confidentiality, integrity, and access control
protections.

Another big architectural difference is that Tahoe-LAFS embraced the
Web from the beginning, with the webapi [1] as the standard
programmable interface and the WUI ("Web User Interface") one of the
supported user interfaces. This has paid off to some degree, since
other projects and local hacks can use the webapi to integrate with
Tahoe-LAFS, and it becomes very easy to use Tahoe-LAFS to host files
for public distribution, either by making the WUI itself publicly
visible or by putting a proxy such as nginx in front of it. On the
other hand, web browsers and web technologies like JavaScript have
historically been rife with security problems. One of the three
security problems that people have uncovered in Tahoe-LAFS over the
years [2] was due to the existence of the webapi. When I spoke with a
Freenet hacker at the Google Summer of Code Mentor Summit last year,
he was adamant that they would not endanger their users' safety by
helping them use web browsers to view and edit the data stored and
communicated through Freenet. I can't exactly disagree with him about
that—web technology is often insecure. But on the other hand it is
improving rapidly by necessity, and on the gripping hand, the Web is
what most people use. If we didn't integrate directly with the Web it
would make Tahoe-LAFS's secure storage properties less accessible to
the majority of users.

(Sometimes security experts reject Tahoe-LAFS as inherently insecure
when they learn about the Web integration. If I notice them doing that
then I try to point out that you can use Tahoe-LAFS without using a
web browser, thus avoiding most of the vulnerabilities. You can use
the CLI—the Tahoe-LAFS command line tool—or FUSE integration instead
of the WUI.)

There are many other differences, of course! They let old and unloved
content die to make room for fresher and more popular content; we stop
accepting new writes if the storage servers run out of space. They use
Java; we use Python. They have an awesome name; we have a terrible
name. And so on. We could probably learn even more from each other
than we already have.

Regards,

Zooko

http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1408 # accounting using bitcoins
http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1427 # Differences
between Freenet and Tahoe

[1] http://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/frontends/webapi.rst
[2] http://tahoe-lafs.org/hacktahoelafs/
_______________________________________________
Tech mailing list
Tech< at >freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech

Re: help me, please,to implement project of storing datas on cellular phones

DmitryTurin.narod.ru — 2012-02-05T21:25:51

ideas are stated
on russian language on the
 http://dmitryturin.narod.ru/rah.htm
on english language on the
 http://dmitryturin.narod.ru/rah-en.doc

help me, please,to implement project of storing datas on cellular phones

DmitryTurin.narod.ru — 2012-02-05T21:22:14

_______________________________________________
Tech mailing list
Tech-RdDMkVZAZeuJnvDnx1genB2eb7JE58TQ< at >public.gmane.org
http://freenetproject.org/cgi-bin/mailman/listinfo/tech

Re: imap and talktalk.net

Matthew Toseland — 2011-11-05T14:00:44

What does this have to do with freenetproject.org? :)
_______________________________________________
Tech mailing list
Tech-RdDMkVZAZeuJnvDnx1genB2eb7JE58TQ< at >public.gmane.org
http://freenetproject.org/cgi-bin/mailman/listinfo/tech

imap and talktalk.net

Anthony Dynes — 2011-09-26T10:58:26

Hi,
     my IP provider is talktalk.net, (bad choice maybe) which dos not carry imap, i have set up thunderbird 6 as specified on the website, after a while it will say localhost in the bottom left corner, if i try to download a message say from gmail it will ask for my password, which it will not except, can you help me short of getting a new IP provider.

                                                                                                                                                  Many Thanks

                                                                                                                                                         Anthony

_______________________________________________
Tech mailing list
Tech-RdDMkVZAZeuJnvDnx1genB2eb7JE58TQ< at >public.gmane.org
http://freenetproject.org/cgi-bin/mailman/listinfo/tech

Re: Freenet on a mesh network

Matthew Toseland — 2011-07-06T19:26:02

It's not a bad idea in principle. But there are many problems:
1. Freenet needs long links as well as short links. Any other scalable routing protocol probably has the same issue, but Freenet in particular needs a lot of short links and a few long links for routing to work.
2. Whatever you build, you'll need some way to exchange data between different towns or cities. One obvious possibility is to move data on a USB stick or a hard disk. This won't be part of end-to-end routing for freenet (at least not until we have long term requests, in the distant future), but if you are using freenet you could use binary blobs to move chosen content between disconnected darknets in each city.
3. Generally wifi doesn't work all that well in pure ad hoc mode. Scaling is a problem above a few thousand nodes. Especially if everyone wants to use the cheapest possible antennas at ground level (in theory directional links at rooftop level could scale a bit better). New technology (e.g. better MIMO) may help.
4. Freenet cannot take advantage of various properties of radio that other protocols might be able to.
5. Freenet tends to assume high uptime (nodes are switched on a large proportion of the time), and in darknet mode (the safest) only talks to your friends. If they are a long way away you'll need to route the packets there, and it won't be very efficient, as they'll have to be repeated many times before they even reach the next freenet-hop. And then multiply this by several hops on freenet...
6. In principle the frequencies can be jammed and/or the nodes can be found.

I'm not saying mesh networks and freenet don't combine for underground communications... in principle it seems like a good idea ...

Another key point: It may make sense to have automatic rendezvous when people's phones are within range of each other, rather than fixed nodes. An "opennet" version of this is called Haggle, have a look at it. Being opennet, they will talk to any node within range, so there is some worry over the fact that your phone will be broadcasting your desire for the latest illegal blog post...

IMHO any underground network like that would probably have some parts be wifi, some of it very directional and hidden, some of it illegal satellite internet hookups, and some parts sneakernet (either swapping disks for long range transport, or possibly between friends for reasonable bandwidth but very high latency, or some sort of phone-rendezvous thing). Probably it would have very high latency in parts, and Freenet can't do that just yet, but some people (me) think it should eventually, or something like Freenet might.
_______________________________________________
Tech mailing list
Tech-RdDMkVZAZeuJnvDnx1genB2eb7JE58TQ< at >public.gmane.org
http://freenetproject.org/cgi-bin/mailman/listinfo/tech

Re: Freenet on a mesh network

Tom Sparks — 2011-06-21T22:56:05

From: Sheref Younan <sherefyounan-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>
Subject: [Tech] Freenet on a mesh network
To: tech-RdDMkVZAZeuJnvDnx1genB2eb7JE58TQ< at >public.gmane.org
Received: Wednesday, 22 June, 2011, 6:07 AM

Hi,I'm wondering about the feasibility to use Freenet over a mesh network independent of the internet. Where every Freenet node will be a node in the mesh, nodes will communicate with neighbours  via WiFi or other wireless communication medium without the need of conventional Internet as a communication medium.

This will have the advantage of offering a scalable and decentralized network that will not need an existing Internet infrastructure and will (among other things) resist block outs like the infamous one made in Egypt during its revolution (January 2011)

any ideas, comments ?

Could work if you have some allways-on nodes
you'll have submit freesites to the network....

you'll also need to setup a lampp server to tell people about the service are on the network before they download freenet

Thanks,Sheref Younan 

--

tom_a_sparks "It's a nerdy thing I like to do"

Please use ISO approved file formats excluding Office Open XML - http://www.gnu.org/philosophy/no-word-attachments.html

3 x (x)Ubuntu 10.04, Amiga A1200 WB 3.1, UAE AF 2006 WB 3.X, Sam440 AOS 4.1.2

Wanted: RiscOS system, GEOS system (C64/C128), Atari ST, Apple Macintosh (68k/PPC only)

-----Inline Attachment Follows-----

_______________________________________________
Tech mailing list
Tech-RdDMkVZAZeuJnvDnx1genB2eb7JE58TQ< at >public.gmane.org
http://freenetproject.org/cgi-bin/mailman/listinfo/tech_______________________________________________
Tech mailing list
Tech-RdDMkVZAZeuJnvDnx1genB2eb7JE58TQ< at >public.gmane.org
http://freenetproject.org/cgi-bin/mailman/listinfo/tech

Freenet on a mesh network

Sheref Younan — 2011-06-21T20:07:42

Hi,
I'm wondering about the feasibility to use Freenet over a mesh network
independent of the internet. Where every Freenet node will be a node in the
mesh, nodes will communicate with neighbours  via WiFi or other wireless
communication medium without the need of conventional Internet as a
communication medium.

This will have the advantage of offering a scalable and decentralized
network that will not need an existing Internet infrastructure and will
(among other things) resist block outs like the infamous one made in Egypt
during its revolution (January 2011)

any ideas, comments ?

Thanks,
Sheref Younan
_______________________________________________
Tech mailing list
Tech-RdDMkVZAZeuJnvDnx1genB2eb7JE58TQ< at >public.gmane.org
http://freenetproject.org/cgi-bin/mailman/listinfo/tech

Re: Freenet on a Delay-tolerant network

Matthew Toseland — 2011-06-08T16:26:33

I don't have time to look into it in detail right now. However I will give you my standard view:
- This sounds a lot like Haggle. Opportunistic forwarding, local broadcast and all that.
- It's equivalent to standing on a bus and asking if anyone has a copy of your favourite illegal file. I hope it works but I don't see it as being closely related to Freenet. However...
- Medium term, Freenet will be largely darknet - that is, friend to friend - and will have support for hiding its traffic via simple steganography.
- Long term, in particularly hostile environments, even stego'ed darknet transports are detectable and/or blockable.
- Therefore, we would like to support high latency transports (which are still darknet), for instance exchanging USB keys with your friends regularly (aka sneakernet), or automatically transferring data between your phone and his when you are physically in close proximity. We would also envisage underground wifi links etc making up some part of such a network, which theoretically could run even in places like North Korea or Cuba where the internet is illegal, even if there is no outside world to tunnel to (or it is infeasible to tunnel to it) or more prosperous countries with heavy internet restrictions (e.g. blocking peer to peer in general, whitelists etc).
- To make any of this work we will need long-term requests (i.e. very high latency, can be forwarded when the originator is offline), which are probably necessary for practical darknets anyway in many cases, and publish/subscribe or something similar (e.g. passive requests), which are very important but on a system with high per hop latency are enormously important.
- However, we would retain the ability to request data which is many hops away. It would just be very high latency (not necessarily low bandwidth though).
- Freenet is actually reasonably well set up to provide a user interface for high latency requests - e.g. downloads are queued and the user gets notified later; even with freesites, you can bookmark them and be notified on an update, or when they fail to load you can queue them as a download.
- One technical challenge will be how to route on such a high latency darknet. Currently we rely on swapping locations to make the network navigable.
- In the shorter term, we'd like to implement an easy means to move data from one darknet to another, without having to know the private keys for the freesites being moved. This is called "binary blobs".

http://new-wiki.freenetproject.org/Steganography
http://wiki.freenetproject.org/HardStego
_______________________________________________
Tech mailing list
Tech-RdDMkVZAZeuJnvDnx1genB2eb7JE58TQ< at >public.gmane.org
http://freenetproject.org/cgi-bin/mailman/listinfo/tech

Freenet on a Delay-tolerant network

Tom Sparks — 2011-06-01T17:35:21

How would Freenet work on a delay-tolerant network like Probabilistic Routing Protocol using History of Encounters and Transitivity (PRoPHET) [1] ?

 [1] http://tools.ietf.org/html/draft-irtf-dtnrg-prophet

--
tom_a_sparks "It's a nerdy thing I like to do"
Please use ISO approved file formats excluding Office Open XML - http://www.gnu.org/philosophy/no-word-attachments.html
3 x (x)Ubuntu 10.04, Amiga A1200 WB 3.1, UAE AF 2006 WB 3.X, Sam440 AOS 4.1

Re: Solution to churn problem and possibly to the PitchBlack attack

Matthew Toseland — 2011-06-01T14:09:58

Good question. I'm not entirely sure, some of them are in our git repositories.
https://github.com/freenet/

One extreme option is to use many nodes in a single JVM. This gives accurate but very slow simulations. See src/freenet/node/simulator/ in freenet's source for this.

You will probably have to write your own though. :|
_______________________________________________
Tech mailing list
Tech-RdDMkVZAZeuJnvDnx1genB2eb7JE58TQ< at >public.gmane.org
http://freenetproject.org/cgi-bin/mailman/listinfo/tech

Re: Solution to churn problem and possibly to the PitchBlack attack

Pierre Abbat — 2011-06-01T04:33:39

There's no mention of a level in the source code. Where are the other 
simulators? There's also no swapping that I could see in the simulator.

Pierre