[freenet-dev] Naming of plugins in svn

[Michael Tänzer]

xor wrote:
>> On November 4, 2008, xor wrote:
>>> I just came up with the idea of renaming it to "Freetalk".
>>> If nobody is against that I will do it today (wednesday).
>> Oh great an IM system for freenet.
> 
> I don't know of any IM system which has "talk" in it's name.
> Besides: People might *always* confuse it with instant messaging,
> no matter how good we chose the name.

Well there is Google talk which is an IM (well it's basically jabber
with a colourful interface)

Talk implies it's like a real conversation where you immediately get a
respond, board, forum, use* refer to somthing the user (probably)
already knows about and assumes they have no real time implication.

>> Thats what freeTALK implies at least to me.
> 
> Well forums are about talking to each others.
> 
>> Maybe FreeMessage or freemess might be better?
> 
> FreeMessage is to long. And for understanding why freemess is not
> a good idea you should probably look up the word "mess" in your
> favorite english-to-your-language book :)

There may be people out there who understand irony but I agree that it
is something we can't rely on.

So the best name I see so far is the "freeboard" proposed by Michael Rogers

regards
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: 260 bytes
Desc: OpenPGP digital signature
URL: 

Re: [freenet-dev] Naming of plugins in svn

[Michael Tänzer]

xor wrote:
>> On November 4, 2008, xor wrote:
>>> I just came up with the idea of renaming it to "Freetalk".
>>> If nobody is against that I will do it today (wednesday).
>> Oh great an IM system for freenet.
> 
> I don't know of any IM system which has "talk" in it's name.
> Besides: People might *always* confuse it with instant messaging,
> no matter how good we chose the name.

Well there is Google talk which is an IM (well it's basically jabber
with a colourful interface)

Talk implies it's like a real conversation where you immediately get a
respond, board, forum, use* refer to somthing the user (probably)
already knows about and assumes they have no real time implication.

>> Thats what freeTALK implies at least to me.
> 
> Well forums are about talking to each others.
> 
>> Maybe FreeMessage or freemess might be better?
> 
> FreeMessage is to long. And for understanding why freemess is not
> a good idea you should probably look up the word "mess" in your
> favorite english-to-your-language book :)

There may be people out there who understand irony but I agree that it
is something we can't rely on.

So the best name I see so far is the "freeboard" proposed by Michael Rogers

regards
[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] git-over-fproxy

[Michael Tänzer]

David ?Bombe? Roden schrieb:
> 
> Daniel mentioned a thing on IRC that needs to be taken care of when the time 
> arrives: repositories of course grow over time. A repository might get big 
> enough that inserting it will become a pain in the ass; unfortunately, the 
> only kind of ?incremental update? that we could think of does have other 
> drawbacks, e.g. disappearing data. I?m not completely sure what to do about 
> that.
> 

How about inserting it incremental but every Xth (or if delta(t)>x)
commit a full version of the repository is released?

So every checkout needs the last full version, plus the incremental
commits, which have been released since then, an update (if it's
somewhat up to date) only needs to pull the incremental commits.


regards
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: 

Re: [freenet-dev] git-over-fproxy

[Michael Tänzer]

David ?Bombe? Roden schrieb:
> 
> Daniel mentioned a thing on IRC that needs to be taken care of when the time 
> arrives: repositories of course grow over time. A repository might get big 
> enough that inserting it will become a pain in the ass; unfortunately, the 
> only kind of “incremental update” that we could think of does have other 
> drawbacks, e.g. disappearing data. I’m not completely sure what to do about 
> that.
> 

How about inserting it incremental but every Xth (or if delta(t)>x)
commit a full version of the repository is released?

So every checkout needs the last full version, plus the incremental
commits, which have been released since then, an update (if it's
somewhat up to date) only needs to pull the incremental commits.


regards
[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] Website and IE

[Michael Tänzer]

Florent Daigni?re schrieb:
> * Loki  [2008-06-04 10:13:51]:
> 
>> Well not a wizard here, but maybe a help.
>>
>> In style.css just activate the out commented line /*width: 150px;*/
>>
>> div#menu {
>>  font-family: Sans-serif, Arial, "Times New Roman", Georgia, Times, 
>> serif; 
>>  float:left;
>>  /*width: 150px;*/< 
>>  font-style: normal;
>>  font-weight: normal;
>>  text-align: left;
>>  line-height: 100%;
>>  color: #00;
>>  background: #CCDDFF;
>>  text-decoration: none;
>>  margin-top: 15px;
>>  margin-bottom: 10px;
>>  border: 1px solid #99CCFF;
>> }
>>
>> Background:
>> If no width definition for the Box exist, so Firefox use the minimum needed 
>> width, IE6 the maximum available width.
>>
> 
> Okay, I've reverted r19832 in r20191 :)
> 

Sorry for that, I had tested in IE but just IE 7 because you can't
install two of them (at least not without some registry hacking).

>> Problems:
>> If the box has a fixed width definition, it will not resize with the font 
>> zooming feature.
>>
> 
> Well, I guess we will have to cope with that for the time being :/
> 

I'm still working on the drupal thingie, but I'm a little short on time
currently.
One of the drupal coders, drewish, was so kind to provide a plugin which
fixes the tranlation problems http://drupal.org/project/active_translation

-- 
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: 

Re: [freenet-dev] Website and IE

[Michael Tänzer]

Florent Daignière schrieb:
> * Loki <[EMAIL PROTECTED]> [2008-06-04 10:13:51]:
> 
>> Well not a wizard here, but maybe a help.
>>
>> In style.css just activate the out commented line /*width: 150px;*/
>>
>> div#menu {
>>  font-family: Sans-serif, Arial, "Times New Roman", Georgia, Times, 
>> serif; 
>>  float:left;
>>  /*width: 150px;*/< 
>>  font-style: normal;
>>  font-weight: normal;
>>  text-align: left;
>>  line-height: 100%;
>>  color: #00;
>>  background: #CCDDFF;
>>  text-decoration: none;
>>  margin-top: 15px;
>>  margin-bottom: 10px;
>>  border: 1px solid #99CCFF;
>> }
>>
>> Background:
>> If no width definition for the Box exist, so Firefox use the minimum needed 
>> width, IE6 the maximum available width.
>>
> 
> Okay, I've reverted r19832 in r20191 :)
> 

Sorry for that, I had tested in IE but just IE 7 because you can't
install two of them (at least not without some registry hacking).

>> Problems:
>> If the box has a fixed width definition, it will not resize with the font 
>> zooming feature.
>>
> 
> Well, I guess we will have to cope with that for the time being :/
> 

I'm still working on the drupal thingie, but I'm a little short on time
currently.
One of the drupal coders, drewish, was so kind to provide a plugin which
fixes the tranlation problems http://drupal.org/project/active_translation

-- 
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] Custom Firefox profile causing aggravation with users?

[Michael Tänzer]

Matthew Toseland schrieb:
> On Sunday 25 May 2008 18:42, Michael T?nzer wrote:
>> Matthew Toseland schrieb:
>>> On Friday 23 May 2008 22:40, Michael T?nzer wrote:
 Matthew Toseland schrieb:
> On Friday 23 May 2008 11:38, Matthew Toseland wrote:
>>> I'm not pushing for any immediate changes, but perhaps being more
>>> user-friendly regarding the custom FF profile is something to consider
>>> for 0.7.1?
>> I'd welcome any suggestions. So far, afaics the options are:
>> 1) Fix the Firefox bug that causes the profile resetting. -no-remote 
>>> should 
>> cause it not only to not coalesce with an existing Firefox copy, but 
> also 
> not 
>> to write to the default profile. Also find a new skin that works with 
>>> FF3, 
>> and ideally is a little more stable!
>> 2) Build something using XULRunner. I believe this is the recommended 
> way 
>>> of 
>> doing things according to the Firefox devs. They provide a sample 
> browser 
>> implemented in XUL, but it's *really* minimal, no right-click-go-back 
> for 
>> example.
>> 3) Bundle a "portable" browser.
> 4) Bundle a browser plugin.
 Maybe we can steal some code from this plugin:
 https://nic-nac-project.org/~kaosmos/profileswitcher-en.html

 it's under GPLv3 (source is in the .xpi) and as far as I have tested, it
 doesn't have the bug you described. So we could still provide a
 Firefox-Profile (which isn't used by default) but also ask (in the
 install wizard) to install the plugin. We alter it's behaviour in such a
 way, that it simply provides a "Browse Freenet" button or menu item
 which then loads our custom profile.
 The advantage would be, that the user has to opt-in and that while he's
 in the browser he can easily browse Freenet (no need to switch through
 start menus).
>>> Don't we want the user to be able to browse Freenet (in a customised 
> browser) 
>>> and non-freenet sites at the same time?
>>>
>> Yes we would still have the two profiles method, the user has two
>> windows open, one with the Freenet profile and one with his default one.
>> We probably don't want Freenet and usual webpages in one window, because
>> it leads to having to use the same profile (I don't think you can do two
>> profiles in one window) which would affect both, performance and privacy.
>> The advantage of the button method is, that the user knows there where
>> adjustments done to his browser (because he had to confirm the install
>> of the plugin in Firefox), we provide a shortcut to the Freenet profile
>> (no hangling through menus) and it doesn't have the bug, that Firefox
>> uses the Freenet profile as the default if you close the default before
>> you close the Freenet profile (at least I haven't experienced it up
>> until now).
> 
> So you can switch profiles on a per-window basis?
> 

Well, if you select another profile in the menu (or in our case click on
the "Browse Freenet" button) you will be asked whether you want to close
the current profile/window (you can also set a default in the settings
and you will not be asked, in our case setting the default to not
closing the current window might be reasonable) and then another window
with the new profile comes up.
So you can't switch the profile of the current window but you can open
another one with the selected profile.

-- 
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: 

Re: [freenet-dev] Custom Firefox profile causing aggravation with users?

[Michael Tänzer]

Matthew Toseland schrieb:
> On Sunday 25 May 2008 18:42, Michael Tänzer wrote:
>> Matthew Toseland schrieb:
>>> On Friday 23 May 2008 22:40, Michael Tänzer wrote:
>>>> Matthew Toseland schrieb:
>>>>> On Friday 23 May 2008 11:38, Matthew Toseland wrote:
>>>>>>> I'm not pushing for any immediate changes, but perhaps being more
>>>>>>> user-friendly regarding the custom FF profile is something to consider
>>>>>>> for 0.7.1?
>>>>>> I'd welcome any suggestions. So far, afaics the options are:
>>>>>> 1) Fix the Firefox bug that causes the profile resetting. -no-remote 
>>> should 
>>>>>> cause it not only to not coalesce with an existing Firefox copy, but 
> also 
>>>>> not 
>>>>>> to write to the default profile. Also find a new skin that works with 
>>> FF3, 
>>>>>> and ideally is a little more stable!
>>>>>> 2) Build something using XULRunner. I believe this is the recommended 
> way 
>>> of 
>>>>>> doing things according to the Firefox devs. They provide a sample 
> browser 
>>>>>> implemented in XUL, but it's *really* minimal, no right-click-go-back 
> for 
>>>>>> example.
>>>>>> 3) Bundle a "portable" browser.
>>>>> 4) Bundle a browser plugin.
>>>> Maybe we can steal some code from this plugin:
>>>> https://nic-nac-project.org/~kaosmos/profileswitcher-en.html
>>>>
>>>> it's under GPLv3 (source is in the .xpi) and as far as I have tested, it
>>>> doesn't have the bug you described. So we could still provide a
>>>> Firefox-Profile (which isn't used by default) but also ask (in the
>>>> install wizard) to install the plugin. We alter it's behaviour in such a
>>>> way, that it simply provides a "Browse Freenet" button or menu item
>>>> which then loads our custom profile.
>>>> The advantage would be, that the user has to opt-in and that while he's
>>>> in the browser he can easily browse Freenet (no need to switch through
>>>> start menus).
>>> Don't we want the user to be able to browse Freenet (in a customised 
> browser) 
>>> and non-freenet sites at the same time?
>>>
>> Yes we would still have the two profiles method, the user has two
>> windows open, one with the Freenet profile and one with his default one.
>> We probably don't want Freenet and usual webpages in one window, because
>> it leads to having to use the same profile (I don't think you can do two
>> profiles in one window) which would affect both, performance and privacy.
>> The advantage of the button method is, that the user knows there where
>> adjustments done to his browser (because he had to confirm the install
>> of the plugin in Firefox), we provide a shortcut to the Freenet profile
>> (no hangling through menus) and it doesn't have the bug, that Firefox
>> uses the Freenet profile as the default if you close the default before
>> you close the Freenet profile (at least I haven't experienced it up
>> until now).
> 
> So you can switch profiles on a per-window basis?
> 

Well, if you select another profile in the menu (or in our case click on
the "Browse Freenet" button) you will be asked whether you want to close
the current profile/window (you can also set a default in the settings
and you will not be asked, in our case setting the default to not
closing the current window might be reasonable) and then another window
with the new profile comes up.
So you can't switch the profile of the current window but you can open
another one with the selected profile.

-- 
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] Custom Firefox profile causing aggravation with users?

[Michael Tänzer]

Matthew Toseland schrieb:
> On Friday 23 May 2008 22:40, Michael T?nzer wrote:
>> Matthew Toseland schrieb:
>>> On Friday 23 May 2008 11:38, Matthew Toseland wrote:
> I'm not pushing for any immediate changes, but perhaps being more
> user-friendly regarding the custom FF profile is something to consider
> for 0.7.1?
 I'd welcome any suggestions. So far, afaics the options are:
 1) Fix the Firefox bug that causes the profile resetting. -no-remote 
> should 
 cause it not only to not coalesce with an existing Firefox copy, but also 
>>> not 
 to write to the default profile. Also find a new skin that works with 
> FF3, 
 and ideally is a little more stable!
 2) Build something using XULRunner. I believe this is the recommended way 
> of 
 doing things according to the Firefox devs. They provide a sample browser 
 implemented in XUL, but it's *really* minimal, no right-click-go-back for 
 example.
 3) Bundle a "portable" browser.
>>> 4) Bundle a browser plugin.
>> Maybe we can steal some code from this plugin:
>> https://nic-nac-project.org/~kaosmos/profileswitcher-en.html
>>
>> it's under GPLv3 (source is in the .xpi) and as far as I have tested, it
>> doesn't have the bug you described. So we could still provide a
>> Firefox-Profile (which isn't used by default) but also ask (in the
>> install wizard) to install the plugin. We alter it's behaviour in such a
>> way, that it simply provides a "Browse Freenet" button or menu item
>> which then loads our custom profile.
>> The advantage would be, that the user has to opt-in and that while he's
>> in the browser he can easily browse Freenet (no need to switch through
>> start menus).
> 
> Don't we want the user to be able to browse Freenet (in a customised browser) 
> and non-freenet sites at the same time?
> 

Yes we would still have the two profiles method, the user has two
windows open, one with the Freenet profile and one with his default one.
We probably don't want Freenet and usual webpages in one window, because
it leads to having to use the same profile (I don't think you can do two
profiles in one window) which would affect both, performance and privacy.
The advantage of the button method is, that the user knows there where
adjustments done to his browser (because he had to confirm the install
of the plugin in Firefox), we provide a shortcut to the Freenet profile
(no hangling through menus) and it doesn't have the bug, that Firefox
uses the Freenet profile as the default if you close the default before
you close the Freenet profile (at least I haven't experienced it up
until now).

-- 
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: 

Re: [freenet-dev] Custom Firefox profile causing aggravation with users?

[Michael Tänzer]

Matthew Toseland schrieb:
> On Friday 23 May 2008 22:40, Michael Tänzer wrote:
>> Matthew Toseland schrieb:
>>> On Friday 23 May 2008 11:38, Matthew Toseland wrote:
>>>>> I'm not pushing for any immediate changes, but perhaps being more
>>>>> user-friendly regarding the custom FF profile is something to consider
>>>>> for 0.7.1?
>>>> I'd welcome any suggestions. So far, afaics the options are:
>>>> 1) Fix the Firefox bug that causes the profile resetting. -no-remote 
> should 
>>>> cause it not only to not coalesce with an existing Firefox copy, but also 
>>> not 
>>>> to write to the default profile. Also find a new skin that works with 
> FF3, 
>>>> and ideally is a little more stable!
>>>> 2) Build something using XULRunner. I believe this is the recommended way 
> of 
>>>> doing things according to the Firefox devs. They provide a sample browser 
>>>> implemented in XUL, but it's *really* minimal, no right-click-go-back for 
>>>> example.
>>>> 3) Bundle a "portable" browser.
>>> 4) Bundle a browser plugin.
>> Maybe we can steal some code from this plugin:
>> https://nic-nac-project.org/~kaosmos/profileswitcher-en.html
>>
>> it's under GPLv3 (source is in the .xpi) and as far as I have tested, it
>> doesn't have the bug you described. So we could still provide a
>> Firefox-Profile (which isn't used by default) but also ask (in the
>> install wizard) to install the plugin. We alter it's behaviour in such a
>> way, that it simply provides a "Browse Freenet" button or menu item
>> which then loads our custom profile.
>> The advantage would be, that the user has to opt-in and that while he's
>> in the browser he can easily browse Freenet (no need to switch through
>> start menus).
> 
> Don't we want the user to be able to browse Freenet (in a customised browser) 
> and non-freenet sites at the same time?
> 

Yes we would still have the two profiles method, the user has two
windows open, one with the Freenet profile and one with his default one.
We probably don't want Freenet and usual webpages in one window, because
it leads to having to use the same profile (I don't think you can do two
profiles in one window) which would affect both, performance and privacy.
The advantage of the button method is, that the user knows there where
adjustments done to his browser (because he had to confirm the install
of the plugin in Firefox), we provide a shortcut to the Freenet profile
(no hangling through menus) and it doesn't have the bug, that Firefox
uses the Freenet profile as the default if you close the default before
you close the Freenet profile (at least I haven't experienced it up
until now).

-- 
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] Custom Firefox profile causing aggravation with users?

[Michael Tänzer]

Matthew Toseland schrieb:
> On Friday 23 May 2008 11:38, Matthew Toseland wrote:
>>> I'm not pushing for any immediate changes, but perhaps being more
>>> user-friendly regarding the custom FF profile is something to consider
>>> for 0.7.1?
>> I'd welcome any suggestions. So far, afaics the options are:
>> 1) Fix the Firefox bug that causes the profile resetting. -no-remote should 
>> cause it not only to not coalesce with an existing Firefox copy, but also 
> not 
>> to write to the default profile. Also find a new skin that works with FF3, 
>> and ideally is a little more stable!
>> 2) Build something using XULRunner. I believe this is the recommended way of 
>> doing things according to the Firefox devs. They provide a sample browser 
>> implemented in XUL, but it's *really* minimal, no right-click-go-back for 
>> example.
>> 3) Bundle a "portable" browser.
> 4) Bundle a browser plugin.

Maybe we can steal some code from this plugin:
https://nic-nac-project.org/~kaosmos/profileswitcher-en.html

it's under GPLv3 (source is in the .xpi) and as far as I have tested, it
doesn't have the bug you described. So we could still provide a
Firefox-Profile (which isn't used by default) but also ask (in the
install wizard) to install the plugin. We alter it's behaviour in such a
way, that it simply provides a "Browse Freenet" button or menu item
which then loads our custom profile.
The advantage would be, that the user has to opt-in and that while he's
in the browser he can easily browse Freenet (no need to switch through
start menus).

-- 
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: 

Re: [freenet-dev] Custom Firefox profile causing aggravation with users?

[Michael Tänzer]

Matthew Toseland schrieb:
> On Friday 23 May 2008 11:38, Matthew Toseland wrote:
>>> I'm not pushing for any immediate changes, but perhaps being more
>>> user-friendly regarding the custom FF profile is something to consider
>>> for 0.7.1?
>> I'd welcome any suggestions. So far, afaics the options are:
>> 1) Fix the Firefox bug that causes the profile resetting. -no-remote should 
>> cause it not only to not coalesce with an existing Firefox copy, but also 
> not 
>> to write to the default profile. Also find a new skin that works with FF3, 
>> and ideally is a little more stable!
>> 2) Build something using XULRunner. I believe this is the recommended way of 
>> doing things according to the Firefox devs. They provide a sample browser 
>> implemented in XUL, but it's *really* minimal, no right-click-go-back for 
>> example.
>> 3) Bundle a "portable" browser.
> 4) Bundle a browser plugin.

Maybe we can steal some code from this plugin:
https://nic-nac-project.org/~kaosmos/profileswitcher-en.html

it's under GPLv3 (source is in the .xpi) and as far as I have tested, it
doesn't have the bug you described. So we could still provide a
Firefox-Profile (which isn't used by default) but also ask (in the
install wizard) to install the plugin. We alter it's behaviour in such a
way, that it simply provides a "Browse Freenet" button or menu item
which then loads our custom profile.
The advantage would be, that the user has to opt-in and that while he's
in the browser he can easily browse Freenet (no need to switch through
start menus).

-- 
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] Website not the big problem atm? was Re: Content Management System

[Michael Tänzer]

Matthew Toseland schrieb:
> On Tuesday 13 May 2008 05:44, Ian Clarke wrote:
>> On Mon, May 12, 2008 at 11:21 PM, Florent Daigni?re
>>  wrote:
>>>  Well what's the solution then? To make Matthew work on the website? to
>>>  send a call for help on @announce (possibly a better phrased than mine)?
>>>
>>>  Shall I forget about the drupal vhost right-now and delete it?
>> Definitely not, its a good experiment, and may yield good results.
>>
>> I think you are right that none of us are good web developers, and
>> frankly its going to be hard to find some web development genius to
>> give his time to re-architecting the website.
>>
>> I think the key is to take advantage of open source, to find a good
>> design that is released under a free license (perhaps GPL, perhaps
>> creative commons, maybe something else), and use it, perhaps with a
>> few minor modifications (logo, color scheme, etc).
>>
>> I've suggested looking at the Mozilla project, because they release
>> their websites under creative commons, and they have some pretty good
>> web-designers.  Of course we should look elsewhere too.
>>

I don't think funding depends on how our website looks, at least not
directly. I still am not convinced that a Mozilla-like design would fit
our project, although I have to admit there are a few things we could
improve (e.g. a simple summary on top of each page, so the user doesn't
have to read through the whole techspeek).
We never could do a landing page like getfirefox which gives almost no
information on the setup process, because Freenet is not as easily set
up, it's not plug'n'play, you have to adjust a few settings.
Apart from the installing process Freenet is not yet another colourful
designer application, it's software that is meant to provide you
anonymity and security against censorship. It's not like candy it's
medicine, it should look different because if it doesn't people could
get careless, but it doesn't have to taste bitter.

>> We need to find a way to have a professional looking website, without
>> a) having to build it from scratch ourselves and b) having to spend
>> any of our precious donations on building it.  Taking advantage of
>> open source HTML and CSS code seems like the natural answer to this.
> 
> As nextgens pointed out recently, our current website has a 40% conversion 
> rate - that is, 40% of our unique visitors downloaded Freenet. Given the 
> level of political baggage and technicality that Freenet inevitably comes 
> with, that suggests that the website is not the biggest problem facing us.
> 
> No?
> 
> IMHO the bigger problem is user retention. And how do we get better user 
> retention?
> - More content.
> - Better performance.
> - A usable chat client. (Whether or not we choose to spend project resources 
> on this, IMHO it will result in higher user retention).

We don't need to attract nerds, they are already on Freenet (at least a
part of them). We need to attract artists, normal users, and other
people (they will bring in some new content) so we have to find out
about use cases which actually would provide them with some
functionality which they can't get elsewhere and which is a really
useful for them and then we have to build the software which makes it
happen. We have to give them reasons to use Freenet, not only give them
no reason not to use it. The question should be "Why should I use
Freenet?" not "Why shouldn't you use it?"

Also we should explain the difference and the advantage between Freenet
and Tor better and in a well visited place (e.g. the whatis.html), there
are many users who think Freenet provides the same core functionality as
Tor and therefore use Tor (I don't mean to bring up a flamewar against
Tor but we have to clarify what the difference is and why it may be
useful to have both systems installed).

Apart from that we should have an ungeekish way to provide support to
people having questions about Freenet. IRC is definitely a bit geekish
and not everyone would subscribe to a mailinglist. But everyone who's on
the web knows how to use forums. Yes I know I don't really like them
either but ask yourself "would your mother subscribe herself to a
mailinglist?" she probably wouldn't. A functionality we could easily
provide with the new CMS.

Also we have to get rid of our filesharing image. I know you can do
filesharing over Freenet but it's not the right place to get the latest
blockbuster (one reason is because it's too slow). The current situation
is that those who think Freenet is yet another filesharing app (but with
better security) and who approve of that get disappointed and those who
disapprove it don't want to have it for that reason but if they had
tried maybe they found out it was the right thing for them. We should
emphasize this more on upcoming press releases.

For the killer application chat client talk to saces, he had a prototype
of some java app called minichat which actually could exchange messages
in almost real time (few seconds dela

Re: [freenet-dev] Website not the big problem atm? was Re: Content Management System

[Michael Tänzer]

Matthew Toseland schrieb:
> On Tuesday 13 May 2008 05:44, Ian Clarke wrote:
>> On Mon, May 12, 2008 at 11:21 PM, Florent Daignière
>> <[EMAIL PROTECTED]> wrote:
>>>  Well what's the solution then? To make Matthew work on the website? to
>>>  send a call for help on @announce (possibly a better phrased than mine)?
>>>
>>>  Shall I forget about the drupal vhost right-now and delete it?
>> Definitely not, its a good experiment, and may yield good results.
>>
>> I think you are right that none of us are good web developers, and
>> frankly its going to be hard to find some web development genius to
>> give his time to re-architecting the website.
>>
>> I think the key is to take advantage of open source, to find a good
>> design that is released under a free license (perhaps GPL, perhaps
>> creative commons, maybe something else), and use it, perhaps with a
>> few minor modifications (logo, color scheme, etc).
>>
>> I've suggested looking at the Mozilla project, because they release
>> their websites under creative commons, and they have some pretty good
>> web-designers.  Of course we should look elsewhere too.
>>

I don't think funding depends on how our website looks, at least not
directly. I still am not convinced that a Mozilla-like design would fit
our project, although I have to admit there are a few things we could
improve (e.g. a simple summary on top of each page, so the user doesn't
have to read through the whole techspeek).
We never could do a landing page like getfirefox which gives almost no
information on the setup process, because Freenet is not as easily set
up, it's not plug'n'play, you have to adjust a few settings.
Apart from the installing process Freenet is not yet another colourful
designer application, it's software that is meant to provide you
anonymity and security against censorship. It's not like candy it's
medicine, it should look different because if it doesn't people could
get careless, but it doesn't have to taste bitter.

>> We need to find a way to have a professional looking website, without
>> a) having to build it from scratch ourselves and b) having to spend
>> any of our precious donations on building it.  Taking advantage of
>> open source HTML and CSS code seems like the natural answer to this.
> 
> As nextgens pointed out recently, our current website has a 40% conversion 
> rate - that is, 40% of our unique visitors downloaded Freenet. Given the 
> level of political baggage and technicality that Freenet inevitably comes 
> with, that suggests that the website is not the biggest problem facing us.
> 
> No?
> 
> IMHO the bigger problem is user retention. And how do we get better user 
> retention?
> - More content.
> - Better performance.
> - A usable chat client. (Whether or not we choose to spend project resources 
> on this, IMHO it will result in higher user retention).

We don't need to attract nerds, they are already on Freenet (at least a
part of them). We need to attract artists, normal users, and other
people (they will bring in some new content) so we have to find out
about use cases which actually would provide them with some
functionality which they can't get elsewhere and which is a really
useful for them and then we have to build the software which makes it
happen. We have to give them reasons to use Freenet, not only give them
no reason not to use it. The question should be "Why should I use
Freenet?" not "Why shouldn't you use it?"

Also we should explain the difference and the advantage between Freenet
and Tor better and in a well visited place (e.g. the whatis.html), there
are many users who think Freenet provides the same core functionality as
Tor and therefore use Tor (I don't mean to bring up a flamewar against
Tor but we have to clarify what the difference is and why it may be
useful to have both systems installed).

Apart from that we should have an ungeekish way to provide support to
people having questions about Freenet. IRC is definitely a bit geekish
and not everyone would subscribe to a mailinglist. But everyone who's on
the web knows how to use forums. Yes I know I don't really like them
either but ask yourself "would your mother subscribe herself to a
mailinglist?" she probably wouldn't. A functionality we could easily
provide with the new CMS.

Also we have to get rid of our filesharing image. I know you can do
filesharing over Freenet but it's not the right place to get the latest
blockbuster (one reason is because it's too slow). The current situation
is that those who think Freenet is yet another filesharing app (but with
better security) and who approve of that get disappointed and those who
disapprove it don't want to have it for that reason but if they had
tried maybe they found out it was the right thing for them. We should
emphasize this more on upcoming press releases.

For the killer application chat client talk to saces, he had a prototype
of some java app called minichat which actually could exchange messages
in almost real tim

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

[Michael Tänzer]

Florent Daigni?re schrieb:
> * Michael T?nzer  [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 ?
> 

Well it should link to the English news section, before your changes it
was href="/index.php?site=news&lang=en" then you changed it to
href="/news.html?lang=en" neither the old nor the new one work now (one
just gets the german section, because of the content negotiation with
the browser).

-- 
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: 

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

[Michael Tänzer]

Florent Daignière schrieb:
> * 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 ?
> 

Well it should link to the English news section, before your changes it
was href="/index.php?site=news&lang=en" then you changed it to
href="/news.html?lang=en" neither the old nor the new one work now (one
just gets the german section, because of the content negotiation with
the browser).

-- 
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] [freenet-cvs] r19836 - in trunk/website: . includes pages/de

[Michael Tänzer]

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.

nextgens at freenetproject.org 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.'  ::  ';
> -  

[freenet-dev] Content Management System

[Michael Tänzer]

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: 

[freenet-dev] Content Management System

[Michael Tänzer]

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: 

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

[Michael Tänzer]

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

[Michael Tänzer]

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

Re: [freenet-dev] Content Management System

[Michael Tänzer]

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

[Michael Tänzer]

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: 

[freenet-dev] Content Management System

[Michael Tänzer]

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
[EMAIL PROTECTED]

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/



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

[freenet-dev] New Website Layout

[Michael Tänzer]

Hi folks,

I've done a new layout for our website. It isn't just prettier but also
cleans up the mess which was done when looking at the old layout with a
browser window narrower than 700 pixel.
I tested it in Firefox (2 & 3), Opera, IE, Safari and Konqueror, but all
of them only in the newest version, it's not seriously broken in any of
them. Almost all browsers do have a problem with
http://freenetproject.org/documentation.html though, there the menu is
quite long and there's not much content, which causes the menu to stick
out of the body element (it's just an aesthetical problem, no content is
unreadable or inaccessible because of this). As always the IE is the
exception, it widens the body element so the menu fits in, but it has
other problems: it uses microsofts broken box model therefore the page
doesn't look the same way as in the other browsers (but it's not ugly,
we could do a CSS hack to fix it, but I don't think we need that) and
the picture with the mug (which leads to the freenet shop) isn't centred.

Please test the new design in your favourite browsers and let me know if
there are some problems.

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: 

[freenet-dev] New Website Layout

[Michael Tänzer]

Hi folks,

I've done a new layout for our website. It isn't just prettier but also
cleans up the mess which was done when looking at the old layout with a
browser window narrower than 700 pixel.
I tested it in Firefox (2 & 3), Opera, IE, Safari and Konqueror, but all
of them only in the newest version, it's not seriously broken in any of
them. Almost all browsers do have a problem with
http://freenetproject.org/documentation.html though, there the menu is
quite long and there's not much content, which causes the menu to stick
out of the body element (it's just an aesthetical problem, no content is
unreadable or inaccessible because of this). As always the IE is the
exception, it widens the body element so the menu fits in, but it has
other problems: it uses microsofts broken box model therefore the page
doesn't look the same way as in the other browsers (but it's not ugly,
we could do a CSS hack to fix it, but I don't think we need that) and
the picture with the mug (which leads to the freenet shop) isn't centred.

Please test the new design in your favourite browsers and let me know if
there are some problems.

[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] Updating the wiki

[Michael Tänzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthew Toseland schrieb:
> [19:03]  toad_, I think we have to have a look on the wiki
> [19:03]  especially the install thingies should be correct when we 
> release the alpha
> 
> I understand that some of the non-english wiki pages still refer to 
> #freenet-refs ? Could their owners / other people speaking the languages in 
> question please update them?
> 

Well that could be still the case (I mentioned it at #freenet-es and
some other channel (#freenet-se?) when I saw it) but wasn't the thing I
wanted to point at.

The install sections (e.g. QuickStart) sometimes explain how things were
done with older installers. Now some things have changed:

- - we use a new java based installer, which provides different options
than the older one (e.g. no extended or poweruser mode)

- - does running another freenet node during install cause problems
anymore? (worked well for me, during a test install) but this is a minor
issue.

- - we do have a install wizard (http://127.0.0.1:/wizard/) and a full
featured config-page so as long as the node starts up properly we
probably don't want to edit the freenet.ini by hand (we could provide
the corresponding option in the freenet.ini for advanced users though
but we don't want to make this the default procedure as it's likely to
produce errors)

- - has someone tested the offline installer recently? I tried it with the
steps and installer provided some weeks ago, but it failed

there's probably more but I don't remember and I didn't go through all
the pages. Somethings I just fixed on the go (e.g. install java on
ubuntu systems on the Prerequisites) but I would appreciate it if
someone had a look at it because 1. I'm German and although I think I
can make myself understood I'm not a native speaker and might have got
some things wrong (doesn't look nice if the first thing you see is a
mistake) 2. my system is localized to the German language (I don't mean
freenet, that is easily changed on the go, but my OS) so I can only
guess what some dialogue boxes say in English


I think if we keep the wiki and website up to date and do some
walkthrough tests once in a while we will significantly reduce traffic
on the IRC and therefore have less work.

Also if one information is outdated (like for example the install
section) people tend to think other parts of the site aren't up to date
too (e.g. the whole "how freenet works" stuff, which usually is being
kept up to date) and stop reading, which leads to even more questions on
IRC.

This is not a problem _now_ but if we really get slashdotted or
announced in some other well visited tech-site (which _will_ happen if
we release a Beta or even a 0.7.0) people will come and ask questions
(or even worse don't ask them and uninstall immediately) and if they hit
our channel and it's very crowded in there and everyone asks the same
questions (just because of wrong manuals) they will get pissed off
(sorry for the wording) (and we will get pissed off too).


So in general we need a more up to date documentation because RTFS (read
the f***ing source) is not an option, especially not when it comes to
installing an app and get it running.



regards
Neo at NHNG
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHn6PHPUBAMhFf+J4RAmpGAKClD8lrsAVZ2QQBnTz0XmkE4a4dggCglUm3
HZTWQr0iu61/1jD7bK/oauI=
=uMxk
-END PGP SIGNATURE-
-- next part --
A non-text attachment was scrubbed...
Name: 0x115FF89E.asc
Type: application/pgp-keys
Size: 2437 bytes
Desc: not available
URL: 

Re: [freenet-dev] Updating the wiki

[Michael Tänzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthew Toseland schrieb:
> [19:03]  toad_, I think we have to have a look on the wiki
> [19:03]  especially the install thingies should be correct when we 
> release the alpha
> 
> I understand that some of the non-english wiki pages still refer to 
> #freenet-refs ? Could their owners / other people speaking the languages in 
> question please update them?
> 

Well that could be still the case (I mentioned it at #freenet-es and
some other channel (#freenet-se?) when I saw it) but wasn't the thing I
wanted to point at.

The install sections (e.g. QuickStart) sometimes explain how things were
done with older installers. Now some things have changed:

- - we use a new java based installer, which provides different options
than the older one (e.g. no extended or poweruser mode)

- - does running another freenet node during install cause problems
anymore? (worked well for me, during a test install) but this is a minor
issue.

- - we do have a install wizard (http://127.0.0.1:/wizard/) and a full
featured config-page so as long as the node starts up properly we
probably don't want to edit the freenet.ini by hand (we could provide
the corresponding option in the freenet.ini for advanced users though
but we don't want to make this the default procedure as it's likely to
produce errors)

- - has someone tested the offline installer recently? I tried it with the
steps and installer provided some weeks ago, but it failed

there's probably more but I don't remember and I didn't go through all
the pages. Somethings I just fixed on the go (e.g. install java on
ubuntu systems on the Prerequisites) but I would appreciate it if
someone had a look at it because 1. I'm German and although I think I
can make myself understood I'm not a native speaker and might have got
some things wrong (doesn't look nice if the first thing you see is a
mistake) 2. my system is localized to the German language (I don't mean
freenet, that is easily changed on the go, but my OS) so I can only
guess what some dialogue boxes say in English


I think if we keep the wiki and website up to date and do some
walkthrough tests once in a while we will significantly reduce traffic
on the IRC and therefore have less work.

Also if one information is outdated (like for example the install
section) people tend to think other parts of the site aren't up to date
too (e.g. the whole "how freenet works" stuff, which usually is being
kept up to date) and stop reading, which leads to even more questions on
IRC.

This is not a problem _now_ but if we really get slashdotted or
announced in some other well visited tech-site (which _will_ happen if
we release a Beta or even a 0.7.0) people will come and ask questions
(or even worse don't ask them and uninstall immediately) and if they hit
our channel and it's very crowded in there and everyone asks the same
questions (just because of wrong manuals) they will get pissed off
(sorry for the wording) (and we will get pissed off too).


So in general we need a more up to date documentation because RTFS (read
the f***ing source) is not an option, especially not when it comes to
installing an app and get it running.



regards
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHn6PHPUBAMhFf+J4RAmpGAKClD8lrsAVZ2QQBnTz0XmkE4a4dggCglUm3
HZTWQr0iu61/1jD7bK/oauI=
=uMxk
-END PGP SIGNATURE-


0x115FF89E.asc
Description: application/pgp-keys
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] The perils of releasing unusable software, or why opennet sucks

[Michael Tänzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthew Toseland schrieb:
> On Wednesday 23 January 2008 23:41, Michael T?nzer wrote:
>> Please see the following discussion:
>>
> http://archives.freenetproject.org/thread/20080115.204804.97aa6904.en.html#20080115.204804.97aa6904
>> David Sowder schrieb:
>>> The node should do it's own tests first and then ask the user.  The node
>>> has a pretty good idea if it is externally accessible.
>> That is the easy to do stuff, but can't be determined on "install time",
>> therefore we should do it in the config page, maybe we could do an
>> useralert in the way "Your node has detected, that it meets the
>> requirements for a seednode. More information on becoming a Seednode can
>> be found at ${link}. Would you like to become a seednode? [Yes] [No]
> 
> Is it important to not ask the user if they're not eligible? We can always 
> ask 
> them and then not include ourselves because we're not.

That is probably the better solution, but that's not the hard problem to
solve. The main point is, we can know whether we're eligible. How we
implement the option whether to act as a seednode is irrelevant if we
don't have a solution to our main problem: the harvesting itself.

>>> The seednodes.fref file should probably some random subset of the total
>>> pool, once we have a auto-harvesting, possibly giving the same client
>>> the same random subset for some period of time.  The entries in
>>> seednodes.fref should probably auto-expire after some time period, once
>>> we have auto-harvesting, relying on the seednodes themselves to
>>> "re-announce" to the central location.
>> If we give away just a subset of the database, we have to make 100% sure
>> that at least 5 of the Seednodes on the subset are up and working.
>> There is also no way of keeping an attacker from requesting the subset
>> more than once in order to get an almost complete list.
> 
> Except by only giving the same 20 nodes to the same IP address? Of course the 
> problem with this is what if some of them aren't working?

If we always give the same 20 we still have to make sure that at least 5
of them are working. And AFAICS it's not possible to effectively limit
it to one computer (we probably don't want to limit it to one IP because
that can easily cheat by reconnecting and getting a new IP (most ISPs
allow that) or if it is a more powerfull attacker just use another IP in
our pool - and if we are a normal user and there are no 5 working
seednodes on our subset, we can't easily get another subset and will get
annoyed --> uninstall freenet).

So if we want to limit the given refs to a subset of our database, we
have to ensure, that they are working. These checks are expensive. And
as there are ways to cheat this subset thingy, we could just globally
limit the seednode.fref to a subset of our database, so there's no way
for attackers to cheat on it (you can't get another subset) and we don't
have to make the expensive checks that often. This is exactly what I
described in my proposal (well, one of the corrections of it).

regards
Neo at NHNG
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHmMZNPUBAMhFf+J4RAskEAKCmk+ftZEdQQmKQSPC+E5F4CbSgSQCdGQvl
CYybZhuj4T0daiUeeuevhEo=
=ymLD
-END PGP SIGNATURE-

Re: [freenet-dev] The perils of releasing unusable software, or why opennet sucks

[Michael Tänzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthew Toseland schrieb:
> On Wednesday 23 January 2008 23:41, Michael Tänzer wrote:
>> Please see the following discussion:
>>
> http://archives.freenetproject.org/thread/20080115.204804.97aa6904.en.html#20080115.204804.97aa6904
>> David Sowder schrieb:
>>> The node should do it's own tests first and then ask the user.  The node
>>> has a pretty good idea if it is externally accessible.
>> That is the easy to do stuff, but can't be determined on "install time",
>> therefore we should do it in the config page, maybe we could do an
>> useralert in the way "Your node has detected, that it meets the
>> requirements for a seednode. More information on becoming a Seednode can
>> be found at ${link}. Would you like to become a seednode? [Yes] [No]
> 
> Is it important to not ask the user if they're not eligible? We can always 
> ask 
> them and then not include ourselves because we're not.

That is probably the better solution, but that's not the hard problem to
solve. The main point is, we can know whether we're eligible. How we
implement the option whether to act as a seednode is irrelevant if we
don't have a solution to our main problem: the harvesting itself.

>>> The seednodes.fref file should probably some random subset of the total
>>> pool, once we have a auto-harvesting, possibly giving the same client
>>> the same random subset for some period of time.  The entries in
>>> seednodes.fref should probably auto-expire after some time period, once
>>> we have auto-harvesting, relying on the seednodes themselves to
>>> "re-announce" to the central location.
>> If we give away just a subset of the database, we have to make 100% sure
>> that at least 5 of the Seednodes on the subset are up and working.
>> There is also no way of keeping an attacker from requesting the subset
>> more than once in order to get an almost complete list.
> 
> Except by only giving the same 20 nodes to the same IP address? Of course the 
> problem with this is what if some of them aren't working?

If we always give the same 20 we still have to make sure that at least 5
of them are working. And AFAICS it's not possible to effectively limit
it to one computer (we probably don't want to limit it to one IP because
that can easily cheat by reconnecting and getting a new IP (most ISPs
allow that) or if it is a more powerfull attacker just use another IP in
our pool - and if we are a normal user and there are no 5 working
seednodes on our subset, we can't easily get another subset and will get
annoyed --> uninstall freenet).

So if we want to limit the given refs to a subset of our database, we
have to ensure, that they are working. These checks are expensive. And
as there are ways to cheat this subset thingy, we could just globally
limit the seednode.fref to a subset of our database, so there's no way
for attackers to cheat on it (you can't get another subset) and we don't
have to make the expensive checks that often. This is exactly what I
described in my proposal (well, one of the corrections of it).

regards
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHmMZNPUBAMhFf+J4RAskEAKCmk+ftZEdQQmKQSPC+E5F4CbSgSQCdGQvl
CYybZhuj4T0daiUeeuevhEo=
=ymLD
-END PGP SIGNATURE-
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] The perils of releasing unusable software, or why opennet sucks

[Michael Tänzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Please see the following discussion:
http://archives.freenetproject.org/thread/20080115.204804.97aa6904.en.html#20080115.204804.97aa6904

David Sowder schrieb:
> The node should do it's own tests first and then ask the user.  The node 
> has a pretty good idea if it is externally accessible.
>

That is the easy to do stuff, but can't be determined on "install time",
therefore we should do it in the config page, maybe we could do an
useralert in the way "Your node has detected, that it meets the
requirements for a seednode. More information on becoming a Seednode can
be found at ${link}. Would you like to become a seednode? [Yes] [No]

> The seednodes.fref file should probably some random subset of the total 
> pool, once we have a auto-harvesting, possibly giving the same client 
> the same random subset for some period of time.  The entries in 
> seednodes.fref should probably auto-expire after some time period, once 
> we have auto-harvesting, relying on the seednodes themselves to 
> "re-announce" to the central location.
> 

If we give away just a subset of the database, we have to make 100% sure
that at least 5 of the Seednodes on the subset are up and working.
There is also no way of keeping an attacker from requesting the subset
more than once in order to get an almost complete list.

> Clients need a method to auto-update their seednodes list.
>
> I could probably do the server-side PHP coding, but I can't say how long 
> it'll take me, but once there's a "go" and I get started actually coding 
> the PHP, it shouldn't take too terribly long.
>

I know too less about php therefore I can't tell whether it would be
possible if the announcement like I proposed it in the earlier
discussion could be written in it, but basically it would be a good idea
to do it in Java/Java-Server-Pages too as that's the language we (and
that's the point: toad) are able to code.

> Colin Davis wrote:
>> Again, I'm not the right guy to ask, but- The node can't test to see if 
>> it's externally accessible, and we can't trust it when it says it can 
>> get outside. It's safer to test externally.
>>
>> Julien Cornuwel wrote:
>>   
>>> What about the node doing all the tests to know if it's eligible to be 
>>> a seednode and then, if it is, ask the user ?
>>>
>>>
>>> Colin Davis a ?crit :
>>> 
 I admit that I'm woefully ignorant when it comes to proper design, 
 and I'm not among the smartest people in the room.
 That said, these don't seem like difficult problems- Certainly it's 
 because I'm missing the complexity.

 I think it the installer should present the option, because that's 
 when users are most likely to hit Yes.
 They don't want to futz with things.. If the question comes up, and 
 there is no default answer (As I showed before), They'll think about 
 it, then choose.

 I'm not entirely convinced that emu having a list of 10-20% of the 
 user's IPs is a horrible thing.
 Keep in mind- We do not have to give this entire list out to each 
 requester, nor do we have to accept data into the list without 
 testing it.
 It's only added to the list if the user explicitly chooses to do so, 
 and even then, we're not sharing it.

 Imagine if you will that there is a PHP script on 
 freenet-project.org.. The  script takes in a noderef, and saves it to 
 a file on the machine. [1]
 A helper application then attempts to connect to the Noderef.. It 
 records if it is successful or failure and the time/date.
 The helper app loops through all the submitted noderefs, and 
 continues to store their success/failure and the time/date.


How do we make sure an attacker can't place bogus nodes on the list,
that only react to our server's IP?

 When we find that we've successfully connected to the node over a 
 long enough time span, it then gets added to VerifiedNodes.txt

 When you start Freenet for the first time, the installer can ask 
 "Would you like to download the freshest set of seed nodes? Having 
 the freshest set of seed nodes allows freenet to get started much 
 faster. Without it, it may take up to a day to become integrated into 
 the network"

 When they make a request to freenet-project.org/getSeeds.php, we 
 return 20 random seeds from the VerifiedNodes file.

 The helper app continues to test nodes from the VerifiedNodes.txt.. 
 If it hits a certain number of failures to connect, it removes the line.


 Assuming there were a way to pass Freenet a noderef from the command 
 line, and get back a success or failure when trying to connect, this 
 is something that I could code up in a bash script in about an hour, 
 and I'm not a very good programmer. I'd be happy to help if you'd like.

 I'm sure I'm missing the complexity somewhere.

 -Colin



 [1] Or 

[freenet-dev] The perils of releasing unusable software, or why opennet sucks

[Michael Tänzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Colin Davis schrieb:
> If we added a  button to the installer to add yourself as a seednode, 
> perhaps we could offer a better collection of starting nodes.
> 
> 
> 
> Do you want to be added to Freenet Directory?
> Adding yourself to the Freenet Directory will publicly publish your 
> connection information, so that new users can use your machine to get up 
> and running faster.
> Publishing your information to the Freenet Directory will allow people 
> to find out that you're running freenet, but will not compromise your 
> anonymity on the network.
> 
> [Yes, Publish my information to the directory.]
> [No, Keep me me as Secure as Possible]
> 
> 
> If they clicked Yes, it could then start the heuristics to check that 
> the node has been up long enough, IP stable, etc, before auto-posting 
> the noderef through php to freenet.com, which could then add it to the 
> next download, or we could have the installer download a random 
> selection from the noderefs during the installation process.
> 
> -Colin
> 

If we want to provide such an option (which should not be given in the
installer but on the config page, so established nodes will become
Seednodes not nodes which haven't integrated well and will be
uninstalled soon as the user just wanted to give it a try) then we need
working seednode harvesting, but that seems pretty complicated as far as
it has been discussed, but if you have an idea, we will be glad to hear
it. We also (for obvious reasons) don't want the seednodes.fref to
become something like the yellow pages for opennet (where not everyone
but almost everyone has an entry and no checks are being made).
The reasons are:
- - freenet is anonymity software, we don't want to publish an almost
complete list of our users
- - if there are many nodes installed and uninstalled, the list becomes
crappy, because many entries lead nowhere, it will take even longer for
new users to connect
- - the seednodes.fref should stay under a few MB
- - we don't want it spammed or even worse flooded with entries from
attackers

regards
Neo at NHNG

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHl5soPUBAMhFf+J4RAtG7AJ9K2PQeeO9ElBNzHkQ7xzp0oSq2+ACcDKoV
sGSo4W0dsGXvzElouY/Nf3k=
=X5/K
-END PGP SIGNATURE-

Re: [freenet-dev] The perils of releasing unusable software, or why opennet sucks

[Michael Tänzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Please see the following discussion:
http://archives.freenetproject.org/thread/20080115.204804.97aa6904.en.html#20080115.204804.97aa6904

David Sowder schrieb:
> The node should do it's own tests first and then ask the user.  The node 
> has a pretty good idea if it is externally accessible.
>

That is the easy to do stuff, but can't be determined on "install time",
therefore we should do it in the config page, maybe we could do an
useralert in the way "Your node has detected, that it meets the
requirements for a seednode. More information on becoming a Seednode can
be found at ${link}. Would you like to become a seednode? [Yes] [No]

> The seednodes.fref file should probably some random subset of the total 
> pool, once we have a auto-harvesting, possibly giving the same client 
> the same random subset for some period of time.  The entries in 
> seednodes.fref should probably auto-expire after some time period, once 
> we have auto-harvesting, relying on the seednodes themselves to 
> "re-announce" to the central location.
> 

If we give away just a subset of the database, we have to make 100% sure
that at least 5 of the Seednodes on the subset are up and working.
There is also no way of keeping an attacker from requesting the subset
more than once in order to get an almost complete list.

> Clients need a method to auto-update their seednodes list.
>
> I could probably do the server-side PHP coding, but I can't say how long 
> it'll take me, but once there's a "go" and I get started actually coding 
> the PHP, it shouldn't take too terribly long.
>

I know too less about php therefore I can't tell whether it would be
possible if the announcement like I proposed it in the earlier
discussion could be written in it, but basically it would be a good idea
to do it in Java/Java-Server-Pages too as that's the language we (and
that's the point: toad) are able to code.

> Colin Davis wrote:
>> Again, I'm not the right guy to ask, but- The node can't test to see if 
>> it's externally accessible, and we can't trust it when it says it can 
>> get outside. It's safer to test externally.
>>
>> Julien Cornuwel wrote:
>>   
>>> What about the node doing all the tests to know if it's eligible to be 
>>> a seednode and then, if it is, ask the user ?
>>>
>>>
>>> Colin Davis a écrit :
>>> 
 I admit that I'm woefully ignorant when it comes to proper design, 
 and I'm not among the smartest people in the room.
 That said, these don't seem like difficult problems- Certainly it's 
 because I'm missing the complexity.

 I think it the installer should present the option, because that's 
 when users are most likely to hit Yes.
 They don't want to futz with things.. If the question comes up, and 
 there is no default answer (As I showed before), They'll think about 
 it, then choose.

 I'm not entirely convinced that emu having a list of 10-20% of the 
 user's IPs is a horrible thing.
 Keep in mind- We do not have to give this entire list out to each 
 requester, nor do we have to accept data into the list without 
 testing it.
 It's only added to the list if the user explicitly chooses to do so, 
 and even then, we're not sharing it.

 Imagine if you will that there is a PHP script on 
 freenet-project.org.. The  script takes in a noderef, and saves it to 
 a file on the machine. [1]
 A helper application then attempts to connect to the Noderef.. It 
 records if it is successful or failure and the time/date.
 The helper app loops through all the submitted noderefs, and 
 continues to store their success/failure and the time/date.


How do we make sure an attacker can't place bogus nodes on the list,
that only react to our server's IP?

 When we find that we've successfully connected to the node over a 
 long enough time span, it then gets added to VerifiedNodes.txt

 When you start Freenet for the first time, the installer can ask 
 "Would you like to download the freshest set of seed nodes? Having 
 the freshest set of seed nodes allows freenet to get started much 
 faster. Without it, it may take up to a day to become integrated into 
 the network"

 When they make a request to freenet-project.org/getSeeds.php, we 
 return 20 random seeds from the VerifiedNodes file.

 The helper app continues to test nodes from the VerifiedNodes.txt.. 
 If it hits a certain number of failures to connect, it removes the line.


 Assuming there were a way to pass Freenet a noderef from the command 
 line, and get back a success or failure when trying to connect, this 
 is something that I could code up in a bash script in about an hour, 
 and I'm not a very good programmer. I'd be happy to help if you'd like.

 I'm sure I'm missing the complexity somewhere.

 -Colin



 [1] Or 

Re: [freenet-dev] The perils of releasing unusable software, or why opennet sucks

[Michael Tänzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Colin Davis schrieb:
> If we added a  button to the installer to add yourself as a seednode, 
> perhaps we could offer a better collection of starting nodes.
> 
> 
> 
> Do you want to be added to Freenet Directory?
> Adding yourself to the Freenet Directory will publicly publish your 
> connection information, so that new users can use your machine to get up 
> and running faster.
> Publishing your information to the Freenet Directory will allow people 
> to find out that you're running freenet, but will not compromise your 
> anonymity on the network.
> 
> [Yes, Publish my information to the directory.]
> [No, Keep me me as Secure as Possible]
> 
> 
> If they clicked Yes, it could then start the heuristics to check that 
> the node has been up long enough, IP stable, etc, before auto-posting 
> the noderef through php to freenet.com, which could then add it to the 
> next download, or we could have the installer download a random 
> selection from the noderefs during the installation process.
> 
> -Colin
> 

If we want to provide such an option (which should not be given in the
installer but on the config page, so established nodes will become
Seednodes not nodes which haven't integrated well and will be
uninstalled soon as the user just wanted to give it a try) then we need
working seednode harvesting, but that seems pretty complicated as far as
it has been discussed, but if you have an idea, we will be glad to hear
it. We also (for obvious reasons) don't want the seednodes.fref to
become something like the yellow pages for opennet (where not everyone
but almost everyone has an entry and no checks are being made).
The reasons are:
- - freenet is anonymity software, we don't want to publish an almost
complete list of our users
- - if there are many nodes installed and uninstalled, the list becomes
crappy, because many entries lead nowhere, it will take even longer for
new users to connect
- - the seednodes.fref should stay under a few MB
- - we don't want it spammed or even worse flooded with entries from
attackers

regards
[EMAIL PROTECTED]

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHl5soPUBAMhFf+J4RAtG7AJ9K2PQeeO9ElBNzHkQ7xzp0oSq2+ACcDKoV
sGSo4W0dsGXvzElouY/Nf3k=
=X5/K
-END PGP SIGNATURE-
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Proposal for Seednode harvesting

[Michael Tänzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthew Toseland schrieb:
> On Thursday 17 January 2008 23:06, Michael T?nzer wrote:
>> Michael T?nzer schrieb:
>>> Matthew Toseland schrieb:
 On Thursday 17 January 2008 03:23, Michael T?nzer (vid,smtp2) wrote:
> Matthew Toseland schrieb:
> As we probably don't want to run a node on our server itself (we could,
> but would it have enough ressources to serve the important things like
> web pages, SVN and stuff even if we are /.ed?) the Seedserver has to
> have a connection to a node somewhere and as we have some Nodes which
> should be available anyway, why not use them? This also balances the
> load between the Seednodes, avoids another single point of failure and
> makes sure they're online so we don't have to recheck apart from that.
> We don't have to be connected to all of our Seednodes all the time. Just
> if we want to verify a new Seednode we establish a new connection to one
> of our Seednodes on the Port which on which the Seedservice runs and
> verify that it's us.
 You mean for the seed server to connect to the seednodes (easily 
> spoofed), or
 for the seednodes to connect to each other (somewhat less easily 
> spoofed)?
>>> For the Seedserver connecting to the Seednodes.
>>> How is it supposed to be spoofed?
>>> - Each packet that doesn't come from our Seedservers IP is dropped
>>> - To accept the package it has to be encrypted with our public key
>>> (which _should_ only be known to us)
>> Doh, of course the public key is known by someone else (otherwise it
>> wouldn't be public) it should be only known by the _SeedServer_ because
>> he's the only one we gave it to. But it also shouldn't be a problem if
>> it get's known in public, then the second part of the identification
>> process comes into play:
> 
> That's not what I mean. I mean an attacker's bogus seednodes know the IP of 
> the seed server and can easily only respond to that IP address, thus saving 
> lots of bandwidth and not providing any useful service to any other node. 
> Also, if it's only verified shortly after adding, they can use this info too.

That's what my proposal in the other mail prevents: There are a few
trusted nodes (not SeedNodes) which report to the SeedServer when
they've found a SeedServer wich is not responding/only sending bogus but
they will connect on random not on command of the SeedServer, so it
should be harder to discover who our trusted nodes are (maybe every Node
reports but only a few are trusted (maybe with a certain probability to
reduce traffic), so the traffic of the trusted Nodes is covered by the
untrusted ones). But I think we would still need the other check to
avoid good SeedNodes getting blacklisted because if we can't connect
with at all (neither with Seednodes nor with trusted peers) that's
likely to be a nodecrash or something but if a SeedNode is connectable
to other SeedNodes but not to trusted peers that is likely to be
malicious and the IP should be blacklisted for 24 hours.

And I believe it's important to set a limit to the number of SeedNodes.
So if we've got 20 good SeedNodes an attacker can do whatever he wants
(ha can do perform headstands as we say in Germany) he won't appear on
our seednodes.fref. If some attacker is on our list and we detect it,
we'll kick him from our list and hopefully another good SeedNode will
turn in for him.

Backdraws:
- - an attacker will try to turn down the good SeedNodes so they will be
listed as disconnected (maybe we should keep a list of disconnected good
SeedNodes which we will try to connect to on their SeedService so
another good SeedNode can take turn for the DoSed one)
- - If an attacker has turned down a SeedNode he will start to connect
with his fake nodes immediately but our unlisted good SeedNodes probably
don't know when to connect and when they check back whether a slot has
been freed, they will be too late.

As an attacker will (hopefully) be likely to not stay long on the list,
we probably want to add some Captcha/hashcash/essay why he should be on
the list/whever to prevent scripting (maybe provide some timed captcha
(a captcha which times out, so it needs to be answered quick and is less
likely to be passed on) which is asked for when the "SeedNode-mode" is
enabled and all SeedNodes which solved that captcha are kept on a list
(the list also includes NodeRef, SeedService-Port and public key), from
which a node is choosen at random to go through the verification process
(another SeedNode fetches ref through it etc.).

Well this is getting pretty complicated but it should do the job and as
we don't want the access to freenet (the process on which we afterwards
build our anonymity) to be insecure or not working (this will push
people to return to the "old ways" (ref trading)) and haven't come up
with a better/easier solution we could either stay with the old system
(which afaics not working because people actually have to do 

Re: [freenet-dev] Proposal for Seednode harvesting

[Michael Tänzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthew Toseland schrieb:
> On Thursday 17 January 2008 23:06, Michael Tänzer wrote:
>> Michael Tänzer schrieb:
>>> Matthew Toseland schrieb:
>>>> On Thursday 17 January 2008 03:23, Michael Tänzer (vid,smtp2) wrote:
>>>>> Matthew Toseland schrieb:
>>>>> As we probably don't want to run a node on our server itself (we could,
>>>>> but would it have enough ressources to serve the important things like
>>>>> web pages, SVN and stuff even if we are /.ed?) the Seedserver has to
>>>>> have a connection to a node somewhere and as we have some Nodes which
>>>>> should be available anyway, why not use them? This also balances the
>>>>> load between the Seednodes, avoids another single point of failure and
>>>>> makes sure they're online so we don't have to recheck apart from that.
>>>>> We don't have to be connected to all of our Seednodes all the time. Just
>>>>> if we want to verify a new Seednode we establish a new connection to one
>>>>> of our Seednodes on the Port which on which the Seedservice runs and
>>>>> verify that it's us.
>>>> You mean for the seed server to connect to the seednodes (easily 
> spoofed), or
>>>> for the seednodes to connect to each other (somewhat less easily 
> spoofed)?
>>> For the Seedserver connecting to the Seednodes.
>>> How is it supposed to be spoofed?
>>> - Each packet that doesn't come from our Seedservers IP is dropped
>>> - To accept the package it has to be encrypted with our public key
>>> (which _should_ only be known to us)
>> Doh, of course the public key is known by someone else (otherwise it
>> wouldn't be public) it should be only known by the _SeedServer_ because
>> he's the only one we gave it to. But it also shouldn't be a problem if
>> it get's known in public, then the second part of the identification
>> process comes into play:
> 
> That's not what I mean. I mean an attacker's bogus seednodes know the IP of 
> the seed server and can easily only respond to that IP address, thus saving 
> lots of bandwidth and not providing any useful service to any other node. 
> Also, if it's only verified shortly after adding, they can use this info too.

That's what my proposal in the other mail prevents: There are a few
trusted nodes (not SeedNodes) which report to the SeedServer when
they've found a SeedServer wich is not responding/only sending bogus but
they will connect on random not on command of the SeedServer, so it
should be harder to discover who our trusted nodes are (maybe every Node
reports but only a few are trusted (maybe with a certain probability to
reduce traffic), so the traffic of the trusted Nodes is covered by the
untrusted ones). But I think we would still need the other check to
avoid good SeedNodes getting blacklisted because if we can't connect
with at all (neither with Seednodes nor with trusted peers) that's
likely to be a nodecrash or something but if a SeedNode is connectable
to other SeedNodes but not to trusted peers that is likely to be
malicious and the IP should be blacklisted for 24 hours.

And I believe it's important to set a limit to the number of SeedNodes.
So if we've got 20 good SeedNodes an attacker can do whatever he wants
(ha can do perform headstands as we say in Germany) he won't appear on
our seednodes.fref. If some attacker is on our list and we detect it,
we'll kick him from our list and hopefully another good SeedNode will
turn in for him.

Backdraws:
- - an attacker will try to turn down the good SeedNodes so they will be
listed as disconnected (maybe we should keep a list of disconnected good
SeedNodes which we will try to connect to on their SeedService so
another good SeedNode can take turn for the DoSed one)
- - If an attacker has turned down a SeedNode he will start to connect
with his fake nodes immediately but our unlisted good SeedNodes probably
don't know when to connect and when they check back whether a slot has
been freed, they will be too late.

As an attacker will (hopefully) be likely to not stay long on the list,
we probably want to add some Captcha/hashcash/essay why he should be on
the list/whever to prevent scripting (maybe provide some timed captcha
(a captcha which times out, so it needs to be answered quick and is less
likely to be passed on) which is asked for when the "SeedNode-mode" is
enabled and all SeedNodes which solved that captcha are kept on a list
(the list also includes NodeRef, SeedService-Port and public key), from
which a node is choosen at random to go through the verification process
(another Se

[freenet-dev] Proposal for Seednode harvesting

[Michael Tänzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michael T?nzer schrieb:
> Matthew Toseland schrieb:
>> On Thursday 17 January 2008 03:23, Michael T?nzer (vid,smtp2) wrote:
>>> Matthew Toseland schrieb:
>>> As we probably don't want to run a node on our server itself (we could,
>>> but would it have enough ressources to serve the important things like
>>> web pages, SVN and stuff even if we are /.ed?) the Seedserver has to
>>> have a connection to a node somewhere and as we have some Nodes which
>>> should be available anyway, why not use them? This also balances the
>>> load between the Seednodes, avoids another single point of failure and
>>> makes sure they're online so we don't have to recheck apart from that.
>>> We don't have to be connected to all of our Seednodes all the time. Just
>>> if we want to verify a new Seednode we establish a new connection to one
>>> of our Seednodes on the Port which on which the Seedservice runs and
>>> verify that it's us.
>> You mean for the seed server to connect to the seednodes (easily spoofed), 
>> or 
>> for the seednodes to connect to each other (somewhat less easily spoofed)?
> 
> For the Seedserver connecting to the Seednodes.
> How is it supposed to be spoofed?
> - Each packet that doesn't come from our Seedservers IP is dropped
> - To accept the package it has to be encrypted with our public key
> (which _should_ only be known to us)

Doh, of course the public key is known by someone else (otherwise it
wouldn't be public) it should be only known by the _SeedServer_ because
he's the only one we gave it to. But it also shouldn't be a problem if
it get's known in public, then the second part of the identification
process comes into play:

> - The SeedServer has to verify itself, by sending back a random number
> encrypted with it's public key (only the SeedServer knows the private
> key to decrypt it an send it back)
> 

regards
Neo at NHNG
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHj99sPUBAMhFf+J4RAq1EAJ9PFjXjb2ei8dsh0/IkT9J6dYehdwCgqzzY
1CPiLOM2d1nIbr5kl+unpTU=
=VFyk
-END PGP SIGNATURE-

[freenet-dev] Proposal for Seednode harvesting

[Michael Tänzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthew Toseland schrieb:
> On Thursday 17 January 2008 03:23, Michael T?nzer (vid,smtp2) wrote:
>> Matthew Toseland schrieb:
>> | It would be good to solve the verification problem without having to have
>> | permanent connections from the seed server to the seed nodes. The
>> problem is
>> | the below doesn't do this: it only verifies that the attacker is
>> listening on
>> | the stipulated port, and that he runs one freenet node somewhere, it does
>> | *not* verify that there is a connectible node on the given node reference.
>>
>> Okay, so the only way to ensure that is to test it by trying to fetch a
>> noderef (maybe our own to prevent that it only delivers refs of a
>> honeynet run by the attacker - if that's possible (e.g. by requesting a
>> key that matches our location and answer to that request). I don't know
>> whether I have understood the Opennet ref swapping process properly)
>> through the new Seednode.
> 
> Fetching a noderef wouldn't help.
> 

As we want to obtain noderefs through the SeedNode, the only way to
ensure that it's possible to get them is try it.
And that's what we do.
What is your suggestion?

>> As we probably don't want to run a node on our server itself (we could,
>> but would it have enough ressources to serve the important things like
>> web pages, SVN and stuff even if we are /.ed?) the Seedserver has to
>> have a connection to a node somewhere and as we have some Nodes which
>> should be available anyway, why not use them? This also balances the
>> load between the Seednodes, avoids another single point of failure and
>> makes sure they're online so we don't have to recheck apart from that.
>> We don't have to be connected to all of our Seednodes all the time. Just
>> if we want to verify a new Seednode we establish a new connection to one
>> of our Seednodes on the Port which on which the Seedservice runs and
>> verify that it's us.
> 
> You mean for the seed server to connect to the seednodes (easily spoofed), or 
> for the seednodes to connect to each other (somewhat less easily spoofed)?

For the Seedserver connecting to the Seednodes.
How is it supposed to be spoofed?
- - Each packet that doesn't come from our Seedservers IP is dropped
- - To accept the package it has to be encrypted with our public key
(which _should_ only be known to us)
- - The SeedServer has to verify itself, by sending back a random number
encrypted with it's public key (only the SeedServer knows the private
key to decrypt it an send it back)

>> Doh, just reread the original proposal, that's something which I had on
>> my mind but didn't write down:
>> Each SeedNode runs a SeedService on a random Port and reports that Port
>> to the SeedServer on the initiation process and keeps it up to date if
>> it changes. The SeedService listens to requests of the SeedServer so if
>> the Seedserver has to verify a new SeedNode it can ask the SeedService
>> of an alredy established SeedNode (of course we recheck the identity of
>> each other).
> 
> Verify by connecting to it?

See above

>> This should also be portscanproof as the connection only can be
>> initiated from the IP of our Server, so we can ignore the others.
>>
>> So the following attacks are left:
>> - manipulated installer
>> - DoS the Seedserver
>> - DoS SeedNodes (not a problem if one SeedNode is DoSed but if they're
>> all down - attacker needs some power to do this (e.g. big botnet) as
>> there (hopefully) are quite a few SeedNodes)
>> - Attacker as Seednode
> 
> It's all about attacker as seednode. The trivial attack is to send in 
> completely bogus noderefs. If we beat that, the attack is to send in noderefs 
> to your own nodes, which only respond to the seed server, or the other 
> seednodes. Or to let anyone connect but never do anything useful after that. 
> And so on. 
> 

The completely bogus noderef is taken care of (the helping SeedNode
obviously can't connect to a bogus ref)

If the attacker only reacts to our SeedNodes (which he knows as he also
can download the seednodes.fref) we have to check from "trusted nodes"
from time to time. These are not published and will (hopefully) remain
anonymous for a while. We have to keep te list of them up to date
manually but we don't have to make shure they're online. They check the
SeedNodes from time to time, whether they can get good (e.g. their own,
as mentioned above) references from it and report to the SeedServer if
not. If at least two Trusted Nodes mark a SeedNode as BAD we
drop/disable it (drop it if the other SeedNodes are able to connect
through it).
We also should use a limit until we take new SeedNodes, so we always
about 20 online SeedNodes (or more if the load is big) but an attacker
can't hold 80/100 SeedNodes which have to be disqualified. So the good
SeedNodes supersede the bad ones.

>> - Honeynet (the attacker could turn the honeynet off when we check him
>> and turn it back on once the check is done - maybe SeedNodes 

Re: [freenet-dev] Proposal for Seednode harvesting

[Michael Tänzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michael Tänzer schrieb:
> Matthew Toseland schrieb:
>> On Thursday 17 January 2008 03:23, Michael Tänzer (vid,smtp2) wrote:
>>> Matthew Toseland schrieb:
>>> As we probably don't want to run a node on our server itself (we could,
>>> but would it have enough ressources to serve the important things like
>>> web pages, SVN and stuff even if we are /.ed?) the Seedserver has to
>>> have a connection to a node somewhere and as we have some Nodes which
>>> should be available anyway, why not use them? This also balances the
>>> load between the Seednodes, avoids another single point of failure and
>>> makes sure they're online so we don't have to recheck apart from that.
>>> We don't have to be connected to all of our Seednodes all the time. Just
>>> if we want to verify a new Seednode we establish a new connection to one
>>> of our Seednodes on the Port which on which the Seedservice runs and
>>> verify that it's us.
>> You mean for the seed server to connect to the seednodes (easily spoofed), 
>> or 
>> for the seednodes to connect to each other (somewhat less easily spoofed)?
> 
> For the Seedserver connecting to the Seednodes.
> How is it supposed to be spoofed?
> - Each packet that doesn't come from our Seedservers IP is dropped
> - To accept the package it has to be encrypted with our public key
> (which _should_ only be known to us)

Doh, of course the public key is known by someone else (otherwise it
wouldn't be public) it should be only known by the _SeedServer_ because
he's the only one we gave it to. But it also shouldn't be a problem if
it get's known in public, then the second part of the identification
process comes into play:

> - The SeedServer has to verify itself, by sending back a random number
> encrypted with it's public key (only the SeedServer knows the private
> key to decrypt it an send it back)
> 

regards
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHj99sPUBAMhFf+J4RAq1EAJ9PFjXjb2ei8dsh0/IkT9J6dYehdwCgqzzY
1CPiLOM2d1nIbr5kl+unpTU=
=VFyk
-END PGP SIGNATURE-
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Proposal for Seednode harvesting

[Michael Tänzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthew Toseland schrieb:
> On Thursday 17 January 2008 03:23, Michael Tänzer (vid,smtp2) wrote:
>> Matthew Toseland schrieb:
>> | It would be good to solve the verification problem without having to have
>> | permanent connections from the seed server to the seed nodes. The
>> problem is
>> | the below doesn't do this: it only verifies that the attacker is
>> listening on
>> | the stipulated port, and that he runs one freenet node somewhere, it does
>> | *not* verify that there is a connectible node on the given node reference.
>>
>> Okay, so the only way to ensure that is to test it by trying to fetch a
>> noderef (maybe our own to prevent that it only delivers refs of a
>> honeynet run by the attacker - if that's possible (e.g. by requesting a
>> key that matches our location and answer to that request). I don't know
>> whether I have understood the Opennet ref swapping process properly)
>> through the new Seednode.
> 
> Fetching a noderef wouldn't help.
> 

As we want to obtain noderefs through the SeedNode, the only way to
ensure that it's possible to get them is try it.
And that's what we do.
What is your suggestion?

>> As we probably don't want to run a node on our server itself (we could,
>> but would it have enough ressources to serve the important things like
>> web pages, SVN and stuff even if we are /.ed?) the Seedserver has to
>> have a connection to a node somewhere and as we have some Nodes which
>> should be available anyway, why not use them? This also balances the
>> load between the Seednodes, avoids another single point of failure and
>> makes sure they're online so we don't have to recheck apart from that.
>> We don't have to be connected to all of our Seednodes all the time. Just
>> if we want to verify a new Seednode we establish a new connection to one
>> of our Seednodes on the Port which on which the Seedservice runs and
>> verify that it's us.
> 
> You mean for the seed server to connect to the seednodes (easily spoofed), or 
> for the seednodes to connect to each other (somewhat less easily spoofed)?

For the Seedserver connecting to the Seednodes.
How is it supposed to be spoofed?
- - Each packet that doesn't come from our Seedservers IP is dropped
- - To accept the package it has to be encrypted with our public key
(which _should_ only be known to us)
- - The SeedServer has to verify itself, by sending back a random number
encrypted with it's public key (only the SeedServer knows the private
key to decrypt it an send it back)

>> Doh, just reread the original proposal, that's something which I had on
>> my mind but didn't write down:
>> Each SeedNode runs a SeedService on a random Port and reports that Port
>> to the SeedServer on the initiation process and keeps it up to date if
>> it changes. The SeedService listens to requests of the SeedServer so if
>> the Seedserver has to verify a new SeedNode it can ask the SeedService
>> of an alredy established SeedNode (of course we recheck the identity of
>> each other).
> 
> Verify by connecting to it?

See above

>> This should also be portscanproof as the connection only can be
>> initiated from the IP of our Server, so we can ignore the others.
>>
>> So the following attacks are left:
>> - manipulated installer
>> - DoS the Seedserver
>> - DoS SeedNodes (not a problem if one SeedNode is DoSed but if they're
>> all down - attacker needs some power to do this (e.g. big botnet) as
>> there (hopefully) are quite a few SeedNodes)
>> - Attacker as Seednode
> 
> It's all about attacker as seednode. The trivial attack is to send in 
> completely bogus noderefs. If we beat that, the attack is to send in noderefs 
> to your own nodes, which only respond to the seed server, or the other 
> seednodes. Or to let anyone connect but never do anything useful after that. 
> And so on. 
> 

The completely bogus noderef is taken care of (the helping SeedNode
obviously can't connect to a bogus ref)

If the attacker only reacts to our SeedNodes (which he knows as he also
can download the seednodes.fref) we have to check from "trusted nodes"
from time to time. These are not published and will (hopefully) remain
anonymous for a while. We have to keep te list of them up to date
manually but we don't have to make shure they're online. They check the
SeedNodes from time to time, whether they can get good (e.g. their own,
as mentioned above) references from it and report to the SeedServer if
not. If at least two Trusted Nodes mark a SeedNode as BAD we
drop/disable it (drop it if the other Seed

[freenet-dev] Proposal for Seednode harvesting

["Michael Tänzer (vid,smtp2)"]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthew Toseland schrieb:
| It would be good to solve the verification problem without having to have
| permanent connections from the seed server to the seed nodes. The
problem is
| the below doesn't do this: it only verifies that the attacker is
listening on
| the stipulated port, and that he runs one freenet node somewhere, it does
| *not* verify that there is a connectible node on the given node reference.
|

Okay, so the only way to ensure that is to test it by trying to fetch a
noderef (maybe our own to prevent that it only delivers refs of a
honeynet run by the attacker - if that's possible (e.g. by requesting a
key that matches our location and answer to that request). I don't know
whether I have understood the Opennet ref swapping process properly)
through the new Seednode.
As we probably don't want to run a node on our server itself (we could,
but would it have enough ressources to serve the important things like
web pages, SVN and stuff even if we are /.ed?) the Seedserver has to
have a connection to a node somewhere and as we have some Nodes which
should be available anyway, why not use them? This also balances the
load between the Seednodes, avoids another single point of failure and
makes sure they're online so we don't have to recheck apart from that.
We don't have to be connected to all of our Seednodes all the time. Just
if we want to verify a new Seednode we establish a new connection to one
of our Seednodes on the Port which on which the Seedservice runs and
verify that it's us.
Doh, just reread the original proposal, that's something which I had on
my mind but didn't write down:
Each SeedNode runs a SeedService on a random Port and reports that Port
to the SeedServer on the initiation process and keeps it up to date if
it changes. The SeedService listens to requests of the SeedServer so if
the Seedserver has to verify a new SeedNode it can ask the SeedService
of an alredy established SeedNode (of course we recheck the identity of
each other).
This should also be portscanproof as the connection only can be
initiated from the IP of our Server, so we can ignore the others.

So the following attacks are left:
- - manipulated installer
- - DoS the Seedserver
- - DoS SeedNodes (not a problem if one SeedNode is DoSed but if they're
all down - attacker needs some power to do this (e.g. big botnet) as
there (hopefully) are quite a few SeedNodes)
- - Attacker as Seednode
- - Honeynet (the attacker could turn the honeynet off when we check him
and turn it back on once the check is done - maybe SeedNodes should
check each others functionality from time to time without announcing it,
but don't they have enough load to carry? Another solution is, that a
new Client always tries to get refs from at least 3 SeedNodes and check
whether the peers are connected (trying to get the refs of peers he got
from one SeedNode through peers he got from another one))


regards
Neo at NHNG
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHjspDPUBAMhFf+J4RAvQYAJ0cNVKgBaXLVYoDbebQkJv4hZcyAwCfQUUv
YTEKy1Z8/hd87pPIfDJogfo=
=g9yM
-END PGP SIGNATURE-

Re: [freenet-dev] Proposal for Seednode harvesting

[Michael Tänzer (vid,smtp2)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthew Toseland schrieb:
| It would be good to solve the verification problem without having to have
| permanent connections from the seed server to the seed nodes. The
problem is
| the below doesn't do this: it only verifies that the attacker is
listening on
| the stipulated port, and that he runs one freenet node somewhere, it does
| *not* verify that there is a connectible node on the given node reference.
|

Okay, so the only way to ensure that is to test it by trying to fetch a
noderef (maybe our own to prevent that it only delivers refs of a
honeynet run by the attacker - if that's possible (e.g. by requesting a
key that matches our location and answer to that request). I don't know
whether I have understood the Opennet ref swapping process properly)
through the new Seednode.
As we probably don't want to run a node on our server itself (we could,
but would it have enough ressources to serve the important things like
web pages, SVN and stuff even if we are /.ed?) the Seedserver has to
have a connection to a node somewhere and as we have some Nodes which
should be available anyway, why not use them? This also balances the
load between the Seednodes, avoids another single point of failure and
makes sure they're online so we don't have to recheck apart from that.
We don't have to be connected to all of our Seednodes all the time. Just
if we want to verify a new Seednode we establish a new connection to one
of our Seednodes on the Port which on which the Seedservice runs and
verify that it's us.
Doh, just reread the original proposal, that's something which I had on
my mind but didn't write down:
Each SeedNode runs a SeedService on a random Port and reports that Port
to the SeedServer on the initiation process and keeps it up to date if
it changes. The SeedService listens to requests of the SeedServer so if
the Seedserver has to verify a new SeedNode it can ask the SeedService
of an alredy established SeedNode (of course we recheck the identity of
each other).
This should also be portscanproof as the connection only can be
initiated from the IP of our Server, so we can ignore the others.

So the following attacks are left:
- - manipulated installer
- - DoS the Seedserver
- - DoS SeedNodes (not a problem if one SeedNode is DoSed but if they're
all down - attacker needs some power to do this (e.g. big botnet) as
there (hopefully) are quite a few SeedNodes)
- - Attacker as Seednode
- - Honeynet (the attacker could turn the honeynet off when we check him
and turn it back on once the check is done - maybe SeedNodes should
check each others functionality from time to time without announcing it,
but don't they have enough load to carry? Another solution is, that a
new Client always tries to get refs from at least 3 SeedNodes and check
whether the peers are connected (trying to get the refs of peers he got
from one SeedNode through peers he got from another one))


regards
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHjspDPUBAMhFf+J4RAvQYAJ0cNVKgBaXLVYoDbebQkJv4hZcyAwCfQUUv
YTEKy1Z8/hd87pPIfDJogfo=
=g9yM
-END PGP SIGNATURE-
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] {SPAM?} Re: [freenet-cvs] r16954 - trunk/freenet/src/freenet/node

[Michael Tänzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michael Rogers schrieb:
| David Sowder wrote:
|> Cloud 1 and Cloud 2 need to be using the same N2NM type ID number for a
|> particular service if any of [A, B, C] connects with [D, E, F] if such a
|> connection is to then allow all of [A, B, C, D, E, F] to potentially
|> talk to each other because otherwise would involve some sort of
|> "difference resolution protocol" to force either [A, B, C] or [D, E, F]
|> to change their service name to N2NM type mapping to either the same
|> N2NM type ID number of the other or a third N2NM type ID number used by
|> [A, B, C, D, E, F].
|
| If you view the ID as a port number rather than a message type then
| there's no problem. Node A runs the service on port 123, node B runs it
| on port 456, etc. When you want to connect to the Foo service on a
| particular node, contact its lookup service and get the port number for
| the string "Foo". The string, rather than the port number, identifies
| the service. Different instances can have different names (eg Foo/Alice
| and Foo/Bob).
|

If we use names we also have to ensure, that there are no duplicates
(e.g. two apps named foo). It would be no problem to give names on a
first come first serve basis (first app gets foo and the second foo2)
but if the fcfs is applied different on the node we want to exchange
messages with (e.g. because we only started the second app or both in
another order) foo requests foo on the other node but gets foo2.
This can be solved by providing something like ICANN.

So as we need some fixed Table in any case I would prefer David's method
to keep it simple.

Neo at NHNG
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHjUxbPUBAMhFf+J4RAsN9AJ4qdTpsdrTEn8na9KnJNHDbYOwtTgCcCEox
6E3/XIMWk0v57toiLjyPVM8=
=etqC
-END PGP SIGNATURE-

[freenet-dev] Proposal for Seednode harvesting

[Michael Tänzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Seedserver - our script/app/whever that runs on our servers
(freenetproject.org) and takes care of the harvesting
Seednode - well the seednode
Seedclient - a new Freenet-Node which wants to bootstrap into Freenet
Seedservice -  a service which is run on the seednode to be addressed by
the Seedserver

Stage1
We deliver the public key of our Seedserver with Freenet (e.g. in the
installer or jar).
Once a node chooses to become a Seednode (Alice) it sends it's own
public key and port on which it runs the Seedservice encrypted with the
public key of the Server to our Seedserver. The Seedserver sends a
random number encrypted with the public key of Alice who has to return it.

Now the Server and the Node know each others public key and can't be
MITMed, under the assumption that the installer was correct. The
following traffic can be encrypted.

Stage2
The Seedserver asks some already established Seednode (Bob) to insert a
file which holds a random number encrypted with the public key of Alice.
Bob reports the key under which this has been inserted to Alice who
fetches it and sends the random number to the Server.
If Alice can't fetch the key, we ask another two Seednodes for inserting
it, if it still fails Alice is considered not to be connected (obviously
we have to have a long timeout here).

Now the Server knows Alice if is connected and can add her to his
Seednodes-list/DB

A Seednode has to follow this routine every 24 hours and whenever
something changes (different IP, disable Seedserver, etc. (obviously if
a seednode goes offline it doesn't have to prove it's connected to
freenet)).
The Server only accepts changes from Seednodes wich prove they can read
a random number encrypted with the public key of the Seednode entry they
want to alter.
The Server removes (or marks them disabled) Seednode entries that
weren't updated 26 hours and of Seednodes that didn't react on
insertrequests more than 3 times in a row (maybe disable them and try
again 30 min. later)

Possible Attacks:
- - manipulated installer - Well this is a general problem, not only to
seednode harvesting. We have to come up with a suitable solution for
this (SSL with trusted certificate (expensive), signed installer (how
can our users know whether to trust the public key?)

- - DoS the Seedserver - well then you could probably also DoS our
webserver and prevent our users from downloading the installer and
seednodes.fref

- - An attacker could add his node as a Seednode - well that is an obvious
problem for all of the automatic methods and also partly applies to
Seednodes which are added manually and Opennet in general - if an
attacker succesfully added a Seednode, he could have a whole farm of
manipulated nodes to which a new node is connected to and the new node
can't tell. This is especially a problem if the ghost-net has some kind
of proxy which relays requests in his own name so the node can't get
other opennet-connections and doesn't know it's not on the real freenet
and if it gets or even worse inserts some content which in the most
countries is illegal, the attacker can tell because he could spider the
freenet and do a blacklist.

Looking forward to your comments
Neo at NHNG
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHjRwEPUBAMhFf+J4RAvjxAJ91iM5ACrr5GzBOdNfEb3+So9uFJQCfUkYf
PVRa4Brixfd8BiaNzhC7+OY=
=/6/7
-END PGP SIGNATURE-

[freenet-dev] New full-probabilistic HTL was Tunnels vs premix routing was Re: Vulnerability in inserting the manifest before finishing

[Michael Tänzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthew Toseland schrieb:
| On Saturday 05 January 2008 05:15, Michael Rogers wrote:
|> Matthew Toseland wrote:
|>> The 50% chance of decrementing
|>> at 10 means that 3 resets equals 6 nodes with HTL 10...
|> It's more complicated than that... if the HTL is 10 and the closest
|> location isn't the previous hop's location, then the attacker knows the
|> previous hop doesn't decrement at 10.
|
| It's a function of the input node, not the output node. Although that's
| problematic on rerouting, so we may change it to be a function of the
input
| node for the first node tried, and then a function of the output node...
| Hmmm. Why did we want to choose it once per node again? I'm sure there
was a
| good reason, but I don't remember it...
|
|> Likewise if the HTL is 9 and the
|> closest location isn't the previous hop's location, the previous hop
|> decrements at 10. Either way, the attacker can use that knowledge for
|> the rest of the session.
|
| Okay, so for a single request, if HTL is 10, and closestLocation is
equal to
| the node's location, the node could be the originator or it could have
reset
| it. If HTL is 10, and closestLocation is not equal to the node's
location,
| the node cannot be the originator and cannot have reset the HTL.
|
| So without keeping any state, we just look for requests which have
| closestLocation equal to the previous node's location, and we have a 1
in (#
| resets per request + 1) chance that it's the originator (1 in 4 on the
| previous assumption). Ouch! I'm not sure how the additional state we
could
| keep from the above would help the attacker.
|
| For a non-resetting HTL, the odds are even worse, unless we have a long
| probabilistic htl=max stage. So plainly a weighted coin would help
| significantly. The problem is that a weighted coin would increase the
| variance in path length *significantly*, cause more no-fault timeouts,
cause
| more no-fault failures (too short a path), make request coalescing
extremely
| difficult, and likewise with ULPRs. Is there an alternative?
|
| [snip]

How about a combination of HTL and weighted coin: We don't only
decrement probabilisticly at 10 and 1 but on all the way down from 10 to
0 and flip the coin each time so no (100% sure) assumption can be made
what we will do next time. In Order to travel not too far we weigh the
coin (let's say at 80% for a decrement). If our location is closer than
the closestLocation we don't set closestLocation to our actual location
but to a location a little bit _closer_ (if we set it to a location more
far away the next node knows we reset closestLocation), this is also
done probabilistic, and set the HTL to a value between 8 and 10 (more
likely to 10 than to 8 - maybe we could even set it to a value between 1
and 10 but make 1 extremely unlikely e.g.
(int)(11-10*Math.pow(PROBABILITY_TUNER,(-Math.random( where
PROBABILITY_TUNER is 10^(1/(1-(Probability of HTL=10))) ).
To add even more fuzz we could even make the probabilities a partly
random value. So every time the node is started it calculates the
probabilities to decrement the HTL per possible HTL-value. Of course we
had to limit that but again I would speak for letting them be everything
but making it more likely to be a suitable value.

If we do the above the attacker can't rely on anything being for sure,
he can just estimate the probability, and even that does vary everytime
the peer-node is restarted.
But for routing purposes it should be reliable enough. If we get an data
not found we just have to try again (If we decide that we still need it
- - that could be not the case if we're searching for the next 5
USK-editions but find none of them, then we could just try the first
again and if it's not found we assume we have found the last edition)
and it will be likely that the data is found if it's present.


regards
Neo at NHNG
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHjN3NPUBAMhFf+J4RAi9+AJoC/xo9SeMBSMJpdflevn02JyohzgCeNnPd
myP+vfSnIsPF1FjYOrY7XUs=
=Jea/
-END PGP SIGNATURE-

Re: [freenet-dev] {SPAM?} Re: [freenet-cvs] r16954 - trunk/freenet/src/freenet/node

[Michael Tänzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michael Rogers schrieb:
| David Sowder wrote:
|> Cloud 1 and Cloud 2 need to be using the same N2NM type ID number for a
|> particular service if any of [A, B, C] connects with [D, E, F] if such a
|> connection is to then allow all of [A, B, C, D, E, F] to potentially
|> talk to each other because otherwise would involve some sort of
|> "difference resolution protocol" to force either [A, B, C] or [D, E, F]
|> to change their service name to N2NM type mapping to either the same
|> N2NM type ID number of the other or a third N2NM type ID number used by
|> [A, B, C, D, E, F].
|
| If you view the ID as a port number rather than a message type then
| there's no problem. Node A runs the service on port 123, node B runs it
| on port 456, etc. When you want to connect to the Foo service on a
| particular node, contact its lookup service and get the port number for
| the string "Foo". The string, rather than the port number, identifies
| the service. Different instances can have different names (eg Foo/Alice
| and Foo/Bob).
|

If we use names we also have to ensure, that there are no duplicates
(e.g. two apps named foo). It would be no problem to give names on a
first come first serve basis (first app gets foo and the second foo2)
but if the fcfs is applied different on the node we want to exchange
messages with (e.g. because we only started the second app or both in
another order) foo requests foo on the other node but gets foo2.
This can be solved by providing something like ICANN.

So as we need some fixed Table in any case I would prefer David's method
to keep it simple.

[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHjUxbPUBAMhFf+J4RAsN9AJ4qdTpsdrTEn8na9KnJNHDbYOwtTgCcCEox
6E3/XIMWk0v57toiLjyPVM8=
=etqC
-END PGP SIGNATURE-
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Proposal for Seednode harvesting

[Michael Tänzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Seedserver - our script/app/whever that runs on our servers
(freenetproject.org) and takes care of the harvesting
Seednode - well the seednode
Seedclient - a new Freenet-Node which wants to bootstrap into Freenet
Seedservice -  a service which is run on the seednode to be addressed by
the Seedserver

Stage1
We deliver the public key of our Seedserver with Freenet (e.g. in the
installer or jar).
Once a node chooses to become a Seednode (Alice) it sends it's own
public key and port on which it runs the Seedservice encrypted with the
public key of the Server to our Seedserver. The Seedserver sends a
random number encrypted with the public key of Alice who has to return it.

Now the Server and the Node know each others public key and can't be
MITMed, under the assumption that the installer was correct. The
following traffic can be encrypted.

Stage2
The Seedserver asks some already established Seednode (Bob) to insert a
file which holds a random number encrypted with the public key of Alice.
Bob reports the key under which this has been inserted to Alice who
fetches it and sends the random number to the Server.
If Alice can't fetch the key, we ask another two Seednodes for inserting
it, if it still fails Alice is considered not to be connected (obviously
we have to have a long timeout here).

Now the Server knows Alice if is connected and can add her to his
Seednodes-list/DB

A Seednode has to follow this routine every 24 hours and whenever
something changes (different IP, disable Seedserver, etc. (obviously if
a seednode goes offline it doesn't have to prove it's connected to
freenet)).
The Server only accepts changes from Seednodes wich prove they can read
a random number encrypted with the public key of the Seednode entry they
want to alter.
The Server removes (or marks them disabled) Seednode entries that
weren't updated 26 hours and of Seednodes that didn't react on
insertrequests more than 3 times in a row (maybe disable them and try
again 30 min. later)

Possible Attacks:
- - manipulated installer - Well this is a general problem, not only to
seednode harvesting. We have to come up with a suitable solution for
this (SSL with trusted certificate (expensive), signed installer (how
can our users know whether to trust the public key?)

- - DoS the Seedserver - well then you could probably also DoS our
webserver and prevent our users from downloading the installer and
seednodes.fref

- - An attacker could add his node as a Seednode - well that is an obvious
problem for all of the automatic methods and also partly applies to
Seednodes which are added manually and Opennet in general - if an
attacker succesfully added a Seednode, he could have a whole farm of
manipulated nodes to which a new node is connected to and the new node
can't tell. This is especially a problem if the ghost-net has some kind
of proxy which relays requests in his own name so the node can't get
other opennet-connections and doesn't know it's not on the real freenet
and if it gets or even worse inserts some content which in the most
countries is illegal, the attacker can tell because he could spider the
freenet and do a blacklist.

Looking forward to your comments
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHjRwEPUBAMhFf+J4RAvjxAJ91iM5ACrr5GzBOdNfEb3+So9uFJQCfUkYf
PVRa4Brixfd8BiaNzhC7+OY=
=/6/7
-END PGP SIGNATURE-
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] New full-probabilistic HTL was Tunnels vs premix routing was Re: Vulnerability in inserting the manifest before finishing

[Michael Tänzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthew Toseland schrieb:
| On Saturday 05 January 2008 05:15, Michael Rogers wrote:
|> Matthew Toseland wrote:
|>> The 50% chance of decrementing
|>> at 10 means that 3 resets equals 6 nodes with HTL 10...
|> It's more complicated than that... if the HTL is 10 and the closest
|> location isn't the previous hop's location, then the attacker knows the
|> previous hop doesn't decrement at 10.
|
| It's a function of the input node, not the output node. Although that's
| problematic on rerouting, so we may change it to be a function of the
input
| node for the first node tried, and then a function of the output node...
| Hmmm. Why did we want to choose it once per node again? I'm sure there
was a
| good reason, but I don't remember it...
|
|> Likewise if the HTL is 9 and the
|> closest location isn't the previous hop's location, the previous hop
|> decrements at 10. Either way, the attacker can use that knowledge for
|> the rest of the session.
|
| Okay, so for a single request, if HTL is 10, and closestLocation is
equal to
| the node's location, the node could be the originator or it could have
reset
| it. If HTL is 10, and closestLocation is not equal to the node's
location,
| the node cannot be the originator and cannot have reset the HTL.
|
| So without keeping any state, we just look for requests which have
| closestLocation equal to the previous node's location, and we have a 1
in (#
| resets per request + 1) chance that it's the originator (1 in 4 on the
| previous assumption). Ouch! I'm not sure how the additional state we
could
| keep from the above would help the attacker.
|
| For a non-resetting HTL, the odds are even worse, unless we have a long
| probabilistic htl=max stage. So plainly a weighted coin would help
| significantly. The problem is that a weighted coin would increase the
| variance in path length *significantly*, cause more no-fault timeouts,
cause
| more no-fault failures (too short a path), make request coalescing
extremely
| difficult, and likewise with ULPRs. Is there an alternative?
|
| [snip]

How about a combination of HTL and weighted coin: We don't only
decrement probabilisticly at 10 and 1 but on all the way down from 10 to
0 and flip the coin each time so no (100% sure) assumption can be made
what we will do next time. In Order to travel not too far we weigh the
coin (let's say at 80% for a decrement). If our location is closer than
the closestLocation we don't set closestLocation to our actual location
but to a location a little bit _closer_ (if we set it to a location more
far away the next node knows we reset closestLocation), this is also
done probabilistic, and set the HTL to a value between 8 and 10 (more
likely to 10 than to 8 - maybe we could even set it to a value between 1
and 10 but make 1 extremely unlikely e.g.
(int)(11-10*Math.pow(PROBABILITY_TUNER,(-Math.random( where
PROBABILITY_TUNER is 10^(1/(1-(Probability of HTL=10))) ).
To add even more fuzz we could even make the probabilities a partly
random value. So every time the node is started it calculates the
probabilities to decrement the HTL per possible HTL-value. Of course we
had to limit that but again I would speak for letting them be everything
but making it more likely to be a suitable value.

If we do the above the attacker can't rely on anything being for sure,
he can just estimate the probability, and even that does vary everytime
the peer-node is restarted.
But for routing purposes it should be reliable enough. If we get an data
not found we just have to try again (If we decide that we still need it
- - that could be not the case if we're searching for the next 5
USK-editions but find none of them, then we could just try the first
again and if it's not found we assume we have found the last edition)
and it will be likely that the data is found if it's present.


regards
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHjN3NPUBAMhFf+J4RAi9+AJoC/xo9SeMBSMJpdflevn02JyohzgCeNnPd
myP+vfSnIsPF1FjYOrY7XUs=
=Jea/
-END PGP SIGNATURE-
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] German Translation Update (freenet.l10n.de.v1090)

[Michael Tänzer]

Here's an Update for the German language file. The translations from
Ratchet and Anonymous were (I'm sorry to have to say so) crappy.

Regards
Michael
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: freenet.l10n.de.override.properties
URL: 

[freenet-dev] German Translation Update (freenet.l10n.de.v1090)

[Michael Tänzer]

Here's an Update for the German language file. The translations from
Ratchet and Anonymous were (I'm sorry to have to say so) crappy.

Regards
Michael
Announcer.announceAlertIntro=Der Knoten versucht gerade, sich mit Seednodes 
(Saat-Knoten) zu verbinden und sich selbst im Opennet (Fremden-Netzwerk) 
bekannt zu machen. Dies kann ein paar Minuten dauern.
Announcer.announceAlertNoSeednodes=Es wurde keine seednodes.fref-Datei 
gefunden, deshalb wird der Knoten nicht in der Lage sein sich aus eigener Kraft 
automatisch mit dem Opennet zu verbinden. Bitte fügen Sie manuell ein paar 
Knoten hinzu.
Announcer.announceAlertTitle=Knoten macht sich bekannt
Announcer.announceDetails=Wir haben kürzlich ${recentSentAnnouncements} 
Bekanntgaben gesendet, von denen ${runningAnnouncements} noch laufen, und haben 
${addedNodes} Knoten hinzugefügt (${refusedNodes} Knoten haben uns abgelehnt). 
Wir sind gerade mit ${connectedSeednodes} Seednodes (Saat-Knoten) verbunden und 
versuchen uns mit weiteren ${disconnectedSeednodes} zu verbinden.
Announcer.announceLoading=Der Knoten lädt gerade die 
Seednodes(Saat-Knoten)-Datei herunter, sodass er versuchen kann sich mit dem 
Rest des Netzwerks bekannt zu machen. Die Bekanntgabe kann ein paar Minuten 
dauern.
BookmarkEditorToadlet.addDefaultBookmarks=Die Standard-Lesezeichen erneut 
hinzufügen
ConnectionsToadlet.nodeStatus.ROUTING DISABLED=VERKEHR NICHT WEITERLEITEN
ConnectivityToadlet.addressTitle=Adresse
ConnectivityToadlet.byIPTitle=Pakete für ${ip} nach IP-Adresse - ${status} 
(minimale Tunnel-Lebenszeit ${tunnelLength})
ConnectivityToadlet.byPortTitle=Pakete für ${port} nach Port - ${status} 
(minimale Tunnel-Lebenszeit ${tunnelLength})
ConnectivityToadlet.firstReceiveLeadTime=Vom Verbinden bis zum ersten Empfang
ConnectivityToadlet.firstSendLeadTime=Vom Start bis zum ersten Senden
ConnectivityToadlet.remote=REMOTE
ConnectivityToadlet.title=Erreichbarkeit aus dem Internet für ${nodeName}
DarknetConnectionsToadlet.burstingShort=Bursting
DarknetConnectionsToadlet.disconnecting=Trenne Verbindung (wir entfernen den 
Knoten gerade, wir müssen ihm mitteilen, dass er weggehen soll und dies kann 
eine kurze Zeit dauern)
DarknetConnectionsToadlet.disconnectingShort=Trenne Verbindung
DarknetConnectionsToadlet.listening=Nicht verbunden aber lauschend: Dieser 
Knoten wird nicht oft versuchen sich mit diesen Partnern zu verbinden, weil der 
Benutzer ihn auf BurstOnly gesetzt hat.
DarknetConnectionsToadlet.routingDisabled=Verkehr nicht weiterleiten (wir sind 
gerade mit dem Knoten verbunden aber wir oder er weigern sich (Daten-)Verkehr 
weiterzuleiten)
DarknetConnectionsToadlet.routingDisabledShort=Verkehr nicht weiterleiten
FcpServer.assumeDownloadDDAIsAllowedLong=Annehmen, dass das Herunterladen von 
DDA erlaubt ist? Wenn nicht, müssen sie eine TestDDARequest (TestDDAAnfrage) 
auslösen, bevor Sie einen DDA-Zugriff ausführen.
FcpServer.assumeUploadDDAIsAllowedLong=Annehmen, dass das Hochladen von DDA 
erlaubt ist? Wenn nicht, müssen sie eine TestDDARequest (TestDDAAnfrage) 
auslösen, bevor Sie einen DDA-Zugriff ausführen.
FirstTimeWizardToadlet.clickContinue=Hier klicken um fortzufahren.
FirstTimeWizardToadlet.congratzLong=Herzlichen Glückwunsch, die 
Basis-Konfiguration Ihres Freenet-Knotens ist nun abgeschlossen. Sie können 
alle Parameter, die Sie soeben eingestellt haben, ändern indem Sie auf die 
"Konfiguration"s-Seite gehen. Diese ist jederzeit vom Menü auf der linken 
Seite der Oberfläche zu erreichen. Wir wünschen Ihnen ein angenehmes 
Freenet-Erlebnis.
FirstTimeWizardToadlet.continueEnd=Hier klicken, um anzufangen, Freenet zu 
benutzen!
FirstTimeWizardToadlet.welcomeInfoboxContent1=Willkommen beim 
Freenet-Einrichtungs-Assistent. Dieses Werkzeug erlaubt es Ihnen, Ihren Knoten 
schnell und einfach für den ersten Betrieb einzurichten.
LogConfigHandler.enabledLong=Auf nein setzen um die Protokollierung komplett 
abzuschalten
N2NTMToadlet.peerNotFoundWithHash=Der Partner mit dem Hash-Code 
\u201C${hash}\u201D konnte nicht gefunden werden.
Node.assumeNATed=Annehmen, dass der Port nicht weitergeleitet ist.
Node.assumeNATedLong=Soll der Knoten annehmen, dass der Port NATed (hinter 
einem NAT-Gerät (z.B. Router)) und nicht weitergeleitet ist und Handshakes 
(Verbindungsanfragen) immer aggressiv (alle 10-30 Sekunden) senden, ohne 
Rücksicht auf jegliche Hinweise auf das Gegenteil?
Node.maxOpennetPeersLong=Maximale Anzahl an Opennet-Partnern (muss zwischen 0 
und 20 (inklusive) liegen, etwaige Darknet-Verbindungen werden vom Gesamt-Limit 
abgezogen)
Node.maxOpennetPeersMustBeTwentyOrLess=Muss zwanzig oder weniger sein
Node.notUsingSunVM=Sie versuchen den Knoten in einer nicht-Sun JVM: ${vendor} 
${version} zu betreiben. Dies wird nicht empfohlen: der Knoten könnte nicht 
gut laufen. Bitte besorgen Sie sich, wenn möglich, Sun java von 
http://www.java.com/getjava/.
Node.notUsingSunVMTitle=Es wird keine Sun JVM benutzt
Node.notUsingWrapper=Sie benutzen den Knoten ohne 

[freenet-dev] German Translation freenet.l10n.de.v1075

[Michael Tänzer]

Hi folks,

Here is an update of the German Translation.

Greets
Michael
-- next part --
A non-text attachment was scrubbed...
Name: freenet.l10n.de.override.properties
Type: application/octet-stream
Size: 4053 bytes
Desc: not available
URL: 

[freenet-dev] German Translation freenet.l10n.de.v1075

[Michael Tänzer]

Hi folks,

Here is an update of the German Translation.

Greets
Michael


freenet.l10n.de.override.properties
Description: Binary data
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Tiny Update of German the Language and broken Link (freenet.l10n.de.v1070)

[Michael Tänzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi

there is a tiny language override attached and I wanted to report, that
the link to Freemail (on http://freenetproject.org/freemail.html) is broken.

Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHKnOdPUBAMhFf+J4RAtCgAJoDiG8OM/QV+WQHDcX21pxGxYeVZQCcCsAe
kZd3NxsV40yM6i0TPt4N6Tw=
=D0cz
-END PGP SIGNATURE-
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: freenet.l10n.de.override.properties
URL: 

[freenet-dev] Tiny Update of German the Language and broken Link (freenet.l10n.de.v1070)

[Michael Tänzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi

there is a tiny language override attached and I wanted to report, that
the link to Freemail (on http://freenetproject.org/freemail.html) is broken.

Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHKnOdPUBAMhFf+J4RAtCgAJoDiG8OM/QV+WQHDcX21pxGxYeVZQCcCsAe
kZd3NxsV40yM6i0TPt4N6Tw=
=D0cz
-END PGP SIGNATURE-
Node.inBWLimit=Limit für hereinkommende Bandbreite (Bytes pro Sekunde)
End
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] [l10n] new feature for translators

[Michael Tänzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Florent Daigni?re schrieb:
> Hi,
> 
>   Just a small line to let you know that from now on, emu will be
>   generating diffs of the english strings. That might be handy to
>   see what has been done in between versions...
> 
>   They will be reachable at:
>   http://emu.freenetproject.org/~svn-build/l10n/
> 
> NextGen$
> 

Exactly what I needed, so I don't need to check out svn and do diffs myself.
Thanks for that one.

Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHJKh7PUBAMhFf+J4RAsdOAJ4kQtqDC+VJ0Bx/Iq2R4aXDWp7cFwCeNfTn
OCwW5gbrCuPdLMeUgdfPXWQ=
=tj+j
-END PGP SIGNATURE-

Re: [freenet-dev] [l10n] new feature for translators

[Michael Tänzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Florent Daignière schrieb:
> Hi,
> 
>   Just a small line to let you know that from now on, emu will be
>   generating diffs of the english strings. That might be handy to
>   see what has been done in between versions...
> 
>   They will be reachable at:
>   http://emu.freenetproject.org/~svn-build/l10n/
> 
> NextGen$
> 

Exactly what I needed, so I don't need to check out svn and do diffs myself.
Thanks for that one.

Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHJKh7PUBAMhFf+J4RAsdOAJ4kQtqDC+VJ0Bx/Iq2R4aXDWp7cFwCeNfTn
OCwW5gbrCuPdLMeUgdfPXWQ=
=tj+j
-END PGP SIGNATURE-
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] [freenet-cvs] r15616 - in trunk/freenet/src/freenet: clients/http l10n

[Michael Tänzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthew Toseland wrote:
> More comments below. What Ian told me was we should localise stuff that a 
> normal user will see i.e. only stuff that you don't have to turn on advanced 
> mode for. That was specifically regarding me doing the work though, it *may* 
> make sense to localise other stuff if we have the manpower.
> 

Most of the advanced options include technical terms, which are often
(at least in German) not translatable or not well known by their German
translation, so it would result in a mix of two languages (more than it
already is) and this would be a problem to fit in the German grammar
(keeping the original meaning and in the same time producing a valid
German sentence would be hard, it already is sometimes). So I wouldn't
say I'm completely against it but it would be very difficult and could
lead to misconceptions which, especially in the advanced section, could
be critical.

What we should do is make the table entries in the status column in the
friends list (we could use the DarknetConnectionsToadlet.busyShort etc),
the string "Statistic gathering" in the statistics section and maybe the
dropdown values true and false translatable.

Michael

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHI8KVPUBAMhFf+J4RAuiUAJ9rKDUKHfxrOtx4gr9FQgIRrDKB1ACgskUF
v9hehtQ6h7QZZkNb+pJW6K0=
=lPd6
-END PGP SIGNATURE-

Re: [freenet-dev] [freenet-cvs] r15616 - in trunk/freenet/src/freenet: clients/http l10n

[Michael Tänzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthew Toseland wrote:
> More comments below. What Ian told me was we should localise stuff that a 
> normal user will see i.e. only stuff that you don't have to turn on advanced 
> mode for. That was specifically regarding me doing the work though, it *may* 
> make sense to localise other stuff if we have the manpower.
> 

Most of the advanced options include technical terms, which are often
(at least in German) not translatable or not well known by their German
translation, so it would result in a mix of two languages (more than it
already is) and this would be a problem to fit in the German grammar
(keeping the original meaning and in the same time producing a valid
German sentence would be hard, it already is sometimes). So I wouldn't
say I'm completely against it but it would be very difficult and could
lead to misconceptions which, especially in the advanced section, could
be critical.

What we should do is make the table entries in the status column in the
friends list (we could use the DarknetConnectionsToadlet.busyShort etc),
the string "Statistic gathering" in the statistics section and maybe the
dropdown values true and false translatable.

Michael

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHI8KVPUBAMhFf+J4RAuiUAJ9rKDUKHfxrOtx4gr9FQgIRrDKB1ACgskUF
v9hehtQ6h7QZZkNb+pJW6K0=
=lPd6
-END PGP SIGNATURE-
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] German Translation (freenet.l10n.de.v1065)

[Michael Tänzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi everyone,

here's the new override for the German language.

regards
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHBoCBPUBAMhFf+J4RAlw/AJ9eUv3Q7JwR4//VctE9qAqthiu3CgCfRIRa
Fa9QnBNCoDUj8kSJ0lQQLAI=
=RzAs
-END PGP SIGNATURE-
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: freenet.l10n.de.override.properties
URL: 

[freenet-dev] German Translation (freenet.l10n.de.v1065)

[Michael Tänzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi everyone,

here's the new override for the German language.

regards
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHBoCBPUBAMhFf+J4RAlw/AJ9eUv3Q7JwR4//VctE9qAqthiu3CgCfRIRa
Fa9QnBNCoDUj8kSJ0lQQLAI=
=RzAs
-END PGP SIGNATURE-
DarknetConnectionsToadlet.disconnecting=Trennen (wir entfernen den Knoten 
gerade, wir müssen ihm mitteilen, dass er weggehen soll und dies kann eine 
kurze Zeit dauern)
DarknetConnectionsToadlet.disconnectingShort=Trennen
DarknetConnectionsToadlet.pasteReference=Die Referenz hier einfügen (der 
Knoten wird Chat-Programm-Zeilen-Zusätze (z.B. [14:56] ) normalerweise 
automatisch entfernen):
FirstTimeWizardToadlet.chooseNodeNameLong=Bitte geben Sie einen Knoten-Namen in 
das unten stehende Feld ein (wir empfehlen einen Spitznamen, möglicherweise 
mit einer E-Mail-Adresse). Dies dient Ihren Freunden (vertrauenswürdigen 
Partnern, welche Sie manuell hinzugefügt haben) dazu, Ihren Knoten einfach von 
ihren anderen Knoten zu unterscheiden. Dies ist für Fremde (nicht 
vertrauenswürdige, automatisch hinzugefügte Partner) nicht sichtbar. Beachten 
Sie, dass jeder Freund oder Fremde Sie einfach an Ihrer IP-Adresse erkennen 
könnte, da Sie mit Ihnen  verbunden sind, aber sie können nicht so einfach 
herausfinden, was Sie anfordern.
IPDetectorPluginManager.suggestForwardTwoPorts=Sie möchten die Ports 
(UDP-Port-Nummern ${port1} und ${port2}) vielleicht manuell weiterleiten. 
(Siehe http://wiki.freenetproject.org/FirewallAndRouterIssues (Englisch)).
IPUndetectedUserAlert.detectingWithConfigLink=Freenet versucht gerade Ihre 
externe IP-Adresse zu ermitteln. Wenn dies mehr als ein paar Minuten dauert, 
dann läuft etwas schief und Sie können die "Hinweis auf temporäre 
IP-Adresse"-${link}Einstellung${/link} benutzen.
IPUndetectedUserAlert.suggestForwardPort=Es wäre auch eine gute Idee, den Port 
${port} (UDP) auf ihrem Router weiterzuleiten, um es einfach zu machen sich mit 
ihrem Knoten zu verbinden.
IPUndetectedUserAlert.suggestForwardTwoPorts=Es wäre auch eine gute Idee, die 
Ports ${port1} und ${port2} (UDP) auf ihrem Router weiterzuleiten, um es 
einfach zu machen sich mit ihrem Knoten zu verbinden.
IPUndetectedUserAlert.unknownAddress=Freenet war nicht imstande Ihre IP-Adresse 
zu ermitteln (oder die IP-Adresse ihrer Firewall oder Ihres NAT-Geräts 
(Router)). Sie können immer noch Referenzen mit anderen Menschen austauschen, 
dies wird aber nur funktionieren, wenn der andere Benutzer sich nicht hinter 
einem NAT-Gerät oder einer Firewall befindet. Sobald Sie sich auf diesem Weg 
mit einem anderen Benutzer verbunden haben, wird Freenet in der Lage sein ihre 
externe IP-Adresse zu ermitteln. Sie können auch ihre momentane IP-Adresse 
feststellen und diese Ihrem Knoten mit der "Hinweis auf temporäre 
IP-Adresse"-${link}Einstellung${/link} mitteilen.
Node.passOpennetPeersThroughDarknetLong=Wenn aktiviert, werden 
Opennet-Knotenreferenzen (NIEMALS unsere eigene Darknet-Knotenreferenz) über 
unsere Darknet-Partner weitergeleitet. Sodass ein Knoten (dieser Knoten oder 
seine Partner) Opennet-Partner von seinen Darknet-Partnern bekommen kann. Dies 
ist nützlich, da es uns erlaubt einen Bootstrap (Erlangung neuer Quellen ohne 
vorher welche zu haben) nach neuen Opennet-Partnern durchzuführen nachdem wir 
unsere Partner, zum Beispiel durch Ausfallzeiten, verloren haben. Jedoch kann 
es eine Traffic(Verkehrs)-Analyse etwas erleichtern, deshalb sollten Sie es 
ausschalten wenn Sie paranoid sind.
OpennetConnectionsToadlet.successTime=Letzter Zeitpunkt zu dem eine 
erfolgreicher CHK-Abruf stattfand
OpennetConnectionsToadlet.successTimeTitle=Letzter Erfolg
PproxyToadlet.pluginStopping=Plugin wird gestoppt
WelcomeToadlet.shutdownDone=Der Freenet-Knoten wird heruntergefahren.
End
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] How to fix Frost

[Michael Tänzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

As I'm just a translator, I'm not really familiar with how exactly
Freenet works, but I had some ideas on this topic so here they are:

I think a kind of public rating system could help, which stores the
username of the poster, and how many people classified it as
SPAM/annoying(users that are not spammers but behave (sometimes) in a
annoying way)/good

As something like this rating system does not need anonymity itself,
just the users of it, one could think of a system that is faster than
normal freesites.

The rating system could have a fixed address which is known by any node
but the connection to it is routed through other nodes (a little bit
like tor), this way there is just one place to look for the rating file,
but even if the rating system is compromised, the attacker can't tell
where the request originated from. On the rating server there could be a
database which holds the ratings and creates a file which can be read by
Frost.

Pros:
- -no complicated routing needed, because there's one server who hosts the
system
- -no site inserts needed therefore less load on the network
- -the current version of the file is always available (given the server
works well)
- -just the first (about) 10 people need to read the (and mark it as) SPAM
and newbies will be read (unless they're marked as SPAM too)

Cons:
- -single point of failure (could be diminished if every node holds a copy
of the file in the last version it downloaded it (which it needs to
store anyway) so if the server is down the node sends a request to it's
peers and gets the last version available), if the server is down "on a
long-time basis" we are where we are now, but we haven't lost anything
- -could be abused by spammers (marking useful posts as SPAM so the system
doesn't really work and is turned of by the users) maybe the web of
trust idea could work in here, so if people who are trusted by many
others (or maybe many trustworthy others (starting point: the
developers)) can change the rating more significantly than others. Maybe
even based on the own system: only people who are rated themselves with
good a couple of times may mark something as anything (or are stored in
a different field so the rating differentiates between trusted and
untrusted counts)


Maybe the special routing system could be used for similar services too
(once implemented) although I can't think of examples right now.

Looking forward to hear your thoughts about it
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGvNlePUBAMhFf+J4RApryAKCt+MtcAvz7P5xh1nFHZlJ5/z8bjQCaA8aV
HYcK3Up97QzQKjKf23Lkvvc=
=j0dy
-END PGP SIGNATURE-
-- next part --
A non-text attachment was scrubbed...
Name: 0x115FF89E.asc
Type: application/pgp-keys
Size: 2437 bytes
Desc: not available
URL: 

Re: [freenet-dev] How to fix Frost

[Michael Tänzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

As I'm just a translator, I'm not really familiar with how exactly
Freenet works, but I had some ideas on this topic so here they are:

I think a kind of public rating system could help, which stores the
username of the poster, and how many people classified it as
SPAM/annoying(users that are not spammers but behave (sometimes) in a
annoying way)/good

As something like this rating system does not need anonymity itself,
just the users of it, one could think of a system that is faster than
normal freesites.

The rating system could have a fixed address which is known by any node
but the connection to it is routed through other nodes (a little bit
like tor), this way there is just one place to look for the rating file,
but even if the rating system is compromised, the attacker can't tell
where the request originated from. On the rating server there could be a
database which holds the ratings and creates a file which can be read by
Frost.

Pros:
- -no complicated routing needed, because there's one server who hosts the
system
- -no site inserts needed therefore less load on the network
- -the current version of the file is always available (given the server
works well)
- -just the first (about) 10 people need to read the (and mark it as) SPAM
and newbies will be read (unless they're marked as SPAM too)

Cons:
- -single point of failure (could be diminished if every node holds a copy
of the file in the last version it downloaded it (which it needs to
store anyway) so if the server is down the node sends a request to it's
peers and gets the last version available), if the server is down "on a
long-time basis" we are where we are now, but we haven't lost anything
- -could be abused by spammers (marking useful posts as SPAM so the system
doesn't really work and is turned of by the users) maybe the web of
trust idea could work in here, so if people who are trusted by many
others (or maybe many trustworthy others (starting point: the
developers)) can change the rating more significantly than others. Maybe
even based on the own system: only people who are rated themselves with
good a couple of times may mark something as anything (or are stored in
a different field so the rating differentiates between trusted and
untrusted counts)


Maybe the special routing system could be used for similar services too
(once implemented) although I can't think of examples right now.

Looking forward to hear your thoughts about it
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGvNlePUBAMhFf+J4RApryAKCt+MtcAvz7P5xh1nFHZlJ5/z8bjQCaA8aV
HYcK3Up97QzQKjKf23Lkvvc=
=j0dy
-END PGP SIGNATURE-


0x115FF89E.asc
Description: application/pgp-keys
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] German Translation (freenet.l10n.de.v1052)

[Michael Tänzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Here's the German translation update.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD4DBQFGvEbkPUBAMhFf+J4RAjpBAJi19pc33p6luhTvqWyb75gCnhhQAKCp9Y+z
i+ZQTAEr/9zZQG9U7sob/Q==
=gHOT
-END PGP SIGNATURE-
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: freenet.l10n.de.override.properties
URL: 

[freenet-dev] German Translation (freenet.l10n.de.v1052)

[Michael Tänzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Here's the German translation update.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD4DBQFGvEbkPUBAMhFf+J4RAjpBAJi19pc33p6luhTvqWyb75gCnhhQAKCp9Y+z
i+ZQTAEr/9zZQG9U7sob/Q==
=gHOT
-END PGP SIGNATURE-
Node.alwaysAllowLocalAddresses=Das Verbinden mit Knoten über lokale Adressen 
immer erlauben?
Node.alwaysAllowLocalAddressesLong=Wenn aktiviert, wird der Knoten versuchen 
sich sowohl über die lokalen Adressen (localhost, LAN) als auch über die 
öffentlichen IPs mit den Knoten zu verbinden. Wenn dies nicht aktiviert ist, 
können Sie es immer noch für spezifische Darknet-Partner einschalten (aber 
nicht für Opennet-Partner). Aktivieren Sie dies, wenn Sie sich mit anderen 
Knoten im selben LAN (Netzwerk) oder Computer verbinden wollen und es Ihnen 
nichts ausmacht, dass fehlerhafte Referenzen Ihren Knoten dazu veranlassen 
können, UDP-Pakete zu Geräten in Ihrem LAN zu senden.
Node.passOpennetPeersThroughDarknet=Opennet-Knotenreferenzen über 
Darknet-Partner weiterleiten?
Node.passOpennetPeersThroughDarknetLong=Wenn aktiviert, werden 
Opennet-Knotenreferenzen (NIEMALS unsere eigene Darknet-Knotenreferenz) über 
unsere Darknet-Partner weitergeleitet. Sodass ein Knoten (dieser Knoten oder 
seine Partner) Opennet-Partner von seinen Darknet-Partnern bekommen kann. Dies 
ist nützlich, da es uns erlaubt einen Bootstrap (Erlangung neuer Quellen ohne 
vorher welche zu haben) mit neuen Opennet-Partnern durchzuführen nachdem wir 
unsere Partner, zum Beispiel durch Ausfallzeiten, verloren haben. Jedoch kann 
es eine Traffic(Verkehrs)-Analyse etwas erleichtern, deshalb sollten Sie es 
ausschalten wenn Sie paranoid sind.
End
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] German Translation (freenet.l10n.de.v1049)

[Michael Tänzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Here's the current translation. The file looks a little too big to me, I
changed just a few things (should be about 11 strings) but the
override-file gives 34 lines and it looks to me as if the things I
changed in last version are also included. I'm not sure whether it's a
bug or just dumbness of my own, do I have to remove translation
overrides I made in a previous version manually? If so it would be
probably a good Idea to have a button "Remove all translation overrides"
(combined with ten questions whether you're sure or completely insane)
to make this process much easier. But I completely understand if you
have more important things to do.

Definitely a bug is this issue:
https://bugs.freenetproject.org/view.php?id=1576
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGqgDVPUBAMhFf+J4RAk+lAJ0Udl7nw2GV7Fa/shMBuNsRAsJSdQCfdDFd
CzlyW1W1ElZtADMJsjD6I6o=
=OOeS
-END PGP SIGNATURE-
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: freenet.l10n.de.override.properties
URL: 

[freenet-dev] German Translation (freenet.l10n.de.v1049)

[Michael Tänzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Here's the current translation. The file looks a little too big to me, I
changed just a few things (should be about 11 strings) but the
override-file gives 34 lines and it looks to me as if the things I
changed in last version are also included. I'm not sure whether it's a
bug or just dumbness of my own, do I have to remove translation
overrides I made in a previous version manually? If so it would be
probably a good Idea to have a button "Remove all translation overrides"
(combined with ten questions whether you're sure or completely insane)
to make this process much easier. But I completely understand if you
have more important things to do.

Definitely a bug is this issue:
https://bugs.freenetproject.org/view.php?id=1576
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGqgDVPUBAMhFf+J4RAk+lAJ0Udl7nw2GV7Fa/shMBuNsRAsJSdQCfdDFd
CzlyW1W1ElZtADMJsjD6I6o=
=OOeS
-END PGP SIGNATURE-
DarknetConnectionsToadlet.darknetFnpPort=Darknet-FNP: ${port}/UDP (wird benutzt 
um sich mit vertrauenswürdigen Partnern d.h. Freunden zu verbinden; leiten Sie 
diesen Port weiter wenn Sie können)
DarknetConnectionsToadlet.disabled=Nicht verbunden und deaktiviert: weil der 
Benutzer den Knoten angewiesen hat sich nicht mit diesen Partnern zu verbinden.
DarknetConnectionsToadlet.fullTitle=${counts} Freunde (vertrauenswürdige 
Partner) von ${name}
DarknetConnectionsToadlet.listening=Nicht verbunden aber hörend: Dieser Knoten 
wird nicht oft versuchen sich mit diesen Partnern zu verbinden, weil der 
Benutzer sie auf BurstOnly (nur bersten) gesetzt hat.
DarknetConnectionsToadlet.neverConnected=Niemals verbunden: Der Knoten hat sich 
noch nie mit diesen Partnern verbunden.
DarknetConnectionsToadlet.opennetFnpPort=Opennet-FNP: ${port}/UDP (wird benutzt 
um sich mit nicht vertrauenswürdigen Partnern d.h. Fremden zu verbinden; 
leiten Sie diesen Port weiter wenn Sie können)
FirstTimeWizardToadlet.connectToStrangers=Mit Fremden verbinden?
FirstTimeWizardToadlet.connectToStrangersLong=Wenn Sie Freenet sich mit Fremden 
verbinden lassen, wird Freenet für Sie weniger sicher sein, jeder kann 
herausfinden, dass Sie Freenet benutzen und jeder böse Mensch kann sich mit 
Ihrem Knoten verbinden. Wenn Sie dies nicht tun, werden Sie mindestens drei 
andere Freunde (Leute, die Sie schon kennen), die Freenet benutzen, manuell 
kontaktieren und sich mit Ihnen verbinden müssen.
FirstTimeWizardToadlet.continue=Fortfahren
FirstTimeWizardToadlet.enableOpennet=Automatisch mit Knoten von nicht 
vertrauenswürdigen Fremden verbinden?
FirstTimeWizardToadlet.step1Title=Freenet-Einrichtungs-Assistent! - Freunde und 
Fremde
FirstTimeWizardToadlet.step2Title=Freenet-Einrichtungs-Assistent! - Wählen Sie 
einen Knoten-Namen
FirstTimeWizardToadlet.step3Title=Freenet-Einrichtungs-Assistent! - 
Bandbreiten-Limits
FirstTimeWizardToadlet.step4Title=Freenet-Einrichtungs-Assistent! - Größe des 
Datenspeichers
FirstTimeWizardToadlet.step5Title=Freenet-Einrichtungs-Assistent! - 
Netzwerk-Konfiguration
FirstTimeWizardToadlet.step6Title=Freenet-Einrichtungs-Assistent! - Herzlichen 
Glückwunsch, Ihr Knoten ist nun konfiguriert
IPDetectorPluginManager.direct=Sie scheinen direkt mit dem Internet verbunden 
zu sein. Herzlichen Glückwunsch, Sie sollten in der Lage sein, sich mit jedem 
anderen Freenet-Knoten zu verbinden.
IPDetectorPluginManager.fullCone=Ihre Internet-Verbindung scheint sich hinter 
einem "full cone"-NAT (Router) zu befinden. Herzlichen Glückwunsch, Ihr Knoten 
sollte in der Lage sein, sich mit jedem anderen Knoten zu verbinden.
IPDetectorPluginManager.portRestricted=Ihre Internet-Verbindung scheint sich 
hinter einem "port-restricted cone"-NAT (Router) zu befinden. Sie werden in der 
Lage sein sich mit den meisten anderen Benutzern zu verbinden, aber nicht mit 
denen, die sich hinter einem symmetrischen NAT befinden.
IPDetectorPluginManager.restricted=Ihre Internet-Verbindung scheint sich hinter 
einem "restricted cone"-NAT (Router) zu befinden. Sie sollten in der Lage sein, 
sich mit den meisten anderen Benutzern zu verbinden.
IPDetectorPluginManager.symmetric=Ihre Internet-Verbindung scheint sich hinter 
einem symmetrischen NAT (Router) oder einer Firewall zu befinden. Sie werden 
wahrscheinlich nur in der Lage sein, sich mit Benutzern zu verbinden, die 
direkt oder über "restricted cone"-NATs mit dem Internet verbunden sind.
IPUndetectedUserAlert.unknownAddress=Freenet war nicht imstande Ihre IP-Adresse 
zu ermitteln (oder die IP-Adresse ihrer Firewall oder Ihres NAT-Geräts 
(Router)). Sie können immer noch Referenzen mit anderen Menschen austauschen, 
dies wird aber nur funktionieren, wenn der andere Benutzer sich nicht hinter 
einem NAT-Gerät oder einer Firewall befindet. Sobald Sie sich auf diesem Weg 
mit einem anderen Benutzer verbunden haben, wird Freenet in der Lage sein ihre 
externe IP-Adresse zu

[freenet-dev] German Translation (freenet.l10n.de.v1048)

[Michael Tänzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Here's the updated German translation (for node version 1048).
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGqJVkPUBAMhFf+J4RAjVSAJ0ey8SuXXdD7DnBA+qvSpXdy75HrQCgnVqv
a2Lc7Wctq/6aobaGulAoxyI=
=P7r+
-END PGP SIGNATURE-
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: freenet.l10n.de.override.properties
URL: 

[freenet-dev] German Translation (freenet.l10n.de.v1048)

[Michael Tänzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Here's the updated German translation (for node version 1048).
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGqJVkPUBAMhFf+J4RAjVSAJ0ey8SuXXdD7DnBA+qvSpXdy75HrQCgnVqv
a2Lc7Wctq/6aobaGulAoxyI=
=P7r+
-END PGP SIGNATURE-
DarknetConnectionsToadlet.disabled=Nicht verbunden und deaktiviert: weil der 
Benutzer den Knoten angewiesen hat sich nicht mit diesen Partnern zu verbinden.
DarknetConnectionsToadlet.listening=Nicht verbunden aber hörend: Dieser Knoten 
wird nicht oft versuchen sich mit diesen Partnern zu verbinden, weil der 
Benutzer sie auf BurstOnly (nur bersten) gesetzt hat.
DarknetConnectionsToadlet.neverConnected=Niemals verbunden: Der Knoten hat sich 
noch nie mit diesen Partnern verbunden.
FirstTimeWizardToadlet.connectToStrangers=Mit Fremden verbinden?
FirstTimeWizardToadlet.connectToStrangersLong=Wenn Sie Freenet sich mit Fremden 
verbinden lassen, wird Freenet für Sie weniger sicher sein, jeder kann 
herausfinden, dass Sie Freenet benutzen und jeder böse Mensch kann sich mit 
Ihrem Knoten verbinden. Wenn Sie dies nicht tun, werden Sie mindestens drei 
andere Freunde (Leute, die Sie schon kennen), die Freenet benutzen, manuell 
kontaktieren und sich mit Ihnen verbinden müssen.
FirstTimeWizardToadlet.continue=Fortfahren
FirstTimeWizardToadlet.enableOpennet=Automatisch mit Knoten von nicht 
vertrauenswürdigen Fremden verbinden?
FirstTimeWizardToadlet.step6Title=Freenet-Einrichtungs-Assistent! - Herzlichen 
Glückwunsch, Ihr Knoten ist nun konfiguriert
IPDetectorPluginManager.direct=Sie scheinen direkt mit dem Internet verbunden 
zu sein. Herzlichen Glückwunsch, Sie sollten in der Lage sein, sich mit jedem 
anderen Freenet-Knoten zu verbinden.
IPDetectorPluginManager.fullCone=Ihre Internet-Verbindung scheint sich hinter 
einem "full cone"-NAT (Router) zu befinden. Herzlichen Glückwunsch, Ihr Knoten 
sollte in der Lage sein, sich mit jedem anderen Knoten zu verbinden.
IPDetectorPluginManager.portRestricted=Ihre Internet-Verbindung scheint sich 
hinter einem "port-restricted cone"-NAT (Router) zu befinden. Sie werden in der 
Lage sein sich mit den meisten anderen Benutzern zu verbinden, aber nicht mit 
denen, die sich hinter einem symmetrischen NAT befinden.
IPDetectorPluginManager.restricted=Ihre Internet-Verbindung scheint sich hinter 
einem "restricted cone"-NAT (Router) zu befinden. Sie sollten in der Lage sein, 
sich mit den meisten anderen Benutzern zu verbinden.
IPDetectorPluginManager.symmetric=Ihre Internet-Verbindung scheint sich hinter 
einem symmetrischen NAT (Router) oder einer Firewall zu befinden. Sie werden 
wahrscheinlich nur in der Lage sein, sich mit Benutzern zu verbinden, die 
direkt oder über "restricted cone"-NATs mit dem Internet verbunden sind.
IPUndetectedUserAlert.unknownAddress=Freenet war nicht imstande Ihre IP-Adresse 
zu ermitteln (oder die IP-Adresse ihrer Firewall oder Ihres NAT-Geräts 
(Router)). Sie können immer noch Referenzen mit anderen Menschen austauschen, 
dies wird aber nur funktionieren, wenn der andere Benutzer sich nicht hinter 
einem NAT-Gerät oder einer Firewall befindet. Sobald Sie sich auf diesem Weg 
mit einem anderen Benutzer verbunden haben, wird Freenet in der Lage sein ihre 
externe IP-Adresse zu ermitteln. Sie können auch ihre momentane IP-Adresse 
feststellen und diese Ihrem Knoten mit der "Hinweis auf temporäre 
IP-Adresse"-${link}Einstellung${/link} mitteilen. Es wäre auch eine gute Idee, 
den UDP-Port ${port} in Ihrem Router weiterzuleiten, um es Anderen zu 
erleichtern zu Ihrem Knoten Kontakt aufzunehmen.
IPUndetectedUserAlert.unknownAddressWithConfigLink=Freenet war nicht imstande 
Ihre IP-Adresse zu ermitteln (oder die IP-Adresse ihrer Firewall oder Ihres 
NAT-Geräts (Router)). Sie können immer noch Referenzen mit anderen Menschen 
austauschen, dies wird aber nur funktionieren, wenn der andere Benutzer sich 
nicht hinter einem NAT-Gerät oder einer Firewall befindet. Sobald Sie sich auf 
diesem Weg mit einem anderen Benutzer verbunden haben, wird Freenet in der Lage 
sein ihre externe IP-Adresse zu ermitteln. Sie können auch ihre momentane 
IP-Adresse feststellen und diese Ihrem Knoten mit der "Hinweis auf temporäre 
IP-Adresse"-${link}Einstellung${/link} mitteilen. Es wäre auch eine gute Idee, 
den UDP-Port ${port} in Ihrem Router weiterzuleiten, um es Anderen zu 
erleichtern zu Ihrem Knoten Kontakt aufzunehmen.
MeaningfulNodeNameUserAlert.noNodeNick=Anscheinend kennt Ihr Knoten Ihren 
Nickname (Spitznamen) nicht. Ihre E-Mail-Adresse oder IRC-Nickname hier 
einzufügen, ist allgemein gesprochen, eine gute Idee und hilft ihren Freunden 
ihren Knoten zu identifizieren. (Beachten Sie, dass nur Ihre darknet-Partner, 
die auf der Freunde-Seite aufgelistet sind, Ihren Knoten-Namen sehen können, 
Fremde können ihn nicht einsehen).
Node.opennetEnabled=Promiskuitiven Modus einschalten (au

[freenet-dev] [Fwd: German Translation (de.l10n.v1)]

[Michael Tänzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthew Toseland schrieb:
> Thanks! Is this related to the partial german translation that saces 
> committed? Also you should have a look at the changes to the strings when 
> 1048 comes out (there are often changes to existing strings as well as adding 
> new strings).

I didn't know about any partial translation already available, so I
guess it's not. I also have to admit, that I'm not so confident with
SVN, so I don't know what saces' translation looked like (If it's the
one currently available through the Web-Interface of the repository it's
exactly the one I contributed).
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGp4f9PUBAMhFf+J4RAkl9AKCFP0B9lvpHlb5kfA7echQX4tg2FACfRkmA
x6ZEQTW9OvPWINfUTK5axlc=
=eICi
-END PGP SIGNATURE-

Re: [freenet-dev] [Fwd: German Translation (de.l10n.v1)]

[Michael Tänzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthew Toseland schrieb:
> Thanks! Is this related to the partial german translation that saces 
> committed? Also you should have a look at the changes to the strings when 
> 1048 comes out (there are often changes to existing strings as well as adding 
> new strings).

I didn't know about any partial translation already available, so I
guess it's not. I also have to admit, that I'm not so confident with
SVN, so I don't know what saces' translation looked like (If it's the
one currently available through the Web-Interface of the repository it's
exactly the one I contributed).
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGp4f9PUBAMhFf+J4RAkl9AKCFP0B9lvpHlb5kfA7echQX4tg2FACfRkmA
x6ZEQTW9OvPWINfUTK5axlc=
=eICi
-END PGP SIGNATURE-
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] [Fwd: German Translation (de.l10n.v1)]

[Michael Tänzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sorry, sent that mail without being subscribed to the list.

-  Original-Nachricht 
Betreff: German Translation (de.l10n.v1)
Datum: Tue, 24 Jul 2007 06:17:29 +0200
Von: Michael T?nzer 
An: devl at freenetproject.org

Hi folks,

I've just finished the German translation of Freenet (attached).

By the way, the "Key:" right on the homepage of FProxy in the box "Fetch
a Key" is not translatable. Looks a bit odd because it's the first thing
you see, could someone fix that?

Best regards,
Michael T?nzer
aka Thomas Anderson
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGpij3PUBAMhFf+J4RAg88AJ0fI/B3RTCO7zdZfGQ2L5lAg93wBgCgqn4h
0OCTz9Nees+Nv15S+PS4edA=
=Gk92
-END PGP SIGNATURE-
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: freenet.l10n.unlisted.override.properties
URL: