[freenet-dev] Website not the big problem atm? was Re: Content Management System
On Tue, May 13, 2008 at 10:06 PM, Florent Daigni?re wrote: > * Ian Clarke [2008-05-13 13:45:18]: > > On Tue, May 13, 2008 at 12:59 PM, Matthew Toseland > > wrote: > > > As nextgens pointed out recently, our current website has a 40% > conversion > > > rate - that is, 40% of our unique visitors downloaded Freenet. > > > > Firstly, I don't buy that stat, and secondly, the inference you draw > > from it is wrong. > > > > I don't buy the stat because: > > > > 40% of visitors view the download page (according to Google > > Analytics), that doesn't mean 40% of visitors downloaded Freenet, or > > really understood what it was when they clicked on this. I think a lot > > of people just habitually click on "Download" when they see it. > > > > The standard corporate method to gather statistics is to phone home or > to ask for feedback through surveys; do we want to do that? No, but that doesn't mean we should make important decisions based on flawed data. > > I mean, just look at it, its a mass of > > text, with a menu the length of the Amazon river. > > I'm more worried about the content itself than how it's presented. Most > of it *is* outdated. Both are a serious problem. Users these days have higher expectations of websites, right now we aren't meeting those expectations. > > I've personally had > > many experiences of people not having a clue what Freenet was, nor > > trying it out, even after viewing the website. > > > > That hardly prove anything either. Some man pages are known to be useful and > well-designed pieces of documentation... and still, users don't read > them. You are right, it doesn't prove much, but it reinforces most people's perceptions that our website really doesn't make the grade. Ian. -- Email: ian at uprizer.com Cell: +1 512 422 3588 Skype: sanity
Re: [freenet-dev] [freenet-cvs] r19914 - trunk/freenet/src/freenet/crypt/ciphers
* Daniel Cheng <[EMAIL PROTECTED]> [2008-05-14 11:34:19]:
> On 5/14/08, Florent Daignière <[EMAIL PROTECTED]> wrote:
> > * [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2008-05-13 16:11:59]:
> >
> > > Author: j16sdiz
> > > Date: 2008-05-13 16:11:59 + (Tue, 13 May 2008)
> > > New Revision: 19914
> > >
> > > Added:
> > >trunk/freenet/src/freenet/crypt/ciphers/RijndaelTest.java
> > > Log:
> > > JUnit for Rijndael
> > >
> > >
> > > Added: trunk/freenet/src/freenet/crypt/ciphers/RijndaelTest.java
> > > ===
> > > --- trunk/freenet/src/freenet/crypt/ciphers/RijndaelTest.java
> > > (rev 0)
> > > +++ trunk/freenet/src/freenet/crypt/ciphers/RijndaelTest.java 2008-05-13
> > > 16:11:59 UTC (rev 19914)
> > > @@ -0,0 +1,95 @@
> > > +/* This code is part of Freenet. It is distributed under the GNU General
> > > + * Public License, version 2 (or at your option any later version). See
> > > + * http://www.gnu.org/ for further details of the GPL. */
> > > +package freenet.crypt.ciphers;
> > > +
> > > +import java.util.Arrays;
> > > +import java.util.Random;
> > > +
> > > +import javax.crypto.Cipher;
> > > +
> > > +import freenet.crypt.UnsupportedCipherException;
> > > +import freenet.support.HexUtil;
> > > +import junit.framework.TestCase;
> > > +
> > > +/**
> > > + * @author sdiz
> > > + */
> > > +public class RijndaelTest extends TestCase {
> > > + private final byte[] PLAINTXT128_1 =
> > > HexUtil.hexToBytes("0123456789abcdef1123456789abcdef");
> > > + private final byte[] KEY128_1 =
> > > HexUtil.hexToBytes("deadbeefcafebabe0123456789abcdef");
> > > + private final byte[] CIPHER128_1 =
> > > HexUtil.hexToBytes("8c5b8c04805c0e07dd62b381730d5d10");
> > > +
> > > + private final byte[] PLAINTXT192_1 =
> > > HexUtil.hexToBytes("0123456789abcdef1123456789abcdef2123456789abcdef");
> > > + private final byte[] KEY192_1 =
> > > HexUtil.hexToBytes("deadbeefcafebabe0123456789abcdefcafebabedeadbeef");
> > > + private final byte[] CIPHER192_1 =
> > > HexUtil.hexToBytes("7fae974786a9741d96693654bc7a8aff09b3f116840ffced");
> > > +
> > > + private final byte[] PLAINTXT256_1 = HexUtil
> > > +
> > > .hexToBytes("0123456789abcdef1123456789abcdef2123456789abcdef3123456789abcdef");
> > > + private final byte[] KEY256_1 = HexUtil
> > > +
> > > .hexToBytes("deadbeefcafebabe0123456789abcdefcafebabedeadbeefcafebabe01234567");
> > > + private final byte[] CIPHER256_1 = HexUtil
> > > +
> > > .hexToBytes("6fcbc68fc938e5f5a7c24d7422f4b5f153257b6fb53e0bca26770497dd65078c");
> > > +
> > > + private static final Random rand = new Random();
> >
> > Where did you dig those constants from? presumably FIPS but would you
> > mind putting a reference in a comment please ?
> >
>
> No, it's not from any know reference. I just pick a random key and
> plain text, enipher it, get the ciphertext.
>
Using our implementation or a 3rd party one ?
> I was planning to implement JVM-based AES (bug 2330), this test is
> just a casual test to verify the pure java implementation and jvm
> implementation matches.
>
Well then you should be testing it against the live jvm's code and not
some pre-computed value if that's the point...
Anyway I do suggest you check it against known to be good values:
http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf for
instance.
signature.asc
Description: Digital signature
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] Post-0.7.0 priorities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 | I disagree. Your actual bandwidth usage is determined by how many requests the | other nodes send you. This is largely determined by the *average bandwidth | limit* across the whole network. If we increase the average bandwidth limit, | we increase the traffic on your node. Ah, ok, that's probably true. I was thinking you've been talking about that helping *my* node to better utilize the bandwidth available, hence my reply. |> Great that we agree on this one. I've been unsuccessful in bringing at |> least two of my friends to Freenet because they were running into |> memory-related problems, one of them going as far as calling Freenet |> "that damn bloatware" (well, actual wording also included a couple of |> pretty strong Russian expletives :-). | | Hehe. Consensus is good. They are specifically talking about memory/CPU here? | Or bandwidth usage, total transfer in a month, etc etc? Well, memory usage was what finally turned them off, as far as I can see. One of the people I've mentioned (a pretty experienced computer and p2p user) had immediately and repeatedly crashed his node upon discovering Thaw and Frost file sharing tools - he put a couple of hundreds of large files there for both insertion and download, not really understanding how Freenet handles this (on a side note, this is something which is *really* unclear to most casual P2P users I've talked to, especially those with Gnutella/eMule/Kazaa background). Naturally, Freenet quickly ran out of memory, and simply wasn't recovering on its own. We've finally been able to solve this problem by giving Java enough memory to load the queue, then quickly removing files from it (there's probably a better way, but I wasn't aware of it). In the second case, the machine on which we tried to install Freenet was a little bit old (but nothing ancient - P4 2.4 GHz/1 Gb RAM), used as a dedicated P2P machine by my other friend. Shortly after installing Freenet, it became unresponsive - almost constant disk access, high CPU usage, etc. After stopping Freenet, the load went down immediately. We tried actually giving Freenet less than default memory (96 Mb, IIRC), but it didn't really help. |> Well, it seems more or less straightforward from the outside: handle |> additional update URLs and a set of (revocable?) public keys + expose |> the API over FCP. Am I missing something important? | | Yeah but we'd have to unpack, support post-unpack scripts, etc etc ... really | we'd want the apps to provide their own unpacker and just feed them a single | file for them to do what they want with? I think that the latter approach is preferable - they could be using full-blown native installers, etc. No need for Freenet to open that can of worms. Just allow the app to check for updates over FCP and feed it the (verified) update file when one becomes available. What to do with it is up to the application. Regards, Victor Denisov. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIKekCS81Mh9/iCDgRAirPAKDMp5pzomB5CCZgDSJmS9iHv0I0RgCg02+v eEJQYj+Qj0VTyGW2I1uXJDE= =6bPm -END PGP SIGNATURE-
[freenet-dev] Post-0.7.0 priorities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 | What evidence is there that people need to have multi-gigabyte | datastores? We aren't necessarily helping ourselves by telling people | they need to devote anywhere from 1-5% of their total hard disks to | Freenet, unless it *really is* necessary. Freenet enthusiasts may be | ok with this, but casual users probably won't be, and we *need* casual | users. | | Personally I'm pretty skeptical of anything requiring more than 100MB. My store had filled to 100% in less than 72 hours (that would be slightly less than 1 Gb of data), so I doubt that it really stores anything past the last week at best. And one week isn't exactly what we should aim for when talking about data retention, even for unpopular data. As a side note, I *really* miss a stat for the LRU timestamp for the store (or at least I wasn't able to find it) - so I coule be wrong with my "one week" estimate. It would be really interesting to see for how long does your store actually store things. Regards, Victor Denisov. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIKeMhS81Mh9/iCDgRAkD8AJ0WoWa2n7W5t/W6CAgtFKEOugdNzACgvr2d ybupUuIQ/AcE7mCFQh0wQkY= =BGZ/ -END PGP SIGNATURE-
[freenet-dev] Website not the big problem atm? was Re: Content Management System
On Tuesday 13 May 2008 20:30, Michael T?nzer wrote: > Matthew Toseland schrieb: > > > > 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?" Anonymous web hosting is one obvious thing that you can't really get elsewhere - Tor is rubbish at 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). It's in the FAQ, but maybe we need to allude to it or even give a very short explanation with a link to the FAQ. > > 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. Ugh. Can we gateway them to the support list? Nextgens? IMHO this is orthogonal to to-CMS-or-not-to-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. I disagree. Filesharing is something we do reasonably well. Yes it's slower than bittorrent for the most popular stuff, but for less common stuff IMHO it is competitive. > > 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 delay (<<10s), I guess with ULPRs it's > even less). The app is based on his message system Freeze (slogan > "cooler than Frost") which he started programming when the DOS on Frost > began (the first versions where published before we knew about FMS). > Freeze is a Freenet plugin (no port needed) has some features like queue > forking and so on and it should be possible to use a WoT on it (we have > talked about some nice ideas about entering the WoT), it is designed to > use GPG as encryption/signing (I think there where more cool features > but I understood only half of it). We also talked about maybe doing a > hybrid plugin which can talk Freeze and FMS, then we could migrate our > users softly over to Freeze. Well talk to him if you need to know more. I doubt very much that that will work well with WoT. ULPRs are unreliable, and it only works fast now because it polls constantly. > > regards > Neo at NHNG -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080513/30a629bf/attachment.pgp>
[freenet-dev] Website not the big problem atm? was Re: Content Management System
On Tuesday 13 May 2008 20:40, Ian Clarke wrote: > On Tue, May 13, 2008 at 2:30 PM, Michael T?nzer > wrote: > > I don't think funding depends on how our website looks, at least not > > directly > > Not directly, but definitely indirectly. Funding is proportional to > the number of users, and the number of users is proportional to the > number of people persuaded to use Freenet by the website. > > >. 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). > > I'm not suggesting we need a direct copy of the Mozilla design, but > we do need to aim for that level of simplicity and friendliness. > > > 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. > > There are situations where some configuration is desirable, but not > absolutely necessary. Sensible defaults are the key. There are some questions we need to ask the user post install, however this should be as easy as possible, and in particular, we shouldn't have to prepare the user for them on the download page. The user can go back to it if (s)he needs to because something breaks, of course. And the front page is not the download page anyway. > > > 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. > > Google is used for all sorts of serious things, and yet its design is > friendly. I don't see anything wrong with a design that implies > Freenet will be easy to use, I think this is what a friendly design > says to people, it implies ease of use. > > Anyway, I agreed with most of the rest of what you said. > > Ian. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080513/fa09a158/attachment.pgp>
Re: [freenet-dev] Website not the big problem atm? was Re: Content Management System
On Tue, May 13, 2008 at 10:06 PM, Florent Daignière <[EMAIL PROTECTED]> wrote: > * Ian Clarke <[EMAIL PROTECTED]> [2008-05-13 13:45:18]: > > On Tue, May 13, 2008 at 12:59 PM, Matthew Toseland > > <[EMAIL PROTECTED]> wrote: > > > As nextgens pointed out recently, our current website has a 40% > conversion > > > rate - that is, 40% of our unique visitors downloaded Freenet. > > > > Firstly, I don't buy that stat, and secondly, the inference you draw > > from it is wrong. > > > > I don't buy the stat because: > > > > 40% of visitors view the download page (according to Google > > Analytics), that doesn't mean 40% of visitors downloaded Freenet, or > > really understood what it was when they clicked on this. I think a lot > > of people just habitually click on "Download" when they see it. > > > > The standard corporate method to gather statistics is to phone home or > to ask for feedback through surveys; do we want to do that? No, but that doesn't mean we should make important decisions based on flawed data. > > I mean, just look at it, its a mass of > > text, with a menu the length of the Amazon river. > > I'm more worried about the content itself than how it's presented. Most > of it *is* outdated. Both are a serious problem. Users these days have higher expectations of websites, right now we aren't meeting those expectations. > > I've personally had > > many experiences of people not having a clue what Freenet was, nor > > trying it out, even after viewing the website. > > > > That hardly prove anything either. Some man pages are known to be useful and > well-designed pieces of documentation... and still, users don't read > them. You are right, it doesn't prove much, but it reinforces most people's perceptions that our website really doesn't make the grade. Ian. -- Email: [EMAIL PROTECTED] Cell: +1 512 422 3588 Skype: sanity ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] Website not the big problem atm? was Re: Content Management System
;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 delay (<<10s), I guess with ULPRs it's even less). The app is based on his message system Freeze (slogan "cooler than Frost") which he started programming when the DOS on Frost began (the first versions where published before we knew about FMS). Freeze is a Freenet plugin (no port needed) has some features like queue forking and so on and it should be possible to use a WoT on it (we have talked about some nice ideas about entering the WoT), it is designed to use GPG as encryption/signing (I think there where more cool features but I understood only half of it). We also talked about maybe doing a hybrid plugin which can talk Freeze and FMS, then we could migrate our users softly over to Freeze. Well talk to him if you need to know more. 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: <https://emu.freenetproject.org/pipermail/devl/attachments/20080513/a9671cd8/attachment.pgp>
Re: [freenet-dev] [freenet-cvs] r19914 - trunk/freenet/src/freenet/crypt/ciphers
On 5/14/08, Florent Daignière <[EMAIL PROTECTED]> wrote:
> * [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2008-05-13 16:11:59]:
>
> > Author: j16sdiz
> > Date: 2008-05-13 16:11:59 + (Tue, 13 May 2008)
> > New Revision: 19914
> >
> > Added:
> >trunk/freenet/src/freenet/crypt/ciphers/RijndaelTest.java
> > Log:
> > JUnit for Rijndael
> >
> >
> > Added: trunk/freenet/src/freenet/crypt/ciphers/RijndaelTest.java
> > ===
> > --- trunk/freenet/src/freenet/crypt/ciphers/RijndaelTest.java
> > (rev 0)
> > +++ trunk/freenet/src/freenet/crypt/ciphers/RijndaelTest.java 2008-05-13
> > 16:11:59 UTC (rev 19914)
> > @@ -0,0 +1,95 @@
> > +/* This code is part of Freenet. It is distributed under the GNU General
> > + * Public License, version 2 (or at your option any later version). See
> > + * http://www.gnu.org/ for further details of the GPL. */
> > +package freenet.crypt.ciphers;
> > +
> > +import java.util.Arrays;
> > +import java.util.Random;
> > +
> > +import javax.crypto.Cipher;
> > +
> > +import freenet.crypt.UnsupportedCipherException;
> > +import freenet.support.HexUtil;
> > +import junit.framework.TestCase;
> > +
> > +/**
> > + * @author sdiz
> > + */
> > +public class RijndaelTest extends TestCase {
> > + private final byte[] PLAINTXT128_1 =
> > HexUtil.hexToBytes("0123456789abcdef1123456789abcdef");
> > + private final byte[] KEY128_1 =
> > HexUtil.hexToBytes("deadbeefcafebabe0123456789abcdef");
> > + private final byte[] CIPHER128_1 =
> > HexUtil.hexToBytes("8c5b8c04805c0e07dd62b381730d5d10");
> > +
> > + private final byte[] PLAINTXT192_1 =
> > HexUtil.hexToBytes("0123456789abcdef1123456789abcdef2123456789abcdef");
> > + private final byte[] KEY192_1 =
> > HexUtil.hexToBytes("deadbeefcafebabe0123456789abcdefcafebabedeadbeef");
> > + private final byte[] CIPHER192_1 =
> > HexUtil.hexToBytes("7fae974786a9741d96693654bc7a8aff09b3f116840ffced");
> > +
> > + private final byte[] PLAINTXT256_1 = HexUtil
> > +
> > .hexToBytes("0123456789abcdef1123456789abcdef2123456789abcdef3123456789abcdef");
> > + private final byte[] KEY256_1 = HexUtil
> > +
> > .hexToBytes("deadbeefcafebabe0123456789abcdefcafebabedeadbeefcafebabe01234567");
> > + private final byte[] CIPHER256_1 = HexUtil
> > +
> > .hexToBytes("6fcbc68fc938e5f5a7c24d7422f4b5f153257b6fb53e0bca26770497dd65078c");
> > +
> > + private static final Random rand = new Random();
>
> Where did you dig those constants from? presumably FIPS but would you
> mind putting a reference in a comment please ?
>
No, it's not from any know reference. I just pick a random key and
plain text, enipher it, get the ciphertext.
I was planning to implement JVM-based AES (bug 2330), this test is
just a casual test to verify the pure java implementation and jvm
implementation matches.
Regards,
Daniel Cheng
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Website not the big problem atm? was Re: Content Management System
* Ian Clarke <[EMAIL PROTECTED]> [2008-05-13 13:45:18]: > On Tue, May 13, 2008 at 12:59 PM, Matthew Toseland > <[EMAIL PROTECTED]> wrote: > > As nextgens pointed out recently, our current website has a 40% conversion > > rate - that is, 40% of our unique visitors downloaded Freenet. > > Firstly, I don't buy that stat, and secondly, the inference you draw > from it is wrong. > > I don't buy the stat because: > > 40% of visitors view the download page (according to Google > Analytics), that doesn't mean 40% of visitors downloaded Freenet, or > really understood what it was when they clicked on this. I think a lot > of people just habitually click on "Download" when they see it. > The standard corporate method to gather statistics is to phone home or to ask for feedback through surveys; do we want to do that? > > 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? > > No. I definitely don't think you can conclude that the website isn't > a problem from this statistic. I agree but not for the same reason... Statistics gathered right-after a big release are irrelevant (the visitor-base is biased: they came here *because* of the announcement where they read that freenet is and that it is cool/smart/whatever)... They are unlikely to look for anything but the download link. > I mean, just look at it, its a mass of > text, with a menu the length of the Amazon river. I'm more worried about the content itself than how it's presented. Most of it *is* outdated. > I've personally had > many experiences of people not having a clue what Freenet was, nor > trying it out, even after viewing the website. > That hardly prove anything either. Some man pages are known to be useful and well-designed pieces of documentation... and still, users don't read them. signature.asc Description: Digital signature ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] [freenet-cvs] r19914 - trunk/freenet/src/freenet/crypt/ciphers
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2008-05-13 16:11:59]:
> Author: j16sdiz
> Date: 2008-05-13 16:11:59 + (Tue, 13 May 2008)
> New Revision: 19914
>
> Added:
>trunk/freenet/src/freenet/crypt/ciphers/RijndaelTest.java
> Log:
> JUnit for Rijndael
>
>
> Added: trunk/freenet/src/freenet/crypt/ciphers/RijndaelTest.java
> ===
> --- trunk/freenet/src/freenet/crypt/ciphers/RijndaelTest.java
> (rev 0)
> +++ trunk/freenet/src/freenet/crypt/ciphers/RijndaelTest.java 2008-05-13
> 16:11:59 UTC (rev 19914)
> @@ -0,0 +1,95 @@
> +/* This code is part of Freenet. It is distributed under the GNU General
> + * Public License, version 2 (or at your option any later version). See
> + * http://www.gnu.org/ for further details of the GPL. */
> +package freenet.crypt.ciphers;
> +
> +import java.util.Arrays;
> +import java.util.Random;
> +
> +import javax.crypto.Cipher;
> +
> +import freenet.crypt.UnsupportedCipherException;
> +import freenet.support.HexUtil;
> +import junit.framework.TestCase;
> +
> +/**
> + * @author sdiz
> + */
> +public class RijndaelTest extends TestCase {
> + private final byte[] PLAINTXT128_1 =
> HexUtil.hexToBytes("0123456789abcdef1123456789abcdef");
> + private final byte[] KEY128_1 =
> HexUtil.hexToBytes("deadbeefcafebabe0123456789abcdef");
> + private final byte[] CIPHER128_1 =
> HexUtil.hexToBytes("8c5b8c04805c0e07dd62b381730d5d10");
> +
> + private final byte[] PLAINTXT192_1 =
> HexUtil.hexToBytes("0123456789abcdef1123456789abcdef2123456789abcdef");
> + private final byte[] KEY192_1 =
> HexUtil.hexToBytes("deadbeefcafebabe0123456789abcdefcafebabedeadbeef");
> + private final byte[] CIPHER192_1 =
> HexUtil.hexToBytes("7fae974786a9741d96693654bc7a8aff09b3f116840ffced");
> +
> + private final byte[] PLAINTXT256_1 = HexUtil
> +
> .hexToBytes("0123456789abcdef1123456789abcdef2123456789abcdef3123456789abcdef");
> + private final byte[] KEY256_1 = HexUtil
> +
> .hexToBytes("deadbeefcafebabe0123456789abcdefcafebabedeadbeefcafebabe01234567");
> + private final byte[] CIPHER256_1 = HexUtil
> +
> .hexToBytes("6fcbc68fc938e5f5a7c24d7422f4b5f153257b6fb53e0bca26770497dd65078c");
> +
> + private static final Random rand = new Random();
Where did you dig those constants from? presumably FIPS but would you
mind putting a reference in a comment please ?
signature.asc
Description: 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
On Tuesday 13 May 2008 19:45, Ian Clarke wrote: > On Tue, May 13, 2008 at 12:59 PM, Matthew Toseland > wrote: > > As nextgens pointed out recently, our current website has a 40% conversion > > rate - that is, 40% of our unique visitors downloaded Freenet. > > Firstly, I don't buy that stat, and secondly, the inference you draw > from it is wrong. > > I don't buy the stat because: > > 40% of visitors view the download page (according to Google > Analytics), that doesn't mean 40% of visitors downloaded Freenet, or > really understood what it was when they clicked on this. I think a lot > of people just habitually click on "Download" when they see it. Fair point. Nextgens, can you get us a statistic on the number who actually downloaded new_installer.jar ?? > > > 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? > > No. I definitely don't think you can conclude that the website isn't > a problem from this statistic. I mean, just look at it, its a mass of > text, with a menu the length of the Amazon river. I've personally had > many experiences of people not having a clue what Freenet was, nor > trying it out, even after viewing the website. Because Freenet's start page is a blog, which doesn't contain any content that would be relevant to a newbie? > > I've even had experiences of people raving about how great Freenet > was, but later admitting that they hadn't even tried it. Something is > wrong when people can be excited by something, yet not even test it. That's not uncommon in all walks of life! > > > 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). > > All important, but the website is also important. > > Ian. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080513/7d9f7c92/attachment.pgp>
[freenet-dev] Post-0.7.0 priorities
On Tuesday 13 May 2008 19:38, Ian Clarke wrote: > On Tue, May 13, 2008 at 12:53 PM, Matthew Toseland > wrote: > > > > It could be related to the fact that I've only been able to dedicate > > > about 2 Gb for my store, but I doubt it. > > > > That certainly won't help. > > What evidence is there that people need to have multi-gigabyte > datastores? We aren't necessarily helping ourselves by telling people > they need to devote anywhere from 1-5% of their total hard disks to > Freenet, unless it *really is* necessary. Freenet enthusiasts may be > ok with this, but casual users probably won't be, and we *need* casual > users. > > Personally I'm pretty skeptical of anything requiring more than 100MB. How big is your current hard disk? Do you have any ideas for some empirical or scientific way to determine how much storage is needed? AFAICS "as much as possible" has to be a good thing for data retention, no? Assuming a node uses 16K/sec bandwidth, which is the default, uses the same output as input (normally input is a bit lower than output, but not a lot lower), and uses 50% of that for receiving data it didn't have before, and has a 100MB cache, a new block which isn't subsequently requested should reach the bottom of the LRU in 3.55 hours. Data will stay in the store for much longer however. But that relies on us being able to find it, and the nodes it is stored to being online. Being able to find it is probably largely a matter at the moment of location churn. We need to deal with this. There are some ideas, we need to talk to oskar and vive about them. The nodes we stored the data to being online is probably intractable. :( > > Ian. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080513/7e983135/attachment.pgp>
[freenet-dev] Post 0.7 idea: off-grid darknet!
On Tuesday 13 May 2008 00:24, Evan Daniel wrote: > On Mon, May 12, 2008 at 6:56 PM, Ian Clarke wrote: > > On Mon, May 12, 2008 at 9:52 AM, Matthew Toseland > > >> 2. Most or all Freenet apps assume a few seconds latency on requests > > >> (Frost, Fproxy, etc), yet the latency with the sneakernet would be > > >> measured in days. Freenet's existing apps would be useless here. > > > > > > Not true IMHO. A lot of existing Freenet apps deal with long term requests, > > > which would work very nicely with sneakernet. > > > > Such as? FMS is pretty slow even with multi-second requests, do you > > really think it would be useful with multi-day requests? I can't > > think of a single Freenet app that would be useful over a transport > > with multi-day latencies, it would be insane. > > I'm pretty sure FMS is slow because it has a list of a few hundred > identities to poll for messages, and it only polls 10-20 at a time. > On a sneakernet you'd send all the poll requests at once. There's no > reason the delay on receiving a message couldn't be roughly the > one-way latency of the path. > > Downloading any sort of large media file can take days on Freenet > *right now*. People still do it. What do I care whether the 4 day > download delay is routing delay or bandwidth limit? Precisely, this is the promise for non-hostile-regime operation where you may have more bandwidth over sneakernet than over your ISP's slow internet connection. IMHO it's a great way to build the darknet, and of course you can fetch the top few blocks over the UDP connection. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080513/b62ccf4a/attachment.pgp>
[freenet-dev] Post 0.7 idea: off-grid darknet!
On Tuesday 13 May 2008 00:44, Michael Rogers wrote: > Evan Daniel wrote: > > The major change needed would be a way to request not the specific SSK > > block, but the SSK, whatever CHK it happens to redirect to, and any > > CHK blocks needed to decode the result > > Exactly, so you'd need a different protocol, different data formats and > a different routing implementation to cope with the latency - which > raises the question, why use Freenet instead of building a separate network? Why would you need different data formats? Well there are two options here: 1. Bigger SSKs, big enough to contain the entire message. Bback has asked for this for Frost, but I'm not sure what the advantage is: it would make uploading spam slower, but it would also make downloading it slower. 2. True (non-key-based) publish/subscribe. 2. Higher level requests, as a latency/security tradeoff. These could use the same keys, or very similar keys, but clearly they are somewhat different to how we do things now. In any case the client level protocol doesn't have to be much different. Even with the same exact request semantics, hopefully your neighbours would hopefully be subscribed to the same stream, in which case, the latency would only be a single local round trip. > > > -- plus a way to prevent that > > being a DoS attack (tit-for-tat?). > > How would TFT work in this context? Say Alice sends Bob a batch of > requests and Bob doesn't find the data - does Alice punish Bob for > black-holing the requests or does Bob punish Alice for trying to DoS > him? What if Alice was only forwarding the requests for Carol? > > I have some ideas for DoS-resistant routing, but they're only suitable > for long streams of messages between the same endpoints, and the > endpoints need to share an authentication key. I'm not sure whether they > could be adapted to anonymous pub/sub. There are ways to limit the damage e.g. by only allowing a certain number of requests at each priority level for any single peer? > > Cheers, > Michael -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080513/0be0d4be/attachment.pgp>
Re: [freenet-dev] Website not the big problem atm? was Re: Content Management System
* Matthew Toseland <[EMAIL PROTECTED]> [2008-05-13 19:50:38]: > On Tuesday 13 May 2008 19:45, Ian Clarke wrote: > > On Tue, May 13, 2008 at 12:59 PM, Matthew Toseland > > <[EMAIL PROTECTED]> wrote: > > > As nextgens pointed out recently, our current website has a 40% > conversion > > > rate - that is, 40% of our unique visitors downloaded Freenet. > > > > Firstly, I don't buy that stat, and secondly, the inference you draw > > from it is wrong. > > > > I don't buy the stat because: > > > > 40% of visitors view the download page (according to Google > > Analytics), that doesn't mean 40% of visitors downloaded Freenet, or > > really understood what it was when they clicked on this. I think a lot > > of people just habitually click on "Download" when they see it. > > Fair point. Nextgens, can you get us a statistic on the number who actually > downloaded new_installer.jar ?? It's not relevant here as windows vista users use the .exe file... Here are the real-stats in number of hits (not unique visitors) [EMAIL PROTECTED]:/var/log/vlogger-https/downloads.freenetproject.org# for i in $( ls -1 05*); do echo $i:$(zgrep -cE 'GET /alpha/installer/.*install' $i); done 05012008-access.log.gz:418 05022008-access.log.gz:384 05032008-access.log.gz:387 05042008-access.log.gz:408 05052008-access.log.gz:448 05062008-access.log.gz:481 05072008-access.log.gz:389 05082008-access.log.gz:1963 05092008-access.log.gz:6518 05102008-access.log.gz:2596 05112008-access.log:1431 05112008-access.log.gz:1 05122008-access.log:1626 05132008-access.log:1518 for i in $( ls -1 05*); do echo $i:$(zgrep -cE 'GET /download.html' $i); done 05012008-access.log.gz:726 05022008-access.log.gz:623 05032008-access.log.gz:663 05042008-access.log:530 05042008-access.log.gz:0 05052008-access.log.gz:819 05062008-access.log.gz:717 05072008-access.log.gz:668 05082008-access.log.gz:4268 05092008-access.log.gz:15636 05102008-access.log.gz:5203 05112008-access.log:3403 05112008-access.log.gz:4 05122008-access.log:3897 05132008-access.log:3645 We aren't that far from the ~40% announced... signature.asc Description: Digital signature ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] Post 0.7 idea: off-grid darknet!
key, 3x every half hour. In 0.8 we might simply issue a single passive request and renew it when challenged (hopefully less than that). On sneakernet it would be exactly the same. > > > I see it more as a long term, attack resistant, scalable solution for general > > communication in places where Freenet-over-UDP doesn't work. > > Agreed. Scalability IMHO requires *some* form of routing. Yes, a lot of it would be broadcast/multicast, but not all of it. There is a difference between broadcast radio and the internet! > > > What is wrong with this vision? Technically speaking, this might be best > > post-0.8, but I do think that there is a certain synergy here. > > Two things having "a certain synergy" is way way way below the bar > needed to justify incorporating the functionality into the same app. Maybe we should call a ceasefire for the time being, and I'll bug you all again about it in 0.8 when we have passive requests, transport plugins, and maybe new load management? > > Ian. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080513/caf6c2d0/attachment.pgp>
[freenet-dev] Post 0.7 idea: off-grid darknet!
On Monday 12 May 2008 23:56, Michael Rogers wrote: > Matthew Toseland wrote: > >> 1. The platform for this type of thing is a small mobile device, > >> getting Freenet to work well on an iPhone would be a world of pain - > >> and doesn't buy anything for us > > > > No, to do that requires a massive amount of short range bandwidth. Phones do > > not have this. > > Bluetooth? Even less bandwidth than wifi, no? We need several gigabits (over a range measured in feet) for it to be viable. > > > Not true IMHO. A lot of existing Freenet apps deal with long term requests, > > which would work very nicely with sneakernet. > > Which apps do you have in mind? I can't think of any Freenet app that > would be useful with a ten-day delay between requesting a [KSU]SK and > finding out which CHK it redirects to, and then another ten days to > request the top block of the splitfile, and then another ten days for > the data. In the border case where the two nodes have a low-latency low-bandwidth connection as well, this would work well. If we are talking about pure high-latency: - Where did you get the USK from? Hopefully you, or somebody near you, were subscribed to it via passive requests. - There's a good chance the top few blocks will be cached relatively nearby - the top few blocks are for example probably in the freesite's USK container. - But maybe even with all this, there would still be too many round trips. In which case you need a high level tunnel of some kind, with different security tradeoffs... :< > > > I see it more as a long term, attack resistant, scalable solution for general > > communication in places where Freenet-over-UDP doesn't work. > > That would be a very valuable system, I just don't see what it's got to > do with Freenet. Ummm, the fact that it would be a routable small world darknet? That clients would be identical in terms of bulk downloads, and similar for other things? (E.g. FMS would work adequately with this, admittedly with an absolutely horrible latency, which would be cut to a moderately horrible latency with true passive requests). > > Cheers, > Michael -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080513/b97f5db2/attachment.pgp>
[freenet-dev] Post 0.7 idea: off-grid darknet!
On Monday 12 May 2008 23:28, Michael Rogers wrote: > Matthew Toseland wrote: > > Hence request priorities, so that the requests for the top blocks go over the > > UDP connections. > > Are you assuming that every sneakernet connection will be backed up by > an internet connection? No, it's merely an interesting case that will be common in a lot of less hostile, richer places (which being outside of the megacities don't have stellar bandwidth). > > > So the routing code > > could be very similar to the current code, but we would presumably have to > > store the stats in a database of some kind. > > So in other words the code would be similar, but separate? Perhaps. Some of it we'd just tune with subclasses e.g. the failure table code. > > > Again, request priorities. Maybe two completely different kinds of requests, > > fast (darknet only, no priority) and slow (can go over sneakernet or > > real-time darknet links, different sub-priorities, high latency). > > Yes, I think the code would have to be separate because the requirements > are completely different: batch operation, latency on the order of days > rather than seconds, round-trips must be minimised at all costs. A lot of our current usage is for batch operation. But you have a fair point about round-trips. > (For > example the current accept/reject negotiation would add two days per hop > in a sneakernet; token passing doesn't solve the problem because you > still need to handle loops.) True. > > So the implementations will be separate, and as Ian pointed out, so will > the applications: people won't use a system with ten-day latency for the > same purposes as a system with ten-second latency. If the > implementations and applications will both be separate, there's no > advantage that I can see to gluing the two systems together. Then why do people use Freenet for multi-day bulk downloads today? Clearly there is an overlap. Also we could handle publish/subscribe systems fairly efficiently. > > Cheers, > Michael -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080513/3fb2624e/attachment.pgp>
[freenet-dev] Website not the big problem atm? was Re: Content Management System
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. > > 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). > > Ian. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080513/9106f1a3/attachment.pgp>
[freenet-dev] Post-0.7.0 priorities
On Monday 12 May 2008 23:10, Michael Rogers wrote: > Victor Denisov wrote: > > Input Rate: 17.6 KiB/sec (of 300 KiB) > > Output Rate: 15.9 KiB/sec (of 200 KiB) > > Total Input: 4.83 GiB (28.3 KiB/sec) > > Total Output: 5.66 GiB (33.2 KiB/sec) > > > > Used Java memory: 122 MiB > > Allocated Java memory: 127 MiB > > Maximum Java memory: 284 MiB > > Running threads: 152/700 > > > > So, basically, network had grown about 3x after 0.7 release. My node has > > been up for 2 days, and is pretty well established in the network. It's > > not overloaded (CPU usage is ~ 5-10%). Yet it doesn't use more than > > about 15% of the allowed bandwidth, on average. > > If the average speed of a node is, say, 20 KB/s then your node's > unlikely to be able to use 300 KB/s because its peers won't be > sending/accepting enough traffic (due to their own bandwidth limits, not > yours). This could be solved by allowing fast nodes to have more peers, > but of course that creates the possibility of ubernodes. It could also be solved to a degree by a different load management scheme that allowed us more fine grained control over the degree to which ubernodes can take more requests... But a) that's probably too big a job for 0.7.1, and b) the current system seems to more or less work. > > Cheers, > Michael -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080513/f2fb54bd/attachment.pgp>
[freenet-dev] Post-0.7.0 priorities
On Monday 12 May 2008 20:19, Victor Denisov wrote: > | On Friday 09 May 2008 07:27, Victor Denisov wrote: > |> | Automatic bandwidth calibration. Other p2p apps have this, we should > |> have it. > |> > |> Good idea. Also, we should definitely look into better utilizing > |> available bandwidth. Freenet's the only p2p app which consistently > |> underutilizes my upload limit (~ 2 Mbit/s out of 8 Mbit/s of link > |> capacity). I understand that we don't want to create supernodes, but > |> come on, 2 Mbit/s is *nothing* these days. > | > | IMHO automatic bandwidth calibration will help a lot with this. Beyond > that > | we're looking at token passing, which may be too big for 0.7.1. > > Excerpt from my current node stats: > > networkSizeEstimateSession: 6039 nodes > nodeUptime: 2d1h > pInstantReject: 0,0% > uptimeAverage: 100,0% > Peer statistics > ~* Connected: 17 > ~* Backed off: 3 > ~* Seeding for: 111 > Input Rate: 17.6 KiB/sec (of 300 KiB) > Output Rate: 15.9 KiB/sec (of 200 KiB) > Total Input: 4.83 GiB (28.3 KiB/sec) > Total Output: 5.66 GiB (33.2 KiB/sec) > > Used Java memory: 122 MiB > Allocated Java memory: 127 MiB > Maximum Java memory: 284 MiB > Running threads: 152/700 > > So, basically, network had grown about 3x after 0.7 release. Great! > My node has > been up for 2 days, and is pretty well established in the network. It's > not overloaded (CPU usage is ~ 5-10%). Yet it doesn't use more than > about 15% of the allowed bandwidth, on average. Automatic bandwidth > calibration won't help - I've allowed Freenet to use much less that my > uplink allows to. I disagree. Your actual bandwidth usage is determined by how many requests the other nodes send you. This is largely determined by the *average bandwidth limit* across the whole network. If we increase the average bandwidth limit, we increase the traffic on your node. > > It could be related to the fact that I've only been able to dedicate > about 2 Gb for my store, but I doubt it. That certainly won't help. > > | Agreed, memory usage is a usability issue: the user shouldn't have to > care > | about it. > > Great that we agree on this one. I've been unsuccessful in bringing at > least two of my friends to Freenet because they were running into > memory-related problems, one of them going as far as calling Freenet > "that damn bloatware" (well, actual wording also included a couple of > pretty strong Russian expletives :-). Hehe. Consensus is good. They are specifically talking about memory/CPU here? Or bandwidth usage, total transfer in a month, etc etc? > > |> Shouldn't we consider auto-updating bundled applications as well? Or > |> perhaps providing an auto-update API for use by third-party apps? Just a > |> thought. > | > | Maybe, that would be harder though. I would be happy to discuss it > with their > | authors. > > Well, it seems more or less straightforward from the outside: handle > additional update URLs and a set of (revocable?) public keys + expose > the API over FCP. Am I missing something important? Yeah but we'd have to unpack, support post-unpack scripts, etc etc ... really we'd want the apps to provide their own unpacker and just feed them a single file for them to do what they want with? > > Regards, > Victor Denisov. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080513/f2126e45/attachment.pgp>
[freenet-dev] [freenet-cvs] r19789 - branches/saltedhashstore/freenet/src/freenet/store
On Saturday 10 May 2008 04:10, Daniel Cheng wrote: > On Sat, May 10, 2008 at 6:24 AM, Matthew Toseland > wrote: > > On Tuesday 06 May 2008 08:39, j16sdiz at freenetproject.org wrote: > >> Author: j16sdiz > >> Date: 2008-05-06 07:39:43 + (Tue, 06 May 2008) > >> New Revision: 19789 > >> > >> Modified: > >> > > branches/saltedhashstore/freenet/src/freenet/store/SaltedHashFreenetStore.java > >> Log: > >> option for saving plain key (for migration) > > > > For datastore histograms? It ought to be possible to make migration possible > > without knowing the full key ... but it would require that the salt isn't > > used in crypto, or is easily reversed out... hmmm. > >> > > This code save all necessary keys to allow migrate _back_ to BDBFS. I > don't want to lost any data in this early testing stage. Ahh, okay. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080513/387cbc86/attachment.pgp>
[freenet-dev] WoT plugin
On Monday 12 May 2008 20:05, Julien Cornuwel wrote: > bbackde at googlemail.com a ?crit : > > When you publish a shared trust tree with 2 identities, everyone could > > easily figure > > out that this two identities are the same person. > > I wasn't thinking about sharing the same trustlist but : the first > identity publish its trustlist and others don't. What would be shared > would be the trust *tree*, ie. what identities are viewed and what are not. That might work, although it's bad if all secondary identities don't publish trust lists and most primaries do... > > > I think option 2 together should be implemented, added with the possibility to > > take over (selected) trust states from other local identities. > > > Well, that's possible and it's not really complex to implement. But that > will be more complex to use for the clients. Having an identity that > sees someone posts while another don't can be quite disapointing. That could be a pain yes. It's another reason for a user to have a completely separate UI for his or her second identity... and preferably a second personality too! :) -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080513/50223105/attachment.pgp>
[freenet-dev] WoT plugin
On Monday 12 May 2008 18:14, you wrote: > Hi, > > I'm having interrogations about the use of the WoT plugin and I'm > confronted to a choice : > > The plugin is able to handle multiple local identites. But do you think > it could be usefull to allow local identities to set different trust > levels on other identities. Yes, it's essential, otherwise it will be possible to identify that two local identities are the same because they publish identical trust lists. Of course, they'd have to be announced separately to maintain the illusion of separation, and then the user would have to be careful; ideally there would be two different *reading* clients as well as posting. > > Possibilities are : > > 1) One identity publish its trustlist and all local identities share the > same trust tree. > 2) Every local identity has to handle its own trust list and has its own > trust tree. That implies that one identity might see someone while > another won't. > > In my opinion, 1) would fit most uses of the plugin. Except the one > where you share your node with a person you totally disagree with (quite > unlikely, isn't it ?). > > The flaw of 2) is that every identity has to set its own trust values > for every identities. An option could be to allow the user to set a > "parent" identity that the new identity would share it's trust list with. > > What do you think ? I think you should support completely separate identities which can't be easily linked together, just as Frost did. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080513/fd6bf4ff/attachment.pgp>
Re: [freenet-dev] [freenet-cvs] r19918 - in trunk/freenet: src/freenet/crypt/ciphers test/freenet/crypt test/freenet/crypt/ciphers
On Wed, May 14, 2008 at 4:45 AM, <[EMAIL PROTECTED]> wrote: > Author: dbkr > Date: 2008-05-13 20:45:14 + (Tue, 13 May 2008) > New Revision: 19918 > > Added: >trunk/freenet/test/freenet/crypt/ciphers/ >trunk/freenet/test/freenet/crypt/ciphers/RijndaelTest.java > Removed: >trunk/freenet/src/freenet/crypt/ciphers/RijndaelTest.java > Log: > Move the Rijndael test to the test directory, so Freenet can still be built > without junit. Please keep things with extra test dependencies separate! > Oops. Thank you. ___ 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
On Tue, May 13, 2008 at 2:30 PM, Michael T?nzer wrote: > I don't think funding depends on how our website looks, at least not > directly Not directly, but definitely indirectly. Funding is proportional to the number of users, and the number of users is proportional to the number of people persuaded to use Freenet by the website. >. 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). I'm not suggesting we need a direct copy of the Mozilla design, but we do need to aim for that level of simplicity and friendliness. > 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. There are situations where some configuration is desirable, but not absolutely necessary. Sensible defaults are the key. > 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. Google is used for all sorts of serious things, and yet its design is friendly. I don't see anything wrong with a design that implies Freenet will be easy to use, I think this is what a friendly design says to people, it implies ease of use. Anyway, I agreed with most of the rest of what you said. Ian. -- Email: ian at uprizer.com Cell: +1 512 422 3588 Skype: sanity
Re: [freenet-dev] Website not the big problem atm? was Re: Content Management System
On Tuesday 13 May 2008 20:30, Michael Tänzer wrote: > Matthew Toseland schrieb: > > > > 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?" Anonymous web hosting is one obvious thing that you can't really get elsewhere - Tor is rubbish at 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). It's in the FAQ, but maybe we need to allude to it or even give a very short explanation with a link to the FAQ. > > 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. Ugh. Can we gateway them to the support list? Nextgens? IMHO this is orthogonal to to-CMS-or-not-to-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. I disagree. Filesharing is something we do reasonably well. Yes it's slower than bittorrent for the most popular stuff, but for less common stuff IMHO it is competitive. > > 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 delay (<<10s), I guess with ULPRs it's > even less). The app is based on his message system Freeze (slogan > "cooler than Frost") which he started programming when the DOS on Frost > began (the first versions where published before we knew about FMS). > Freeze is a Freenet plugin (no port needed) has some features like queue > forking and so on and it should be possible to use a WoT on it (we have > talked about some nice ideas about entering the WoT), it is designed to > use GPG as encryption/signing (I think there where more cool features > but I understood only half of it). We also talked about maybe doing a > hybrid plugin which can talk Freeze and FMS, then we could migrate our > users softly over to Freeze. Well talk to him if you need to know more. I doubt very much that that will work well with WoT. ULPRs are unreliable, and it only works fast now because it polls constantly. > > regards > [EMAIL PROTECTED] pgpsRjWdM2ySs.pgp Description: PGP signature ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Website not the big problem atm? was Re: Content Management System
On Tuesday 13 May 2008 20:40, Ian Clarke wrote: > On Tue, May 13, 2008 at 2:30 PM, Michael Tänzer > <[EMAIL PROTECTED]> wrote: > > I don't think funding depends on how our website looks, at least not > > directly > > Not directly, but definitely indirectly. Funding is proportional to > the number of users, and the number of users is proportional to the > number of people persuaded to use Freenet by the website. > > >. 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). > > I'm not suggesting we need a direct copy of the Mozilla design, but > we do need to aim for that level of simplicity and friendliness. > > > 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. > > There are situations where some configuration is desirable, but not > absolutely necessary. Sensible defaults are the key. There are some questions we need to ask the user post install, however this should be as easy as possible, and in particular, we shouldn't have to prepare the user for them on the download page. The user can go back to it if (s)he needs to because something breaks, of course. And the front page is not the download page anyway. > > > 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. > > Google is used for all sorts of serious things, and yet its design is > friendly. I don't see anything wrong with a design that implies > Freenet will be easy to use, I think this is what a friendly design > says to people, it implies ease of use. > > Anyway, I agreed with most of the rest of what you said. > > Ian. pgpUpBYKUVRxQ.pgp Description: PGP 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
On Tue, May 13, 2008 at 12:59 PM, Matthew Toseland wrote: > As nextgens pointed out recently, our current website has a 40% conversion > rate - that is, 40% of our unique visitors downloaded Freenet. Firstly, I don't buy that stat, and secondly, the inference you draw from it is wrong. I don't buy the stat because: 40% of visitors view the download page (according to Google Analytics), that doesn't mean 40% of visitors downloaded Freenet, or really understood what it was when they clicked on this. I think a lot of people just habitually click on "Download" when they see it. > 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? No. I definitely don't think you can conclude that the website isn't a problem from this statistic. I mean, just look at it, its a mass of text, with a menu the length of the Amazon river. I've personally had many experiences of people not having a clue what Freenet was, nor trying it out, even after viewing the website. I've even had experiences of people raving about how great Freenet was, but later admitting that they hadn't even tried it. Something is wrong when people can be excited by something, yet not even test it. > 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). All important, but the website is also important. Ian. -- Email: ian at uprizer.com Cell: +1 512 422 3588 Skype: sanity
[freenet-dev] Post-0.7.0 priorities
On Tue, May 13, 2008 at 12:53 PM, Matthew Toseland wrote: > > It could be related to the fact that I've only been able to dedicate > > about 2 Gb for my store, but I doubt it. > > That certainly won't help. What evidence is there that people need to have multi-gigabyte datastores? We aren't necessarily helping ourselves by telling people they need to devote anywhere from 1-5% of their total hard disks to Freenet, unless it *really is* necessary. Freenet enthusiasts may be ok with this, but casual users probably won't be, and we *need* casual users. Personally I'm pretty skeptical of anything requiring more than 100MB. Ian. -- Email: ian at uprizer.com Cell: +1 512 422 3588 Skype: sanity
Re: [freenet-dev] Website not the big problem atm? was Re: Content Management System
On Tue, May 13, 2008 at 2:30 PM, Michael Tänzer <[EMAIL PROTECTED]> wrote: > I don't think funding depends on how our website looks, at least not > directly Not directly, but definitely indirectly. Funding is proportional to the number of users, and the number of users is proportional to the number of people persuaded to use Freenet by the website. >. 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). I'm not suggesting we need a direct copy of the Mozilla design, but we do need to aim for that level of simplicity and friendliness. > 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. There are situations where some configuration is desirable, but not absolutely necessary. Sensible defaults are the key. > 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. Google is used for all sorts of serious things, and yet its design is friendly. I don't see anything wrong with a design that implies Freenet will be easy to use, I think this is what a friendly design says to people, it implies ease of use. Anyway, I agreed with most of the rest of what you said. Ian. -- Email: [EMAIL PROTECTED] Cell: +1 512 422 3588 Skype: sanity ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Website not the big problem atm? was Re: Content Management System
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
Re: [freenet-dev] Post-0.7.0 priorities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 | I disagree. Your actual bandwidth usage is determined by how many requests the | other nodes send you. This is largely determined by the *average bandwidth | limit* across the whole network. If we increase the average bandwidth limit, | we increase the traffic on your node. Ah, ok, that's probably true. I was thinking you've been talking about that helping *my* node to better utilize the bandwidth available, hence my reply. |> Great that we agree on this one. I've been unsuccessful in bringing at |> least two of my friends to Freenet because they were running into |> memory-related problems, one of them going as far as calling Freenet |> "that damn bloatware" (well, actual wording also included a couple of |> pretty strong Russian expletives :-). | | Hehe. Consensus is good. They are specifically talking about memory/CPU here? | Or bandwidth usage, total transfer in a month, etc etc? Well, memory usage was what finally turned them off, as far as I can see. One of the people I've mentioned (a pretty experienced computer and p2p user) had immediately and repeatedly crashed his node upon discovering Thaw and Frost file sharing tools - he put a couple of hundreds of large files there for both insertion and download, not really understanding how Freenet handles this (on a side note, this is something which is *really* unclear to most casual P2P users I've talked to, especially those with Gnutella/eMule/Kazaa background). Naturally, Freenet quickly ran out of memory, and simply wasn't recovering on its own. We've finally been able to solve this problem by giving Java enough memory to load the queue, then quickly removing files from it (there's probably a better way, but I wasn't aware of it). In the second case, the machine on which we tried to install Freenet was a little bit old (but nothing ancient - P4 2.4 GHz/1 Gb RAM), used as a dedicated P2P machine by my other friend. Shortly after installing Freenet, it became unresponsive - almost constant disk access, high CPU usage, etc. After stopping Freenet, the load went down immediately. We tried actually giving Freenet less than default memory (96 Mb, IIRC), but it didn't really help. |> Well, it seems more or less straightforward from the outside: handle |> additional update URLs and a set of (revocable?) public keys + expose |> the API over FCP. Am I missing something important? | | Yeah but we'd have to unpack, support post-unpack scripts, etc etc ... really | we'd want the apps to provide their own unpacker and just feed them a single | file for them to do what they want with? I think that the latter approach is preferable - they could be using full-blown native installers, etc. No need for Freenet to open that can of worms. Just allow the app to check for updates over FCP and feed it the (verified) update file when one becomes available. What to do with it is up to the application. Regards, Victor Denisov. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIKekCS81Mh9/iCDgRAirPAKDMp5pzomB5CCZgDSJmS9iHv0I0RgCg02+v eEJQYj+Qj0VTyGW2I1uXJDE= =6bPm -END PGP SIGNATURE- ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Post-0.7.0 priorities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 | What evidence is there that people need to have multi-gigabyte | datastores? We aren't necessarily helping ourselves by telling people | they need to devote anywhere from 1-5% of their total hard disks to | Freenet, unless it *really is* necessary. Freenet enthusiasts may be | ok with this, but casual users probably won't be, and we *need* casual | users. | | Personally I'm pretty skeptical of anything requiring more than 100MB. My store had filled to 100% in less than 72 hours (that would be slightly less than 1 Gb of data), so I doubt that it really stores anything past the last week at best. And one week isn't exactly what we should aim for when talking about data retention, even for unpopular data. As a side note, I *really* miss a stat for the LRU timestamp for the store (or at least I wasn't able to find it) - so I coule be wrong with my "one week" estimate. It would be really interesting to see for how long does your store actually store things. Regards, Victor Denisov. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIKeMhS81Mh9/iCDgRAkD8AJ0WoWa2n7W5t/W6CAgtFKEOugdNzACgvr2d ybupUuIQ/AcE7mCFQh0wQkY= =BGZ/ -END PGP SIGNATURE- ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Website not the big problem atm? was Re: Content Management System
On Tuesday 13 May 2008 19:45, Ian Clarke wrote: > On Tue, May 13, 2008 at 12:59 PM, Matthew Toseland > <[EMAIL PROTECTED]> wrote: > > As nextgens pointed out recently, our current website has a 40% conversion > > rate - that is, 40% of our unique visitors downloaded Freenet. > > Firstly, I don't buy that stat, and secondly, the inference you draw > from it is wrong. > > I don't buy the stat because: > > 40% of visitors view the download page (according to Google > Analytics), that doesn't mean 40% of visitors downloaded Freenet, or > really understood what it was when they clicked on this. I think a lot > of people just habitually click on "Download" when they see it. Fair point. Nextgens, can you get us a statistic on the number who actually downloaded new_installer.jar ?? > > > 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? > > No. I definitely don't think you can conclude that the website isn't > a problem from this statistic. I mean, just look at it, its a mass of > text, with a menu the length of the Amazon river. I've personally had > many experiences of people not having a clue what Freenet was, nor > trying it out, even after viewing the website. Because Freenet's start page is a blog, which doesn't contain any content that would be relevant to a newbie? > > I've even had experiences of people raving about how great Freenet > was, but later admitting that they hadn't even tried it. Something is > wrong when people can be excited by something, yet not even test it. That's not uncommon in all walks of life! > > > 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). > > All important, but the website is also important. > > Ian. pgpIUg36uHobO.pgp Description: PGP signature ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Post-0.7.0 priorities
On Tuesday 13 May 2008 19:38, Ian Clarke wrote: > On Tue, May 13, 2008 at 12:53 PM, Matthew Toseland > <[EMAIL PROTECTED]> wrote: > > > > It could be related to the fact that I've only been able to dedicate > > > about 2 Gb for my store, but I doubt it. > > > > That certainly won't help. > > What evidence is there that people need to have multi-gigabyte > datastores? We aren't necessarily helping ourselves by telling people > they need to devote anywhere from 1-5% of their total hard disks to > Freenet, unless it *really is* necessary. Freenet enthusiasts may be > ok with this, but casual users probably won't be, and we *need* casual > users. > > Personally I'm pretty skeptical of anything requiring more than 100MB. How big is your current hard disk? Do you have any ideas for some empirical or scientific way to determine how much storage is needed? AFAICS "as much as possible" has to be a good thing for data retention, no? Assuming a node uses 16K/sec bandwidth, which is the default, uses the same output as input (normally input is a bit lower than output, but not a lot lower), and uses 50% of that for receiving data it didn't have before, and has a 100MB cache, a new block which isn't subsequently requested should reach the bottom of the LRU in 3.55 hours. Data will stay in the store for much longer however. But that relies on us being able to find it, and the nodes it is stored to being online. Being able to find it is probably largely a matter at the moment of location churn. We need to deal with this. There are some ideas, we need to talk to oskar and vive about them. The nodes we stored the data to being online is probably intractable. :( > > Ian. pgpt56KXwLvWB.pgp Description: PGP signature ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Website not the big problem atm? was Re: Content Management System
On Tue, May 13, 2008 at 12:59 PM, Matthew Toseland <[EMAIL PROTECTED]> wrote: > As nextgens pointed out recently, our current website has a 40% conversion > rate - that is, 40% of our unique visitors downloaded Freenet. Firstly, I don't buy that stat, and secondly, the inference you draw from it is wrong. I don't buy the stat because: 40% of visitors view the download page (according to Google Analytics), that doesn't mean 40% of visitors downloaded Freenet, or really understood what it was when they clicked on this. I think a lot of people just habitually click on "Download" when they see it. > 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? No. I definitely don't think you can conclude that the website isn't a problem from this statistic. I mean, just look at it, its a mass of text, with a menu the length of the Amazon river. I've personally had many experiences of people not having a clue what Freenet was, nor trying it out, even after viewing the website. I've even had experiences of people raving about how great Freenet was, but later admitting that they hadn't even tried it. Something is wrong when people can be excited by something, yet not even test it. > 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). All important, but the website is also important. Ian. -- Email: [EMAIL PROTECTED] Cell: +1 512 422 3588 Skype: sanity ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Post 0.7 idea: off-grid darknet!
On Tuesday 13 May 2008 00:24, Evan Daniel wrote: > On Mon, May 12, 2008 at 6:56 PM, Ian Clarke <[EMAIL PROTECTED]> wrote: > > On Mon, May 12, 2008 at 9:52 AM, Matthew Toseland > > >> 2. Most or all Freenet apps assume a few seconds latency on requests > > >> (Frost, Fproxy, etc), yet the latency with the sneakernet would be > > >> measured in days. Freenet's existing apps would be useless here. > > > > > > Not true IMHO. A lot of existing Freenet apps deal with long term requests, > > > which would work very nicely with sneakernet. > > > > Such as? FMS is pretty slow even with multi-second requests, do you > > really think it would be useful with multi-day requests? I can't > > think of a single Freenet app that would be useful over a transport > > with multi-day latencies, it would be insane. > > I'm pretty sure FMS is slow because it has a list of a few hundred > identities to poll for messages, and it only polls 10-20 at a time. > On a sneakernet you'd send all the poll requests at once. There's no > reason the delay on receiving a message couldn't be roughly the > one-way latency of the path. > > Downloading any sort of large media file can take days on Freenet > *right now*. People still do it. What do I care whether the 4 day > download delay is routing delay or bandwidth limit? Precisely, this is the promise for non-hostile-regime operation where you may have more bandwidth over sneakernet than over your ISP's slow internet connection. IMHO it's a great way to build the darknet, and of course you can fetch the top few blocks over the UDP connection. pgpvD1g2WQfGy.pgp Description: PGP signature ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Post 0.7 idea: off-grid darknet!
On Tuesday 13 May 2008 00:44, Michael Rogers wrote: > Evan Daniel wrote: > > The major change needed would be a way to request not the specific SSK > > block, but the SSK, whatever CHK it happens to redirect to, and any > > CHK blocks needed to decode the result > > Exactly, so you'd need a different protocol, different data formats and > a different routing implementation to cope with the latency - which > raises the question, why use Freenet instead of building a separate network? Why would you need different data formats? Well there are two options here: 1. Bigger SSKs, big enough to contain the entire message. Bback has asked for this for Frost, but I'm not sure what the advantage is: it would make uploading spam slower, but it would also make downloading it slower. 2. True (non-key-based) publish/subscribe. 2. Higher level requests, as a latency/security tradeoff. These could use the same keys, or very similar keys, but clearly they are somewhat different to how we do things now. In any case the client level protocol doesn't have to be much different. Even with the same exact request semantics, hopefully your neighbours would hopefully be subscribed to the same stream, in which case, the latency would only be a single local round trip. > > > -- plus a way to prevent that > > being a DoS attack (tit-for-tat?). > > How would TFT work in this context? Say Alice sends Bob a batch of > requests and Bob doesn't find the data - does Alice punish Bob for > black-holing the requests or does Bob punish Alice for trying to DoS > him? What if Alice was only forwarding the requests for Carol? > > I have some ideas for DoS-resistant routing, but they're only suitable > for long streams of messages between the same endpoints, and the > endpoints need to share an authentication key. I'm not sure whether they > could be adapted to anonymous pub/sub. There are ways to limit the damage e.g. by only allowing a certain number of requests at each priority level for any single peer? > > Cheers, > Michael pgpClUZZE1Yu1.pgp Description: PGP signature ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Post-0.7.0 priorities
On Tue, May 13, 2008 at 12:53 PM, Matthew Toseland <[EMAIL PROTECTED]> wrote: > > It could be related to the fact that I've only been able to dedicate > > about 2 Gb for my store, but I doubt it. > > That certainly won't help. What evidence is there that people need to have multi-gigabyte datastores? We aren't necessarily helping ourselves by telling people they need to devote anywhere from 1-5% of their total hard disks to Freenet, unless it *really is* necessary. Freenet enthusiasts may be ok with this, but casual users probably won't be, and we *need* casual users. Personally I'm pretty skeptical of anything requiring more than 100MB. Ian. -- Email: [EMAIL PROTECTED] Cell: +1 512 422 3588 Skype: sanity ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Post 0.7 idea: off-grid darknet!
On Monday 12 May 2008 23:56, Ian Clarke wrote: > On Mon, May 12, 2008 at 9:52 AM, Matthew Toseland > <[EMAIL PROTECTED]> wrote: > > On Saturday 10 May 2008 17:33, Ian Clarke wrote: > >> I see a simple scenario where a "sneakernet" would be useful is in a > >> situation like Burma or Tibet where stuff is happening, possibly a > >> political crack-down, and the authorities are actively trying to > >> prevent information from getting out. > > > > You are assuming a short term emergency, right? > > In this scenario, yes - although I think similar issues arise in > aggressively repressive regimes such as Burma and North Korea. Exactly: such a system would be useful long-term anywhere where you can get a computer but not a (safe) internet connection. > > > This is what happens now, except that the determination of what is most > > important is made individually. If there is no filtering, it will of course > > be flooded with garbage. > > Well, its kinda what happens now, except this proposal would be > faster, lower risk, and much more convenient. Flooding is a danger, > but I'm sure it could be mitigated. Ok. > > > Manual filtering will work better, if stuff is of universal relevance. Any > > broadcast system will be flooded. > > Manual filtering would require transmission in the clear, and would > require far more human intervention. Some kind of web-of-trust for > authors may be more appropriate. Passive requests? Publish/subscribe? Both features for Freenet 0.8. :) > > >> 1. The platform for this type of thing is a small mobile device, > >> getting Freenet to work well on an iPhone would be a world of pain - > >> and doesn't buy anything for us > > > > No, to do that requires a massive amount of short range bandwidth. Phones do > > not have this. What you want is to swap actual memory sticks, at least until > > PDAs with UWB (maybe wireless USB) are available. > > iPhones support 802.11n, which apparently operates at up to 70Mbps at > ranges up to 300m. That seems plenty fast enough to me. That's nice yeah, but how long are you going to be in close contact? An hour? And how much congestion can you expect - how many other people will be using this at once? How much general noise will there be from commercial networks, public wifi, etc etc? I'm not sure you could reliably exchange more than a gig... That's not to say I'm not a fan of this kind of stuff: IMHO it's better than sneakernet in a lot of ways, and it's a very viable alternate transport, which a sneakernet system should take advantage of if possible. But I do believe it should use whatever is available, high or low latency, i.e. have pluggable transports. > > > Furthermore, with the currently planned changes IMHO Freenet 0.7.1 will be > > able to run in a 64MB memory limit. Running it on a low end device is not so > > far away, and would have some massive advantages (e.g. being able to ship it > > on one of the fanless boxes they currently ship for overnight bittorrent > > downloads). > > It would be nice if Freenet could run on an iPhone, but I'm not > holding my breath. :) > > >> 2. Most or all Freenet apps assume a few seconds latency on requests > >> (Frost, Fproxy, etc), yet the latency with the sneakernet would be > >> measured in days. Freenet's existing apps would be useless here. > > > > Not true IMHO. A lot of existing Freenet apps deal with long term requests, > > which would work very nicely with sneakernet. > > Such as? FMS is pretty slow even with multi-second requests, do you > really think it would be useful with multi-day requests? I can't > think of a single Freenet app that would be useful over a transport > with multi-day latencies, it would be insane. Downloads of all kinds. These can take a long time. Uploads of all kinds, likewise. These already take ages. Freenet has minimal "offline browsing" support already, in that if a page DNFs, it offers a "keep trying and tell me when done" option. Once mister_wavey's bandwidth scheduler goes in, this may be used more widely, as many nodes will be not connected at all during peak hours, but the user can still browse what is available there. I don't see a fundamental problem with FMS over sneakernet. Practically speaking, of course it would be slow: it can't be faster than the underlying network. However, with subscriptions (over passive requests), there is no reason for it to require many many round trips. In terms of API, FMS wouldn't notice the difference at all, because FMS simply subscribes to a key (ClientGet MaxRetries=-1). At the moment, we poll for the key, 3x every half hour. In 0.8 we might simply issue a single passive request and renew it when challenged (hopefully less than that). On sneakernet it would be exactly the same. > > > I see it more as a long term, attack resistant, scalable solution for general > > communication in places where Freenet-over-UDP doesn't work. > > Agreed. Scalability IMHO requires *some* form
Re: [freenet-dev] Post 0.7 idea: off-grid darknet!
On Monday 12 May 2008 23:56, Michael Rogers wrote: > Matthew Toseland wrote: > >> 1. The platform for this type of thing is a small mobile device, > >> getting Freenet to work well on an iPhone would be a world of pain - > >> and doesn't buy anything for us > > > > No, to do that requires a massive amount of short range bandwidth. Phones do > > not have this. > > Bluetooth? Even less bandwidth than wifi, no? We need several gigabits (over a range measured in feet) for it to be viable. > > > Not true IMHO. A lot of existing Freenet apps deal with long term requests, > > which would work very nicely with sneakernet. > > Which apps do you have in mind? I can't think of any Freenet app that > would be useful with a ten-day delay between requesting a [KSU]SK and > finding out which CHK it redirects to, and then another ten days to > request the top block of the splitfile, and then another ten days for > the data. In the border case where the two nodes have a low-latency low-bandwidth connection as well, this would work well. If we are talking about pure high-latency: - Where did you get the USK from? Hopefully you, or somebody near you, were subscribed to it via passive requests. - There's a good chance the top few blocks will be cached relatively nearby - the top few blocks are for example probably in the freesite's USK container. - But maybe even with all this, there would still be too many round trips. In which case you need a high level tunnel of some kind, with different security tradeoffs... :< > > > I see it more as a long term, attack resistant, scalable solution for general > > communication in places where Freenet-over-UDP doesn't work. > > That would be a very valuable system, I just don't see what it's got to > do with Freenet. Ummm, the fact that it would be a routable small world darknet? That clients would be identical in terms of bulk downloads, and similar for other things? (E.g. FMS would work adequately with this, admittedly with an absolutely horrible latency, which would be cut to a moderately horrible latency with true passive requests). > > Cheers, > Michael pgpzJjFQF3l8Z.pgp Description: PGP signature ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Post 0.7 idea: off-grid darknet!
On Monday 12 May 2008 23:28, Michael Rogers wrote: > Matthew Toseland wrote: > > Hence request priorities, so that the requests for the top blocks go over the > > UDP connections. > > Are you assuming that every sneakernet connection will be backed up by > an internet connection? No, it's merely an interesting case that will be common in a lot of less hostile, richer places (which being outside of the megacities don't have stellar bandwidth). > > > So the routing code > > could be very similar to the current code, but we would presumably have to > > store the stats in a database of some kind. > > So in other words the code would be similar, but separate? Perhaps. Some of it we'd just tune with subclasses e.g. the failure table code. > > > Again, request priorities. Maybe two completely different kinds of requests, > > fast (darknet only, no priority) and slow (can go over sneakernet or > > real-time darknet links, different sub-priorities, high latency). > > Yes, I think the code would have to be separate because the requirements > are completely different: batch operation, latency on the order of days > rather than seconds, round-trips must be minimised at all costs. A lot of our current usage is for batch operation. But you have a fair point about round-trips. > (For > example the current accept/reject negotiation would add two days per hop > in a sneakernet; token passing doesn't solve the problem because you > still need to handle loops.) True. > > So the implementations will be separate, and as Ian pointed out, so will > the applications: people won't use a system with ten-day latency for the > same purposes as a system with ten-second latency. If the > implementations and applications will both be separate, there's no > advantage that I can see to gluing the two systems together. Then why do people use Freenet for multi-day bulk downloads today? Clearly there is an overlap. Also we could handle publish/subscribe systems fairly efficiently. > > Cheers, > Michael pgpNHg0Vk4SB9.pgp Description: PGP 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
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. > > 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). > > Ian. pgpGGfTO8Sqi6.pgp Description: PGP signature ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Post-0.7.0 priorities
On Monday 12 May 2008 23:10, Michael Rogers wrote: > Victor Denisov wrote: > > Input Rate: 17.6 KiB/sec (of 300 KiB) > > Output Rate: 15.9 KiB/sec (of 200 KiB) > > Total Input: 4.83 GiB (28.3 KiB/sec) > > Total Output: 5.66 GiB (33.2 KiB/sec) > > > > Used Java memory: 122 MiB > > Allocated Java memory: 127 MiB > > Maximum Java memory: 284 MiB > > Running threads: 152/700 > > > > So, basically, network had grown about 3x after 0.7 release. My node has > > been up for 2 days, and is pretty well established in the network. It's > > not overloaded (CPU usage is ~ 5-10%). Yet it doesn't use more than > > about 15% of the allowed bandwidth, on average. > > If the average speed of a node is, say, 20 KB/s then your node's > unlikely to be able to use 300 KB/s because its peers won't be > sending/accepting enough traffic (due to their own bandwidth limits, not > yours). This could be solved by allowing fast nodes to have more peers, > but of course that creates the possibility of ubernodes. It could also be solved to a degree by a different load management scheme that allowed us more fine grained control over the degree to which ubernodes can take more requests... But a) that's probably too big a job for 0.7.1, and b) the current system seems to more or less work. > > Cheers, > Michael pgpGcHdLATgRD.pgp Description: PGP signature ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Post-0.7.0 priorities
On Monday 12 May 2008 20:19, Victor Denisov wrote: > | On Friday 09 May 2008 07:27, Victor Denisov wrote: > |> | Automatic bandwidth calibration. Other p2p apps have this, we should > |> have it. > |> > |> Good idea. Also, we should definitely look into better utilizing > |> available bandwidth. Freenet's the only p2p app which consistently > |> underutilizes my upload limit (~ 2 Mbit/s out of 8 Mbit/s of link > |> capacity). I understand that we don't want to create supernodes, but > |> come on, 2 Mbit/s is *nothing* these days. > | > | IMHO automatic bandwidth calibration will help a lot with this. Beyond > that > | we're looking at token passing, which may be too big for 0.7.1. > > Excerpt from my current node stats: > > networkSizeEstimateSession: 6039 nodes > nodeUptime: 2d1h > pInstantReject: 0,0% > uptimeAverage: 100,0% > Peer statistics > ~* Connected: 17 > ~* Backed off: 3 > ~* Seeding for: 111 > Input Rate: 17.6 KiB/sec (of 300 KiB) > Output Rate: 15.9 KiB/sec (of 200 KiB) > Total Input: 4.83 GiB (28.3 KiB/sec) > Total Output: 5.66 GiB (33.2 KiB/sec) > > Used Java memory: 122 MiB > Allocated Java memory: 127 MiB > Maximum Java memory: 284 MiB > Running threads: 152/700 > > So, basically, network had grown about 3x after 0.7 release. Great! > My node has > been up for 2 days, and is pretty well established in the network. It's > not overloaded (CPU usage is ~ 5-10%). Yet it doesn't use more than > about 15% of the allowed bandwidth, on average. Automatic bandwidth > calibration won't help - I've allowed Freenet to use much less that my > uplink allows to. I disagree. Your actual bandwidth usage is determined by how many requests the other nodes send you. This is largely determined by the *average bandwidth limit* across the whole network. If we increase the average bandwidth limit, we increase the traffic on your node. > > It could be related to the fact that I've only been able to dedicate > about 2 Gb for my store, but I doubt it. That certainly won't help. > > | Agreed, memory usage is a usability issue: the user shouldn't have to > care > | about it. > > Great that we agree on this one. I've been unsuccessful in bringing at > least two of my friends to Freenet because they were running into > memory-related problems, one of them going as far as calling Freenet > "that damn bloatware" (well, actual wording also included a couple of > pretty strong Russian expletives :-). Hehe. Consensus is good. They are specifically talking about memory/CPU here? Or bandwidth usage, total transfer in a month, etc etc? > > |> Shouldn't we consider auto-updating bundled applications as well? Or > |> perhaps providing an auto-update API for use by third-party apps? Just a > |> thought. > | > | Maybe, that would be harder though. I would be happy to discuss it > with their > | authors. > > Well, it seems more or less straightforward from the outside: handle > additional update URLs and a set of (revocable?) public keys + expose > the API over FCP. Am I missing something important? Yeah but we'd have to unpack, support post-unpack scripts, etc etc ... really we'd want the apps to provide their own unpacker and just feed them a single file for them to do what they want with? > > Regards, > Victor Denisov. pgpNEFjXe9HnW.pgp Description: PGP signature ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] [freenet-cvs] r19789 - branches/saltedhashstore/freenet/src/freenet/store
On Saturday 10 May 2008 04:10, Daniel Cheng wrote: > On Sat, May 10, 2008 at 6:24 AM, Matthew Toseland > <[EMAIL PROTECTED]> wrote: > > On Tuesday 06 May 2008 08:39, [EMAIL PROTECTED] wrote: > >> Author: j16sdiz > >> Date: 2008-05-06 07:39:43 + (Tue, 06 May 2008) > >> New Revision: 19789 > >> > >> Modified: > >> > > branches/saltedhashstore/freenet/src/freenet/store/SaltedHashFreenetStore.java > >> Log: > >> option for saving plain key (for migration) > > > > For datastore histograms? It ought to be possible to make migration possible > > without knowing the full key ... but it would require that the salt isn't > > used in crypto, or is easily reversed out... hmmm. > >> > > This code save all necessary keys to allow migrate _back_ to BDBFS. I > don't want to lost any data in this early testing stage. Ahh, okay. pgp3jfUUo1vMy.pgp Description: PGP signature ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] WoT plugin
On Monday 12 May 2008 20:05, Julien Cornuwel wrote: > [EMAIL PROTECTED] a écrit : > > When you publish a shared trust tree with 2 identities, everyone could > > easily figure > > out that this two identities are the same person. > > I wasn't thinking about sharing the same trustlist but : the first > identity publish its trustlist and others don't. What would be shared > would be the trust *tree*, ie. what identities are viewed and what are not. That might work, although it's bad if all secondary identities don't publish trust lists and most primaries do... > > > I think option 2 together should be implemented, added with the possibility to > > take over (selected) trust states from other local identities. > > > Well, that's possible and it's not really complex to implement. But that > will be more complex to use for the clients. Having an identity that > sees someone posts while another don't can be quite disapointing. That could be a pain yes. It's another reason for a user to have a completely separate UI for his or her second identity... and preferably a second personality too! :) pgpwDNvYfFoCq.pgp Description: PGP signature ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] WoT plugin
On Monday 12 May 2008 18:14, you wrote: > Hi, > > I'm having interrogations about the use of the WoT plugin and I'm > confronted to a choice : > > The plugin is able to handle multiple local identites. But do you think > it could be usefull to allow local identities to set different trust > levels on other identities. Yes, it's essential, otherwise it will be possible to identify that two local identities are the same because they publish identical trust lists. Of course, they'd have to be announced separately to maintain the illusion of separation, and then the user would have to be careful; ideally there would be two different *reading* clients as well as posting. > > Possibilities are : > > 1) One identity publish its trustlist and all local identities share the > same trust tree. > 2) Every local identity has to handle its own trust list and has its own > trust tree. That implies that one identity might see someone while > another won't. > > In my opinion, 1) would fit most uses of the plugin. Except the one > where you share your node with a person you totally disagree with (quite > unlikely, isn't it ?). > > The flaw of 2) is that every identity has to set its own trust values > for every identities. An option could be to allow the user to set a > "parent" identity that the new identity would share it's trust list with. > > What do you think ? I think you should support completely separate identities which can't be easily linked together, just as Frost did. pgpIefh6ryDqK.pgp Description: PGP signature ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] Chinese translation for dont-close-me / welcome
On Mon, May 12, 2008 at 11:08 PM, Matthew Toseland wrote: > On Sunday 11 May 2008 10:03, Daniel Cheng wrote: > > Hi, > > Here are the Chinese translation for cont-close-me and welcome.html > > Great stuff. A full chinese translation would be wonderful, however I prefer > you work on code if you can't do both... Ideally we'd like somebody else to > maintain the chinese translation... Some of the translations came from yongjhen on FMS. I will ask if he will maintain them.
[freenet-dev] Content Management System
* Ian Clarke [2008-05-12 23:04:59]: > On Mon, May 12, 2008 at 9:32 PM, Florent Daigni?re > wrote: > > I personnaly won't work on it for now. The main point against our > > current website is that it's not community-friendly... Let's see if the > > community feels involved and will contribute to the presumably > > community-friendly sandbox. > > Not sure that this makes much sense. Seems like you are saying that > unless the "community" builds up the new site so that its better than > the current site, then the "community" doesn't deserve a better > website. Hmm. To paraphrase Margaret Thatcher, "There is no such > thing as community", its all just individuals. > Heh I'm trying to make things move forward here... sorry if that sounded rude or inappropriate but yeah... I think we need external help to make any progress here. Most of the current contributors are coders and don't have good web-designing skills ... or don't want to do it. > Freenet needs a website worthy of a respectable and reasonably well > funded free software project in 2008, unfortunately it doesn't have > one right now. We all agree that the current website sucks. > Maybe Drupal is the answer, maybe not. Frankly I'm > not convinced that migrating to a CMS really solves the big problems > with the website at all. > Me neither... but Michael suggested it and no one strongly objected this time. Last time someone did suggest it I was the one who did object... and let's face it, the website hasn't evolved much since then... so presumably I might have been wrong. > Either way, its up to us to come up with a website that newbies feel > comfortable with. We've been very lucky with funding from large > donors over the years, but sooner or later that luck is going to run > out. We can't assume that when the Google donation runs out in 6 > months, we will find someone else willing to donate $10k+. We have 6 > months to build up enough of a userbase that we can get >$3k/month in > donations reliably, or we can wave goodbye to Matthew's full-time > attention. Call me a pessimist, but this project is in big trouble if > we lose Matthew. > > Having an appealing website that efficiently turns newbies into > dedicated Freenet users (and donors) isn't just some nice thing to > make us all feel better, its a requirement for the survival of the > project. 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? -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080513/93143d5b/attachment.pgp>
[freenet-dev] WoT plugin
* Julien Cornuwel [2008-05-12 19:14:06]: > Hi, > > I'm having interrogations about the use of the WoT plugin and I'm > confronted to a choice : > > The plugin is able to handle multiple local identites. But do you think > it could be usefull to allow local identities to set different trust > levels on other identities. > > Possibilities are : > > 1) One identity publish its trustlist and all local identities share the > same trust tree. > 2) Every local identity has to handle its own trust list and has its own > trust tree. That implies that one identity might see someone while > another won't. > > In my opinion, 1) would fit most uses of the plugin. Except the one > where you share your node with a person you totally disagree with (quite > unlikely, isn't it ?). > > The flaw of 2) is that every identity has to set its own trust values > for every identities. An option could be to allow the user to set a > "parent" identity that the new identity would share it's trust list with. > > > What do you think ? Go for the second option -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080513/89167f44/attachment.pgp>
[freenet-dev] Content Management System
* Michael T?nzer [2008-05-08 17:41:55]: > Florent Daigni?re schrieb: > > * Michael T?nzer [2008-05-08 05:04:07]: > 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. Okay, let's try it. I've set a drupal vhost up on emu (http://wwwtest.freenetproject.org/). Here is the deal: if it reaches the point where it's actually better than the actual website then we switch permanently... Otherwise I'll just delete it. I will grant admin access to whoever wants it... and can install modules/themes/whatever on request. We need to put some kind of deadline otherwise nothing will ever be done: what about one month? I personnaly won't work on it for now. The main point against our current website is that it's not community-friendly... Let's see if the community feels involved and will contribute to the presumably community-friendly sandbox. > 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. It seems like it's a per-page versioning... that's not what we want, is it ? -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080513/70ece08d/attachment.pgp>
[freenet-dev] Post 0.7 idea: off-grid darknet!
Evan Daniel wrote: > The major change needed would be a way to request not the specific SSK > block, but the SSK, whatever CHK it happens to redirect to, and any > CHK blocks needed to decode the result Exactly, so you'd need a different protocol, different data formats and a different routing implementation to cope with the latency - which raises the question, why use Freenet instead of building a separate network? > -- plus a way to prevent that > being a DoS attack (tit-for-tat?). How would TFT work in this context? Say Alice sends Bob a batch of requests and Bob doesn't find the data - does Alice punish Bob for black-holing the requests or does Bob punish Alice for trying to DoS him? What if Alice was only forwarding the requests for Carol? I have some ideas for DoS-resistant routing, but they're only suitable for long streams of messages between the same endpoints, and the endpoints need to share an authentication key. I'm not sure whether they could be adapted to anonymous pub/sub. Cheers, Michael
