Steve Dougherty | 29 Aug 00:31 2015

Freenet 0.7.5 1471-pre1

Freenet unstable testing prerelease 1471-pre1 is now available.

WebOfTrust now has an updatable testing version built and maintained by
xor. It currently offers build 17, which has performance improvements.
To use it, unload WebOfTrust, then load "WebOfTrust Testing Versions" on
the Plugins page. As built by xor it requires Java 7 but will work with
Java 6 in the stable release.

Sites can now set favicons with <link ref="icon" type=... href=...>.

Some things need to be implemented before the stable release:

* 1471 will be the last build to work with Java 6. It will refuse to
  auto-update to a build requiring a newer version
* updated wrapper binaries, which should fix some failures to start,
  especially with non-Latin in the path to the working directory.

I'll reply with keys once inserts are complete.

- Steve

---
David ‘Bombe’ Roden (2):
      Fix potential resource leak
      Allow icons in <link> tags

Florent Daigniere (21):
      Fix CID-122355: Resource leak in Metadata.java
      Fix CID-74397: Indefinite wait in RealCompressor
      Fix CID-122317: Indefinite wait in FCPConnectionOutputHandler
(Continue reading)

Matthew Toseland | 22 Aug 16:30 2015
Picon
Picon

Who originally proposed Bloom filter sharing?

I'm hoping to do a university project next year including implementing
Bloom filter sharing in Freenet. I recall talking to a theorist who said
he'd been assuming we had it for years in simulations and it boosted
success rates by about 10%. Who originally proposed this, and why do we
expect it to work well even on idealised simulated networks? IMHO there
are good reasons to expect it to work well in practice because of the
chaotic nature of real networks - but there's a tradeoff with connection
churn on opennet, I'm initially assuming we only have bloom filters on
darknet.

There is a paper in 2004 that incorporates it as part of a proposal for
enhancing Freenet. There's another one in 2002 for a small world p2p
system based on bloom filter sharing, and one that looks like it
inspired work on Gnutella. I was under the impression that this was one
of the things proposed in 2000-2001 before I arrived by Oskar et al, but
I can't find it. The mailing lists/bug tracker/wiki go back to ~ 2009.

Bloom filter sharing essentially means telling our peers what's in our
datastore, in a compressed form that occasionally gets false positives.
Hence we can effectively check all our peers' stores when handling a
request, and potentially find a shorter, cheaper route to the data. This
is faster and more secure than actually asking our peers. Note that we
don't store our own / high HTL requests in the datastore anyway so there
is no real security issue here, only losing some dubious aspect of
"plausible deniability" re our datastore contents.

Some papers I've found so far:
http://arxiv.org/pdf/cs/0209031.pdf
- 2002 small world p2p using bloom filter sharing

(Continue reading)

Arne Babenhauserheide | 19 Aug 01:11 2015
Picon

Fundraising opportunity

Here’s something we should have a look at:

http://www.state.gov/j/drl/p/245721.htm State Department funding opportunity announced  Funding
Theme #2: Digital Safety: Support, training and information resources that contribute to greater
digital safety for users in Internet repressive societies, traditional human rights organizations,
and/or at-risk populations 

Best wishes,
Arne
--
singing a part of the history of free software: 

- http://infinite-hands.draketo.de

_______________________________________________
Devl mailing list
Devl <at> freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
xor | 18 Aug 16:54 2015

Another fundraising idea

Hey folks,

I recently noticed that one of our official plugins has an "About" menu which 
shows a Bitcoin address to donate to the author (KeyUtils that is).

Nobody has complained about that yet, and I also think it's OK: If you give 
away free stuff such as software, you're doing people a favor, and for that 
favor you're OK to ask them for donations in a non-intrusive way.

Why not do this with the fred web interface?
Our users are the people who have the most interest in Freenet, and thus are 
the most likely to donate.

Additionally, it might be the easiest solution to implement the idea 
"fundraising progress bar like Wikipedia, where 100% = 1 year of funding":
Fred already *has* code to render progress bars for downloads.

I think this would be pretty easy to implement with the existing fred code:
I would suggest we add this as a user alert using our regular user 
notification structure. If you think this is too intrusive, it might even 
maybe be possible to make the alert register in a way which causes the "N 
notifications" counter to not increase; i.e. the alert would not distract the 
user from his business, it would only be visible if the user goes to the page 
anyway.

It should have a "Dismiss until next funding emergency" button which should 
dismiss it until either:
- 1 year has passed.
- the project funds have gone to "$ 0" (where 0 would be something like $1000 
to guarantee that we can still pay the webserver for a long time). We could 
(Continue reading)

Steve Dougherty | 17 Aug 00:28 2015

Freenet 0.7.5 build 1470 released

This release fixes Freemail problems that prevented sending mail, and
removes a compromised opennet seed node. Freemail also gains changes to
IMAP / SMTP handling, a new message link on the inbox page, links to
senders' WoT profiles, and new translations:

  - Czech
  - Greek
  - Spanish
  - Finnish
  - Hungarian
  - Dutch
  - Polish
  - Portuguese (Portugal)
  - Serbian
  - Turkish

To clarify, the CHK metadata bug fixes in 1468 are added as a new
compatibility mode that is not yet the default. Compatibility with 1416
keys is available.

The Fred Spanish translation has comprehensive updates as well.

- Steve Dougherty

Freemail v0.2.7.1:
---
David ‘Bombe’ Roden (18):
      Remove “delete on finalize” constructor parameter
      Add convenience method for the “seen” IMAP flag
      Add convenience method for the “deleted” IMAP flag
(Continue reading)

xor | 15 Aug 12:31 2015

New WOT version finished: Version 0.4.3 build0016

I would be happy if this could be included in the Freenet release on Sunday as 
it fixes the outrageous "WOT creates thousands of threads" issue.

Changelog as specified in tag build0016 follows...

Web of Trust Version 0.4.3 build0016
---------------------------------------------------------

SUMMARY AND OUTLOOK - detailed changelog is below:

The main goal of this build is to improve the very poor latency of the
web interface.
This is done by redesigning the way fetched Identity XML files are
processed.
Previously, each file would be processed in a thread of its own, even
though the actual processing requires a single lock which can only be
taken by one thread at once. This did cause processing to be effectively
single-threaded, while hundreds or even thousands of threads would be
piling up when competing for the single lock.
With this build, processing is redesigned to queue fetched XML files to
disk and process them one-by-one on a single thread.
As a result, the web interface thread now does not have to compete
against hundreds of threads who want the same lock.
This will result in much lower latency of the web interface, especially
if your WOT is not permanently running and thus at startup has to
process many identity files in bulk.

There are some more benefits which are listed in the detailed changelog
below.

(Continue reading)

Matthew Toseland | 14 Aug 15:27 2015
Picon
Picon

Re: An idea for load management

On 12/08/15 22:20, Arne Babenhauserheide wrote:
> Am Mittwoch, 12. August 2015, 19:45:11 schrieb Matthew Toseland:
>> On 12/08/15 19:42, Arne Babenhauserheide wrote:
>>> Am Sonntag, 9. August 2015, 12:14:59 schrieb Matthew Toseland:
>>>> - When load is high, we tend to kill requests which are close to the
>>>> originator. (But without directly using HTL)
>>> This only works when not using opennet FOAF routing.
>> I don't see why that would affect this?
> Because it partially decouples closeness of the node from distance to the receiver.
>
> After thinking about it a bit, I’m not sure though if this will really
> be a problem. After 3-4 hops, the distances are pretty close.
Close hop-wise should still be a reasonable proxy for close
location-wise. And we want to kill requests that are far from the target
location-wise IMHO, for efficiency as well as for pushing back to the
originator. Although maybe this would have bad effects on nodes with
very poor connectivity?
>
> Best wishes,
> Arne
>
> PS: Feel free to move this back onto the list.
> --
> singing a part of the history of free software: 
>
> - http://infinite-hands.draketo.de

_______________________________________________
(Continue reading)

Matthew Toseland | 9 Aug 13:14 2015
Picon
Picon

An idea for load management

For bulk requests:
- Queue incoming requests.
- Implement strict round robin between peers.
- If a request is not accepted in X period, *the request is killed*, not
rerouted.
- Within a peer's round-robin slot, always accept the request closest to
this node's location, regardless of age.

Interesting consequences:
- When load is high, we tend to kill requests which are close to the
originator. (But without directly using HTL)
-- This achieves the effect of slowing down the originator without
depending on the originator behaving fairly.
-- It also prevents request rates from giving away information about the
originator.
- Overall more requests will be terminated, wasting a bit more
bandwidth. But hopefully mostly early on, so the impact shouldn't be too
bad.
- Overall much less mis-routing in response to load.
- If a request is killed, we'll usually be able to try a different key
(for a splitfile), but if we really need it we'll try a different peer
(per-node failure tables).
- This might make per-node failure tables weaker by killing requests
more often; we might need to allow more retries before RecentlyFailed
kicks in. However, RecentlyFailed seems to be causing glitches at the
moment anyway.
- Location is only taken into account within a node's RR slot, so DoS
attacks by sending lots of bogus requests near our location are not
effective.
- Simpler than the current scheme (at least conceptually!).
(Continue reading)

Steve Dougherty | 3 Aug 14:11 2015

Inconsistent freenet.crypt.MessageAuthCodeTest failures

Hi everyone / Charles,

We're running into seemingly distro-specific failures to raise a
NullPointerException:

freenet.crypt.MessageAuthCodeTest.testVerifyDataNullInput1
freenet.crypt.MessageAuthCodeTest.testVerifyNullInput1
freenet.crypt.MessageAuthCodeTest.testVerifyNullInput2

The first fails with:

junit.framework.AssertionFailedError: MACType: HMACSHA256
 	at
freenet.crypt.MessageAuthCodeTest.testVerifyDataNullInput1(MessageAuthCodeTest.java:352)

and the latter two with:

Expected exception: java.lang.NullPointerException.

We have yet to find a reason for this difference. These pass on Debian -
both Wheezy and sid - but fail on Arch and Fedora 22. Debian has Java
1.6 / 1.8, Arch has Java 1.7, and Fedora has 1.8. Arch, Fedora, and
Debian all have JUnit 4.12 / Hamcrest 1.3.

Any suggestions for what to look into next?

Thanks,
Steve

(Continue reading)

Ian Clarke | 31 Jul 10:05 2015

Thoughts on FProxy

In the years since we designed FProxy, UI design has come a long way.  In a
sense we were ahead of our time, since many desktop GUIs are now
implemented as web apps (eg. Slack), although embedded in native containers.

In more recent years a stack of tools have emerged for designing webapps.
JavaScript is growing up, ES6
<http://weblogs.asp.net/dwahlin/getting-started-with-es6-%E2%80%93-the-next-version-of-javascript>
supports some nice language features like a compact lambda syntax, and
pre-processors like TypeScript <http://www.typescriptlang.org/> introduce
static typing, while allowing use of ES6 features on browsers that don't
yet support it.

Bootstrap <http://getbootstrap.com/> allows non-designers (ie. us) to build
pretty UIs, and React <http://facebook.github.io/react/> allows concurrent
updates of the UI in a convenient form.  GraphQL
<http://facebook.github.io/react/blog/2015/05/01/graphql-introduction.html>
is an emerging replacement for REST for client-server communication (and a
library <https://github.com/andimarek/graphql-java> exists for server-side
Java support), although it's still quite early.

Reading this article
<http://draketo.de/english/freenet/forgotten-cryptopunk-paradise> in
particular, it hits home the potential Freenet could have with a modern UI,
and the tools now exist for us to build a solid UI even if UI design isn't
the core competency of the typical Freenet volunteer.

Thoughts?

Ian.
_______________________________________________
(Continue reading)

Ian Clarke | 31 Jul 09:34 2015

Great series of Freenet articles

I'm surprised I didn't see these earlier: http://draketo.de/english/freenet

This one is quite recent:
http://draketo.de/light/english/freenet/communication-primitives-1-files-and-sites

Ian.
_______________________________________________
Devl mailing list
Devl <at> freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Gmane