date:20080508

> - $out .= '::  ';
> - 
> - foreach ( $pages as $userlang => $path ) 
> - {
> - foreach ( $languages as $abbr_lang_name => 
> $full_lang_name ) 
> - {
> - if ($userlang == $abbr_lang_name) 
> - {
> - $out .= ' href="'.$abbr_lang_name.'/'.($page ? $page : 
> "index").'.html">'.$full_lang_name.'  ::  ';
> - }
> - }
> - }
> - 
> - $out .= '';
> - }   
> - }   
> - return $out;
> - 
> -}
> - 
> -if (isset($_REQUEST["lang"])) 
> -{
> - $lang_q = array( $_REQUEST["lang"] => '1' );
> - $lang = $_REQUEST["lang"];
> -}
> -else
> -{
> - $lang_q = setLanguage();
> -}
> -
> -if (isset($_REQUEST["page"])) {
> - $page = htmlentities($_REQUEST["page"]);
> - $file = selectPage($lang_q, $page); 
> - if(!file_exists($file) )
> - {
> - header('HTTP/1.0 404 Not Found');
> - if(empty($_SERVER["HTTP_REFERER"]) || 
> empty($_SERVER["REQUEST_URI"])){
> - header("Location: /");
> - }else{
> - echo "404";
> - echo "404 error - broken link";
> - $to="webmaster";
> - $subject="404 error";
> - $content="\nA 404 error has occurred on the website : 
> may you fix it ?\nFrom :  ".$_SERVER["HTTP_REFERER"]."\nTo : 
> ".$_SERVER["REQUEST_URI"]."\nAt : ".date("D M j Y g:i:s a T"."\nUser-agent : 
> ".$_SERVER["HTTP_USER_AGENT"]);
> - @mail($to,$subject,$content,"svn-build");
> - }
> - die;
> - }
> -} else {
> - $page = "index";
> - $lang_q = setLanguage();
> - $file = selectPage($lang_q, $page);
> -}
> - 
> -?>
> \ No newline at end of file
> 
> Modified: trunk/website/index.php
> ===
> --- trunk/website/index.php   2008-05-08 09:23:12 UTC (rev 19835)
> +++ trunk/website/index.php   2008-05-08 09:28:07 UTC (rev 19836)
> @@ -1,5 +1,14 @@
>
> +if (!isset($_REQUEST["rewritten"])) {
> + $currentURI = "$_SERVER["REQUEST_URI"]";
> + $newURI = ereg_replace("/test\.php\?page=(.+)","/$1.html",$currentURI);
> + header("Request-URI: $newURI");
> + header("Content-Location: $newURI");
> + header("Location: $newURI");
> + die;
> +}   
> +
>  include 'includes/common.inc.php';
>  
>  ?>
> 
> Modified: trunk/website/pages/de/fairshare.php
> ===
> --- trunk/website/pages/de/fairshare.php  2008-05-08 09:23:12 UTC (rev 
> 19835)
> +++ trunk/website/pages/de/fairshare.php  2008-05-08 09:28:07 UTC (rev 
> 19836)
> @@ -2,7 +2,7 @@
>Ian Clarke - 29. M?rz 2001
>
>Dies ist die deutsche ?bersetzung des Artikels. Die englische
> -  Originalversion finden Sie  +  Originalversion finden Sie >hier.
>  
>Einleitung
> @@ -120,4 +120,4 @@
>des Effekts von Freenet auf das Urheberrecht bekamen, uns dazu gebracht hat
>?ber dieses Problem nachzudenken.
>
> -  
> \ No newline at end of file
> +  
> 
> Modified: trunk/website/pages/de/news.php
> ===
> --- trunk/website/pages/de/news.php   2008-05-08 09:23:12 UTC (rev 19835)
> +++ trunk/website/pages/de/news.php   2008-05-08 09:28:07 UTC (rev 19836)
> @@ -6,7 +6,7 @@
>  Neuigkeiten
>  
>  Die deutsche Übersetzung der Neuigkeiten (Stand vom 5.4.2008)
> -ist evtl. veraltet, die Englische 
> Version
> +ist evtl. veraltet, die Englische Version
>  sollte aber auf dem neusten Stand sein.
>  
>  
> 
> ___
> cvs mailing list
> cvs at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/cvs


-- 
Follow the blue rabbit - The Freenet Project - http://freenetproject.org/

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20080508/351b78c3/attachment.pgp>

[freenet-dev] What to do with the 0.5 related stuffs?

2008-05-08 Thread Ringo Kamens

I think we should keep .5 stuff around, since a lot of things link to
it but there's no reason to advertise it. Also, I get the feeling that
lots of freenet users don't trust .7 yet and that the .5 community
will continue to flourish for quite some time.
Comrade Ringo Kamens

On Thu, May 8, 2008 at 10:39 PM, Florent Daigni?re
 wrote:
> Hi,
>
>I'm currently in the process of cleaning up our server... And
>I'm planning to get rid of all the .5-related stuffs now that
>0.7 is officially released. That includes our builds and
>seednode files hosted on downloads.freenetproject.org, a *lot*
>of apache redirection for old URLs and the short mention of it
>on the download page of our website.
>
>Obviously we will keep the source code in our svn-tree.
>
>Any objection? If so, object soon or never.
>
> NextGen$
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFII7lDU/Z/dHFfxtcRAt+vAKDC8m40MX5p0NkC7ucmorH5W8preACeKnhy
> 2GUom+T8MaIlTdfNuw75TVQ=
> =aENc
> -END PGP SIGNATURE-
>
> ___
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>

Re: [freenet-dev] Post-0.7.0 priorities

2008-05-08 Thread Victor Denisov

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

| Automatic bandwidth calibration. Other p2p apps have this, we should
have it.

Good idea. Also, we should definitely look into better utilizing
available bandwidth. Freenet's the only p2p app which consistently
underutilizes my upload limit (~ 2 Mbit/s out of 8 Mbit/s of link
capacity). I understand that we don't want to create supernodes, but
come on, 2 Mbit/s is *nothing* these days.

| Client layer changes: I propose to move the entire client layer onto
disk. We

I say this deserves to be moved to High or Very High priority. The main
problem is not memory usage as is (most people have 1 Gb+ of RAM now),
but rather inability of Java to properly grow and shrink its memory
usage on the "as needed" basis. Not a single native Windows application
behaves this way, and I doubt many users are prepared to understand and
adjust memory limits manually. Heck, even I, being a Java developer,
spent several days trying to understand what heap limit to set for
Freenet so that it won't run out of memory (and that it uses ~ 2x memory
on 64-bit JVM doesn't help any). Also, perhaps we can detect OOM errors
and offer the user to increase the memory limit next time he tries to
run Freenet?

| Auto-update for plugins: We should have had this ages ago. Several
people have

Shouldn't we consider auto-updating bundled applications as well? Or
perhaps providing an auto-update API for use by third-party apps? Just a
thought.

Hope the above was helpful,

Regards,
Victor Denisov.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFII+7pS81Mh9/iCDgRAhN7AJ93mwVa2Ogqo+6JLiY2322AgPm2WwCgwYmw
DQ2jkkYDeZ07pXaoE/qH/Uo=
=WSBl
-END PGP SIGNATURE-
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Post-0.7.0 priorities

stems), easy.
Timescale: 3 days
Priority: Low.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20080508/099dc9fb/attachment.pgp>

[freenet-dev] Content Management System

Ian Clarke schrieb:
> On Thu, May 8, 2008 at 12:49 PM, Victor Denisov  
> wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>>  Hash: SHA1
>>  | consider a migration seriously. If it was up to me, we would use Trac
>>  | and only Trac (for the website, wikki and bug-tracker).
>>
>>  A quick vote of confidence for Trac. It's a *very* good piece of
>>  software, and its Wiki<->Tickets<->SVN integration is amazing. We've
>>  used it for three major projects now and had nothing but *very* positive
>>  experience.
> 
> Trac isn't a bad bugtracker, probably better than Mantis, although has
> some conspicuous limitations, such as no dependencies between bugs.
> 
> That being said, I don't think Trac is designed to be a CMS, and
> frankly I don't think its appearance is enticing as a "user facing"
> website, its even worse than the current Freenet website.  If we did
> use it, it would require some major re-theming.
> 

ACK

> I think we should look to commercial and well-funded open source
> projects for inspiration about how to make our website enticing for
> first-time visitors, while still providing the depth of information we
> need to convey.
> 
> http://getfirefox.com/ is good because its colorful, inviting, and the
> "call to action" is very clear, you don't have to spend much time
> looking for that download link!  Now, its tone may be a little too
> in-your-face for Freenet, but there are things we can learn from it.
> 

getfirefox is drupal driven

> I'm a big fan of David Watanabe's work, both the software he writes,
> and the websites he designs for them.  I'd recommend looking at:
> 
>   http://xtorrent.com/
>   http://www.inquisitorx.com/safari/
>   http://www.acquisitionx.com/
> 

The design is cool, but it's a little bit too trendy in my opinion (it's
ok for stylish apple addons, but not suitable for freenet, as it's
supposed to be secure software, not another design wonder). Also some
users who don't have the bandwith would really be annoyed by the large
pictures.
Apart from that there's not much documentation on the websites, no
navigation menu (we would definitely need one, as we have more than
three pages to offer).
I don't think we could apply a similar design to freenet.

> You could argue that all of those things have it easy, because most
> people understand what those things do, they don't need an elaborate
> explanation.  But look at Gnome's website:
> 
>   http://www.gnome.org/
> 
> It is clean, simple, yet if you need to you can quickly dig down to a
> vast wealth of information.
> 

Gnome uses Plone as it's CMS. This may be not the best choice for us
though, as Plone is Phyton based, but that's something nextgens might
know better than me.

> Either way, since we are Java hackers for the most part, not web
> designers, I strongly recommend that we borrow as much as we can from
> elsewhere, even so far as using free or creative commons HTML and CSS
> verbatim, perhaps with only a few minor changes.
> 
> Ian.
> 

Neo at NHNG
-- 
Follow the blue rabbit - The Freenet Project - http://freenetproject.org/

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20080508/54972bfb/attachment.pgp>

[freenet-dev] Content Management System

2008-05-08 Thread Victor Denisov

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

| consider a migration seriously. If it was up to me, we would use Trac
| and only Trac (for the website, wikki and bug-tracker).

A quick vote of confidence for Trac. It's a *very* good piece of
software, and its Wiki<->Tickets<->SVN integration is amazing. We've
used it for three major projects now and had nothing but *very* positive
experience.

Regards,
Victor Denisov.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIIz0rS81Mh9/iCDgRAsoSAKDSzT3tW+DaA/FkOefLAU4MUuVkfACgz8sx
QflbOaD1swFHdHMWj7Uzago=
=QlxK
-END PGP SIGNATURE-

Re: [freenet-dev] What to do with the 0.5 related stuffs?

2008-05-08 Thread Ringo Kamens

I think we should keep .5 stuff around, since a lot of things link to
it but there's no reason to advertise it. Also, I get the feeling that
lots of freenet users don't trust .7 yet and that the .5 community
will continue to flourish for quite some time.
Comrade Ringo Kamens

On Thu, May 8, 2008 at 10:39 PM, Florent Daignière
<[EMAIL PROTECTED]> wrote:
> Hi,
>
>I'm currently in the process of cleaning up our server... And
>I'm planning to get rid of all the .5-related stuffs now that
>0.7 is officially released. That includes our builds and
>seednode files hosted on downloads.freenetproject.org, a *lot*
>of apache redirection for old URLs and the short mention of it
>on the download page of our website.
>
>Obviously we will keep the source code in our svn-tree.
>
>Any objection? If so, object soon or never.
>
> NextGen$
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFII7lDU/Z/dHFfxtcRAt+vAKDC8m40MX5p0NkC7ucmorH5W8preACeKnhy
> 2GUom+T8MaIlTdfNuw75TVQ=
> =aENc
> -END PGP SIGNATURE-
>
> ___
> Devl mailing list
> Devl@freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] [freenet-cvs] r19836 - in trunk/website: . includes pages/de

* Michael Tänzer <[EMAIL PROTECTED]> [2008-05-08 23:35:21]:

> Some of your changes broke the link to the English news site on the
> German one. The old link doesn't work either.
> We need that link because the news section needs to be up to date and I
> can't always translate it in real time.

Okay, what's the exact url of the broken link ?


signature.asc
Description: Digital signature
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Post 0.7 idea: off-grid darknet!

swapping.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20080508/8fee3468/attachment.pgp>

[freenet-dev] What to do with the 0.5 related stuffs?

Hi,

I'm currently in the process of cleaning up our server... And
I'm planning to get rid of all the .5-related stuffs now that
0.7 is officially released. That includes our builds and
seednode files hosted on downloads.freenetproject.org, a *lot*
of apache redirection for old URLs and the short mention of it
on the download page of our website.

Obviously we will keep the source code in our svn-tree.

Any objection? If so, object soon or never.

NextGen$


signature.asc
Description: Digital signature
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Freenet 0.7.0 released!

The Freenet Project is very pleased to announce the release of Freenet 0.7.0.

Freenet is software designed to allow the free exchange of information over
the Internet without fear of censorship, or reprisal. To achieve this
Freenet makes it very difficult for adversaries to reveal the identity,
either of the person publishing, or downloading content. The Freenet project
started in 1999, released Freenet 0.1 in March 2000, and has been under
active development ever since.

Freenet is unique in that it handles the storage of content, meaning that if
necessary users can upload content to Freenet and then disconnect. We've
discovered that this is a key requirement for many Freenet users. Once
uploaded, content is mirrored and moved around the Freenet network, making it
very difficult to trace, or to destroy. Content will remain in Freenet for
as long as people are retrieving it, although Freenet makes no guarantee that
content will be stored indefinitely.

The journey towards Freenet 0.7 began in 2005 with the realization that some
of Freenet's most vulnerable users needed to hide the fact that they were
using Freenet, not just what they were doing with it. The result of this
realization was a ground-up redesign and rewrite of Freenet, adding
a "darknet" capability, allowing users to limit who their Freenet software
would communicate with to trusted friends. This would make it far more
difficult for a third-party to determine who is using Freenet.

Freenet 0.7 also embodies significant improvements to almost every other
aspect of Freenet, including efficiency, security, and usability. Freenet is
available for Windows, Linux, and OSX. It can be downloaded from:

http://freenetproject.org/download.html

This release would not have been possible without the release of numerous
volunteers, and Matthew Toseland, Freenet's full time developer. Matthew's
work is funded through donations via our website (as well as a few larger
sponsors from time to time). We ask that anyone who can help us to ensure
Matthew's continued employment visit our donations page and make a
contribution at:

http://freenetproject.org/donate.html
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080508/22148572/attachment.pgp>

[freenet-dev] Content Management System

* Michael T?nzer  [2008-05-08 17:41:55]:

> Florent Daigni?re schrieb:
> > * Michael T?nzer  [2008-05-08 05:04:07]:
> > 
> >> In the last few weeks I've done some work on the website. While
> >> translating it, there were some things that struck me so I changed them.
> >> But our site is still far from perfect. It lacks a attractive design and
> >> some features that would be quite handy (e.g. select the language by
> >> hand, RSS-Feeds, a search) but are a little bit difficult to implement
> >> (at least if we want to do it in a safe and efficient way) or at least I
> >> don't have the time and skills to do it.
> > 
> > Select language by hand is trivial to implement and we can delegate the 
> > search
> > to google so that's trivial too... okay RSS would require some work
> > 
> 
> I know it's not that hard to do but someone actually has to do it.

No one has bothered that's why it hasn't been done.

[snip.]

> > At the moment we are using mantis as a BTS, Wikka as a wiki-engine, a
> > home-maid website and *loads* of custom scripting for almost
> > everything... How do you plan to migrate existing content ?
> > 
> 
> The fully custom made site is one of the problems, as we are not experts
> in some of the things we did. I saw that you fixed some security issues
> in our php code today, some issues that dealt with character escaping
> and such things.

The broken code wasn't mine! I have already fixed the exact same bug 3
years ago and someone reintroduced it since then!

We should really have regression tests; even for the website.

> I'm no PHP expert but I think these are things which
> are obvious to a professional php-developer but can completely break our
> security, which means if some  here> guy used this issue to hack into our server and replace the
> binaries we provide, then this could be rather dangerous for our users.
> 

I'm not a fan of security by obscurity but let's face it: we have fixed
only a few security related bugs in the last few years... Drupal had many
more (and that's logical given that it's a gaz plant compared to our
requirements). Their last release was on the 9th of April and guess
what? It's a security bugfix!

> What I want to say: If you're not absolutely sure about what you're
> doing, leave it to the pros, they know how to deal with it, and we can
> concentrate on what we do best: provide our users with tools to give
> them true freedom of speech.
> 

Go on with that logic... and we end up being dependant on a 3rd party
entity. We left SourceForge because their service wasn't up to our
expectations anymore and at the time there was no good alternative.

> It's probably not possible to migrate in two days but it seems that now
> is a good point to start the process, as Ian mentioned he wanted to
> change the website significantly (this also includes the texts). We
> probably should migrate in a soft way and try it in a test environment
> first. The Website would be a good point to start with because it has
> not so much content on it. The other things could be done step by step,
> or never if we want to keep them (e.g. I'm not quite convinced about
> drupals bug tracker, but there are definitely better wiki engines than
> wikkawiki).

I don't share your views here. Either we switch to a CMS and use it for
everything or we don't.

They are good and bad reasons to switch to a CMS: I don't think that
security is a good one. As you've highlighted, our website doesn't
evolve much and has a long history; that's why it's pretty secure
overall. On the other hand, integration of services into the CMS
is a good reason to make the switch. Find a CMS which has a good
integration with mantis or can import its tickets and then we can
consider a migration seriously. If it was up to me, we would use Trac
and only Trac (for the website, wikki and bug-tracker).

A few weeks ago someone asked me to set a blog engine up (Wordpress), I
did and so far no one used it... We obviously don't want the same thing
to happen with a Drupal, do we ?
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20080508/f1fd2e16/attachment.pgp>

Re: [freenet-dev] Post 0.7 idea: off-grid darknet!

On Friday 09 May 2008 01:23, Daniel Cheng wrote:
> On Fri, May 9, 2008 at 2:58 AM, Matthew Toseland
> <[EMAIL PROTECTED]> wrote:
> > On Thursday 08 May 2008 01:41, Matthew Toseland wrote:
> >> https://bugs.freenetproject.org/view.php?id=2345
> >>
> >> ---
> >> A typical domestic internet connection has at most 1Mbps uplink. In some
> >> megacities 100Mbps or even 1Gbps is available (symmetric), however it is
> >> unlikely that the bandwidth available in most homes will exceed a few
> >> megabits in the near future.
> >>
> >> We could implement darknet sneakernet connections by exchanging USB 
sticks.
> >> E.g. if you meet somebody every day (e.g. a coworker), you could exchange
> >> (cheap) 8G sticks, plug them in overnight, and then do the same again the
> >> next day. This would produce approx 100K/sec (1Mbps) each way for each
> > person
> >> you did it with.
> >>
> >> The performance here imho isn't world-shattering, but nonetheless it's
> >> interesting. And it would build the darknet, some of it completely 
off-grid,
> >> work in many places where nothing else does safely, and get us some great
> >> headlines.
> >> ---
> >>
> >> IMHO this is something we should seriously consider, if not this year, 
then
> > at
> >> least next year during the 0.8 cycle. The main technical prerequisite is
> >> token passing load management, unless we implement a completely different
> >> load management system for it. True passive requests would help in that
> >> they'd make publish/subscribe work much better on this. Even if it's not
> >> perfect, it'd be a very interesting way to get people in, and far from 
being
> >> a publicity stunt, it would be of immense long-term value.
> >>
> >
> > Ian is of the view that this should be a separate application based on 
similar
> > principles to Freenet. I'm not. We agree that there are some significant
> > issues to deal with. I am of the view that these networks are mutually
> > complementary and therefore should talk to each other: Darknet over UDP 
isn't
> > safe in hostile environments, and off-grid darknets a) work much better if
> > parts of them are online (certainly we could expect some covert wireless
> > links in places, but being able to link to a functional on-grid darknet 
would
> > surely be a benefit; long links are going to be rare on a pure off-grid
> > darknet), and b) would be much easier to bootstrap from a working on-grid
> > darknet.
> >
> > W.r.t. code (and to some degree protocol), IMHO most of Freenet's code 
would
> > be useful to a darknet sneakernet implementation:
> > - The entire client layer could be reused. The queue is by definition a 
long
> > term structure, Fproxy offers to download stuff in the background and 
tells
> > you when it's done etc. FCP could be reused, although on a
> > pure-off-grid-darknet node, clearly they would have to use it in a 
different
> > way to what they do now.
> > - Full passive requests would be virtually identical for the two
> > implementations. ULPRs could be adapted without too much difficulty. This
> > makes FMS etc somewhat feasible, if slow, and anything that can be seen as
> > publish/subscribe (e.g. getting new editions of freesites) possible. Full
> > passive requests are a long term goal as they would have some interesting
> > advantages, but even ULPRs, with sufficient tweaking, may be sufficient to
> > make this usable.
> > - The link layer would obviously be worthless, except in the IMHO 
interesting
> > case where you have both a darknet connection *and* exchange of flash 
cards
> > going on with a peer. Thus low latency requests such as Frost traffic can 
go
> > over the link, and when you queue a big splitfile, it would fetch the top
> > blocks of the pyramid over the link, and then queue the rest to come back
> > over the following day's card exchange.
> > - Request priorities would be necessary.
> > - We probably couldn't reuse the current load limiting/management code. We
> > would in all likelihood need token passing. This is something we will need
> > long term anyway, of course.
> > - Swapping: This is probably the hardest part. Our current strategy 
involves a
> > commit/reveal protocol (4 round trips). This clearly won't work well on a
> > pure off-grid darknet. Doing a large part of the work offline will be
> > necessary, and to do that a lot of topology may need to be exposed... 
which
> > is bad because it makes life easier for a well-resourced attacker. Also, 
the
> > off-grid network may have to be partially separate in routing terms 
through
> > some sort of tiered routing (look at the network labelling code for 
something
> > related).
> > - User interface to transport: We want users to be able to just plug in a
> > bunch of USB sticks to a mini-hub, and have Freenet auto-detect that they 
are
> > formatted for it, download from them, and then upload to them, all ready 
for
> > the next day for them to be swapped back. I don't know what native support
> > this would require.
> 
>

[freenet-dev] Content Management System

Florent Daigni?re schrieb:
> * Michael T?nzer  [2008-05-08 05:04:07]:
> 
>> In the last few weeks I've done some work on the website. While
>> translating it, there were some things that struck me so I changed them.
>> But our site is still far from perfect. It lacks a attractive design and
>> some features that would be quite handy (e.g. select the language by
>> hand, RSS-Feeds, a search) but are a little bit difficult to implement
>> (at least if we want to do it in a safe and efficient way) or at least I
>> don't have the time and skills to do it.
> 
> Select language by hand is trivial to implement and we can delegate the search
> to google so that's trivial too... okay RSS would require some work
> 

I know it's not that hard to do but someone actually has to do it. And
if there is an already existent solution, why not do it with that one
instead of inventing the wheel yet another time.

>> I also noticed, that the format
>> we use to save the content (it's just a php file containing HTML which
>> is included in some kind of very simple template) leaves room for
>> optimization (for both, the author who needs to write valid HTML and
>> know about the things he can do with it (not all of us do know how to
>> write clean and valid HTML (I do not exclude myself from this
>> statement)), and the user, who might get malformed HTML or ugly pages
>> because the browser has some bugs the author didn't know of). We also
>> have the problem, that our site consists of many different components:
>> there's the homepage, the wiki, emu, SVN, which looks very fragmented.
>>
>> We could address most of this problems by using a CMS (content
>> management system).
> 
> It's not the first time it's being debated...
> 
>> Of course a CMS is not a Swiss Army knife for
>> everything and it does raise several issues: is it fast enough to
>> survive a slashdot, can we use our already existent database, how can we
>> migrate, is it safe?
> 
> Don't worry about performances for now...
> 

I don't but Ian did when I had a discussion with him about the some web
design issues recently where I mentioned CMSs.

> At the moment we are using mantis as a BTS, Wikka as a wiki-engine, a
> home-maid website and *loads* of custom scripting for almost
> everything... How do you plan to migrate existing content ?
> 

The fully custom made site is one of the problems, as we are not experts
in some of the things we did. I saw that you fixed some security issues
in our php code today, some issues that dealt with character escaping
and such things. I'm no PHP expert but I think these are things which
are obvious to a professional php-developer but can completely break our
security, which means if some  guy used this issue to hack into our server and replace the
binaries we provide, then this could be rather dangerous for our users.

What I want to say: If you're not absolutely sure about what you're
doing, leave it to the pros, they know how to deal with it, and we can
concentrate on what we do best: provide our users with tools to give
them true freedom of speech.

It's probably not possible to migrate in two days but it seems that now
is a good point to start the process, as Ian mentioned he wanted to
change the website significantly (this also includes the texts). We
probably should migrate in a soft way and try it in a test environment
first. The Website would be a good point to start with because it has
not so much content on it. The other things could be done step by step,
or never if we want to keep them (e.g. I'm not quite convinced about
drupals bug tracker, but there are definitely better wiki engines than
wikkawiki).

> Can a CMS have some level of history ? All the tools we use have
> native versioning; that's a feature we don't want to loose.

Drupal has native versioning, I think that's one of the core features
which made it one of the favourite CMSs for OpenSource projects.

Neo at NHNG

-- 
Follow the blue rabbit - The Freenet Project - http://freenetproject.org/

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20080508/571556e0/attachment.pgp>

Re: [freenet-dev] Post 0.7 idea: off-grid darknet!

2008-05-08 Thread Daniel Cheng

On Fri, May 9, 2008 at 2:58 AM, Matthew Toseland
<[EMAIL PROTECTED]> wrote:
> On Thursday 08 May 2008 01:41, Matthew Toseland wrote:
>> https://bugs.freenetproject.org/view.php?id=2345
>>
>> ---
>> A typical domestic internet connection has at most 1Mbps uplink. In some
>> megacities 100Mbps or even 1Gbps is available (symmetric), however it is
>> unlikely that the bandwidth available in most homes will exceed a few
>> megabits in the near future.
>>
>> We could implement darknet sneakernet connections by exchanging USB sticks.
>> E.g. if you meet somebody every day (e.g. a coworker), you could exchange
>> (cheap) 8G sticks, plug them in overnight, and then do the same again the
>> next day. This would produce approx 100K/sec (1Mbps) each way for each
> person
>> you did it with.
>>
>> The performance here imho isn't world-shattering, but nonetheless it's
>> interesting. And it would build the darknet, some of it completely off-grid,
>> work in many places where nothing else does safely, and get us some great
>> headlines.
>> ---
>>
>> IMHO this is something we should seriously consider, if not this year, then
> at
>> least next year during the 0.8 cycle. The main technical prerequisite is
>> token passing load management, unless we implement a completely different
>> load management system for it. True passive requests would help in that
>> they'd make publish/subscribe work much better on this. Even if it's not
>> perfect, it'd be a very interesting way to get people in, and far from being
>> a publicity stunt, it would be of immense long-term value.
>>
>
> Ian is of the view that this should be a separate application based on similar
> principles to Freenet. I'm not. We agree that there are some significant
> issues to deal with. I am of the view that these networks are mutually
> complementary and therefore should talk to each other: Darknet over UDP isn't
> safe in hostile environments, and off-grid darknets a) work much better if
> parts of them are online (certainly we could expect some covert wireless
> links in places, but being able to link to a functional on-grid darknet would
> surely be a benefit; long links are going to be rare on a pure off-grid
> darknet), and b) would be much easier to bootstrap from a working on-grid
> darknet.
>
> W.r.t. code (and to some degree protocol), IMHO most of Freenet's code would
> be useful to a darknet sneakernet implementation:
> - The entire client layer could be reused. The queue is by definition a long
> term structure, Fproxy offers to download stuff in the background and tells
> you when it's done etc. FCP could be reused, although on a
> pure-off-grid-darknet node, clearly they would have to use it in a different
> way to what they do now.
> - Full passive requests would be virtually identical for the two
> implementations. ULPRs could be adapted without too much difficulty. This
> makes FMS etc somewhat feasible, if slow, and anything that can be seen as
> publish/subscribe (e.g. getting new editions of freesites) possible. Full
> passive requests are a long term goal as they would have some interesting
> advantages, but even ULPRs, with sufficient tweaking, may be sufficient to
> make this usable.
> - The link layer would obviously be worthless, except in the IMHO interesting
> case where you have both a darknet connection *and* exchange of flash cards
> going on with a peer. Thus low latency requests such as Frost traffic can go
> over the link, and when you queue a big splitfile, it would fetch the top
> blocks of the pyramid over the link, and then queue the rest to come back
> over the following day's card exchange.
> - Request priorities would be necessary.
> - We probably couldn't reuse the current load limiting/management code. We
> would in all likelihood need token passing. This is something we will need
> long term anyway, of course.
> - Swapping: This is probably the hardest part. Our current strategy involves a
> commit/reveal protocol (4 round trips). This clearly won't work well on a
> pure off-grid darknet. Doing a large part of the work offline will be
> necessary, and to do that a lot of topology may need to be exposed... which
> is bad because it makes life easier for a well-resourced attacker. Also, the
> off-grid network may have to be partially separate in routing terms through
> some sort of tiered routing (look at the network labelling code for something
> related).
> - User interface to transport: We want users to be able to just plug in a
> bunch of USB sticks to a mini-hub, and have Freenet auto-detect that they are
> formatted for it, download from them, and then upload to them, all ready for
> the next day for them to be swapped back. I don't know what native support
> this would require.

Binary Blobs (.fblob)?

> Based on the above, IMHO this *might* be feasible, it becomes a lot more
> interesting after some of the features we have planned for 0.7.1/0.8 have
> been implemented, but even then there are some major problem

[freenet-dev] Post-0.7.0 priorities

I've made a bug on the bug tracker to which I've linked all the things that I 
think *might* be important for 0.7.1. Please contribute to this bug by 
setting it related to anything that you think it should be related to, or 
reply to this thread.

Stuff I think is important for the next release:

Automatic bandwidth calibration. Other p2p apps have this, we should have it. 
It should significantly improve the average output bandwidth available, since 
most users presumably don't set the output limit. Further it would improve 
usability by making the connection more responsive.
Timescale: Unclear at this point.
Priority: High.

Datastore changes: It looks very much like we can have both better network 
performance and much less memory overhead by using a non-associative salted 
hash table on disk. Daniel Cheng (sdiz) is currently implementing this on a 
branch. I will be reviewing the code soon. Nextgens has asked about its 
suitability for the cache as opposed to the store; mrogers' simulations were 
based on it being for the store.
Timescale: A lot of this is done already, most work will be sdiz's.
Priority: High.

More work on ULPRs: Various changes related to coalescing and temporarily 
suppressing requests if there are too many for a single key over a period. 
Should help with FMS and to boost payload %.
Timescale: 1 week
Priority: High.

Use peers' peers' locations for routing: According to oskar and vive, this 
should significantly cut average path lengths. There is minimal security 
impact as this data is already exposed by swapping.
Timescale: 1 week
Priority: High.

Faster swapping: Vive has some ideas to improve swapping performance 
significantly. Hopefully he can turn these into implementible proposals. This 
would significantly improve performance (especially given the level of churn 
we see), and also help with security (because we could reset more to prevent 
swapping attacks).
Timescale: Depends on Vive. Implementation probably relatively easy.
Priority: High if possible. Would justify calling it 0.8.0 IMHO.

Streams and MTU: We can improve our payload proportion significantly, allow 
for much smaller packets, support smaller MTUs, avoid padding with random 
data, and support simple stego, by implementing transport layer streams. 
There are also a number of other mostly minor changes which we should 
implement to make Freenet work well on low MTU connections.
Timescale: 2-4 weeks??
Priority: High.

Better Librarian integration: We should have a search box on the homepage, it 
should be embeddable in freesites. And XMLSpider probably needs some more 
debugging.
Timescale: 1 week or less.
Priority: High.

Client layer changes: I propose to move the entire client layer onto disk. We 
would continue to store enough data to restart requests from scratch in 
downloads.dat.gz, but we would have an on-disk queue structure instead of an 
in-memory queue structure. This combined with the datastore changes would 
make our memory usage fixed, regardless of the size of your store or the 
number of requests you queue. It would solve many bug reports, it would 
incorporate the long-awaited true request resuming, would make Freenet run 
well on home servers with 128M or maybe even 64M of RAM, and generally is a 
good idea.
Timescale: 2 weeks??
Priority: Medium.

Auto-update for plugins: We should have had this ages ago. Several people have 
been complaining about it, it is a security issue if you want them kept up to 
date. It shouldn't be difficult.
Timescale: 3 days
Priority: Medium.

Better content filter: Filter on insert by default (for performance on fetch), 
support more HTML etc, support RSS, support some other formats (e.g. mp3), 
etc.
Timescale: 1 week, more for more formats.
Priority: Medium.

Better USKs: Hierarchical DBRs would help USK lookups to find something close 
to the latest version quickly, then plod through the editions from there to 
find the latest version.
Timescale: 2 days.
Priority: Medium.

System tray icon: IMHO this would be a good usability feature. It would make 
it obvious that Freenet is running in the background and make it easy to 
throttle it or disable it when you want to play an MMORPG etc.
Timescale: 1 week???
Priority: Medium.

Bandwidth: mister_wavey is working on a bandwidth scheduler. It would be a big 
help for a lot of users who have off-peak quotas etc. There will be a user 
friendly config sub-page for it. Average bandwidth limits, maybe actually 
telling the node a monthly quota, would also be useful for many users. More 
accurate bandwidth limiting (limiting all packets not just transfers) would 
also be a big help for users on slower upstream connections.
Timescale: Unknown.
Priority: Medium.

Allocate temporary files out of a small number of blob files: Further 
reduction in memory usage, some other benefits, cuts the number of fd's we 
use (thus allowing more FEC threads on mutli-core systems), easy.
Timescale: 3 days
Priority: Low.


pgpSXxvkgxraD.pgp

Re: [freenet-dev] [freenet-cvs] r19836 - in trunk/website: . includes pages/de

Some of your changes broke the link to the English news site on the
German one. The old link doesn't work either.
We need that link because the news section needs to be up to date and I
can't always translate it in real time.

[EMAIL PROTECTED] schrieb:
> Author: nextgens
> Date: 2008-05-08 09:28:07 + (Thu, 08 May 2008)
> New Revision: 19836
> 
> Removed:
>trunk/website/includes/common.inc.php~
> Modified:
>trunk/website/index.php
>trunk/website/pages/de/fairshare.php
>trunk/website/pages/de/news.php
> Log:
> website: attempt to redirect old-links to new ones
> 
> Deleted: trunk/website/includes/common.inc.php~
> ===
> --- trunk/website/includes/common.inc.php~2008-05-08 09:23:12 UTC (rev 
> 19835)
> +++ trunk/website/includes/common.inc.php~2008-05-08 09:28:07 UTC (rev 
> 19836)
> @@ -1,139 +0,0 @@
> - -
> -function setLanguage() {
> - global $lang;
> - 
> - $lang = $_GET['lang'];
> - 
> - if(!isset($lang)) 
> - {
> - $languages = split(",", $_SERVER['HTTP_ACCEPT_LANGUAGE'] );
> - foreach ($languages as $language) {
> - $lang_array = split(";q=", trim( $language ) );
> - $lang = trim( $lang_array[0] );
> - if( !isset( $lang_array[1] ) )
> - $q = 1;
> - else
> - $q = trim($lang_array[1]);
> - $lang_q["$lang"] = (float)$q;
> - }
> - 
> - arsort($lang_q);
> - $i = 0;
> - $lang_index = Array();
> - foreach($lang_q as $lang => $q) {
> - $lang_index[$i] = $lang; //add to a new array the index 
> key/language
> - $i++;
> - }
> -  
> - }
> - else
> - {
> - $lang_q[$lang] = '1' ;
> - }
> -   
> -   //return $lang_index; // uncomment for returning array with 
> keys={0..n-1}, values={most..least preferred}
> -return $lang_q;
> - 
> -}
> -
> -function selectPage($lang_q, $page) {
> - 
> - if (isset($page))
> - {
> - #echo "common - page exists 
> ".dirname(__FILE__).'/'.$page.'.inc.php';
> - if (file_exists(dirname(__FILE__).'/'.$page.'.inc.php')) {
> - #echo "file exists";
> - include dirname(__FILE__).'/'.$page.'.inc.php'; 
> // include file with  $pages-array
> - foreach ( $lang_q as $aLang => $relevance ) 
> // loop through each language
> - {   
> - foreach ( $pages as $userlang => $path )
> // loop through each language-file
> - {
> - if ($aLang == $userlang) {  
> // if we have 
> a match, set file-include to $path
> - $file = $path;
> - if 
> (file_exists($_SERVER['DOCUMENT_ROOT'].$file))
>// if file exists, break loop
> - {
> - break 2;
> - }
> - }
> - }
> - 
> - }   
> - if (!isset($file))
> - {
> - $file = $pages['en']; //if no match, default to 
> english
> - }   
> - }
> - }
> - return $file;
> -
> -}
> -
> -function otherLanguages() {
> - 
> - include dirname(__FILE__).'/languages.inc.php'; // Include language 
> descriptions
> - 
> - global $page;
> - 
> - 
> - if (isset($page))
> - {
> - if (file_exists(dirname(__FILE__).'/'.$page.'.inc.php')) 
> - {
> - include dirname(__FILE__).'/'.$page.'.inc.php'; 
> - 
> - $out .= '::  ';
> - 
> - foreach ( $pages as $userlang => $path ) 
> - {
> - foreach ( $languages as $abbr_lang_name => 
> $full_lang_name ) 
> - {
> - if ($userlang == $abbr_lang_name) 
> - {
> - $out .= ' href="'.$abbr_lang_name.'/'.($page ? $page : 
> "index").'.html">'.$full_lang_name.'  ::  ';
> -

Re: [freenet-dev] Content Management System

Ian Clarke schrieb:
> On Thu, May 8, 2008 at 12:49 PM, Victor Denisov <[EMAIL PROTECTED]> wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>>  Hash: SHA1
>>  | consider a migration seriously. If it was up to me, we would use Trac
>>  | and only Trac (for the website, wikki and bug-tracker).
>>
>>  A quick vote of confidence for Trac. It's a *very* good piece of
>>  software, and its Wiki<->Tickets<->SVN integration is amazing. We've
>>  used it for three major projects now and had nothing but *very* positive
>>  experience.
> 
> Trac isn't a bad bugtracker, probably better than Mantis, although has
> some conspicuous limitations, such as no dependencies between bugs.
> 
> That being said, I don't think Trac is designed to be a CMS, and
> frankly I don't think its appearance is enticing as a "user facing"
> website, its even worse than the current Freenet website.  If we did
> use it, it would require some major re-theming.
> 

ACK

> I think we should look to commercial and well-funded open source
> projects for inspiration about how to make our website enticing for
> first-time visitors, while still providing the depth of information we
> need to convey.
> 
> http://getfirefox.com/ is good because its colorful, inviting, and the
> "call to action" is very clear, you don't have to spend much time
> looking for that download link!  Now, its tone may be a little too
> in-your-face for Freenet, but there are things we can learn from it.
> 

getfirefox is drupal driven

> I'm a big fan of David Watanabe's work, both the software he writes,
> and the websites he designs for them.  I'd recommend looking at:
> 
>   http://xtorrent.com/
>   http://www.inquisitorx.com/safari/
>   http://www.acquisitionx.com/
> 

The design is cool, but it's a little bit too trendy in my opinion (it's
ok for stylish apple addons, but not suitable for freenet, as it's
supposed to be secure software, not another design wonder). Also some
users who don't have the bandwith would really be annoyed by the large
pictures.
Apart from that there's not much documentation on the websites, no
navigation menu (we would definitely need one, as we have more than
three pages to offer).
I don't think we could apply a similar design to freenet.

> You could argue that all of those things have it easy, because most
> people understand what those things do, they don't need an elaborate
> explanation.  But look at Gnome's website:
> 
>   http://www.gnome.org/
> 
> It is clean, simple, yet if you need to you can quickly dig down to a
> vast wealth of information.
> 

Gnome uses Plone as it's CMS. This may be not the best choice for us
though, as Plone is Phyton based, but that's something nextgens might
know better than me.

> Either way, since we are Java hackers for the most part, not web
> designers, I strongly recommend that we borrow as much as we can from
> elsewhere, even so far as using free or creative commons HTML and CSS
> verbatim, perhaps with only a few minor changes.
> 
> Ian.
> 

[EMAIL PROTECTED]
-- 
Follow the blue rabbit - The Freenet Project - http://freenetproject.org/



signature.asc
Description: OpenPGP digital signature
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Content Management System

* Michael T?nzer  [2008-05-08 05:04:07]:

> In the last few weeks I've done some work on the website. While
> translating it, there were some things that struck me so I changed them.
> But our site is still far from perfect. It lacks a attractive design and
> some features that would be quite handy (e.g. select the language by
> hand, RSS-Feeds, a search) but are a little bit difficult to implement
> (at least if we want to do it in a safe and efficient way) or at least I
> don't have the time and skills to do it.

Select language by hand is trivial to implement and we can delegate the search
to google so that's trivial too... okay RSS would require some work

> I also noticed, that the format
> we use to save the content (it's just a php file containing HTML which
> is included in some kind of very simple template) leaves room for
> optimization (for both, the author who needs to write valid HTML and
> know about the things he can do with it (not all of us do know how to
> write clean and valid HTML (I do not exclude myself from this
> statement)), and the user, who might get malformed HTML or ugly pages
> because the browser has some bugs the author didn't know of). We also
> have the problem, that our site consists of many different components:
> there's the homepage, the wiki, emu, SVN, which looks very fragmented.
> 
> We could address most of this problems by using a CMS (content
> management system).

It's not the first time it's being debated...

> Of course a CMS is not a Swiss Army knife for
> everything and it does raise several issues: is it fast enough to
> survive a slashdot, can we use our already existent database, how can we
> migrate, is it safe?

Don't worry about performances for now...

At the moment we are using mantis as a BTS, Wikka as a wiki-engine, a
home-maid website and *loads* of custom scripting for almost
everything... How do you plan to migrate existing content ?

Can a CMS have some level of history ? All the tools we use have
native versioning; that's a feature we don't want to loose.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20080508/c524e592/attachment.pgp>

[freenet-dev] Content Management System

2008-05-08 Thread Ian Clarke

On Thu, May 8, 2008 at 12:49 PM, Victor Denisov  wrote:
> -BEGIN PGP SIGNED MESSAGE-
>  Hash: SHA1
>  | consider a migration seriously. If it was up to me, we would use Trac
>  | and only Trac (for the website, wikki and bug-tracker).
>
>  A quick vote of confidence for Trac. It's a *very* good piece of
>  software, and its Wiki<->Tickets<->SVN integration is amazing. We've
>  used it for three major projects now and had nothing but *very* positive
>  experience.

Trac isn't a bad bugtracker, probably better than Mantis, although has
some conspicuous limitations, such as no dependencies between bugs.

That being said, I don't think Trac is designed to be a CMS, and
frankly I don't think its appearance is enticing as a "user facing"
website, its even worse than the current Freenet website.  If we did
use it, it would require some major re-theming.

I think we should look to commercial and well-funded open source
projects for inspiration about how to make our website enticing for
first-time visitors, while still providing the depth of information we
need to convey.

http://getfirefox.com/ is good because its colorful, inviting, and the
"call to action" is very clear, you don't have to spend much time
looking for that download link!  Now, its tone may be a little too
in-your-face for Freenet, but there are things we can learn from it.

I'm a big fan of David Watanabe's work, both the software he writes,
and the websites he designs for them.  I'd recommend looking at:

  http://xtorrent.com/
  http://www.inquisitorx.com/safari/
  http://www.acquisitionx.com/

You could argue that all of those things have it easy, because most
people understand what those things do, they don't need an elaborate
explanation.  But look at Gnome's website:

  http://www.gnome.org/

It is clean, simple, yet if you need to you can quickly dig down to a
vast wealth of information.

Either way, since we are Java hackers for the most part, not web
designers, I strongly recommend that we borrow as much as we can from
elsewhere, even so far as using free or creative commons HTML and CSS
verbatim, perhaps with only a few minor changes.

Ian.

-- 
Email: ian at uprizer.com
Cell: +1 512 422 3588
Skype: sanity

Re: [freenet-dev] Post 0.7 idea: off-grid darknet!

On Thursday 08 May 2008 01:41, Matthew Toseland wrote:
> https://bugs.freenetproject.org/view.php?id=2345
> 
> ---
> A typical domestic internet connection has at most 1Mbps uplink. In some 
> megacities 100Mbps or even 1Gbps is available (symmetric), however it is 
> unlikely that the bandwidth available in most homes will exceed a few 
> megabits in the near future.
> 
> We could implement darknet sneakernet connections by exchanging USB sticks. 
> E.g. if you meet somebody every day (e.g. a coworker), you could exchange 
> (cheap) 8G sticks, plug them in overnight, and then do the same again the 
> next day. This would produce approx 100K/sec (1Mbps) each way for each 
person 
> you did it with.
> 
> The performance here imho isn't world-shattering, but nonetheless it's 
> interesting. And it would build the darknet, some of it completely off-grid, 
> work in many places where nothing else does safely, and get us some great 
> headlines.
> ---
> 
> IMHO this is something we should seriously consider, if not this year, then 
at 
> least next year during the 0.8 cycle. The main technical prerequisite is 
> token passing load management, unless we implement a completely different 
> load management system for it. True passive requests would help in that 
> they'd make publish/subscribe work much better on this. Even if it's not 
> perfect, it'd be a very interesting way to get people in, and far from being 
> a publicity stunt, it would be of immense long-term value.
> 

Ian is of the view that this should be a separate application based on similar 
principles to Freenet. I'm not. We agree that there are some significant 
issues to deal with. I am of the view that these networks are mutually 
complementary and therefore should talk to each other: Darknet over UDP isn't 
safe in hostile environments, and off-grid darknets a) work much better if 
parts of them are online (certainly we could expect some covert wireless 
links in places, but being able to link to a functional on-grid darknet would 
surely be a benefit; long links are going to be rare on a pure off-grid 
darknet), and b) would be much easier to bootstrap from a working on-grid 
darknet.

W.r.t. code (and to some degree protocol), IMHO most of Freenet's code would 
be useful to a darknet sneakernet implementation:
- The entire client layer could be reused. The queue is by definition a long 
term structure, Fproxy offers to download stuff in the background and tells 
you when it's done etc. FCP could be reused, although on a 
pure-off-grid-darknet node, clearly they would have to use it in a different 
way to what they do now.
- Full passive requests would be virtually identical for the two 
implementations. ULPRs could be adapted without too much difficulty. This 
makes FMS etc somewhat feasible, if slow, and anything that can be seen as 
publish/subscribe (e.g. getting new editions of freesites) possible. Full 
passive requests are a long term goal as they would have some interesting 
advantages, but even ULPRs, with sufficient tweaking, may be sufficient to 
make this usable.
- The link layer would obviously be worthless, except in the IMHO interesting 
case where you have both a darknet connection *and* exchange of flash cards 
going on with a peer. Thus low latency requests such as Frost traffic can go 
over the link, and when you queue a big splitfile, it would fetch the top 
blocks of the pyramid over the link, and then queue the rest to come back 
over the following day's card exchange.
- Request priorities would be necessary.
- We probably couldn't reuse the current load limiting/management code. We 
would in all likelihood need token passing. This is something we will need 
long term anyway, of course.
- Swapping: This is probably the hardest part. Our current strategy involves a 
commit/reveal protocol (4 round trips). This clearly won't work well on a 
pure off-grid darknet. Doing a large part of the work offline will be 
necessary, and to do that a lot of topology may need to be exposed... which 
is bad because it makes life easier for a well-resourced attacker. Also, the 
off-grid network may have to be partially separate in routing terms through 
some sort of tiered routing (look at the network labelling code for something 
related).
- User interface to transport: We want users to be able to just plug in a 
bunch of USB sticks to a mini-hub, and have Freenet auto-detect that they are 
formatted for it, download from them, and then upload to them, all ready for 
the next day for them to be swapped back. I don't know what native support 
this would require.

Based on the above, IMHO this *might* be feasible, it becomes a lot more 
interesting after some of the features we have planned for 0.7.1/0.8 have 
been implemented, but even then there are some major problems to solve, such 
as swapping.


pgpSGwd7L2Wtq.pgp
Description: PGP signature
___
Devl mailing list
Devl@freenetproject.org
http:

[freenet-dev] Freenet 0.7.0 released!

The Freenet Project is very pleased to announce the release of Freenet 0.7.0.

Freenet is software designed to allow the free exchange of information over 
the Internet without fear of censorship, or reprisal.  To achieve this 
Freenet makes it very difficult for adversaries to reveal the identity, 
either of the person publishing, or downloading content.  The Freenet project 
started in 1999, released Freenet 0.1 in March 2000, and has been under 
active development ever since.

Freenet is unique in that it handles the storage of content, meaning that if 
necessary users can upload content to Freenet and then disconnect.  We've 
discovered that this is a key requirement for many Freenet users.  Once 
uploaded, content is mirrored and moved around the Freenet network, making it 
very difficult to trace, or to destroy.   Content will remain in Freenet for 
as long as people are retrieving it, although Freenet makes no guarantee that 
content will be stored indefinitely.

The journey towards Freenet 0.7 began in 2005 with the realization that some 
of Freenet's most vulnerable users needed to hide the fact that they were 
using Freenet, not just what they were doing with it.  The result of this 
realization was a ground-up redesign and rewrite of Freenet, adding 
a "darknet" capability, allowing users to limit who their Freenet software 
would communicate with to trusted friends.  This would make it far more 
difficult for a third-party to determine who is using Freenet.

Freenet 0.7 also embodies significant improvements to almost every other 
aspect of Freenet, including efficiency, security, and usability.  Freenet is 
available for Windows, Linux, and OSX. It can be downloaded from:

   http://freenetproject.org/download.html

This release would not have been possible without the release of numerous 
volunteers, and Matthew Toseland, Freenet's full time developer. Matthew's 
work is funded through donations via our website (as well as a few larger 
sponsors from time to time).  We ask that anyone who can help us to ensure 
Matthew's continued employment visit our donations page and make a 
contribution at:

   http://freenetproject.org/donate.html


pgpIYQ9w4ma2J.pgp
Description: PGP signature
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Content Management System

2008-05-08 Thread Ian Clarke

On Thu, May 8, 2008 at 12:49 PM, Victor Denisov <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
>  Hash: SHA1
>  | consider a migration seriously. If it was up to me, we would use Trac
>  | and only Trac (for the website, wikki and bug-tracker).
>
>  A quick vote of confidence for Trac. It's a *very* good piece of
>  software, and its Wiki<->Tickets<->SVN integration is amazing. We've
>  used it for three major projects now and had nothing but *very* positive
>  experience.

Trac isn't a bad bugtracker, probably better than Mantis, although has
some conspicuous limitations, such as no dependencies between bugs.

That being said, I don't think Trac is designed to be a CMS, and
frankly I don't think its appearance is enticing as a "user facing"
website, its even worse than the current Freenet website.  If we did
use it, it would require some major re-theming.

I think we should look to commercial and well-funded open source
projects for inspiration about how to make our website enticing for
first-time visitors, while still providing the depth of information we
need to convey.

http://getfirefox.com/ is good because its colorful, inviting, and the
"call to action" is very clear, you don't have to spend much time
looking for that download link!  Now, its tone may be a little too
in-your-face for Freenet, but there are things we can learn from it.

I'm a big fan of David Watanabe's work, both the software he writes,
and the websites he designs for them.  I'd recommend looking at:

  http://xtorrent.com/
  http://www.inquisitorx.com/safari/
  http://www.acquisitionx.com/

You could argue that all of those things have it easy, because most
people understand what those things do, they don't need an elaborate
explanation.  But look at Gnome's website:

  http://www.gnome.org/

It is clean, simple, yet if you need to you can quickly dig down to a
vast wealth of information.

Either way, since we are Java hackers for the most part, not web
designers, I strongly recommend that we borrow as much as we can from
elsewhere, even so far as using free or creative commons HTML and CSS
verbatim, perhaps with only a few minor changes.

Ian.

-- 
Email: [EMAIL PROTECTED]
Cell: +1 512 422 3588
Skype: sanity
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Content Management System

2008-05-08 Thread Victor Denisov

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

| consider a migration seriously. If it was up to me, we would use Trac
| and only Trac (for the website, wikki and bug-tracker).

A quick vote of confidence for Trac. It's a *very* good piece of
software, and its Wiki<->Tickets<->SVN integration is amazing. We've
used it for three major projects now and had nothing but *very* positive
experience.

Regards,
Victor Denisov.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIIz0rS81Mh9/iCDgRAsoSAKDSzT3tW+DaA/FkOefLAU4MUuVkfACgz8sx
QflbOaD1swFHdHMWj7Uzago=
=QlxK
-END PGP SIGNATURE-
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Content Management System

* Michael Tänzer <[EMAIL PROTECTED]> [2008-05-08 17:41:55]:

> Florent Daignière schrieb:
> > * Michael Tänzer <[EMAIL PROTECTED]> [2008-05-08 05:04:07]:
> > 
> >> In the last few weeks I've done some work on the website. While
> >> translating it, there were some things that struck me so I changed them.
> >> But our site is still far from perfect. It lacks a attractive design and
> >> some features that would be quite handy (e.g. select the language by
> >> hand, RSS-Feeds, a search) but are a little bit difficult to implement
> >> (at least if we want to do it in a safe and efficient way) or at least I
> >> don't have the time and skills to do it.
> > 
> > Select language by hand is trivial to implement and we can delegate the 
> > search
> > to google so that's trivial too... okay RSS would require some work
> > 
> 
> I know it's not that hard to do but someone actually has to do it.

No one has bothered that's why it hasn't been done.

[snip.]

> > At the moment we are using mantis as a BTS, Wikka as a wiki-engine, a
> > home-maid website and *loads* of custom scripting for almost
> > everything... How do you plan to migrate existing content ?
> > 
> 
> The fully custom made site is one of the problems, as we are not experts
> in some of the things we did. I saw that you fixed some security issues
> in our php code today, some issues that dealt with character escaping
> and such things.

The broken code wasn't mine! I have already fixed the exact same bug 3
years ago and someone reintroduced it since then!

We should really have regression tests; even for the website.

> I'm no PHP expert but I think these are things which
> are obvious to a professional php-developer but can completely break our
> security, which means if some  here> guy used this issue to hack into our server and replace the
> binaries we provide, then this could be rather dangerous for our users.
> 

I'm not a fan of security by obscurity but let's face it: we have fixed
only a few security related bugs in the last few years... Drupal had many
more (and that's logical given that it's a gaz plant compared to our
requirements). Their last release was on the 9th of April and guess
what? It's a security bugfix!

> What I want to say: If you're not absolutely sure about what you're
> doing, leave it to the pros, they know how to deal with it, and we can
> concentrate on what we do best: provide our users with tools to give
> them true freedom of speech.
> 

Go on with that logic... and we end up being dependant on a 3rd party
entity. We left SourceForge because their service wasn't up to our
expectations anymore and at the time there was no good alternative.

> It's probably not possible to migrate in two days but it seems that now
> is a good point to start the process, as Ian mentioned he wanted to
> change the website significantly (this also includes the texts). We
> probably should migrate in a soft way and try it in a test environment
> first. The Website would be a good point to start with because it has
> not so much content on it. The other things could be done step by step,
> or never if we want to keep them (e.g. I'm not quite convinced about
> drupals bug tracker, but there are definitely better wiki engines than
> wikkawiki).

I don't share your views here. Either we switch to a CMS and use it for
everything or we don't.

They are good and bad reasons to switch to a CMS: I don't think that
security is a good one. As you've highlighted, our website doesn't
evolve much and has a long history; that's why it's pretty secure
overall. On the other hand, integration of services into the CMS
is a good reason to make the switch. Find a CMS which has a good
integration with mantis or can import its tickets and then we can
consider a migration seriously. If it was up to me, we would use Trac
and only Trac (for the website, wikki and bug-tracker).

A few weeks ago someone asked me to set a blog engine up (Wordpress), I
did and so far no one used it... We obviously don't want the same thing
to happen with a Drupal, do we ?


signature.asc
Description: Digital signature
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Content Management System

Florent Daignière schrieb:
> * Michael Tänzer <[EMAIL PROTECTED]> [2008-05-08 05:04:07]:
> 
>> In the last few weeks I've done some work on the website. While
>> translating it, there were some things that struck me so I changed them.
>> But our site is still far from perfect. It lacks a attractive design and
>> some features that would be quite handy (e.g. select the language by
>> hand, RSS-Feeds, a search) but are a little bit difficult to implement
>> (at least if we want to do it in a safe and efficient way) or at least I
>> don't have the time and skills to do it.
> 
> Select language by hand is trivial to implement and we can delegate the search
> to google so that's trivial too... okay RSS would require some work
> 

I know it's not that hard to do but someone actually has to do it. And
if there is an already existent solution, why not do it with that one
instead of inventing the wheel yet another time.

>> I also noticed, that the format
>> we use to save the content (it's just a php file containing HTML which
>> is included in some kind of very simple template) leaves room for
>> optimization (for both, the author who needs to write valid HTML and
>> know about the things he can do with it (not all of us do know how to
>> write clean and valid HTML (I do not exclude myself from this
>> statement)), and the user, who might get malformed HTML or ugly pages
>> because the browser has some bugs the author didn't know of). We also
>> have the problem, that our site consists of many different components:
>> there's the homepage, the wiki, emu, SVN, which looks very fragmented.
>>
>> We could address most of this problems by using a CMS (content
>> management system).
> 
> It's not the first time it's being debated...
> 
>> Of course a CMS is not a Swiss Army knife for
>> everything and it does raise several issues: is it fast enough to
>> survive a slashdot, can we use our already existent database, how can we
>> migrate, is it safe?
> 
> Don't worry about performances for now...
> 

I don't but Ian did when I had a discussion with him about the some web
design issues recently where I mentioned CMSs.

> At the moment we are using mantis as a BTS, Wikka as a wiki-engine, a
> home-maid website and *loads* of custom scripting for almost
> everything... How do you plan to migrate existing content ?
> 

The fully custom made site is one of the problems, as we are not experts
in some of the things we did. I saw that you fixed some security issues
in our php code today, some issues that dealt with character escaping
and such things. I'm no PHP expert but I think these are things which
are obvious to a professional php-developer but can completely break our
security, which means if some  guy used this issue to hack into our server and replace the
binaries we provide, then this could be rather dangerous for our users.

What I want to say: If you're not absolutely sure about what you're
doing, leave it to the pros, they know how to deal with it, and we can
concentrate on what we do best: provide our users with tools to give
them true freedom of speech.

It's probably not possible to migrate in two days but it seems that now
is a good point to start the process, as Ian mentioned he wanted to
change the website significantly (this also includes the texts). We
probably should migrate in a soft way and try it in a test environment
first. The Website would be a good point to start with because it has
not so much content on it. The other things could be done step by step,
or never if we want to keep them (e.g. I'm not quite convinced about
drupals bug tracker, but there are definitely better wiki engines than
wikkawiki).

> Can a CMS have some level of history ? All the tools we use have
> native versioning; that's a feature we don't want to loose.

Drupal has native versioning, I think that's one of the core features
which made it one of the favourite CMSs for OpenSource projects.

[EMAIL PROTECTED]

-- 
Follow the blue rabbit - The Freenet Project - http://freenetproject.org/



signature.asc
Description: OpenPGP digital signature
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Content Management System

In the last few weeks I've done some work on the website. While
translating it, there were some things that struck me so I changed them.
But our site is still far from perfect. It lacks a attractive design and
some features that would be quite handy (e.g. select the language by
hand, RSS-Feeds, a search) but are a little bit difficult to implement
(at least if we want to do it in a safe and efficient way) or at least I
don't have the time and skills to do it. I also noticed, that the format
we use to save the content (it's just a php file containing HTML which
is included in some kind of very simple template) leaves room for
optimization (for both, the author who needs to write valid HTML and
know about the things he can do with it (not all of us do know how to
write clean and valid HTML (I do not exclude myself from this
statement)), and the user, who might get malformed HTML or ugly pages
because the browser has some bugs the author didn't know of). We also
have the problem, that our site consists of many different components:
there's the homepage, the wiki, emu, SVN, which looks very fragmented.

We could address most of this problems by using a CMS (content
management system). Of course a CMS is not a Swiss Army knife for
everything and it does raise several issues: is it fast enough to
survive a slashdot, can we use our already existent database, how can we
migrate, is it safe?

The three commonly used Open CMS' are:

Typo3 - the elder:
-first release in 1998, therefore probably pretty safe by now
-complicated to administer and design (has it's own template-language)
-but therefore very powerful
-according to some sites Typo3 needs a powerful server

Joomla! - the most used:
-easy to administer and design (at least the last time I used it)
-very big community
-had some security vulnerabilities in the past (hopefully this will have
more or less disappeared with the ground-up rewrite in version 1.5 - the
most vulnerabilities where in third party modules though)

Drupal - the community focused (and therefore my favourite):
-should be as easy as Joomla
-has some features which are especially interesting for communities
(like us - mozilla.org and other OpenSource projects seem to use it too)

All of them are licensed under GPL, they all provide caching techniques
to cope with high traffic, they all can use mySQL, other databases are
also supported. It's important, that the functionality we want to have
is covered with the standard modules as much as possible, third party
modules are a major security risk.

Looking forward to your comments
Neo at NHNG

P.S.: The question whether Joomla! or Drupal is the better CMS seems to
be a question of belief.
-- 
Follow the blue rabbit - The Freenet Project - http://freenetproject.org/

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20080508/67b476b8/attachment.pgp>

Re: [freenet-dev] Content Management System

* Michael Tänzer <[EMAIL PROTECTED]> [2008-05-08 05:04:07]:

> In the last few weeks I've done some work on the website. While
> translating it, there were some things that struck me so I changed them.
> But our site is still far from perfect. It lacks a attractive design and
> some features that would be quite handy (e.g. select the language by
> hand, RSS-Feeds, a search) but are a little bit difficult to implement
> (at least if we want to do it in a safe and efficient way) or at least I
> don't have the time and skills to do it.

Select language by hand is trivial to implement and we can delegate the search
to google so that's trivial too... okay RSS would require some work

> I also noticed, that the format
> we use to save the content (it's just a php file containing HTML which
> is included in some kind of very simple template) leaves room for
> optimization (for both, the author who needs to write valid HTML and
> know about the things he can do with it (not all of us do know how to
> write clean and valid HTML (I do not exclude myself from this
> statement)), and the user, who might get malformed HTML or ugly pages
> because the browser has some bugs the author didn't know of). We also
> have the problem, that our site consists of many different components:
> there's the homepage, the wiki, emu, SVN, which looks very fragmented.
> 
> We could address most of this problems by using a CMS (content
> management system).

It's not the first time it's being debated...

> Of course a CMS is not a Swiss Army knife for
> everything and it does raise several issues: is it fast enough to
> survive a slashdot, can we use our already existent database, how can we
> migrate, is it safe?

Don't worry about performances for now...

At the moment we are using mantis as a BTS, Wikka as a wiki-engine, a
home-maid website and *loads* of custom scripting for almost
everything... How do you plan to migrate existing content ?

Can a CMS have some level of history ? All the tools we use have
native versioning; that's a feature we don't want to loose.


signature.asc
Description: Digital signature
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Post 0.7 idea: off-grid darknet!