[freenet-dev] Current uservoice top 5

[Zero3]

Matthew Toseland skrev:
>> 3. Add a 'pause' feature. (131 votes)
> Now 140 votes.
>> Remarkably high ranking, I wonder what proportion of our users use online 
>> games?

I can fix a Windows helper to do this (in the same style as the other 
helpers in the wininstaller).

Obviously this once again raises the question of whether this kind of 
stuff ought to be done cross-platform or platform specific.

In any way - if nobody finds time to make a cross-platform solution in 
the next couple of months, I offer to make a Windows solution. This will 
require the actual "pause" feature done in Freenet itself first of 
course (unless you simply want to stop the node completely instead).

- Zero3

Re: [freenet-dev] Current uservoice top 5

[Zero3]

Matthew Toseland skrev:
 3. Add a 'pause' feature. (131 votes)
 Now 140 votes.
 Remarkably high ranking, I wonder what proportion of our users use online 
 games?

I can fix a Windows helper to do this (in the same style as the other 
helpers in the wininstaller).

Obviously this once again raises the question of whether this kind of 
stuff ought to be done cross-platform or platform specific.

In any way - if nobody finds time to make a cross-platform solution in 
the next couple of months, I offer to make a Windows solution. This will 
require the actual pause feature done in Freenet itself first of 
course (unless you simply want to stop the node completely instead).

- Zero3
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Current uservoice top 5

[Matthew Toseland]

The top 5 uservoice items are still exactly the same. This might be partly 
because it's not a front page item any more, but they continue to get more 
votes.

On Monday 04 May 2009 16:33:30 Matthew Toseland wrote:
> 1. Release the 20 nodes barrier (206 votes)
Now 226 votes.
> 
> As I have mentioned IMHO this is a straightforward plea for more performance.
> 
> 2. One GUI for all. (155 votes)
Now 171 votes.
> 
> This is usability, particularly bundling more functionality. VIVE LA Freetalk!
> 
> 3. Add a 'pause' feature. (131 votes)
Now 140 votes.
> 
> Remarkably high ranking, I wonder what proportion of our users use online 
> games?
> 
> 4. Implement reinsert on demand. (79 votes)
Now 105 votes.
> 
> This is IMHO about data persistence.
> 
> 5. Use port 80,443,53,1863 for communication. (74 votes)
Now 90 votes
> 
> I have no idea how this got into the top 5! Any ideas? People trying to run 
> nodes at work perhaps?
> 
My comments before stand; users' priorities would seem to be:
- Performance.
- Usability.
- Pause feature would be very popular.
- Data persistence.
- TCP and HTTP support: apparently UDP is a problem for quite a few users!

Thus post 0.7.5, IMHO this shows we should look at:
- Pause feature. (direct request, usability)
- System tray icon to drive pause/unpause. (pause feature support, usability)
- More opennet peers for fast nodes. (Will take some tuning) (speed)
- Bulk flag. (Will take some tuning) (speed)
- More usability work. (Most of which will be done before 0.7.5) (usability)
- Freetalk. (usability)
- MHKs. (data persistence)
- Bloom filter sharing. (data persistence, speed)
- Security improvements to make Bloom filter sharing and reinsert on demand 
safer. (support for other features)
- Look into reinsert on demand in e.g. infinity0's filesharing/searching 
plugin. (data persistence, usability)
- Look into bringing forward transport plugins. (tcp/http)
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: 

Re: [freenet-dev] Current uservoice top 5

[Matthew Toseland]

The top 5 uservoice items are still exactly the same. This might be partly 
because it's not a front page item any more, but they continue to get more 
votes.

On Monday 04 May 2009 16:33:30 Matthew Toseland wrote:
 1. Release the 20 nodes barrier (206 votes)
Now 226 votes.
 
 As I have mentioned IMHO this is a straightforward plea for more performance.
 
 2. One GUI for all. (155 votes)
Now 171 votes.
 
 This is usability, particularly bundling more functionality. VIVE LA Freetalk!
 
 3. Add a 'pause' feature. (131 votes)
Now 140 votes.
 
 Remarkably high ranking, I wonder what proportion of our users use online 
 games?
 
 4. Implement reinsert on demand. (79 votes)
Now 105 votes.
 
 This is IMHO about data persistence.
 
 5. Use port 80,443,53,1863 for communication. (74 votes)
Now 90 votes
 
 I have no idea how this got into the top 5! Any ideas? People trying to run 
 nodes at work perhaps?
 
My comments before stand; users' priorities would seem to be:
- Performance.
- Usability.
- Pause feature would be very popular.
- Data persistence.
- TCP and HTTP support: apparently UDP is a problem for quite a few users!

Thus post 0.7.5, IMHO this shows we should look at:
- Pause feature. (direct request, usability)
- System tray icon to drive pause/unpause. (pause feature support, usability)
- More opennet peers for fast nodes. (Will take some tuning) (speed)
- Bulk flag. (Will take some tuning) (speed)
- More usability work. (Most of which will be done before 0.7.5) (usability)
- Freetalk. (usability)
- MHKs. (data persistence)
- Bloom filter sharing. (data persistence, speed)
- Security improvements to make Bloom filter sharing and reinsert on demand 
safer. (support for other features)
- Look into reinsert on demand in e.g. infinity0's filesharing/searching 
plugin. (data persistence, usability)
- Look into bringing forward transport plugins. (tcp/http)


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Current uservoice top 5

[Arne Babenhauserheide]

On Wednesday, 13. May 2009 19:00:54 Matthew Toseland wrote:
> We could pause most of the node relatively easily, there will still be some
> background activity, and therefore some garbage collection, but it can be
> kept minimal...

That would be great. 

As long as it doesn't access its memory very often, my system will put most of 
it to swap, so this should also free most of the memory. 

> > But I don't want to have that all the time. When I compile something in
> > the background, I want freenet to take predecence (that's already well
> > covered with the low scheduling priority, though).
>
> How would Freenet tell the difference?

When I click "pause" I want it to reduce its activity (ideally there'd be 
"take a break for X hours" instead of "pause now and stay paused", because 
else I'm prone to forget that I paused it. 

Best wishes, 
Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
   - singing a part of the history of free software -
  http://infinite-hands.draketo.de
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] Current uservoice top 5

[Matthew Toseland]

On Sunday 10 May 2009 20:50:00 Arne Babenhauserheide wrote:
> Am Mittwoch 06 Mai 2009 00:23:54 schrieb Matthew Toseland:
> > Isn't using a reasonably low scheduling priority enough? And we already do
> > that!
> 
> Not really, since I can't disable it (when I want full speed), and it sadly 
> doesn't work really well for memory consumption. 
> 
> I'd like an option to have freenet go inactive as soon as the system load 
gets 
> too high. It will lose connections anyway (low scheduling priority leads to 
> far too high answer-times), so it could just explicitely take a break until 
my 
> system runs well again. 

We could pause most of the node relatively easily, there will still be some 
background activity, and therefore some garbage collection, but it can be 
kept minimal...
> 
> But I don't want to have that all the time. When I compile something in the 
> background, I want freenet to take predecence (that's already well covered 
> with the low scheduling priority, though). 

How would Freenet tell the difference?
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: 

Re: [freenet-dev] Current uservoice top 5

[Matthew Toseland]

On Sunday 10 May 2009 20:50:00 Arne Babenhauserheide wrote:
 Am Mittwoch 06 Mai 2009 00:23:54 schrieb Matthew Toseland:
  Isn't using a reasonably low scheduling priority enough? And we already do
  that!
 
 Not really, since I can't disable it (when I want full speed), and it sadly 
 doesn't work really well for memory consumption. 
 
 I'd like an option to have freenet go inactive as soon as the system load 
gets 
 too high. It will lose connections anyway (low scheduling priority leads to 
 far too high answer-times), so it could just explicitely take a break until 
my 
 system runs well again. 

We could pause most of the node relatively easily, there will still be some 
background activity, and therefore some garbage collection, but it can be 
kept minimal...
 
 But I don't want to have that all the time. When I compile something in the 
 background, I want freenet to take predecence (that's already well covered 
 with the low scheduling priority, though). 

How would Freenet tell the difference?


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Current uservoice top 5

[Arne Babenhauserheide]

On Wednesday, 13. May 2009 19:00:54 Matthew Toseland wrote:
 We could pause most of the node relatively easily, there will still be some
 background activity, and therefore some garbage collection, but it can be
 kept minimal...

That would be great. 

As long as it doesn't access its memory very often, my system will put most of 
it to swap, so this should also free most of the memory. 

  But I don't want to have that all the time. When I compile something in
  the background, I want freenet to take predecence (that's already well
  covered with the low scheduling priority, though).

 How would Freenet tell the difference?

When I click pause I want it to reduce its activity (ideally there'd be 
take a break for X hours instead of pause now and stay paused, because 
else I'm prone to forget that I paused it. 

Best wishes, 
Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
   - singing a part of the history of free software -
  http://infinite-hands.draketo.de


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Current uservoice top 5

[Robert Hailey]

On May 10, 2009, at 2:50 PM, Arne Babenhauserheide wrote:

> Am Mittwoch 06 Mai 2009 00:23:54 schrieb Matthew Toseland:
>> Isn't using a reasonably low scheduling priority enough? And we  
>> already do
>> that!
>
> Not really, since I can't disable it (when I want full speed), and  
> it sadly
> doesn't work really well for memory consumption.
>
> I'd like an option to have freenet go inactive as soon as the system  
> load gets
> too high. It will lose connections anyway (low scheduling priority  
> leads to
> far too high answer-times), so it could just explicitely take a  
> break until my
> system runs well again.
>
> But I don't want to have that all the time. When I compile something  
> in the
> background, I want freenet to take predecence (that's already well  
> covered
> with the low scheduling priority, though).
>
> Best wishes,
> Arne

AFAIK this is a common design in other systems. Sendmail, for example,  
will not accept any network connections if the system's load is over  
some constant.

I suppose the real issue would be detecting that in a platform- 
independent way (i.e. adding more JNI???).

--
Robert Hailey

Re: [freenet-dev] Current uservoice top 5

[Robert Hailey]

On May 10, 2009, at 2:50 PM, Arne Babenhauserheide wrote:

 Am Mittwoch 06 Mai 2009 00:23:54 schrieb Matthew Toseland:
 Isn't using a reasonably low scheduling priority enough? And we  
 already do
 that!

 Not really, since I can't disable it (when I want full speed), and  
 it sadly
 doesn't work really well for memory consumption.

 I'd like an option to have freenet go inactive as soon as the system  
 load gets
 too high. It will lose connections anyway (low scheduling priority  
 leads to
 far too high answer-times), so it could just explicitely take a  
 break until my
 system runs well again.

 But I don't want to have that all the time. When I compile something  
 in the
 background, I want freenet to take predecence (that's already well  
 covered
 with the low scheduling priority, though).

 Best wishes,
 Arne

AFAIK this is a common design in other systems. Sendmail, for example,  
will not accept any network connections if the system's load is over  
some constant.

I suppose the real issue would be detecting that in a platform- 
independent way (i.e. adding more JNI???).

--
Robert Hailey

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

Re: [freenet-dev] Current uservoice top 5

[Matthew Toseland]

On Monday 11 May 2009 16:50:44 Robert Hailey wrote:
 
 On May 10, 2009, at 2:50 PM, Arne Babenhauserheide wrote:
 
  Am Mittwoch 06 Mai 2009 00:23:54 schrieb Matthew Toseland:
  Isn't using a reasonably low scheduling priority enough? And we  
  already do
  that!
 
  Not really, since I can't disable it (when I want full speed), and  
  it sadly
  doesn't work really well for memory consumption.
 
  I'd like an option to have freenet go inactive as soon as the system  
  load gets
  too high. It will lose connections anyway (low scheduling priority  
  leads to
  far too high answer-times), so it could just explicitely take a  
  break until my
  system runs well again.

On Windows, it may not get enough CPU time even to do a graceful shutdown. If 
you start a game, or anything else that runs at higher priority, and uses all 
available cores, Freenet will not get scheduled at all, except maybe when the 
other task is waiting for I/O.
 
  But I don't want to have that all the time. When I compile something  
  in the
  background, I want freenet to take predecence (that's already well  
  covered
  with the low scheduling priority, though).
 
  Best wishes,
  Arne
 
 AFAIK this is a common design in other systems. Sendmail, for example,  
 will not accept any network connections if the system's load is over  
 some constant.

Partly because it forks each time...
 
 I suppose the real issue would be detecting that in a platform- 
 independent way (i.e. adding more JNI???).

Exactly, sendmail isn't cross platform.


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Current uservoice top 5

[Arne Babenhauserheide]

Am Mittwoch 06 Mai 2009 00:23:54 schrieb Matthew Toseland:
> Isn't using a reasonably low scheduling priority enough? And we already do
> that!

Not really, since I can't disable it (when I want full speed), and it sadly 
doesn't work really well for memory consumption. 

I'd like an option to have freenet go inactive as soon as the system load gets 
too high. It will lose connections anyway (low scheduling priority leads to 
far too high answer-times), so it could just explicitely take a break until my 
system runs well again. 

But I don't want to have that all the time. When I compile something in the 
background, I want freenet to take predecence (that's already well covered 
with the low scheduling priority, though). 

Best wishes, 
Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
   - singing a part of the history of free software -
  http://infinite-hands.draketo.de


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

Re: [freenet-dev] Current uservoice top 5

[Arne Babenhauserheide]

Am Mittwoch 06 Mai 2009 00:23:54 schrieb Matthew Toseland:
 Isn't using a reasonably low scheduling priority enough? And we already do
 that!

Not really, since I can't disable it (when I want full speed), and it sadly 
doesn't work really well for memory consumption. 

I'd like an option to have freenet go inactive as soon as the system load gets 
too high. It will lose connections anyway (low scheduling priority leads to 
far too high answer-times), so it could just explicitely take a break until my 
system runs well again. 

But I don't want to have that all the time. When I compile something in the 
background, I want freenet to take predecence (that's already well covered 
with the low scheduling priority, though). 

Best wishes, 
Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
   - singing a part of the history of free software -
  http://infinite-hands.draketo.de




signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Current uservoice top 5

[Matthew Toseland]

On Tuesday 05 May 2009 18:05:22 Robert Hailey wrote:
> 
> On May 4, 2009, at 11:29 AM, Evan Daniel wrote:
> 
> > On Mon, May 4, 2009 at 11:33 AM, Matthew Toseland
> >  wrote:
> >> 1. Release the 20 nodes barrier (206 votes)
> >>
> >> As I have mentioned IMHO this is a straightforward plea for more  
> >> performance.
> >
> > I'll reiterate a point I've made before.
> >
> > While this represents a simple plea for performance, I don't think
> > it's an irrational one -- that is, I think the overall network
> > performance is hampered by having all nodes have the same number of
> > connections.
> >
> > Because all connections use similar amounts of bandwidth, the network
> > speed is limited by the slower nodes.  This is true regardless of the
> > absolute number of connections; raising the maximum for fast nodes
> > should have a very similar effect to lowering it for slow nodes.  What
> > matters is that slow nodes have fewer connections than fast nodes.
> 
> I'm not saying that it's wrong, but the 20 node barrier is a bit  
> arbitrary... we find ourselves talking about performance, bandwidth,  
> and a constant.
> 
> I could see a bandwidth-limited node totally choking with only a few  
> connections, and certainly even an 'uber-node'/unlimited bandwidth  
> would reach a point where adding extra peers would be of no benefit.
> 
> Perhaps there are even just a minority of nodes on the network that  
> are actually making it slow (seeing that a request may travel through  
> ~20 nodes). Is it possible that some nodes have too many peers for  
> there bandwidth setting? would it make a difference?

If so, it's a bug: if they are a minority they should simply get backed off.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] Current uservoice top 5

[Matthew Toseland]

On Tuesday 05 May 2009 07:16:36 Arne Babenhauserheide wrote:
> Am Montag 04 Mai 2009 19:59:15 schrieb Arne Babenhauserheide:
> > Am Montag 04 Mai 2009 17:33:30 schrieb Matthew Toseland:
> > > 3. Add a 'pause' feature. (131 votes)
> > >
> > > Remarkably high ranking, I wonder what proportion of our users use 
online
> > > games?
> >
> > Or with other filesharing services (short lived torrents, downloading in
> > Gnutella) or with graphics editing or video editing or just plain 
compiling
> > the new packages or haggling with a completely overloaded E-Mail 
program...
> 
> I just thought about this the other way round: When do I want freenet to use 
> my full CPU power? 
> 
> I got to 
> 
> 1) When I do something which doesn't need much resources, for example 
writing 
> or coding. 
> 
> 2) When I browse freenet myself. 
> 
> 3) When I'm not at my computer and no compiles are running. 
> 
> So a nicer solution might be to have 
> 
> a) a hard pause: stop hard until disabled again, and 
> 
> b) a soft pause: only use less resources while the user is active - except 
if 
> he's firing off manual freenet requests (webinterface). 
> 
> The soft pause could for example use a screensaver as seti at home does to 
detect 
> inactivity. 
> 
> The modes could even be turned around: Soft pause as default mode, so 
freenet 
> is only active while my computer has little other load. 
> 
> The problem with soft pause as default mode could be that users who shut 
down 
> their computers as soon as they leave them would contribute little to the 
> computer, so I think we can discard it. If someone wants it, he should have 
to 
> enable it everytime he starts freenet - with this it's only viable for long 
> running nodes. 

Isn't using a reasonably low scheduling priority enough? And we already do 
that!
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] Current uservoice top 5

[Matthew Toseland]

On Tuesday 05 May 2009 05:19:35 Evan Daniel wrote:
> On Mon, May 4, 2009 at 6:15 PM, Matthew Toseland
>  wrote:
> > On Monday 04 May 2009 17:29:51 Evan Daniel wrote:
> >> On Mon, May 4, 2009 at 11:33 AM, Matthew Toseland
> >>  wrote:
> >> > 1. Release the 20 nodes barrier (206 votes)
> >> >
> >> > As I have mentioned IMHO this is a straightforward plea for more
> > performance.
> >>
> >> I'll reiterate a point I've made before.
> >>
> >> While this represents a simple plea for performance, I don't think
> >> it's an irrational one -- that is, I think the overall network
> >> performance is hampered by having all nodes have the same number of
> >> connections.
> >>
> >> Because all connections use similar amounts of bandwidth, the network
> >> speed is limited by the slower nodes. ?This is true regardless of the
> >> absolute number of connections; raising the maximum for fast nodes
> >> should have a very similar effect to lowering it for slow nodes. ?What
> >> matters is that slow nodes have fewer connections than fast nodes.
> >>
> >> For example, the max allowed connections (and default setting) could
> >> be 1 connection per 2KiB/s output bandwidth, but never more than 20 or
> >> less than 15.
> >
> > What would the point be? Don't we need a significant range for it to make 
much
> > difference?
> 
> If the network is in fact limited by the per-connection speed of the
> slower nodes, and they are in fact a minority of the network,
> increasing the per-connection bandwidth of the slower nodes by 33%
> should result in a throughput increase for most of the rest of the
> network of a similar magnitude.  A performance improvement of 10-30%
> should be easily measurable, and (at the high end of that) noticeable
> enough to be appreciated by most users.

Well, it *shouldn't* be limited by the slowest nodes, because they should get 
backed off. And I dunno if 30% is measurable - the signal is incredibly 
noisy. I'd hope it would be.
> 
> Really, though, the idea would be to use it as a network-wide test.
> Small tests by a few users are helpful, but not nearly as informative
> as a network-wide test.  Assuming the change produced measurable
> improvement, it would make sense to explore further changes.  For
> example, changing the range to 15-30, or increasing the per-connection
> bandwidth requirement, or making the per-connection requirement
> nonlinear, or some other option.  However, security concerns
> (especially ubernodes) are bigger with more dramatic changes.

Yes, but manageable imho. The interaction with FOAF throws up additional 
security challenges, but the per-node request proportion limit should deal 
with this adequately, no?
> 
> >> Those numbers are based on some (very limited) testing
> >> I've done -- if I reduce the allowed bw, that is the approximate
> >> number of connections required to make full use of it.
> >>
> >> Reducing the number of connections for slow nodes has some additional
> >> benefits. ?First, my limited testing shows a slight increase in
> >> payload % at low bw limits as a result of reducing the connection
> >> count (there is some per-connection network overhead).
> >
> > True.
> 
> To be specific, my anecdotal evidence is that it improves the payload
> fraction by roughly 3-8%.

Yes but a 10KB/sec opennet node with 10 peers is noticeably slower than a 
10KB/sec opennet node with 20, no? We should find out.
> 
> >
> >> Second, bloom
> >> filter sharing represents a per-connection overhead (mostly in the
> >> initial transfer -- updates are low bw, as discussed). ?If (when?)
> >> implemented, it will represent a smaller total overhead with fewer
> >> connections than with more. ?Presumably, the greatest impact is on
> >> slower nodes.
> >
> > Really it's determined by churn, isn't it? Or by any heuristic artificial
> > limits we impose...
> 
> My assumption is that connection duration is well modeled by a
> per-connection half-life, that is largely independent of the number of
> connections.  The bandwidth used on such filters is proportional to
> the total churn, so fewer connections means less churn in absolute
> sense but the same connection half-life.  (That is, bloom filter
> bandwidth usage is proportional to # of connections * per-connection
> churn rate.)  I don't have any evidence for that assumption, though.

Isn't the churn rate proportional to the number of requests handled more than 
the number of connections? Fewer connections might even mean more churn?
> 
> >> On the other hand, too few connections may make various attacks
> >> easier. ?I have no idea how strong an effect this is. ?However, a node
> >> that has too many connections (ie insufficient bw to use them all
> >> fully) may show burstier behavior and thus be more susceptible to
> >> traffic analysis.
> >
> > Yes, definitely true with our current padding algorithms.
> >
> >> In addition, fewer connections means a larger
> >> network diameter on average, which may have an impact on routing.
> >> 

[freenet-dev] Current uservoice top 5

[Robert Hailey]

On May 4, 2009, at 11:29 AM, Evan Daniel wrote:

> On Mon, May 4, 2009 at 11:33 AM, Matthew Toseland
>  wrote:
>> 1. Release the 20 nodes barrier (206 votes)
>>
>> As I have mentioned IMHO this is a straightforward plea for more  
>> performance.
>
> I'll reiterate a point I've made before.
>
> While this represents a simple plea for performance, I don't think
> it's an irrational one -- that is, I think the overall network
> performance is hampered by having all nodes have the same number of
> connections.
>
> Because all connections use similar amounts of bandwidth, the network
> speed is limited by the slower nodes.  This is true regardless of the
> absolute number of connections; raising the maximum for fast nodes
> should have a very similar effect to lowering it for slow nodes.  What
> matters is that slow nodes have fewer connections than fast nodes.

I'm not saying that it's wrong, but the 20 node barrier is a bit  
arbitrary... we find ourselves talking about performance, bandwidth,  
and a constant.

I could see a bandwidth-limited node totally choking with only a few  
connections, and certainly even an 'uber-node'/unlimited bandwidth  
would reach a point where adding extra peers would be of no benefit.

Perhaps there are even just a minority of nodes on the network that  
are actually making it slow (seeing that a request may travel through  
~20 nodes). Is it possible that some nodes have too many peers for  
there bandwidth setting? would it make a difference?

--
Robert Hailey

-- next part --
An HTML attachment was scrubbed...
URL: 

[freenet-dev] Current uservoice top 5

[Arne Babenhauserheide]

Am Montag 04 Mai 2009 19:59:15 schrieb Arne Babenhauserheide:
> Am Montag 04 Mai 2009 17:33:30 schrieb Matthew Toseland:
> > 3. Add a 'pause' feature. (131 votes)
> >
> > Remarkably high ranking, I wonder what proportion of our users use online
> > games?
>
> Or with other filesharing services (short lived torrents, downloading in
> Gnutella) or with graphics editing or video editing or just plain compiling
> the new packages or haggling with a completely overloaded E-Mail program...

I just thought about this the other way round: When do I want freenet to use 
my full CPU power? 

I got to 

1) When I do something which doesn't need much resources, for example writing 
or coding. 

2) When I browse freenet myself. 

3) When I'm not at my computer and no compiles are running. 

So a nicer solution might be to have 

a) a hard pause: stop hard until disabled again, and 

b) a soft pause: only use less resources while the user is active - except if 
he's firing off manual freenet requests (webinterface). 

The soft pause could for example use a screensaver as seti at home does to 
detect 
inactivity. 

The modes could even be turned around: Soft pause as default mode, so freenet 
is only active while my computer has little other load. 

The problem with soft pause as default mode could be that users who shut down 
their computers as soon as they leave them would contribute little to the 
computer, so I think we can discard it. If someone wants it, he should have to 
enable it everytime he starts freenet - with this it's only viable for long 
running nodes. 

Best wishes, 
Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
   - singing a part of the history of free software -
  http://infinite-hands.draketo.de
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] Current uservoice top 5

[Evan Daniel]

On Mon, May 4, 2009 at 6:15 PM, Matthew Toseland
 wrote:
> On Monday 04 May 2009 17:29:51 Evan Daniel wrote:
>> On Mon, May 4, 2009 at 11:33 AM, Matthew Toseland
>>  wrote:
>> > 1. Release the 20 nodes barrier (206 votes)
>> >
>> > As I have mentioned IMHO this is a straightforward plea for more
> performance.
>>
>> I'll reiterate a point I've made before.
>>
>> While this represents a simple plea for performance, I don't think
>> it's an irrational one -- that is, I think the overall network
>> performance is hampered by having all nodes have the same number of
>> connections.
>>
>> Because all connections use similar amounts of bandwidth, the network
>> speed is limited by the slower nodes. ?This is true regardless of the
>> absolute number of connections; raising the maximum for fast nodes
>> should have a very similar effect to lowering it for slow nodes. ?What
>> matters is that slow nodes have fewer connections than fast nodes.
>>
>> For example, the max allowed connections (and default setting) could
>> be 1 connection per 2KiB/s output bandwidth, but never more than 20 or
>> less than 15.
>
> What would the point be? Don't we need a significant range for it to make much
> difference?

If the network is in fact limited by the per-connection speed of the
slower nodes, and they are in fact a minority of the network,
increasing the per-connection bandwidth of the slower nodes by 33%
should result in a throughput increase for most of the rest of the
network of a similar magnitude.  A performance improvement of 10-30%
should be easily measurable, and (at the high end of that) noticeable
enough to be appreciated by most users.

Really, though, the idea would be to use it as a network-wide test.
Small tests by a few users are helpful, but not nearly as informative
as a network-wide test.  Assuming the change produced measurable
improvement, it would make sense to explore further changes.  For
example, changing the range to 15-30, or increasing the per-connection
bandwidth requirement, or making the per-connection requirement
nonlinear, or some other option.  However, security concerns
(especially ubernodes) are bigger with more dramatic changes.

>
>> Those numbers are based on some (very limited) testing
>> I've done -- if I reduce the allowed bw, that is the approximate
>> number of connections required to make full use of it.
>>
>> Reducing the number of connections for slow nodes has some additional
>> benefits. ?First, my limited testing shows a slight increase in
>> payload % at low bw limits as a result of reducing the connection
>> count (there is some per-connection network overhead).
>
> True.

To be specific, my anecdotal evidence is that it improves the payload
fraction by roughly 3-8%.

>
>> Second, bloom
>> filter sharing represents a per-connection overhead (mostly in the
>> initial transfer -- updates are low bw, as discussed). ?If (when?)
>> implemented, it will represent a smaller total overhead with fewer
>> connections than with more. ?Presumably, the greatest impact is on
>> slower nodes.
>
> Really it's determined by churn, isn't it? Or by any heuristic artificial
> limits we impose...

My assumption is that connection duration is well modeled by a
per-connection half-life, that is largely independent of the number of
connections.  The bandwidth used on such filters is proportional to
the total churn, so fewer connections means less churn in absolute
sense but the same connection half-life.  (That is, bloom filter
bandwidth usage is proportional to # of connections * per-connection
churn rate.)  I don't have any evidence for that assumption, though.

>>
>> On the other hand, too few connections may make various attacks
>> easier. ?I have no idea how strong an effect this is. ?However, a node
>> that has too many connections (ie insufficient bw to use them all
>> fully) may show burstier behavior and thus be more susceptible to
>> traffic analysis.
>
> Yes, definitely true with our current padding algorithms.
>
>> In addition, fewer connections means a larger
>> network diameter on average, which may have an impact on routing.
>> Lower degree also means that the node has fewer neighbor bloom filters
>> to check, which means that a request is compared against fewer stores
>> during its traversal of the network.
>
> True.

Do you know how big a problem this would cause?  My assumption is that
it would be a fairly small effect even on the nodes with fewer
connections, and that they would be in the minority.

>>
>> I'm intentionally suggesting a small change -- it's less likely to
>> cause major problems. ?By keeping the ratio between slow nodes (15
>> connections) and fast nodes (20 connections) modest, the potential for
>> reliance on ubernodes is kept minimal. ?(Similarly, if you want to
>> raise the 20 connections limit instead of lower it, I think it should
>> only be increased slightly.)
>
> Why? I don't see the point unless the upper bound is significantly higher than
> the lower 

[freenet-dev] Current uservoice top 5

[Matthew Toseland]

On Monday 04 May 2009 17:29:51 Evan Daniel wrote:
> On Mon, May 4, 2009 at 11:33 AM, Matthew Toseland
>  wrote:
> > 1. Release the 20 nodes barrier (206 votes)
> >
> > As I have mentioned IMHO this is a straightforward plea for more 
performance.
> 
> I'll reiterate a point I've made before.
> 
> While this represents a simple plea for performance, I don't think
> it's an irrational one -- that is, I think the overall network
> performance is hampered by having all nodes have the same number of
> connections.
> 
> Because all connections use similar amounts of bandwidth, the network
> speed is limited by the slower nodes.  This is true regardless of the
> absolute number of connections; raising the maximum for fast nodes
> should have a very similar effect to lowering it for slow nodes.  What
> matters is that slow nodes have fewer connections than fast nodes.
> 
> For example, the max allowed connections (and default setting) could
> be 1 connection per 2KiB/s output bandwidth, but never more than 20 or
> less than 15.  

What would the point be? Don't we need a significant range for it to make much 
difference?

> Those numbers are based on some (very limited) testing 
> I've done -- if I reduce the allowed bw, that is the approximate
> number of connections required to make full use of it.
> 
> Reducing the number of connections for slow nodes has some additional
> benefits.  First, my limited testing shows a slight increase in
> payload % at low bw limits as a result of reducing the connection
> count (there is some per-connection network overhead).  

True.

> Second, bloom 
> filter sharing represents a per-connection overhead (mostly in the
> initial transfer -- updates are low bw, as discussed).  If (when?)
> implemented, it will represent a smaller total overhead with fewer
> connections than with more.  Presumably, the greatest impact is on
> slower nodes.

Really it's determined by churn, isn't it? Or by any heuristic artificial 
limits we impose...
> 
> On the other hand, too few connections may make various attacks
> easier.  I have no idea how strong an effect this is.  However, a node
> that has too many connections (ie insufficient bw to use them all
> fully) may show burstier behavior and thus be more susceptible to
> traffic analysis.  

Yes, definitely true with our current padding algorithms.

> In addition, fewer connections means a larger 
> network diameter on average, which may have an impact on routing.
> Lower degree also means that the node has fewer neighbor bloom filters
> to check, which means that a request is compared against fewer stores
> during its traversal of the network.

True.
> 
> I'm intentionally suggesting a small change -- it's less likely to
> cause major problems.  By keeping the ratio between slow nodes (15
> connections) and fast nodes (20 connections) modest, the potential for
> reliance on ubernodes is kept minimal.  (Similarly, if you want to
> raise the 20 connections limit instead of lower it, I think it should
> only be increased slightly.)

Why? I don't see the point unless the upper bound is significantly higher than 
the lower bound: any improvement won't be measurable.
> 
> And finally: I have done some testing on this proposed change.  At
> first glance, it looks like it doesn't hurt and may help.  However, I
> have not done enough testing to be able to say anything with
> confidence.  I'm not suggesting to implement this change immediately;
> rather, I'm saying that *any* change like this should see some
> real-world testing before implementation, and that reducing the
> defaults for slow nodes is as worthy of consideration and testing as
> raising it for fast nodes.

We did try this (with a minimum of 10 connections), and it seemed that slow 
nodes with only 10 connections were significantly slower. However, this was 
not based on widespread testing. My worry is that slow nodes with few 
connections will be *too* slow, and the network will marginalise them. But 
it's a tradeoff between slightly more efficiency, fewer routes to choose 
from, and fewer nodes sending requests...
> 
> Also: do we have any idea what the distribution of available node
> bandwidth looks like?

It would be great, wouldn't it? Maybe a survey? What questions should we ask?
> 
> Evan Daniel
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: 

Re: [freenet-dev] Current uservoice top 5

[Arne Babenhauserheide]

Am Montag 04 Mai 2009 19:59:15 schrieb Arne Babenhauserheide:
 Am Montag 04 Mai 2009 17:33:30 schrieb Matthew Toseland:
  3. Add a 'pause' feature. (131 votes)
 
  Remarkably high ranking, I wonder what proportion of our users use online
  games?

 Or with other filesharing services (short lived torrents, downloading in
 Gnutella) or with graphics editing or video editing or just plain compiling
 the new packages or haggling with a completely overloaded E-Mail program...

I just thought about this the other way round: When do I want freenet to use 
my full CPU power? 

I got to 

1) When I do something which doesn't need much resources, for example writing 
or coding. 

2) When I browse freenet myself. 

3) When I'm not at my computer and no compiles are running. 

So a nicer solution might be to have 

a) a hard pause: stop hard until disabled again, and 

b) a soft pause: only use less resources while the user is active - except if 
he's firing off manual freenet requests (webinterface). 

The soft pause could for example use a screensaver as s...@home does to detect 
inactivity. 

The modes could even be turned around: Soft pause as default mode, so freenet 
is only active while my computer has little other load. 

The problem with soft pause as default mode could be that users who shut down 
their computers as soon as they leave them would contribute little to the 
computer, so I think we can discard it. If someone wants it, he should have to 
enable it everytime he starts freenet - with this it's only viable for long 
running nodes. 

Best wishes, 
Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
   - singing a part of the history of free software -
  http://infinite-hands.draketo.de


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Current uservoice top 5

[Matthew Toseland]

On Tuesday 05 May 2009 05:19:35 Evan Daniel wrote:
 On Mon, May 4, 2009 at 6:15 PM, Matthew Toseland
 t...@amphibian.dyndns.org wrote:
  On Monday 04 May 2009 17:29:51 Evan Daniel wrote:
  On Mon, May 4, 2009 at 11:33 AM, Matthew Toseland
  t...@amphibian.dyndns.org wrote:
   1. Release the 20 nodes barrier (206 votes)
  
   As I have mentioned IMHO this is a straightforward plea for more
  performance.
 
  I'll reiterate a point I've made before.
 
  While this represents a simple plea for performance, I don't think
  it's an irrational one -- that is, I think the overall network
  performance is hampered by having all nodes have the same number of
  connections.
 
  Because all connections use similar amounts of bandwidth, the network
  speed is limited by the slower nodes.  This is true regardless of the
  absolute number of connections; raising the maximum for fast nodes
  should have a very similar effect to lowering it for slow nodes.  What
  matters is that slow nodes have fewer connections than fast nodes.
 
  For example, the max allowed connections (and default setting) could
  be 1 connection per 2KiB/s output bandwidth, but never more than 20 or
  less than 15.
 
  What would the point be? Don't we need a significant range for it to make 
much
  difference?
 
 If the network is in fact limited by the per-connection speed of the
 slower nodes, and they are in fact a minority of the network,
 increasing the per-connection bandwidth of the slower nodes by 33%
 should result in a throughput increase for most of the rest of the
 network of a similar magnitude.  A performance improvement of 10-30%
 should be easily measurable, and (at the high end of that) noticeable
 enough to be appreciated by most users.

Well, it *shouldn't* be limited by the slowest nodes, because they should get 
backed off. And I dunno if 30% is measurable - the signal is incredibly 
noisy. I'd hope it would be.
 
 Really, though, the idea would be to use it as a network-wide test.
 Small tests by a few users are helpful, but not nearly as informative
 as a network-wide test.  Assuming the change produced measurable
 improvement, it would make sense to explore further changes.  For
 example, changing the range to 15-30, or increasing the per-connection
 bandwidth requirement, or making the per-connection requirement
 nonlinear, or some other option.  However, security concerns
 (especially ubernodes) are bigger with more dramatic changes.

Yes, but manageable imho. The interaction with FOAF throws up additional 
security challenges, but the per-node request proportion limit should deal 
with this adequately, no?
 
  Those numbers are based on some (very limited) testing
  I've done -- if I reduce the allowed bw, that is the approximate
  number of connections required to make full use of it.
 
  Reducing the number of connections for slow nodes has some additional
  benefits.  First, my limited testing shows a slight increase in
  payload % at low bw limits as a result of reducing the connection
  count (there is some per-connection network overhead).
 
  True.
 
 To be specific, my anecdotal evidence is that it improves the payload
 fraction by roughly 3-8%.

Yes but a 10KB/sec opennet node with 10 peers is noticeably slower than a 
10KB/sec opennet node with 20, no? We should find out.
 
 
  Second, bloom
  filter sharing represents a per-connection overhead (mostly in the
  initial transfer -- updates are low bw, as discussed).  If (when?)
  implemented, it will represent a smaller total overhead with fewer
  connections than with more.  Presumably, the greatest impact is on
  slower nodes.
 
  Really it's determined by churn, isn't it? Or by any heuristic artificial
  limits we impose...
 
 My assumption is that connection duration is well modeled by a
 per-connection half-life, that is largely independent of the number of
 connections.  The bandwidth used on such filters is proportional to
 the total churn, so fewer connections means less churn in absolute
 sense but the same connection half-life.  (That is, bloom filter
 bandwidth usage is proportional to # of connections * per-connection
 churn rate.)  I don't have any evidence for that assumption, though.

Isn't the churn rate proportional to the number of requests handled more than 
the number of connections? Fewer connections might even mean more churn?
 
  On the other hand, too few connections may make various attacks
  easier.  I have no idea how strong an effect this is.  However, a node
  that has too many connections (ie insufficient bw to use them all
  fully) may show burstier behavior and thus be more susceptible to
  traffic analysis.
 
  Yes, definitely true with our current padding algorithms.
 
  In addition, fewer connections means a larger
  network diameter on average, which may have an impact on routing.
  Lower degree also means that the node has fewer neighbor bloom filters
  to check, which means that a request is compared against fewer stores
  

Re: [freenet-dev] Current uservoice top 5

[Robert Hailey]

On May 4, 2009, at 11:29 AM, Evan Daniel wrote:


On Mon, May 4, 2009 at 11:33 AM, Matthew Toseland
t...@amphibian.dyndns.org wrote:

1. Release the 20 nodes barrier (206 votes)

As I have mentioned IMHO this is a straightforward plea for more  
performance.


I'll reiterate a point I've made before.

While this represents a simple plea for performance, I don't think
it's an irrational one -- that is, I think the overall network
performance is hampered by having all nodes have the same number of
connections.

Because all connections use similar amounts of bandwidth, the network
speed is limited by the slower nodes.  This is true regardless of the
absolute number of connections; raising the maximum for fast nodes
should have a very similar effect to lowering it for slow nodes.  What
matters is that slow nodes have fewer connections than fast nodes.


I'm not saying that it's wrong, but the 20 node barrier is a bit  
arbitrary... we find ourselves talking about performance, bandwidth,  
and a constant.


I could see a bandwidth-limited node totally choking with only a few  
connections, and certainly even an 'uber-node'/unlimited bandwidth  
would reach a point where adding extra peers would be of no benefit.


Perhaps there are even just a minority of nodes on the network that  
are actually making it slow (seeing that a request may travel through  
~20 nodes). Is it possible that some nodes have too many peers for  
there bandwidth setting? would it make a difference?


--
Robert Hailey

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

Re: [freenet-dev] Current uservoice top 5

[Matthew Toseland]

On Tuesday 05 May 2009 07:16:36 Arne Babenhauserheide wrote:
 Am Montag 04 Mai 2009 19:59:15 schrieb Arne Babenhauserheide:
  Am Montag 04 Mai 2009 17:33:30 schrieb Matthew Toseland:
   3. Add a 'pause' feature. (131 votes)
  
   Remarkably high ranking, I wonder what proportion of our users use 
online
   games?
 
  Or with other filesharing services (short lived torrents, downloading in
  Gnutella) or with graphics editing or video editing or just plain 
compiling
  the new packages or haggling with a completely overloaded E-Mail 
program...
 
 I just thought about this the other way round: When do I want freenet to use 
 my full CPU power? 
 
 I got to 
 
 1) When I do something which doesn't need much resources, for example 
writing 
 or coding. 
 
 2) When I browse freenet myself. 
 
 3) When I'm not at my computer and no compiles are running. 
 
 So a nicer solution might be to have 
 
 a) a hard pause: stop hard until disabled again, and 
 
 b) a soft pause: only use less resources while the user is active - except 
if 
 he's firing off manual freenet requests (webinterface). 
 
 The soft pause could for example use a screensaver as s...@home does to 
detect 
 inactivity. 
 
 The modes could even be turned around: Soft pause as default mode, so 
freenet 
 is only active while my computer has little other load. 
 
 The problem with soft pause as default mode could be that users who shut 
down 
 their computers as soon as they leave them would contribute little to the 
 computer, so I think we can discard it. If someone wants it, he should have 
to 
 enable it everytime he starts freenet - with this it's only viable for long 
 running nodes. 

Isn't using a reasonably low scheduling priority enough? And we already do 
that!


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Current uservoice top 5

[Matthew Toseland]

On Tuesday 05 May 2009 18:05:22 Robert Hailey wrote:
 
 On May 4, 2009, at 11:29 AM, Evan Daniel wrote:
 
  On Mon, May 4, 2009 at 11:33 AM, Matthew Toseland
  t...@amphibian.dyndns.org wrote:
  1. Release the 20 nodes barrier (206 votes)
 
  As I have mentioned IMHO this is a straightforward plea for more  
  performance.
 
  I'll reiterate a point I've made before.
 
  While this represents a simple plea for performance, I don't think
  it's an irrational one -- that is, I think the overall network
  performance is hampered by having all nodes have the same number of
  connections.
 
  Because all connections use similar amounts of bandwidth, the network
  speed is limited by the slower nodes.  This is true regardless of the
  absolute number of connections; raising the maximum for fast nodes
  should have a very similar effect to lowering it for slow nodes.  What
  matters is that slow nodes have fewer connections than fast nodes.
 
 I'm not saying that it's wrong, but the 20 node barrier is a bit  
 arbitrary... we find ourselves talking about performance, bandwidth,  
 and a constant.
 
 I could see a bandwidth-limited node totally choking with only a few  
 connections, and certainly even an 'uber-node'/unlimited bandwidth  
 would reach a point where adding extra peers would be of no benefit.
 
 Perhaps there are even just a minority of nodes on the network that  
 are actually making it slow (seeing that a request may travel through  
 ~20 nodes). Is it possible that some nodes have too many peers for  
 there bandwidth setting? would it make a difference?

If so, it's a bug: if they are a minority they should simply get backed off.


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Current uservoice top 5

[Thomas Sachau]

Matthew Toseland schrieb:
> 1. Release the 20 nodes barrier (206 votes)
> 
> As I have mentioned IMHO this is a straightforward plea for more performance.
> 
> 2. One GUI for all. (155 votes)
> 
> This is usability, particularly bundling more functionality. VIVE LA Freetalk!
> 
> 3. Add a 'pause' feature. (131 votes)
> 
> Remarkably high ranking, I wonder what proportion of our users use online 
> games?
> 
> 4. Implement reinsert on demand. (79 votes)
> 
> This is IMHO about data persistence.
> 
> 5. Use port 80,443,53,1863 for communication. (74 votes)
> 
> I have no idea how this got into the top 5! Any ideas? People trying to run 
> nodes at work perhaps?

The last one may be because of censorship fearing. I have heard at least 1 
report about an ISP
blocking almost all UDP traffic, allowing only port 53. The user was forced to 
use port 53(udp) to
be able to use freenet.


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 315 bytes
Desc: OpenPGP digital signature
URL: 

[freenet-dev] Current uservoice top 5

[Arne Babenhauserheide]

Am Montag 04 Mai 2009 17:33:30 schrieb Matthew Toseland:
> 5. Use port 80,443,53,1863 for communication. (74 votes)
>
> I have no idea how this got into the top 5! Any ideas? People trying to run
> nodes at work perhaps?

Maybe not wanting the provider to be able to just shut down nonstandard ports 
and block freenet that way. 

ISPs can block freenet ports, but shouldn't really block 80 - at least for 
outgoing connections. 

Maybe running it on a server. 

Best wishes, 
Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
   - singing a part of the history of free software -
  http://infinite-hands.draketo.de
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] Current uservoice top 5

[Arne Babenhauserheide]

Am Montag 04 Mai 2009 17:33:30 schrieb Matthew Toseland:
> 3. Add a 'pause' feature. (131 votes)
>
> Remarkably high ranking, I wonder what proportion of our users use online
> games?

Or with other filesharing services (short lived torrents, downloading in 
Gnutella) or with graphics editing or video editing or just plain compiling 
the new packages or haggling with a completely overloaded E-Mail program... 

Uhm, these were most of my reasons for wanting a pause feature :) 

It would be nicest if using the pause feature would also reduce the memory 
footprint... but most memory will be swapped out if it isn't used, so the 
pause feature alone should suffice for freeing memory :) 

Best wishes, 
Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
   - singing a part of the history of free software -
  http://infinite-hands.draketo.de
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] Current uservoice top 5

[VolodyA! V Anarhist]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> 5. Use port 80,443,53,1863 for communication. (74 votes)
> 
> I have no idea how this got into the top 5! Any ideas? People trying to run 
> nodes at work perhaps?

University students who want to connect their node in uni with one that runs
somewhere home... ???

  - Volodya

- --
http://freedom.libsyn.com/   Echo of Freedom, Radical Podcast
http://eng.anarchopedia.org/ Anarchopedia, A Free Knowledge Portal
http://www.freedomporn.org/  Freedom Porn, anarchist and activist smut

 "None of us are free until all of us are free."~ Mihail Bakunin
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkn/OjAACgkQuWy2EFICg+2x0QCfUW0DondcaxHykZHCpCuoBMFa
yCAAoOtfe5h5a74qxW5VV4sCa7SFTEYr
=UFDS
-END PGP SIGNATURE-

[freenet-dev] Current uservoice top 5

[Matthew Toseland]

1. Release the 20 nodes barrier (206 votes)

As I have mentioned IMHO this is a straightforward plea for more performance.

2. One GUI for all. (155 votes)

This is usability, particularly bundling more functionality. VIVE LA Freetalk!

3. Add a 'pause' feature. (131 votes)

Remarkably high ranking, I wonder what proportion of our users use online 
games?

4. Implement reinsert on demand. (79 votes)

This is IMHO about data persistence.

5. Use port 80,443,53,1863 for communication. (74 votes)

I have no idea how this got into the top 5! Any ideas? People trying to run 
nodes at work perhaps?
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] Current uservoice top 5

[Evan Daniel]

On Mon, May 4, 2009 at 11:33 AM, Matthew Toseland
 wrote:
> 1. Release the 20 nodes barrier (206 votes)
>
> As I have mentioned IMHO this is a straightforward plea for more performance.

I'll reiterate a point I've made before.

While this represents a simple plea for performance, I don't think
it's an irrational one -- that is, I think the overall network
performance is hampered by having all nodes have the same number of
connections.

Because all connections use similar amounts of bandwidth, the network
speed is limited by the slower nodes.  This is true regardless of the
absolute number of connections; raising the maximum for fast nodes
should have a very similar effect to lowering it for slow nodes.  What
matters is that slow nodes have fewer connections than fast nodes.

For example, the max allowed connections (and default setting) could
be 1 connection per 2KiB/s output bandwidth, but never more than 20 or
less than 15.  Those numbers are based on some (very limited) testing
I've done -- if I reduce the allowed bw, that is the approximate
number of connections required to make full use of it.

Reducing the number of connections for slow nodes has some additional
benefits.  First, my limited testing shows a slight increase in
payload % at low bw limits as a result of reducing the connection
count (there is some per-connection network overhead).  Second, bloom
filter sharing represents a per-connection overhead (mostly in the
initial transfer -- updates are low bw, as discussed).  If (when?)
implemented, it will represent a smaller total overhead with fewer
connections than with more.  Presumably, the greatest impact is on
slower nodes.

On the other hand, too few connections may make various attacks
easier.  I have no idea how strong an effect this is.  However, a node
that has too many connections (ie insufficient bw to use them all
fully) may show burstier behavior and thus be more susceptible to
traffic analysis.  In addition, fewer connections means a larger
network diameter on average, which may have an impact on routing.
Lower degree also means that the node has fewer neighbor bloom filters
to check, which means that a request is compared against fewer stores
during its traversal of the network.

I'm intentionally suggesting a small change -- it's less likely to
cause major problems.  By keeping the ratio between slow nodes (15
connections) and fast nodes (20 connections) modest, the potential for
reliance on ubernodes is kept minimal.  (Similarly, if you want to
raise the 20 connections limit instead of lower it, I think it should
only be increased slightly.)

And finally: I have done some testing on this proposed change.  At
first glance, it looks like it doesn't hurt and may help.  However, I
have not done enough testing to be able to say anything with
confidence.  I'm not suggesting to implement this change immediately;
rather, I'm saying that *any* change like this should see some
real-world testing before implementation, and that reducing the
defaults for slow nodes is as worthy of consideration and testing as
raising it for fast nodes.

Also: do we have any idea what the distribution of available node
bandwidth looks like?

Evan Daniel

[freenet-dev] Current uservoice top 5

[Matthew Toseland]

1. Release the 20 nodes barrier (206 votes)

As I have mentioned IMHO this is a straightforward plea for more performance.

2. One GUI for all. (155 votes)

This is usability, particularly bundling more functionality. VIVE LA Freetalk!

3. Add a 'pause' feature. (131 votes)

Remarkably high ranking, I wonder what proportion of our users use online 
games?

4. Implement reinsert on demand. (79 votes)

This is IMHO about data persistence.

5. Use port 80,443,53,1863 for communication. (74 votes)

I have no idea how this got into the top 5! Any ideas? People trying to run 
nodes at work perhaps?


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Current uservoice top 5

[Evan Daniel]

On Mon, May 4, 2009 at 11:33 AM, Matthew Toseland
t...@amphibian.dyndns.org wrote:
 1. Release the 20 nodes barrier (206 votes)

 As I have mentioned IMHO this is a straightforward plea for more performance.

I'll reiterate a point I've made before.

While this represents a simple plea for performance, I don't think
it's an irrational one -- that is, I think the overall network
performance is hampered by having all nodes have the same number of
connections.

Because all connections use similar amounts of bandwidth, the network
speed is limited by the slower nodes.  This is true regardless of the
absolute number of connections; raising the maximum for fast nodes
should have a very similar effect to lowering it for slow nodes.  What
matters is that slow nodes have fewer connections than fast nodes.

For example, the max allowed connections (and default setting) could
be 1 connection per 2KiB/s output bandwidth, but never more than 20 or
less than 15.  Those numbers are based on some (very limited) testing
I've done -- if I reduce the allowed bw, that is the approximate
number of connections required to make full use of it.

Reducing the number of connections for slow nodes has some additional
benefits.  First, my limited testing shows a slight increase in
payload % at low bw limits as a result of reducing the connection
count (there is some per-connection network overhead).  Second, bloom
filter sharing represents a per-connection overhead (mostly in the
initial transfer -- updates are low bw, as discussed).  If (when?)
implemented, it will represent a smaller total overhead with fewer
connections than with more.  Presumably, the greatest impact is on
slower nodes.

On the other hand, too few connections may make various attacks
easier.  I have no idea how strong an effect this is.  However, a node
that has too many connections (ie insufficient bw to use them all
fully) may show burstier behavior and thus be more susceptible to
traffic analysis.  In addition, fewer connections means a larger
network diameter on average, which may have an impact on routing.
Lower degree also means that the node has fewer neighbor bloom filters
to check, which means that a request is compared against fewer stores
during its traversal of the network.

I'm intentionally suggesting a small change -- it's less likely to
cause major problems.  By keeping the ratio between slow nodes (15
connections) and fast nodes (20 connections) modest, the potential for
reliance on ubernodes is kept minimal.  (Similarly, if you want to
raise the 20 connections limit instead of lower it, I think it should
only be increased slightly.)

And finally: I have done some testing on this proposed change.  At
first glance, it looks like it doesn't hurt and may help.  However, I
have not done enough testing to be able to say anything with
confidence.  I'm not suggesting to implement this change immediately;
rather, I'm saying that *any* change like this should see some
real-world testing before implementation, and that reducing the
defaults for slow nodes is as worthy of consideration and testing as
raising it for fast nodes.

Also: do we have any idea what the distribution of available node
bandwidth looks like?

Evan Daniel
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Current uservoice top 5

[Arne Babenhauserheide]

Am Montag 04 Mai 2009 17:33:30 schrieb Matthew Toseland:
 3. Add a 'pause' feature. (131 votes)

 Remarkably high ranking, I wonder what proportion of our users use online
 games?

Or with other filesharing services (short lived torrents, downloading in 
Gnutella) or with graphics editing or video editing or just plain compiling 
the new packages or haggling with a completely overloaded E-Mail program... 

Uhm, these were most of my reasons for wanting a pause feature :) 

It would be nicest if using the pause feature would also reduce the memory 
footprint... but most memory will be swapped out if it isn't used, so the 
pause feature alone should suffice for freeing memory :) 

Best wishes, 
Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
   - singing a part of the history of free software -
  http://infinite-hands.draketo.de


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Current uservoice top 5

[Arne Babenhauserheide]

Am Montag 04 Mai 2009 17:33:30 schrieb Matthew Toseland:
 5. Use port 80,443,53,1863 for communication. (74 votes)

 I have no idea how this got into the top 5! Any ideas? People trying to run
 nodes at work perhaps?

Maybe not wanting the provider to be able to just shut down nonstandard ports 
and block freenet that way. 

ISPs can block freenet ports, but shouldn't really block 80 - at least for 
outgoing connections. 

Maybe running it on a server. 

Best wishes, 
Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
   - singing a part of the history of free software -
  http://infinite-hands.draketo.de


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Current uservoice top 5

[VolodyA! V Anarhist]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 5. Use port 80,443,53,1863 for communication. (74 votes)
 
 I have no idea how this got into the top 5! Any ideas? People trying to run 
 nodes at work perhaps?

University students who want to connect their node in uni with one that runs
somewhere home... ???

  - Volodya

- --
http://freedom.libsyn.com/   Echo of Freedom, Radical Podcast
http://eng.anarchopedia.org/ Anarchopedia, A Free Knowledge Portal
http://www.freedomporn.org/  Freedom Porn, anarchist and activist smut

 None of us are free until all of us are free.~ Mihail Bakunin
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkn/OjAACgkQuWy2EFICg+2x0QCfUW0DondcaxHykZHCpCuoBMFa
yCAAoOtfe5h5a74qxW5VV4sCa7SFTEYr
=UFDS
-END PGP SIGNATURE-
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Current uservoice top 5

[Thomas Sachau]

Matthew Toseland schrieb:
 1. Release the 20 nodes barrier (206 votes)
 
 As I have mentioned IMHO this is a straightforward plea for more performance.
 
 2. One GUI for all. (155 votes)
 
 This is usability, particularly bundling more functionality. VIVE LA Freetalk!
 
 3. Add a 'pause' feature. (131 votes)
 
 Remarkably high ranking, I wonder what proportion of our users use online 
 games?
 
 4. Implement reinsert on demand. (79 votes)
 
 This is IMHO about data persistence.
 
 5. Use port 80,443,53,1863 for communication. (74 votes)
 
 I have no idea how this got into the top 5! Any ideas? People trying to run 
 nodes at work perhaps?

The last one may be because of censorship fearing. I have heard at least 1 
report about an ISP
blocking almost all UDP traffic, allowing only port 53. The user was forced to 
use port 53(udp) to
be able to use freenet.




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

Re: [freenet-dev] Current uservoice top 5

[Matthew Toseland]

On Monday 04 May 2009 17:29:51 Evan Daniel wrote:
 On Mon, May 4, 2009 at 11:33 AM, Matthew Toseland
 t...@amphibian.dyndns.org wrote:
  1. Release the 20 nodes barrier (206 votes)
 
  As I have mentioned IMHO this is a straightforward plea for more 
performance.
 
 I'll reiterate a point I've made before.
 
 While this represents a simple plea for performance, I don't think
 it's an irrational one -- that is, I think the overall network
 performance is hampered by having all nodes have the same number of
 connections.
 
 Because all connections use similar amounts of bandwidth, the network
 speed is limited by the slower nodes.  This is true regardless of the
 absolute number of connections; raising the maximum for fast nodes
 should have a very similar effect to lowering it for slow nodes.  What
 matters is that slow nodes have fewer connections than fast nodes.
 
 For example, the max allowed connections (and default setting) could
 be 1 connection per 2KiB/s output bandwidth, but never more than 20 or
 less than 15.  

What would the point be? Don't we need a significant range for it to make much 
difference?

 Those numbers are based on some (very limited) testing 
 I've done -- if I reduce the allowed bw, that is the approximate
 number of connections required to make full use of it.
 
 Reducing the number of connections for slow nodes has some additional
 benefits.  First, my limited testing shows a slight increase in
 payload % at low bw limits as a result of reducing the connection
 count (there is some per-connection network overhead).  

True.

 Second, bloom 
 filter sharing represents a per-connection overhead (mostly in the
 initial transfer -- updates are low bw, as discussed).  If (when?)
 implemented, it will represent a smaller total overhead with fewer
 connections than with more.  Presumably, the greatest impact is on
 slower nodes.

Really it's determined by churn, isn't it? Or by any heuristic artificial 
limits we impose...
 
 On the other hand, too few connections may make various attacks
 easier.  I have no idea how strong an effect this is.  However, a node
 that has too many connections (ie insufficient bw to use them all
 fully) may show burstier behavior and thus be more susceptible to
 traffic analysis.  

Yes, definitely true with our current padding algorithms.

 In addition, fewer connections means a larger 
 network diameter on average, which may have an impact on routing.
 Lower degree also means that the node has fewer neighbor bloom filters
 to check, which means that a request is compared against fewer stores
 during its traversal of the network.

True.
 
 I'm intentionally suggesting a small change -- it's less likely to
 cause major problems.  By keeping the ratio between slow nodes (15
 connections) and fast nodes (20 connections) modest, the potential for
 reliance on ubernodes is kept minimal.  (Similarly, if you want to
 raise the 20 connections limit instead of lower it, I think it should
 only be increased slightly.)

Why? I don't see the point unless the upper bound is significantly higher than 
the lower bound: any improvement won't be measurable.
 
 And finally: I have done some testing on this proposed change.  At
 first glance, it looks like it doesn't hurt and may help.  However, I
 have not done enough testing to be able to say anything with
 confidence.  I'm not suggesting to implement this change immediately;
 rather, I'm saying that *any* change like this should see some
 real-world testing before implementation, and that reducing the
 defaults for slow nodes is as worthy of consideration and testing as
 raising it for fast nodes.

We did try this (with a minimum of 10 connections), and it seemed that slow 
nodes with only 10 connections were significantly slower. However, this was 
not based on widespread testing. My worry is that slow nodes with few 
connections will be *too* slow, and the network will marginalise them. But 
it's a tradeoff between slightly more efficiency, fewer routes to choose 
from, and fewer nodes sending requests...
 
 Also: do we have any idea what the distribution of available node
 bandwidth looks like?

It would be great, wouldn't it? Maybe a survey? What questions should we ask?
 
 Evan Daniel


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Current uservoice top 5

[Evan Daniel]

On Mon, May 4, 2009 at 6:15 PM, Matthew Toseland
t...@amphibian.dyndns.org wrote:
 On Monday 04 May 2009 17:29:51 Evan Daniel wrote:
 On Mon, May 4, 2009 at 11:33 AM, Matthew Toseland
 t...@amphibian.dyndns.org wrote:
  1. Release the 20 nodes barrier (206 votes)
 
  As I have mentioned IMHO this is a straightforward plea for more
 performance.

 I'll reiterate a point I've made before.

 While this represents a simple plea for performance, I don't think
 it's an irrational one -- that is, I think the overall network
 performance is hampered by having all nodes have the same number of
 connections.

 Because all connections use similar amounts of bandwidth, the network
 speed is limited by the slower nodes.  This is true regardless of the
 absolute number of connections; raising the maximum for fast nodes
 should have a very similar effect to lowering it for slow nodes.  What
 matters is that slow nodes have fewer connections than fast nodes.

 For example, the max allowed connections (and default setting) could
 be 1 connection per 2KiB/s output bandwidth, but never more than 20 or
 less than 15.

 What would the point be? Don't we need a significant range for it to make much
 difference?

If the network is in fact limited by the per-connection speed of the
slower nodes, and they are in fact a minority of the network,
increasing the per-connection bandwidth of the slower nodes by 33%
should result in a throughput increase for most of the rest of the
network of a similar magnitude.  A performance improvement of 10-30%
should be easily measurable, and (at the high end of that) noticeable
enough to be appreciated by most users.

Really, though, the idea would be to use it as a network-wide test.
Small tests by a few users are helpful, but not nearly as informative
as a network-wide test.  Assuming the change produced measurable
improvement, it would make sense to explore further changes.  For
example, changing the range to 15-30, or increasing the per-connection
bandwidth requirement, or making the per-connection requirement
nonlinear, or some other option.  However, security concerns
(especially ubernodes) are bigger with more dramatic changes.


 Those numbers are based on some (very limited) testing
 I've done -- if I reduce the allowed bw, that is the approximate
 number of connections required to make full use of it.

 Reducing the number of connections for slow nodes has some additional
 benefits.  First, my limited testing shows a slight increase in
 payload % at low bw limits as a result of reducing the connection
 count (there is some per-connection network overhead).

 True.

To be specific, my anecdotal evidence is that it improves the payload
fraction by roughly 3-8%.


 Second, bloom
 filter sharing represents a per-connection overhead (mostly in the
 initial transfer -- updates are low bw, as discussed).  If (when?)
 implemented, it will represent a smaller total overhead with fewer
 connections than with more.  Presumably, the greatest impact is on
 slower nodes.

 Really it's determined by churn, isn't it? Or by any heuristic artificial
 limits we impose...

My assumption is that connection duration is well modeled by a
per-connection half-life, that is largely independent of the number of
connections.  The bandwidth used on such filters is proportional to
the total churn, so fewer connections means less churn in absolute
sense but the same connection half-life.  (That is, bloom filter
bandwidth usage is proportional to # of connections * per-connection
churn rate.)  I don't have any evidence for that assumption, though.


 On the other hand, too few connections may make various attacks
 easier.  I have no idea how strong an effect this is.  However, a node
 that has too many connections (ie insufficient bw to use them all
 fully) may show burstier behavior and thus be more susceptible to
 traffic analysis.

 Yes, definitely true with our current padding algorithms.

 In addition, fewer connections means a larger
 network diameter on average, which may have an impact on routing.
 Lower degree also means that the node has fewer neighbor bloom filters
 to check, which means that a request is compared against fewer stores
 during its traversal of the network.

 True.

Do you know how big a problem this would cause?  My assumption is that
it would be a fairly small effect even on the nodes with fewer
connections, and that they would be in the minority.


 I'm intentionally suggesting a small change -- it's less likely to
 cause major problems.  By keeping the ratio between slow nodes (15
 connections) and fast nodes (20 connections) modest, the potential for
 reliance on ubernodes is kept minimal.  (Similarly, if you want to
 raise the 20 connections limit instead of lower it, I think it should
 only be increased slightly.)

 Why? I don't see the point unless the upper bound is significantly higher than
 the lower bound: any improvement won't be measurable.

As above, I would hope that the 

[freenet-dev] Current uservoice top 5 (20 node barrier)

[Arne Babenhauserheide]

Am Mittwoch 22 April 2009 14:53:45 schrieb Arne Babenhauserheide:
> Am Mittwoch 22 April 2009 14:38:29 schrieb Matthew Toseland:
> > I don't know. IMHO 150 is probably too much, have you spoken privately to
> > all these people?
>
> I think all people I know privately, including school and university,
> account for maybe 100 to 120 people. Of them I'd trust about 40 as
> connections :)

To test the 150 people limit for the "monkey space", my wife and I just did a 
test by counting all people we know personally and care about (we were walking 
to the supermarket, so we had some free time :) ). 

I got to over 200, and she got to over 300, so 150 is a bit too low as upper 
boundary, I'd say (the article didn't say 150, by the way, but 100 to 230 for 
95%). 

But of these 200 I'd trust only 50 enough that they'd keep the information 
private that I run freenet - she'd trust about 30 people enough (less tech 
savvy community :) ). 

So for pretty communicative people who mostly know tech geeks 150 to 200 
friends might be a good bet (for most tech geeks the number is likely to be 
lower, though). 

(I hope you don't mind my wording. Geek is no insult for me, and neither is 
Nerd)


Just wanted to give you the data :) 


I have a question, though: Would it help routing if people would exchange refs 
with other people who have similar interests? If yes: Can you guess how much 
it would help? 


Best wishes, 
Arne
-- 
-- Ein W?rfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software.
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)

-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] Current uservoice top 5 (20 node barrier)

[Matthew Toseland]

On Wednesday 22 April 2009 16:52:57 Robert Hailey wrote:
> 
> On Apr 22, 2009, at 7:38 AM, Matthew Toseland wrote:
> 
> > On Wednesday 22 April 2009 02:09:21 Arne Babenhauserheide wrote:
> >> So we get to the question, what a freenet contact is: A friend or an
> >> aquaintance.
> >>
> >> If you look at myspace and similar sites, you'll see people with  
> >> hundreds of
> >> "friends" which in truth are aquaintances.
> >>
> >> Also the question arises, which number of friends will be efficient  
> >> for
> >> freenets algorithm: How many people have similar interest?
> >
> > In terms of routing, the main issues are:
> > - There must be a small-world network. Clearly random automatically  
> > selected
> > participants will not form a small-world network, but acquaintances  
> > probably
> > do. I repeat, randomly selected people through any automated  
> > mechanism WILL
> > BREAK ROUTING!
> 
> Are we even sure of that???
> 
> I know that the whole routing algorithm is based on small world  
> theory. However, if we load up a sim of a large randomly connected  
> network, would freenet not operate on it? Perhaps it would sort out  
> effective and usable locations anyway (simply on graph theory)?

No. It would not work well. We demonstrated this pretty clearly with 
#freenet-refs !
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] Current uservoice top 5 (20 node barrier)

[Matthew Toseland]

On Wednesday 22 April 2009 18:53:48 Arne Babenhauserheide wrote:
> Am Mittwoch 22 April 2009 15:53:39 schrieb Matthew Toseland:
> > I don't understand why you want to run a jabber server. Surely announcing
> > to your jabber contacts that you are interested in ref exchange would be
> > sufficient, and would be client level?
> 
> I don't mean announcing to your jabber contacts that you'd like to exchange 
> refs (though that would be a nice option, too). 
> 
> I mean having all freenet refs as jabber contacts automatically, and having 
a 
> freenet jabber ID based on your ref. 
> 
> That way communication with peers would become far easier (it can just rely 
on 
> jabbers own encryption - you're open to your peers anyway - and it can 
> automatically use all features people develop for jabber). 
> 
> That way I'd just add my freenet jabber ID in my noderef with 127.0.0.1 as 
> server, and freenet would add all my refs as jabber contacts for that 
freenet 
> jabber ID. 

Encryption is irrelevant, any such traffic should be tunneled with regular 
freenet traffic and thus be invisible from the network. But it might be an 
interesting idea for a plugin.
> 
> Best wishes, 
> Arne
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: 

Re: [freenet-dev] Current uservoice top 5 (20 node barrier)

[Matthew Toseland]

On Wednesday 22 April 2009 18:53:48 Arne Babenhauserheide wrote:
 Am Mittwoch 22 April 2009 15:53:39 schrieb Matthew Toseland:
  I don't understand why you want to run a jabber server. Surely announcing
  to your jabber contacts that you are interested in ref exchange would be
  sufficient, and would be client level?
 
 I don't mean announcing to your jabber contacts that you'd like to exchange 
 refs (though that would be a nice option, too). 
 
 I mean having all freenet refs as jabber contacts automatically, and having 
a 
 freenet jabber ID based on your ref. 
 
 That way communication with peers would become far easier (it can just rely 
on 
 jabbers own encryption - you're open to your peers anyway - and it can 
 automatically use all features people develop for jabber). 
 
 That way I'd just add my freenet jabber ID in my noderef with 127.0.0.1 as 
 server, and freenet would add all my refs as jabber contacts for that 
freenet 
 jabber ID. 

Encryption is irrelevant, any such traffic should be tunneled with regular 
freenet traffic and thus be invisible from the network. But it might be an 
interesting idea for a plugin.
 
 Best wishes, 
 Arne


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Current uservoice top 5 (20 node barrier)

[Matthew Toseland]

On Wednesday 22 April 2009 16:52:57 Robert Hailey wrote:
 
 On Apr 22, 2009, at 7:38 AM, Matthew Toseland wrote:
 
  On Wednesday 22 April 2009 02:09:21 Arne Babenhauserheide wrote:
  So we get to the question, what a freenet contact is: A friend or an
  aquaintance.
 
  If you look at myspace and similar sites, you'll see people with  
  hundreds of
  friends which in truth are aquaintances.
 
  Also the question arises, which number of friends will be efficient  
  for
  freenets algorithm: How many people have similar interest?
 
  In terms of routing, the main issues are:
  - There must be a small-world network. Clearly random automatically  
  selected
  participants will not form a small-world network, but acquaintances  
  probably
  do. I repeat, randomly selected people through any automated  
  mechanism WILL
  BREAK ROUTING!
 
 Are we even sure of that???
 
 I know that the whole routing algorithm is based on small world  
 theory. However, if we load up a sim of a large randomly connected  
 network, would freenet not operate on it? Perhaps it would sort out  
 effective and usable locations anyway (simply on graph theory)?

No. It would not work well. We demonstrated this pretty clearly with 
#freenet-refs !


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Current uservoice top 5 (20 node barrier)

[Arne Babenhauserheide]

Am Mittwoch 22 April 2009 14:53:45 schrieb Arne Babenhauserheide:
 Am Mittwoch 22 April 2009 14:38:29 schrieb Matthew Toseland:
  I don't know. IMHO 150 is probably too much, have you spoken privately to
  all these people?

 I think all people I know privately, including school and university,
 account for maybe 100 to 120 people. Of them I'd trust about 40 as
 connections :)

To test the 150 people limit for the monkey space, my wife and I just did a 
test by counting all people we know personally and care about (we were walking 
to the supermarket, so we had some free time :) ). 

I got to over 200, and she got to over 300, so 150 is a bit too low as upper 
boundary, I'd say (the article didn't say 150, by the way, but 100 to 230 for 
95%). 

But of these 200 I'd trust only 50 enough that they'd keep the information 
private that I run freenet - she'd trust about 30 people enough (less tech 
savvy community :) ). 

So for pretty communicative people who mostly know tech geeks 150 to 200 
friends might be a good bet (for most tech geeks the number is likely to be 
lower, though). 

(I hope you don't mind my wording. Geek is no insult for me, and neither is 
Nerd)


Just wanted to give you the data :) 


I have a question, though: Would it help routing if people would exchange refs 
with other people who have similar interests? If yes: Can you guess how much 
it would help? 


Best wishes, 
Arne
-- 
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software.
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)

-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Current uservoice top 5 (20 node barrier)

[Arne Babenhauserheide]

Am Mittwoch 22 April 2009 15:53:39 schrieb Matthew Toseland:
> I don't understand why you want to run a jabber server. Surely announcing
> to your jabber contacts that you are interested in ref exchange would be
> sufficient, and would be client level?

I don't mean announcing to your jabber contacts that you'd like to exchange 
refs (though that would be a nice option, too). 

I mean having all freenet refs as jabber contacts automatically, and having a 
freenet jabber ID based on your ref. 

That way communication with peers would become far easier (it can just rely on 
jabbers own encryption - you're open to your peers anyway - and it can 
automatically use all features people develop for jabber). 

That way I'd just add my freenet jabber ID in my noderef with 127.0.0.1 as 
server, and freenet would add all my refs as jabber contacts for that freenet 
jabber ID. 

Best wishes, 
Arne
-- 
-- Ein W?rfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software.
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)

-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt

[freenet-dev] Current uservoice top 5 (20 node barrier)

[Arne Babenhauserheide]

Am Mittwoch 22 April 2009 15:15:07 schrieb VolodyA! V Anarhist:
> > Wouldn't IRC/Jabber break anonymity ?
> >
> > Or, maybe you're speaking of IRC/Jabber over Freenet and i'm wrong ...
>
> It would only let people know that you are running Freenet, not what you
> are doing with it. And whom you are compromising that information to is
> also an issue, if you only announce to your friends that you are willing to
> connect to anyhow that you are using Freenet, then you aren't compromised
> any more than you would otherwise.

It wouldn't even let unrelated people know you're running freenet. They would 
only know that you're running a jabber server (which can easily explain 
strange encrypted traffic :) ). 

And as you said, the jabber server would only be open to your freenet 
contacts, and they have your IP anyway. 

I don't know about all jabber internals, but if it would be open only for your 
friends, you'd be as safe as you already are when runnign freenet. 

Best wishes, 
Arne

-- 
-- Ein W?rfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software.
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)

-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt

[freenet-dev] Current uservoice top 5 (20 node barrier)

[Arne Babenhauserheide]

Am Mittwoch 22 April 2009 14:57:06 schrieb Matthew Toseland:
> > But both have the drawback of drawing people away from the webinterface,
>
> which
>
> > increases the maintenance cost for toad.
>
> Not sure I follow.

They'd be another interface and someone would have to keep it up to date and 
working when things change. 

Best wishes, 
Arne
-- 
-- Ein W?rfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software.
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)

-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt

[freenet-dev] Current uservoice top 5 (20 node barrier)

[Romain Dalmaso]

Wouldn't IRC/Jabber break anonymity ?

Or, maybe you're speaking of IRC/Jabber over Freenet and i'm wrong ...

On 4/22/09, Matthew Toseland  wrote:
> On Wednesday 22 April 2009 13:53:45 Arne Babenhauserheide wrote:
>> Am Mittwoch 22 April 2009 14:38:29 schrieb Matthew Toseland:
>> > > other member of the group as freenet friends, or should they only have
>> > > their closest contacts?
>> >
>> > I don't know. IMHO 150 is probably too much, have you spoken privately
>> > to
>> > all these people?
>>
>> I think all people I know privately, including school and university,
> account
>> for maybe 100 to 120 people. Of them I'd trust about 40 as connections :)
>>
>> If I add people I only know via email, these numbers go up to maybe
>> 150/50.
>
> IMHO that would be great - any of the above figures - especially when you
> take
> into account uptime problems. Practically speaking most people you know
> won't
> run Freenet. However, all the members of a mailing list or a university
> department isn't quite the same thing - 150 people for just one group, plus
> all the other groups and people...
>>
>> > > If they should have more contacts, we'll need stronger friend
> interaction
>> > > features, so we can keep the cost for social interaction with friends
>> > > low.
>> >
>> > We need stronger friend interaction features full stop.
>>
>> How about a shoutbox as first step?
>>
>> There you can send messages to all your contacts.
>>
>> Naturally each shoutbox will have different entries, so it's no real chat,
>>
> but
>> at least it would allow giving quick status messages (that's the main
>> communication i did: "Sorry, my box was down for a day - I'm up again" :)
>
> Well, you can check the box next to each peer ... but yes we should improve
> this. This might be related to vive's student's task?
>>
>> > > A Jabber server which automatically adds all friends as contacts would
>> > >
> be
>> > > an option, I think.
>> >
>> > Hmmm perhaps.
>>
>> It would also add better information about online contacts - directly in
>> the
>> multi-messenger people use anyways.
>>
>> Maybe it could even get control features, like the jabber server from
>> livejournal (you can post LJ entries via jabber).
>>
>> Another option would be IRC :)
>>
>> But both have the drawback of drawing people away from the webinterface,
> which
>> increases the maintenance cost for toad.
>
> Not sure I follow.
>>
>> Best wishes,
>> Arne
>

[freenet-dev] Current uservoice top 5

[Matthew Toseland]

On Wednesday 22 April 2009 14:49:47 Evan Daniel wrote:
> On Mon, Apr 20, 2009 at 10:34 AM, Matthew Toseland
>  wrote:
> 
> > So duplicating the top block is fairly important. Another weakness is that
> > the last segment in a splitfile may have much less redundancy than the 
rest;
> > this can be fixed by making the last 2 segments the same size.
> 
> Is there any reason to make the first n-2 segments full size and the
> last 2 balanced and potentially only (slightly over) half size, rather
> than make all n segments the same size?

Dunno, anyone easily able to do the math?
> 
> Evan Daniel
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] Current uservoice top 5 (20 node barrier)

[Arne Babenhauserheide]

Am Mittwoch 22 April 2009 14:38:29 schrieb Matthew Toseland:
> > other member of the group as freenet friends, or should they only have
> > their closest contacts?
>
> I don't know. IMHO 150 is probably too much, have you spoken privately to
> all these people?

I think all people I know privately, including school and university, account 
for maybe 100 to 120 people. Of them I'd trust about 40 as connections :) 

If I add people I only know via email, these numbers go up to maybe 150/50. 

> > If they should have more contacts, we'll need stronger friend interaction
> > features, so we can keep the cost for social interaction with friends
> > low.
>
> We need stronger friend interaction features full stop.

How about a shoutbox as first step? 

There you can send messages to all your contacts. 

Naturally each shoutbox will have different entries, so it's no real chat, but 
at least it would allow giving quick status messages (that's the main 
communication i did: "Sorry, my box was down for a day - I'm up again" :) 

> > A Jabber server which automatically adds all friends as contacts would be
> > an option, I think.
>
> Hmmm perhaps.

It would also add better information about online contacts - directly in the 
multi-messenger people use anyways. 

Maybe it could even get control features, like the jabber server from 
livejournal (you can post LJ entries via jabber). 

Another option would be IRC :) 

But both have the drawback of drawing people away from the webinterface, which 
increases the maintenance cost for toad. 

Best wishes, 
Arne
-- 
-- Ein W?rfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software.
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)

-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt

[freenet-dev] Current uservoice top 5 (20 node barrier)

[Matthew Toseland]

On Wednesday 22 April 2009 14:33:45 Arne Babenhauserheide wrote:
> Am Mittwoch 22 April 2009 15:15:07 schrieb VolodyA! V Anarhist:
> > > Wouldn't IRC/Jabber break anonymity ?
> > >
> > > Or, maybe you're speaking of IRC/Jabber over Freenet and i'm wrong ...
> >
> > It would only let people know that you are running Freenet, not what you
> > are doing with it. And whom you are compromising that information to is
> > also an issue, if you only announce to your friends that you are willing 
to
> > connect to anyhow that you are using Freenet, then you aren't compromised
> > any more than you would otherwise.
> 
> It wouldn't even let unrelated people know you're running freenet. They 
would 
> only know that you're running a jabber server (which can easily explain 
> strange encrypted traffic :) ). 
> 
> And as you said, the jabber server would only be open to your freenet 
> contacts, and they have your IP anyway. 
> 
> I don't know about all jabber internals, but if it would be open only for 
your 
> friends, you'd be as safe as you already are when runnign freenet. 

I don't understand why you want to run a jabber server. Surely announcing to 
your jabber contacts that you are interested in ref exchange would be 
sufficient, and would be client level?
> 
> Best wishes, 
> Arne
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] Current uservoice top 5 (20 node barrier)

[Matthew Toseland]

On Wednesday 22 April 2009 14:06:48 Romain Dalmaso wrote:
> Wouldn't IRC/Jabber break anonymity ?
> 
> Or, maybe you're speaking of IRC/Jabber over Freenet and i'm wrong ...

We are talking about getting darknet connections via IRC, and yes, there is a 
tradeoff. However, sending darknet refs via email or IM is also detectable 
unless you encrypt the mails; the only means that is really safe is swapping 
them on USB keys in person.
> 
> On 4/22/09, Matthew Toseland  wrote:
> > On Wednesday 22 April 2009 13:53:45 Arne Babenhauserheide wrote:
> >> Am Mittwoch 22 April 2009 14:38:29 schrieb Matthew Toseland:
> >> > > other member of the group as freenet friends, or should they only 
have
> >> > > their closest contacts?
> >> >
> >> > I don't know. IMHO 150 is probably too much, have you spoken privately
> >> > to
> >> > all these people?
> >>
> >> I think all people I know privately, including school and university,
> > account
> >> for maybe 100 to 120 people. Of them I'd trust about 40 as connections :)
> >>
> >> If I add people I only know via email, these numbers go up to maybe
> >> 150/50.
> >
> > IMHO that would be great - any of the above figures - especially when you
> > take
> > into account uptime problems. Practically speaking most people you know
> > won't
> > run Freenet. However, all the members of a mailing list or a university
> > department isn't quite the same thing - 150 people for just one group, 
plus
> > all the other groups and people...
> >>
> >> > > If they should have more contacts, we'll need stronger friend
> > interaction
> >> > > features, so we can keep the cost for social interaction with friends
> >> > > low.
> >> >
> >> > We need stronger friend interaction features full stop.
> >>
> >> How about a shoutbox as first step?
> >>
> >> There you can send messages to all your contacts.
> >>
> >> Naturally each shoutbox will have different entries, so it's no real 
chat,
> >>
> > but
> >> at least it would allow giving quick status messages (that's the main
> >> communication i did: "Sorry, my box was down for a day - I'm up again" :)
> >
> > Well, you can check the box next to each peer ... but yes we should 
improve
> > this. This might be related to vive's student's task?
> >>
> >> > > A Jabber server which automatically adds all friends as contacts 
would
> >> > >
> > be
> >> > > an option, I think.
> >> >
> >> > Hmmm perhaps.
> >>
> >> It would also add better information about online contacts - directly in
> >> the
> >> multi-messenger people use anyways.
> >>
> >> Maybe it could even get control features, like the jabber server from
> >> livejournal (you can post LJ entries via jabber).
> >>
> >> Another option would be IRC :)
> >>
> >> But both have the drawback of drawing people away from the webinterface,
> > which
> >> increases the maintenance cost for toad.
> >
> > Not sure I follow.
> >>
> >> Best wishes,
> >> Arne
> >
> ___
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
> 
> 


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] Current uservoice top 5 (20 node barrier)

[Matthew Toseland]

On Wednesday 22 April 2009 14:30:02 Arne Babenhauserheide wrote:
> Am Mittwoch 22 April 2009 14:57:06 schrieb Matthew Toseland:
> > > But both have the drawback of drawing people away from the webinterface,
> >
> > which
> >
> > > increases the maintenance cost for toad.
> >
> > Not sure I follow.
> 
> They'd be another interface and someone would have to keep it up to date and 
> working when things change. 

They'd be a plugin managed through the web interface, surely?
> 
> Best wishes, 
> Arne
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] Current uservoice top 5 (20 node barrier)

[VolodyA! V Anarhist]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Romain Dalmaso wrote:
> Wouldn't IRC/Jabber break anonymity ?
> 
> Or, maybe you're speaking of IRC/Jabber over Freenet and i'm wrong ...

It would only let people know that you are running Freenet, not what you are
doing with it. And whom you are compromising that information to is also an
issue, if you only announce to your friends that you are willing to connect to
anyhow that you are using Freenet, then you aren't compromised any more than you
would otherwise.

  - Volodya

- --
http://freedom.libsyn.com/   Echo of Freedom, Radical Podcast
http://eng.anarchopedia.org/ Anarchopedia, A Free Knowledge Portal
http://www.freedomporn.org/  Freedom Porn, anarchist and activist smut

 "None of us are free until all of us are free."~ Mihail Bakunin
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknvGFgACgkQuWy2EFICg+3mrQCdFuKXs44c+FVitG++uKhh6+PJ
1bsAoNcXrfdgITjtUXaiVCbITXWIucgp
=SMJy
-END PGP SIGNATURE-

[freenet-dev] Current uservoice top 5 (20 node barrier)

[Matthew Toseland]

On Wednesday 22 April 2009 13:53:45 Arne Babenhauserheide wrote:
> Am Mittwoch 22 April 2009 14:38:29 schrieb Matthew Toseland:
> > > other member of the group as freenet friends, or should they only have
> > > their closest contacts?
> >
> > I don't know. IMHO 150 is probably too much, have you spoken privately to
> > all these people?
> 
> I think all people I know privately, including school and university, 
account 
> for maybe 100 to 120 people. Of them I'd trust about 40 as connections :) 
> 
> If I add people I only know via email, these numbers go up to maybe 150/50. 

IMHO that would be great - any of the above figures - especially when you take 
into account uptime problems. Practically speaking most people you know won't 
run Freenet. However, all the members of a mailing list or a university 
department isn't quite the same thing - 150 people for just one group, plus 
all the other groups and people...
> 
> > > If they should have more contacts, we'll need stronger friend 
interaction
> > > features, so we can keep the cost for social interaction with friends
> > > low.
> >
> > We need stronger friend interaction features full stop.
> 
> How about a shoutbox as first step? 
> 
> There you can send messages to all your contacts. 
> 
> Naturally each shoutbox will have different entries, so it's no real chat, 
but 
> at least it would allow giving quick status messages (that's the main 
> communication i did: "Sorry, my box was down for a day - I'm up again" :) 

Well, you can check the box next to each peer ... but yes we should improve 
this. This might be related to vive's student's task?
> 
> > > A Jabber server which automatically adds all friends as contacts would 
be
> > > an option, I think.
> >
> > Hmmm perhaps.
> 
> It would also add better information about online contacts - directly in the 
> multi-messenger people use anyways. 
> 
> Maybe it could even get control features, like the jabber server from 
> livejournal (you can post LJ entries via jabber). 
> 
> Another option would be IRC :) 
> 
> But both have the drawback of drawing people away from the webinterface, 
which 
> increases the maintenance cost for toad. 

Not sure I follow.
> 
> Best wishes, 
> Arne
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] Current uservoice top 5 (20 node barrier)

[Matthew Toseland]

On Wednesday 22 April 2009 02:09:21 Arne Babenhauserheide wrote:
> Am Dienstag 21 April 2009 17:41:59 schrieb Theodore Hong:
> > VolodyA! V Anarhist  wrote:
> > > Matthew Toseland wrote:
> > > If you watch the 'Human body' documentary it says that humans have on
> > > average 20 people they call friends. I am unsure where that number comes
> > > from, but if it's some scientific study, that's another reason to keep 
20
> > > node limit, or if we increase it than it shouldn't be more than 
something
> > > like 25.
> >
> > There's a thing called Dunbar's number which supposedly represents an
> > upper cognitive limit on the number of friendships that a person can
> > keep track of - estimated to be around 150.
> > http://en.wikipedia.org/wiki/Dunbar%27s_number
> 
> So we get to the question, what a freenet contact is: A friend or an 
> aquaintance. 
> 
> If you look at myspace and similar sites, you'll see people with hundreds of 
> "friends" which in truth are aquaintances. 
> 
> Also the question arises, which number of friends will be efficient for 
> freenets algorithm: How many people have similar interest? 

In terms of routing, the main issues are:
- There must be a small-world network. Clearly random automatically selected 
participants will not form a small-world network, but acquaintances probably 
do. I repeat, randomly selected people through any automated mechanism WILL 
BREAK ROUTING!
- There must be enough of them online at a time that there is a viable, 
routable network.

In terms of security:
- Darknet is much more secure than opennet simply because the cost of getting 
a connection to the target node is much higher. This greatly reduces the 
effectiveness of mobile-attacker source tracing attacks, one of the most 
serious known attacks.
- Clearly you are vulnerable to your peers. But no more so on darknet than on 
opennet, really. On opennet, it is possible to get many connections to the 
target; on darknet, you have to persuade the user to give you such 
connections by e.g. pretending to be many people.

So IMHO unless you have serious security requirements there is no reason not 
to connect to acquaintances.
> 
> The wikipedia entry suggests that specialized academic interest groups are 
in 
> the size of 150 individuals. The same might be true for other specialized 
> groups. 
> 
> If all members of such a group were using freenet: Should they all have 
every 
> other member of the group as freenet friends, or should they only have their 
> closest contacts? 

I don't know. IMHO 150 is probably too much, have you spoken privately to all 
these people?
> 
> If they should have more contacts, we'll need stronger friend interaction 
> features, so we can keep the cost for social interaction with friends low. 

We need stronger friend interaction features full stop.
> 
> A Jabber server which automatically adds all friends as contacts would be an 
> option, I think. 

Hmmm perhaps.
> 
> Best wishes, 
> Arne
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] Current uservoice top 5 (20 node barrier)

[Robert Hailey]

On Apr 22, 2009, at 7:38 AM, Matthew Toseland wrote:

> On Wednesday 22 April 2009 02:09:21 Arne Babenhauserheide wrote:
>> So we get to the question, what a freenet contact is: A friend or an
>> aquaintance.
>>
>> If you look at myspace and similar sites, you'll see people with  
>> hundreds of
>> "friends" which in truth are aquaintances.
>>
>> Also the question arises, which number of friends will be efficient  
>> for
>> freenets algorithm: How many people have similar interest?
>
> In terms of routing, the main issues are:
> - There must be a small-world network. Clearly random automatically  
> selected
> participants will not form a small-world network, but acquaintances  
> probably
> do. I repeat, randomly selected people through any automated  
> mechanism WILL
> BREAK ROUTING!

Are we even sure of that???

I know that the whole routing algorithm is based on small world  
theory. However, if we load up a sim of a large randomly connected  
network, would freenet not operate on it? Perhaps it would sort out  
effective and usable locations anyway (simply on graph theory)?

BTW, like you, I am NOT in favor of making any such random/automatic  
darknet connections.

I think the general question is: How does increasing the cardinality  
effect the network? Presuming that all nodes are currently running at  
throttled speed, then surely it could only effect routing.
- It might make a request get out of an overloaded 'clump' faster  
(around backed off peers/but most of my peers are not backed off).
- It dilutes both relevant (friend) and irrelevant (IRC) darknet links.

 From a free-software standpoint, if someone really wanted to have  
more than 20 connections, why-would/how-could we stop them? If it is  
so popular a request, how would a few super-connected nodes negatively  
effect performance/network? Just make it an obscure/advanced option.


> - There must be enough of them online at a time that there is a  
> viable,
> routable network.

Right... better with more connections, I suppose.

> In terms of security:
> - Darknet is much more secure than opennet simply because the cost  
> of getting
> a connection to the target node is much higher. This greatly reduces  
> the
> effectiveness of mobile-attacker source tracing attacks, one of the  
> most
> serious known attacks.
> - Clearly you are vulnerable to your peers. But no more so on  
> darknet than on
> opennet, really. On opennet, it is possible to get many connections  
> to the
> target; on darknet, you have to persuade the user to give you such
> connections by e.g. pretending to be many people.
>
> So IMHO unless you have serious security requirements there is no  
> reason not
> to connect to acquaintances.

I agree. Unless your acquaintances are a bunch of snoops and hackers  
(you know... those sort that use freenet) :)

--
Robert Hailey

-- next part --
An HTML attachment was scrubbed...
URL: 

[freenet-dev] Current uservoice top 5

[Evan Daniel]

On Mon, Apr 20, 2009 at 10:34 AM, Matthew Toseland
 wrote:

> So duplicating the top block is fairly important. Another weakness is that
> the last segment in a splitfile may have much less redundancy than the rest;
> this can be fixed by making the last 2 segments the same size.

Is there any reason to make the first n-2 segments full size and the
last 2 balanced and potentially only (slightly over) half size, rather
than make all n segments the same size?

Evan Daniel

[freenet-dev] Current uservoice top 5 (20 node barrier)

[David ‘Bombe’ Roden]

On Tuesday 21 April 2009 17:41:59 Theodore Hong wrote:

> There's a thing called Dunbar's number which supposedly represents an
> upper cognitive limit on the number of friendships that a person can
> keep track of - estimated to be around 150.

It?s probably better known as ?the monkeysphere.? [1] :)


David

[1]: http://www.cracked.com/article_14990_what-monkeysphere.html
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] Current uservoice top 5 (20 node barrier)

[Arne Babenhauserheide]

Am Dienstag 21 April 2009 17:41:59 schrieb Theodore Hong:
> VolodyA! V Anarhist  wrote:
> > Matthew Toseland wrote:
> > If you watch the 'Human body' documentary it says that humans have on
> > average 20 people they call friends. I am unsure where that number comes
> > from, but if it's some scientific study, that's another reason to keep 20
> > node limit, or if we increase it than it shouldn't be more than something
> > like 25.
>
> There's a thing called Dunbar's number which supposedly represents an
> upper cognitive limit on the number of friendships that a person can
> keep track of - estimated to be around 150.
> http://en.wikipedia.org/wiki/Dunbar%27s_number

So we get to the question, what a freenet contact is: A friend or an 
aquaintance. 

If you look at myspace and similar sites, you'll see people with hundreds of 
"friends" which in truth are aquaintances. 

Also the question arises, which number of friends will be efficient for 
freenets algorithm: How many people have similar interest? 

The wikipedia entry suggests that specialized academic interest groups are in 
the size of 150 individuals. The same might be true for other specialized 
groups. 

If all members of such a group were using freenet: Should they all have every 
other member of the group as freenet friends, or should they only have their 
closest contacts? 

If they should have more contacts, we'll need stronger friend interaction 
features, so we can keep the cost for social interaction with friends low. 

A Jabber server which automatically adds all friends as contacts would be an 
option, I think. 

Best wishes, 
Arne
-- 
-- Ein W?rfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software.
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)

-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

Re: [freenet-dev] Current uservoice top 5 (20 node barrier)

[Matthew Toseland]

On Wednesday 22 April 2009 02:09:21 Arne Babenhauserheide wrote:
 Am Dienstag 21 April 2009 17:41:59 schrieb Theodore Hong:
  VolodyA! V Anarhist volo...@whengendarmesleeps.org wrote:
   Matthew Toseland wrote:
   If you watch the 'Human body' documentary it says that humans have on
   average 20 people they call friends. I am unsure where that number comes
   from, but if it's some scientific study, that's another reason to keep 
20
   node limit, or if we increase it than it shouldn't be more than 
something
   like 25.
 
  There's a thing called Dunbar's number which supposedly represents an
  upper cognitive limit on the number of friendships that a person can
  keep track of - estimated to be around 150.
  http://en.wikipedia.org/wiki/Dunbar%27s_number
 
 So we get to the question, what a freenet contact is: A friend or an 
 aquaintance. 
 
 If you look at myspace and similar sites, you'll see people with hundreds of 
 friends which in truth are aquaintances. 
 
 Also the question arises, which number of friends will be efficient for 
 freenets algorithm: How many people have similar interest? 

In terms of routing, the main issues are:
- There must be a small-world network. Clearly random automatically selected 
participants will not form a small-world network, but acquaintances probably 
do. I repeat, randomly selected people through any automated mechanism WILL 
BREAK ROUTING!
- There must be enough of them online at a time that there is a viable, 
routable network.

In terms of security:
- Darknet is much more secure than opennet simply because the cost of getting 
a connection to the target node is much higher. This greatly reduces the 
effectiveness of mobile-attacker source tracing attacks, one of the most 
serious known attacks.
- Clearly you are vulnerable to your peers. But no more so on darknet than on 
opennet, really. On opennet, it is possible to get many connections to the 
target; on darknet, you have to persuade the user to give you such 
connections by e.g. pretending to be many people.

So IMHO unless you have serious security requirements there is no reason not 
to connect to acquaintances.
 
 The wikipedia entry suggests that specialized academic interest groups are 
in 
 the size of 150 individuals. The same might be true for other specialized 
 groups. 
 
 If all members of such a group were using freenet: Should they all have 
every 
 other member of the group as freenet friends, or should they only have their 
 closest contacts? 

I don't know. IMHO 150 is probably too much, have you spoken privately to all 
these people?
 
 If they should have more contacts, we'll need stronger friend interaction 
 features, so we can keep the cost for social interaction with friends low. 

We need stronger friend interaction features full stop.
 
 A Jabber server which automatically adds all friends as contacts would be an 
 option, I think. 

Hmmm perhaps.
 
 Best wishes, 
 Arne


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Current uservoice top 5 (20 node barrier)

[Arne Babenhauserheide]

Am Mittwoch 22 April 2009 14:38:29 schrieb Matthew Toseland:
  other member of the group as freenet friends, or should they only have
  their closest contacts?

 I don't know. IMHO 150 is probably too much, have you spoken privately to
 all these people?

I think all people I know privately, including school and university, account 
for maybe 100 to 120 people. Of them I'd trust about 40 as connections :) 

If I add people I only know via email, these numbers go up to maybe 150/50. 

  If they should have more contacts, we'll need stronger friend interaction
  features, so we can keep the cost for social interaction with friends
  low.

 We need stronger friend interaction features full stop.

How about a shoutbox as first step? 

There you can send messages to all your contacts. 

Naturally each shoutbox will have different entries, so it's no real chat, but 
at least it would allow giving quick status messages (that's the main 
communication i did: Sorry, my box was down for a day - I'm up again :) 

  A Jabber server which automatically adds all friends as contacts would be
  an option, I think.

 Hmmm perhaps.

It would also add better information about online contacts - directly in the 
multi-messenger people use anyways. 

Maybe it could even get control features, like the jabber server from 
livejournal (you can post LJ entries via jabber). 

Another option would be IRC :) 

But both have the drawback of drawing people away from the webinterface, which 
increases the maintenance cost for toad. 

Best wishes, 
Arne
-- 
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software.
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)

-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Current uservoice top 5 (20 node barrier)

[Romain Dalmaso]

Wouldn't IRC/Jabber break anonymity ?

Or, maybe you're speaking of IRC/Jabber over Freenet and i'm wrong ...

On 4/22/09, Matthew Toseland t...@amphibian.dyndns.org wrote:
 On Wednesday 22 April 2009 13:53:45 Arne Babenhauserheide wrote:
 Am Mittwoch 22 April 2009 14:38:29 schrieb Matthew Toseland:
   other member of the group as freenet friends, or should they only have
   their closest contacts?
 
  I don't know. IMHO 150 is probably too much, have you spoken privately
  to
  all these people?

 I think all people I know privately, including school and university,
 account
 for maybe 100 to 120 people. Of them I'd trust about 40 as connections :)

 If I add people I only know via email, these numbers go up to maybe
 150/50.

 IMHO that would be great - any of the above figures - especially when you
 take
 into account uptime problems. Practically speaking most people you know
 won't
 run Freenet. However, all the members of a mailing list or a university
 department isn't quite the same thing - 150 people for just one group, plus
 all the other groups and people...

   If they should have more contacts, we'll need stronger friend
 interaction
   features, so we can keep the cost for social interaction with friends
   low.
 
  We need stronger friend interaction features full stop.

 How about a shoutbox as first step?

 There you can send messages to all your contacts.

 Naturally each shoutbox will have different entries, so it's no real chat,

 but
 at least it would allow giving quick status messages (that's the main
 communication i did: Sorry, my box was down for a day - I'm up again :)

 Well, you can check the box next to each peer ... but yes we should improve
 this. This might be related to vive's student's task?

   A Jabber server which automatically adds all friends as contacts would
  
 be
   an option, I think.
 
  Hmmm perhaps.

 It would also add better information about online contacts - directly in
 the
 multi-messenger people use anyways.

 Maybe it could even get control features, like the jabber server from
 livejournal (you can post LJ entries via jabber).

 Another option would be IRC :)

 But both have the drawback of drawing people away from the webinterface,
 which
 increases the maintenance cost for toad.

 Not sure I follow.

 Best wishes,
 Arne

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

Re: [freenet-dev] Current uservoice top 5 (20 node barrier)

[VolodyA! V Anarhist]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Romain Dalmaso wrote:
 Wouldn't IRC/Jabber break anonymity ?
 
 Or, maybe you're speaking of IRC/Jabber over Freenet and i'm wrong ...

It would only let people know that you are running Freenet, not what you are
doing with it. And whom you are compromising that information to is also an
issue, if you only announce to your friends that you are willing to connect to
anyhow that you are using Freenet, then you aren't compromised any more than you
would otherwise.

  - Volodya

- --
http://freedom.libsyn.com/   Echo of Freedom, Radical Podcast
http://eng.anarchopedia.org/ Anarchopedia, A Free Knowledge Portal
http://www.freedomporn.org/  Freedom Porn, anarchist and activist smut

 None of us are free until all of us are free.~ Mihail Bakunin
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknvGFgACgkQuWy2EFICg+3mrQCdFuKXs44c+FVitG++uKhh6+PJ
1bsAoNcXrfdgITjtUXaiVCbITXWIucgp
=SMJy
-END PGP SIGNATURE-
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Current uservoice top 5 (20 node barrier)

[Arne Babenhauserheide]

Am Mittwoch 22 April 2009 14:57:06 schrieb Matthew Toseland:
  But both have the drawback of drawing people away from the webinterface,

 which

  increases the maintenance cost for toad.

 Not sure I follow.

They'd be another interface and someone would have to keep it up to date and 
working when things change. 

Best wishes, 
Arne
-- 
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software.
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)

-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Current uservoice top 5 (20 node barrier)

[Arne Babenhauserheide]

Am Mittwoch 22 April 2009 15:15:07 schrieb VolodyA! V Anarhist:
  Wouldn't IRC/Jabber break anonymity ?
 
  Or, maybe you're speaking of IRC/Jabber over Freenet and i'm wrong ...

 It would only let people know that you are running Freenet, not what you
 are doing with it. And whom you are compromising that information to is
 also an issue, if you only announce to your friends that you are willing to
 connect to anyhow that you are using Freenet, then you aren't compromised
 any more than you would otherwise.

It wouldn't even let unrelated people know you're running freenet. They would 
only know that you're running a jabber server (which can easily explain 
strange encrypted traffic :) ). 

And as you said, the jabber server would only be open to your freenet 
contacts, and they have your IP anyway. 

I don't know about all jabber internals, but if it would be open only for your 
friends, you'd be as safe as you already are when runnign freenet. 

Best wishes, 
Arne

-- 
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software.
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)

-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Current uservoice top 5 (20 node barrier)

[Matthew Toseland]

On Wednesday 22 April 2009 14:30:02 Arne Babenhauserheide wrote:
 Am Mittwoch 22 April 2009 14:57:06 schrieb Matthew Toseland:
   But both have the drawback of drawing people away from the webinterface,
 
  which
 
   increases the maintenance cost for toad.
 
  Not sure I follow.
 
 They'd be another interface and someone would have to keep it up to date and 
 working when things change. 

They'd be a plugin managed through the web interface, surely?
 
 Best wishes, 
 Arne


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Current uservoice top 5

[Evan Daniel]

On Mon, Apr 20, 2009 at 10:34 AM, Matthew Toseland
t...@amphibian.dyndns.org wrote:

 So duplicating the top block is fairly important. Another weakness is that
 the last segment in a splitfile may have much less redundancy than the rest;
 this can be fixed by making the last 2 segments the same size.

Is there any reason to make the first n-2 segments full size and the
last 2 balanced and potentially only (slightly over) half size, rather
than make all n segments the same size?

Evan Daniel
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Current uservoice top 5 (20 node barrier)

[Matthew Toseland]

On Wednesday 22 April 2009 14:33:45 Arne Babenhauserheide wrote:
 Am Mittwoch 22 April 2009 15:15:07 schrieb VolodyA! V Anarhist:
   Wouldn't IRC/Jabber break anonymity ?
  
   Or, maybe you're speaking of IRC/Jabber over Freenet and i'm wrong ...
 
  It would only let people know that you are running Freenet, not what you
  are doing with it. And whom you are compromising that information to is
  also an issue, if you only announce to your friends that you are willing 
to
  connect to anyhow that you are using Freenet, then you aren't compromised
  any more than you would otherwise.
 
 It wouldn't even let unrelated people know you're running freenet. They 
would 
 only know that you're running a jabber server (which can easily explain 
 strange encrypted traffic :) ). 
 
 And as you said, the jabber server would only be open to your freenet 
 contacts, and they have your IP anyway. 
 
 I don't know about all jabber internals, but if it would be open only for 
your 
 friends, you'd be as safe as you already are when runnign freenet. 

I don't understand why you want to run a jabber server. Surely announcing to 
your jabber contacts that you are interested in ref exchange would be 
sufficient, and would be client level?
 
 Best wishes, 
 Arne


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Current uservoice top 5

[Matthew Toseland]

On Wednesday 22 April 2009 14:49:47 Evan Daniel wrote:
 On Mon, Apr 20, 2009 at 10:34 AM, Matthew Toseland
 t...@amphibian.dyndns.org wrote:
 
  So duplicating the top block is fairly important. Another weakness is that
  the last segment in a splitfile may have much less redundancy than the 
rest;
  this can be fixed by making the last 2 segments the same size.
 
 Is there any reason to make the first n-2 segments full size and the
 last 2 balanced and potentially only (slightly over) half size, rather
 than make all n segments the same size?

Dunno, anyone easily able to do the math?
 
 Evan Daniel


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Current uservoice top 5 (20 node barrier)

[Robert Hailey]

On Apr 22, 2009, at 7:38 AM, Matthew Toseland wrote:


On Wednesday 22 April 2009 02:09:21 Arne Babenhauserheide wrote:

So we get to the question, what a freenet contact is: A friend or an
aquaintance.

If you look at myspace and similar sites, you'll see people with  
hundreds of

friends which in truth are aquaintances.

Also the question arises, which number of friends will be efficient  
for

freenets algorithm: How many people have similar interest?


In terms of routing, the main issues are:
- There must be a small-world network. Clearly random automatically  
selected
participants will not form a small-world network, but acquaintances  
probably
do. I repeat, randomly selected people through any automated  
mechanism WILL

BREAK ROUTING!


Are we even sure of that???

I know that the whole routing algorithm is based on small world  
theory. However, if we load up a sim of a large randomly connected  
network, would freenet not operate on it? Perhaps it would sort out  
effective and usable locations anyway (simply on graph theory)?


BTW, like you, I am NOT in favor of making any such random/automatic  
darknet connections.


I think the general question is: How does increasing the cardinality  
effect the network? Presuming that all nodes are currently running at  
throttled speed, then surely it could only effect routing.
- It might make a request get out of an overloaded 'clump' faster  
(around backed off peers/but most of my peers are not backed off).

- It dilutes both relevant (friend) and irrelevant (IRC) darknet links.

From a free-software standpoint, if someone really wanted to have  
more than 20 connections, why-would/how-could we stop them? If it is  
so popular a request, how would a few super-connected nodes negatively  
effect performance/network? Just make it an obscure/advanced option.



- There must be enough of them online at a time that there is a  
viable,

routable network.


Right... better with more connections, I suppose.


In terms of security:
- Darknet is much more secure than opennet simply because the cost  
of getting
a connection to the target node is much higher. This greatly reduces  
the
effectiveness of mobile-attacker source tracing attacks, one of the  
most

serious known attacks.
- Clearly you are vulnerable to your peers. But no more so on  
darknet than on
opennet, really. On opennet, it is possible to get many connections  
to the

target; on darknet, you have to persuade the user to give you such
connections by e.g. pretending to be many people.

So IMHO unless you have serious security requirements there is no  
reason not

to connect to acquaintances.


I agree. Unless your acquaintances are a bunch of snoops and hackers  
(you know... those sort that use freenet) :)


--
Robert Hailey

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

Re: [freenet-dev] Current uservoice top 5 (20 node barrier)

[Arne Babenhauserheide]

Am Mittwoch 22 April 2009 15:53:39 schrieb Matthew Toseland:
 I don't understand why you want to run a jabber server. Surely announcing
 to your jabber contacts that you are interested in ref exchange would be
 sufficient, and would be client level?

I don't mean announcing to your jabber contacts that you'd like to exchange 
refs (though that would be a nice option, too). 

I mean having all freenet refs as jabber contacts automatically, and having a 
freenet jabber ID based on your ref. 

That way communication with peers would become far easier (it can just rely on 
jabbers own encryption - you're open to your peers anyway - and it can 
automatically use all features people develop for jabber). 

That way I'd just add my freenet jabber ID in my noderef with 127.0.0.1 as 
server, and freenet would add all my refs as jabber contacts for that freenet 
jabber ID. 

Best wishes, 
Arne
-- 
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software.
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)

-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Current uservoice top 5 (20 node barrier)

[Theodore Hong]

VolodyA! V Anarhist  wrote:
> Matthew Toseland wrote:
>> 1. (200 votes) Release the 20 nodes barrier
>>
> If you watch the 'Human body' documentary it says that humans have on average 
> 20
> people they call friends. I am unsure where that number comes from, but if 
> it's
> some scientific study, that's another reason to keep 20 node limit, or if we
> increase it than it shouldn't be more than something like 25.

There's a thing called Dunbar's number which supposedly represents an
upper cognitive limit on the number of friendships that a person can
keep track of - estimated to be around 150.
http://en.wikipedia.org/wiki/Dunbar%27s_number

theo

[freenet-dev] Current uservoice top 5 (20 node barrier)

[VolodyA! V Anarhist]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthew Toseland wrote:
> Top 5 suggestions on freenet.uservoice.com. Two are performance, and three 
> are 
> usability.
> 
> 1. (200 votes) Release the 20 nodes barrier
> 
> Interesting that the top issue is essentially a plea for more performance! 
> Some of this will clearly be from frustrated long-term node operators with 
> fast links that Freenet doesn't use, but imho it represents a more general 
> problem: Freenet is slow!

If you watch the 'Human body' documentary it says that humans have on average 20
people they call friends. I am unsure where that number comes from, but if it's
some scientific study, that's another reason to keep 20 node limit, or if we
increase it than it shouldn't be more than something like 25.

  - Volodya

- --
http://freedom.libsyn.com/   Echo of Freedom, Radical Podcast
http://eng.anarchopedia.org/ Anarchopedia, A Free Knowledge Portal
http://www.freedomporn.org/  Freedom Porn, anarchist and activist smut

 "None of us are free until all of us are free."~ Mihail Bakunin
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknt59cACgkQuWy2EFICg+235gCg6cAdLSnhZgpmJMN8JNmOpmLp
+HwAnRzQYszoH8ciAFwnUfbVLzJxtM4I
=o4Aa
-END PGP SIGNATURE-

Re: [freenet-dev] Current uservoice top 5 (20 node barrier)

[VolodyA! V Anarhist]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthew Toseland wrote:
 Top 5 suggestions on freenet.uservoice.com. Two are performance, and three 
 are 
 usability.
 
 1. (200 votes) Release the 20 nodes barrier
 
 Interesting that the top issue is essentially a plea for more performance! 
 Some of this will clearly be from frustrated long-term node operators with 
 fast links that Freenet doesn't use, but imho it represents a more general 
 problem: Freenet is slow!

If you watch the 'Human body' documentary it says that humans have on average 20
people they call friends. I am unsure where that number comes from, but if it's
some scientific study, that's another reason to keep 20 node limit, or if we
increase it than it shouldn't be more than something like 25.

  - Volodya

- --
http://freedom.libsyn.com/   Echo of Freedom, Radical Podcast
http://eng.anarchopedia.org/ Anarchopedia, A Free Knowledge Portal
http://www.freedomporn.org/  Freedom Porn, anarchist and activist smut

 None of us are free until all of us are free.~ Mihail Bakunin
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknt59cACgkQuWy2EFICg+235gCg6cAdLSnhZgpmJMN8JNmOpmLp
+HwAnRzQYszoH8ciAFwnUfbVLzJxtM4I
=o4Aa
-END PGP SIGNATURE-
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Current uservoice top 5 (20 node barrier)

[Theodore Hong]

VolodyA! V Anarhist volo...@whengendarmesleeps.org wrote:
 Matthew Toseland wrote:
 1. (200 votes) Release the 20 nodes barrier

 If you watch the 'Human body' documentary it says that humans have on average 
 20
 people they call friends. I am unsure where that number comes from, but if 
 it's
 some scientific study, that's another reason to keep 20 node limit, or if we
 increase it than it shouldn't be more than something like 25.

There's a thing called Dunbar's number which supposedly represents an
upper cognitive limit on the number of friendships that a person can
keep track of - estimated to be around 150.
http://en.wikipedia.org/wiki/Dunbar%27s_number

theo
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Current uservoice top 5 (20 node barrier)

[Arne Babenhauserheide]

Am Dienstag 21 April 2009 17:41:59 schrieb Theodore Hong:
 VolodyA! V Anarhist volo...@whengendarmesleeps.org wrote:
  Matthew Toseland wrote:
  If you watch the 'Human body' documentary it says that humans have on
  average 20 people they call friends. I am unsure where that number comes
  from, but if it's some scientific study, that's another reason to keep 20
  node limit, or if we increase it than it shouldn't be more than something
  like 25.

 There's a thing called Dunbar's number which supposedly represents an
 upper cognitive limit on the number of friendships that a person can
 keep track of - estimated to be around 150.
 http://en.wikipedia.org/wiki/Dunbar%27s_number

So we get to the question, what a freenet contact is: A friend or an 
aquaintance. 

If you look at myspace and similar sites, you'll see people with hundreds of 
friends which in truth are aquaintances. 

Also the question arises, which number of friends will be efficient for 
freenets algorithm: How many people have similar interest? 

The wikipedia entry suggests that specialized academic interest groups are in 
the size of 150 individuals. The same might be true for other specialized 
groups. 

If all members of such a group were using freenet: Should they all have every 
other member of the group as freenet friends, or should they only have their 
closest contacts? 

If they should have more contacts, we'll need stronger friend interaction 
features, so we can keep the cost for social interaction with friends low. 

A Jabber server which automatically adds all friends as contacts would be an 
option, I think. 

Best wishes, 
Arne
-- 
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software.
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)

-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Current uservoice top 5 (20 node barrier)

[David ‘Bombe’ Roden]

On Tuesday 21 April 2009 17:41:59 Theodore Hong wrote:

 There's a thing called Dunbar's number which supposedly represents an
 upper cognitive limit on the number of friendships that a person can
 keep track of - estimated to be around 150.

It’s probably better known as “the monkeysphere.” [1] :)


David

[1]: http://www.cracked.com/article_14990_what-monkeysphere.html


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Current uservoice top 5

[sich]

Matthew Toseland a ?crit :
> Top 5 suggestions on freenet.uservoice.com. Two are performance, and three 
> are 
> usability.
> 
> 1. (200 votes) Release the 20 nodes barrier
> 
> Interesting that the top issue is essentially a plea for more performance! 
> Some of this will clearly be from frustrated long-term node operators with 
> fast links that Freenet doesn't use, but imho it represents a more general 
> problem: Freenet is slow!

Freenet is not slow ! The speed is good on my opinion. We are talking
about protecting privacy and anonymity, not to have the new fast
download software...

Popular content are generally easy to fetch. Other is little more
difficult yes.


> 2. (150 votes) One GUI for all
> 
> Theoretically this is a demand for a new non-web GUI, but IMHO the important 
> aspects are integrating more functionality and improving the web UI 
> generally; people are quite happy in general with web applications, nobody 
> uses a real email client any more except geeks.

hum, "real email client" is not only for geeks please (I am not a geek
damn :) ).

> 5. (73 votes) Implement reinsert on demand
> 
> This is about more reliable filesharing. Broadly, the concern here is that 
> inserted content does not remain fetchable for very long - if it is not 
> requested, typically 2 weeks or so. IMHO this is bad: clearly we will not be 
> able to cache everything, but given the average datastore size (big) and the 
> average bandwidth limit (small), content ought to last longer than that. We 
> need to be able to quantify this with regular automated tests, we need to 
> investigate to what degree it is caused by newbie nodes, churn etc, fix the 
> uptime estimate code to not only update on connect, implement Bloom filter 
> sharing (which should help significantly imho), and maybe investigate with 
> simulations. Much of the time the problem is that the top block has 
> disappeared; once found the rest of the data can be found relatively quickly. 
> So duplicating the top block is fairly important. Another weakness is that 
> the last segment in a splitfile may have much less redundancy than the rest; 
> this can be fixed by making the last 2 segments the same size. Also, we 
> should consider whether to further increase the level of redundancy, 
> especially in the store: the 3 nodes (on average) which stored (not cached) 
> the data may very well be offline when we fetch it, so unpopular content will 
> frequently not be fetchable. Persistent requests may help in the long term. 
> IMHO Freenet ought to be good at somewhat unpopular content.
> 
> To deal with the issue itself more specifically: infinity0's SoC will be to 
> implement a distributed file indexing/searching system. This might eventually 
> support insert on demand, however insert on demand has serious anonymity 
> issues. In 0.9 we will scramble the splitfile insertion keys in order to 
> prevent this vulnerability, however arguably this will exacerbate the 
> underlying problem, so we may want to reinsert under random keys and then 
> have some of the recipients insert under non-scrambled keys. Obviously, 
> metadata including the hash(es) of the file contents as well as its length 
> will help here; this will probably be a post 0.8 feature, realistically.

Perhaps can you searching about a new sort of key... Some key who are
not going into the datastore, or only for few days (4/5 perhaps). This
keys can go in cache...
This can permit perhaps to use insert on demand on random keys, then if
you reinsert many times the same files you don't use to much datastore
space.

Insert on demand is used for filesharing, but this consume a lot of disk
space in the datastore.
Perhaps should we find something who permit filesharing but don't use to
much datastore space (only caching the keys, not storing, or something
like this).

Insert on demand application should use the wot to be more interesting.


sich

[freenet-dev] Current uservoice top 5

[Matthew Toseland]

On Monday 20 April 2009 17:12:23 sich wrote:
> Matthew Toseland a ?crit :
> > Top 5 suggestions on freenet.uservoice.com. Two are performance, and three 
are 
> > usability.
> > 
> > 1. (200 votes) Release the 20 nodes barrier
> > 
> > Interesting that the top issue is essentially a plea for more performance! 
> > Some of this will clearly be from frustrated long-term node operators with 
> > fast links that Freenet doesn't use, but imho it represents a more general 
> > problem: Freenet is slow!
> 
> Freenet is not slow ! The speed is good on my opinion. We are talking
> about protecting privacy and anonymity, not to have the new fast
> download software...
> 
> Popular content are generally easy to fetch. Other is little more
> difficult yes.
> 
> 
> > 2. (150 votes) One GUI for all
> > 
> > Theoretically this is a demand for a new non-web GUI, but IMHO the 
important 
> > aspects are integrating more functionality and improving the web UI 
> > generally; people are quite happy in general with web applications, nobody 
> > uses a real email client any more except geeks.
> 
> hum, "real email client" is not only for geeks please (I am not a geek
> damn :) ).
> 
> > 5. (73 votes) Implement reinsert on demand
> > 
> > This is about more reliable filesharing. Broadly, the concern here is that 
> > inserted content does not remain fetchable for very long - if it is not 
> > requested, typically 2 weeks or so. IMHO this is bad: clearly we will not 
be 
> > able to cache everything, but given the average datastore size (big) and 
the 
> > average bandwidth limit (small), content ought to last longer than that. 
We 
> > need to be able to quantify this with regular automated tests, we need to 
> > investigate to what degree it is caused by newbie nodes, churn etc, fix 
the 
> > uptime estimate code to not only update on connect, implement Bloom filter 
> > sharing (which should help significantly imho), and maybe investigate with 
> > simulations. Much of the time the problem is that the top block has 
> > disappeared; once found the rest of the data can be found relatively 
quickly. 
> > So duplicating the top block is fairly important. Another weakness is that 
> > the last segment in a splitfile may have much less redundancy than the 
rest; 
> > this can be fixed by making the last 2 segments the same size. Also, we 
> > should consider whether to further increase the level of redundancy, 
> > especially in the store: the 3 nodes (on average) which stored (not 
cached) 
> > the data may very well be offline when we fetch it, so unpopular content 
will 
> > frequently not be fetchable. Persistent requests may help in the long 
term. 
> > IMHO Freenet ought to be good at somewhat unpopular content.
> > 
> > To deal with the issue itself more specifically: infinity0's SoC will be 
to 
> > implement a distributed file indexing/searching system. This might 
eventually 
> > support insert on demand, however insert on demand has serious anonymity 
> > issues. In 0.9 we will scramble the splitfile insertion keys in order to 
> > prevent this vulnerability, however arguably this will exacerbate the 
> > underlying problem, so we may want to reinsert under random keys and then 
> > have some of the recipients insert under non-scrambled keys. Obviously, 
> > metadata including the hash(es) of the file contents as well as its length 
> > will help here; this will probably be a post 0.8 feature, realistically.
> 
> Perhaps can you searching about a new sort of key... Some key who are
> not going into the datastore, or only for few days (4/5 perhaps). This
> keys can go in cache...
> This can permit perhaps to use insert on demand on random keys, then if
> you reinsert many times the same files you don't use to much datastore
> space.
> 
> Insert on demand is used for filesharing, but this consume a lot of disk
> space in the datastore.
> Perhaps should we find something who permit filesharing but don't use to
> much datastore space (only caching the keys, not storing, or something
> like this).

IMHO the first point of call should always be to try to fetch the keys, and 
currently persistence for unpopular content sucks, and hopefully can be 
improved significantly.
> 
> Insert on demand application should use the wot to be more interesting.

Yes.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] Current uservoice top 5

[Matthew Toseland]

On Monday 20 April 2009 16:24:57 xor wrote:
> 
> > To deal with the issue itself more specifically: infinity0's 
> > SoC will be to implement a distributed file 
> > indexing/searching system.
> 
> Will it be possible to make him use the WoT plugin as a base for it?
> This would make very much sense and I can help him if he needs any features.

Yes, that is the idea.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] Current uservoice top 5

[xor]

> To deal with the issue itself more specifically: infinity0's 
> SoC will be to implement a distributed file 
> indexing/searching system.

Will it be possible to make him use the WoT plugin as a base for it?
This would make very much sense and I can help him if he needs any features.

[freenet-dev] Current uservoice top 5

[Matthew Toseland]

Top 5 suggestions on freenet.uservoice.com. Two are performance, and three are 
usability.

1. (200 votes) Release the 20 nodes barrier

Interesting that the top issue is essentially a plea for more performance! 
Some of this will clearly be from frustrated long-term node operators with 
fast links that Freenet doesn't use, but imho it represents a more general 
problem: Freenet is slow!

2. (150 votes) One GUI for all

Theoretically this is a demand for a new non-web GUI, but IMHO the important 
aspects are integrating more functionality and improving the web UI 
generally; people are quite happy in general with web applications, nobody 
uses a real email client any more except geeks.

3. (120 votes) Add a 'pause' feature

This is a remarkably high ranking. It suggests we have a lot of gamers, and 
some easy way to tell the node to go into a mode where it uses as little 
bandwidth as possible, while still being able to get back into the network 
quickly when it is restored, is very popular. Maybe we should expedite this, 
post 0.8-beta1?

4. (101 votes) Show a progress screen when loading a page

This is a surprisingly low ranking IMHO. Anyway it will be implemented soon. 
Hopefully similar measures for pages with images on will help too, they are 
most likely part of sashee's GSoC.

5. (73 votes) Implement reinsert on demand

This is about more reliable filesharing. Broadly, the concern here is that 
inserted content does not remain fetchable for very long - if it is not 
requested, typically 2 weeks or so. IMHO this is bad: clearly we will not be 
able to cache everything, but given the average datastore size (big) and the 
average bandwidth limit (small), content ought to last longer than that. We 
need to be able to quantify this with regular automated tests, we need to 
investigate to what degree it is caused by newbie nodes, churn etc, fix the 
uptime estimate code to not only update on connect, implement Bloom filter 
sharing (which should help significantly imho), and maybe investigate with 
simulations. Much of the time the problem is that the top block has 
disappeared; once found the rest of the data can be found relatively quickly. 
So duplicating the top block is fairly important. Another weakness is that 
the last segment in a splitfile may have much less redundancy than the rest; 
this can be fixed by making the last 2 segments the same size. Also, we 
should consider whether to further increase the level of redundancy, 
especially in the store: the 3 nodes (on average) which stored (not cached) 
the data may very well be offline when we fetch it, so unpopular content will 
frequently not be fetchable. Persistent requests may help in the long term. 
IMHO Freenet ought to be good at somewhat unpopular content.

To deal with the issue itself more specifically: infinity0's SoC will be to 
implement a distributed file indexing/searching system. This might eventually 
support insert on demand, however insert on demand has serious anonymity 
issues. In 0.9 we will scramble the splitfile insertion keys in order to 
prevent this vulnerability, however arguably this will exacerbate the 
underlying problem, so we may want to reinsert under random keys and then 
have some of the recipients insert under non-scrambled keys. Obviously, 
metadata including the hash(es) of the file contents as well as its length 
will help here; this will probably be a post 0.8 feature, realistically.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] Current uservoice top 5

[Matthew Toseland]

Top 5 suggestions on freenet.uservoice.com. Two are performance, and three are 
usability.

1. (200 votes) Release the 20 nodes barrier

Interesting that the top issue is essentially a plea for more performance! 
Some of this will clearly be from frustrated long-term node operators with 
fast links that Freenet doesn't use, but imho it represents a more general 
problem: Freenet is slow!

2. (150 votes) One GUI for all

Theoretically this is a demand for a new non-web GUI, but IMHO the important 
aspects are integrating more functionality and improving the web UI 
generally; people are quite happy in general with web applications, nobody 
uses a real email client any more except geeks.

3. (120 votes) Add a 'pause' feature

This is a remarkably high ranking. It suggests we have a lot of gamers, and 
some easy way to tell the node to go into a mode where it uses as little 
bandwidth as possible, while still being able to get back into the network 
quickly when it is restored, is very popular. Maybe we should expedite this, 
post 0.8-beta1?

4. (101 votes) Show a progress screen when loading a page

This is a surprisingly low ranking IMHO. Anyway it will be implemented soon. 
Hopefully similar measures for pages with images on will help too, they are 
most likely part of sashee's GSoC.

5. (73 votes) Implement reinsert on demand

This is about more reliable filesharing. Broadly, the concern here is that 
inserted content does not remain fetchable for very long - if it is not 
requested, typically 2 weeks or so. IMHO this is bad: clearly we will not be 
able to cache everything, but given the average datastore size (big) and the 
average bandwidth limit (small), content ought to last longer than that. We 
need to be able to quantify this with regular automated tests, we need to 
investigate to what degree it is caused by newbie nodes, churn etc, fix the 
uptime estimate code to not only update on connect, implement Bloom filter 
sharing (which should help significantly imho), and maybe investigate with 
simulations. Much of the time the problem is that the top block has 
disappeared; once found the rest of the data can be found relatively quickly. 
So duplicating the top block is fairly important. Another weakness is that 
the last segment in a splitfile may have much less redundancy than the rest; 
this can be fixed by making the last 2 segments the same size. Also, we 
should consider whether to further increase the level of redundancy, 
especially in the store: the 3 nodes (on average) which stored (not cached) 
the data may very well be offline when we fetch it, so unpopular content will 
frequently not be fetchable. Persistent requests may help in the long term. 
IMHO Freenet ought to be good at somewhat unpopular content.

To deal with the issue itself more specifically: infinity0's SoC will be to 
implement a distributed file indexing/searching system. This might eventually 
support insert on demand, however insert on demand has serious anonymity 
issues. In 0.9 we will scramble the splitfile insertion keys in order to 
prevent this vulnerability, however arguably this will exacerbate the 
underlying problem, so we may want to reinsert under random keys and then 
have some of the recipients insert under non-scrambled keys. Obviously, 
metadata including the hash(es) of the file contents as well as its length 
will help here; this will probably be a post 0.8 feature, realistically.


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Current uservoice top 5

[xor]

 To deal with the issue itself more specifically: infinity0's 
 SoC will be to implement a distributed file 
 indexing/searching system.

Will it be possible to make him use the WoT plugin as a base for it?
This would make very much sense and I can help him if he needs any features.

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

Re: [freenet-dev] Current uservoice top 5

[sich]

Matthew Toseland a écrit :
 Top 5 suggestions on freenet.uservoice.com. Two are performance, and three 
 are 
 usability.
 
 1. (200 votes) Release the 20 nodes barrier
 
 Interesting that the top issue is essentially a plea for more performance! 
 Some of this will clearly be from frustrated long-term node operators with 
 fast links that Freenet doesn't use, but imho it represents a more general 
 problem: Freenet is slow!

Freenet is not slow ! The speed is good on my opinion. We are talking
about protecting privacy and anonymity, not to have the new fast
download software...

Popular content are generally easy to fetch. Other is little more
difficult yes.


 2. (150 votes) One GUI for all
 
 Theoretically this is a demand for a new non-web GUI, but IMHO the important 
 aspects are integrating more functionality and improving the web UI 
 generally; people are quite happy in general with web applications, nobody 
 uses a real email client any more except geeks.

hum, real email client is not only for geeks please (I am not a geek
damn :) ).

 5. (73 votes) Implement reinsert on demand
 
 This is about more reliable filesharing. Broadly, the concern here is that 
 inserted content does not remain fetchable for very long - if it is not 
 requested, typically 2 weeks or so. IMHO this is bad: clearly we will not be 
 able to cache everything, but given the average datastore size (big) and the 
 average bandwidth limit (small), content ought to last longer than that. We 
 need to be able to quantify this with regular automated tests, we need to 
 investigate to what degree it is caused by newbie nodes, churn etc, fix the 
 uptime estimate code to not only update on connect, implement Bloom filter 
 sharing (which should help significantly imho), and maybe investigate with 
 simulations. Much of the time the problem is that the top block has 
 disappeared; once found the rest of the data can be found relatively quickly. 
 So duplicating the top block is fairly important. Another weakness is that 
 the last segment in a splitfile may have much less redundancy than the rest; 
 this can be fixed by making the last 2 segments the same size. Also, we 
 should consider whether to further increase the level of redundancy, 
 especially in the store: the 3 nodes (on average) which stored (not cached) 
 the data may very well be offline when we fetch it, so unpopular content will 
 frequently not be fetchable. Persistent requests may help in the long term. 
 IMHO Freenet ought to be good at somewhat unpopular content.
 
 To deal with the issue itself more specifically: infinity0's SoC will be to 
 implement a distributed file indexing/searching system. This might eventually 
 support insert on demand, however insert on demand has serious anonymity 
 issues. In 0.9 we will scramble the splitfile insertion keys in order to 
 prevent this vulnerability, however arguably this will exacerbate the 
 underlying problem, so we may want to reinsert under random keys and then 
 have some of the recipients insert under non-scrambled keys. Obviously, 
 metadata including the hash(es) of the file contents as well as its length 
 will help here; this will probably be a post 0.8 feature, realistically.

Perhaps can you searching about a new sort of key... Some key who are
not going into the datastore, or only for few days (4/5 perhaps). This
keys can go in cache...
This can permit perhaps to use insert on demand on random keys, then if
you reinsert many times the same files you don't use to much datastore
space.

Insert on demand is used for filesharing, but this consume a lot of disk
space in the datastore.
Perhaps should we find something who permit filesharing but don't use to
much datastore space (only caching the keys, not storing, or something
like this).

Insert on demand application should use the wot to be more interesting.


sich
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Current uservoice top 5

[Matthew Toseland]

On Monday 20 April 2009 16:24:57 xor wrote:
 
  To deal with the issue itself more specifically: infinity0's 
  SoC will be to implement a distributed file 
  indexing/searching system.
 
 Will it be possible to make him use the WoT plugin as a base for it?
 This would make very much sense and I can help him if he needs any features.

Yes, that is the idea.


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Current uservoice top 5

[Matthew Toseland]

On Monday 20 April 2009 17:12:23 sich wrote:
 Matthew Toseland a écrit :
  Top 5 suggestions on freenet.uservoice.com. Two are performance, and three 
are 
  usability.
  
  1. (200 votes) Release the 20 nodes barrier
  
  Interesting that the top issue is essentially a plea for more performance! 
  Some of this will clearly be from frustrated long-term node operators with 
  fast links that Freenet doesn't use, but imho it represents a more general 
  problem: Freenet is slow!
 
 Freenet is not slow ! The speed is good on my opinion. We are talking
 about protecting privacy and anonymity, not to have the new fast
 download software...
 
 Popular content are generally easy to fetch. Other is little more
 difficult yes.
 
 
  2. (150 votes) One GUI for all
  
  Theoretically this is a demand for a new non-web GUI, but IMHO the 
important 
  aspects are integrating more functionality and improving the web UI 
  generally; people are quite happy in general with web applications, nobody 
  uses a real email client any more except geeks.
 
 hum, real email client is not only for geeks please (I am not a geek
 damn :) ).
 
  5. (73 votes) Implement reinsert on demand
  
  This is about more reliable filesharing. Broadly, the concern here is that 
  inserted content does not remain fetchable for very long - if it is not 
  requested, typically 2 weeks or so. IMHO this is bad: clearly we will not 
be 
  able to cache everything, but given the average datastore size (big) and 
the 
  average bandwidth limit (small), content ought to last longer than that. 
We 
  need to be able to quantify this with regular automated tests, we need to 
  investigate to what degree it is caused by newbie nodes, churn etc, fix 
the 
  uptime estimate code to not only update on connect, implement Bloom filter 
  sharing (which should help significantly imho), and maybe investigate with 
  simulations. Much of the time the problem is that the top block has 
  disappeared; once found the rest of the data can be found relatively 
quickly. 
  So duplicating the top block is fairly important. Another weakness is that 
  the last segment in a splitfile may have much less redundancy than the 
rest; 
  this can be fixed by making the last 2 segments the same size. Also, we 
  should consider whether to further increase the level of redundancy, 
  especially in the store: the 3 nodes (on average) which stored (not 
cached) 
  the data may very well be offline when we fetch it, so unpopular content 
will 
  frequently not be fetchable. Persistent requests may help in the long 
term. 
  IMHO Freenet ought to be good at somewhat unpopular content.
  
  To deal with the issue itself more specifically: infinity0's SoC will be 
to 
  implement a distributed file indexing/searching system. This might 
eventually 
  support insert on demand, however insert on demand has serious anonymity 
  issues. In 0.9 we will scramble the splitfile insertion keys in order to 
  prevent this vulnerability, however arguably this will exacerbate the 
  underlying problem, so we may want to reinsert under random keys and then 
  have some of the recipients insert under non-scrambled keys. Obviously, 
  metadata including the hash(es) of the file contents as well as its length 
  will help here; this will probably be a post 0.8 feature, realistically.
 
 Perhaps can you searching about a new sort of key... Some key who are
 not going into the datastore, or only for few days (4/5 perhaps). This
 keys can go in cache...
 This can permit perhaps to use insert on demand on random keys, then if
 you reinsert many times the same files you don't use to much datastore
 space.
 
 Insert on demand is used for filesharing, but this consume a lot of disk
 space in the datastore.
 Perhaps should we find something who permit filesharing but don't use to
 much datastore space (only caching the keys, not storing, or something
 like this).

IMHO the first point of call should always be to try to fetch the keys, and 
currently persistence for unpopular content sucks, and hopefully can be 
improved significantly.
 
 Insert on demand application should use the wot to be more interesting.

Yes.


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl