Re: [freenet-dev] Improving text on wizard was Re: test install on Windows 7
On Sat, 24 Oct 2009 20:19:34 +0100, Matthew Toseland wrote: >> > If we are browsing in incognito mode, we have a shorter warning: >> >> IMHO: Don't bother the user when he is doing the right thing. He is safe, >> so let him in without questions. 1 click saved. > > Problem is it is hard to impossible to reliably detect when he is doing the > *wrong* thing. Until we have a custom browser with non-localhost url's, we > need the user to be aware of the issue? If the incognito flag is passed, I think we can safely assume that we are actually in incognito mode and not show any message. With the exception of the current Chrome bug of course. When Chrome is fixed and FF 1.6 is out, we can cover quite some ground. We still have the separate IE warning, don't we? - Zero3 ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] Improving text on wizard was Re: test install on Windows 7
On Sat, 24 Oct 2009 20:19:34 +0100, Matthew Toseland wrote: >> > If we are browsing in incognito mode, we have a shorter warning: >> >> IMHO: Don't bother the user when he is doing the right thing. He is safe, >> so let him in without questions. 1 click saved. > > Problem is it is hard to impossible to reliably detect when he is doing the > *wrong* thing. Until we have a custom browser with non-localhost url's, we > need the user to be aware of the issue? If the incognito flag is passed, I think we can safely assume that we are actually in incognito mode and not show any message. With the exception of the current Chrome bug of course. When Chrome is fixed and FF 1.6 is out, we can cover quite some ground. We still have the separate IE warning, don't we? - Zero3
[freenet-dev] why does announcing take so long?
On Sun, Oct 25, 2009 at 11:46 AM, Ian Clarke wrote: > I restarted the Freenet node I installed on Windows after not running > it for 24 hours or so, and so far its been several minutes and I only > just got my first peer. > > What is Freenet doing during this time and why does it take so long? > How can we speed it up? Your node is announcing. There should have been a message to that effect, warning you it might take a little while. That means it's sending announcements to the network via the seednodes, and waiting for other nodes to accept its announcements. You can avoid this step and improve your security by adding some darknet connections to friends running Freenet (a couple friends will make it faster, more friends makes it unnecessary). At a network level, making the announcement process faster means making other nodes accept your announcements more quickly. Unfortunately, announcements are bad for network topology (see bug 3584). The connections made by announcements have the wrong properties, but they work (as long as there aren't too many of them); the result has to be fixed up by the path folding logic. My work so far suggests (weakly, with plenty of caveats; read my various other mails / flog posts on Freenet theory) that the opennet topology isn't bad, but neither is it as good as we'd like. That means I'm strongly against any changes that might make the topology worse that don't have simulation evidence that they're an improvement. Therefore, increasing the announcement accept rates is not a solution. So, in order to speed up announcing, we have to have other nodes accept your announcements more often, while simultaneously having those nodes accepting fewer announcements. Right now, we intentionally limit how many announcements we accept in order to preserve topology; we could do this with a more explicit rate limiting, that would probably improve both time for a new node to announce, and reduce the upper bound on how many bad announcement-based connections a node can have. (See bug 3585.) The other way to improve things is to have fewer other nodes sending announcements. That means they need to connect to the network without announcing. That's the old opennet peers mechanism: having nodes reconnect to nodes that they used to be connected to. This isn't trivial, due to some possible attacks and DoSes involving it, but with work it could be better than it is. See bugs 3580-3583 for some improvements that might help a lot. Evan Daniel
[freenet-dev] why does announcing take so long?
I restarted the Freenet node I installed on Windows after not running it for 24 hours or so, and so far its been several minutes and I only just got my first peer. What is Freenet doing during this time and why does it take so long? How can we speed it up? Ian. -- Ian Clarke CEO, Uprizer Labs Email: ian at uprizer.com Ph: +1 512 422 3588
Re: [freenet-dev] why does announcing take so long?
On Sun, Oct 25, 2009 at 11:46 AM, Ian Clarke wrote: > I restarted the Freenet node I installed on Windows after not running > it for 24 hours or so, and so far its been several minutes and I only > just got my first peer. > > What is Freenet doing during this time and why does it take so long? > How can we speed it up? Your node is announcing. There should have been a message to that effect, warning you it might take a little while. That means it's sending announcements to the network via the seednodes, and waiting for other nodes to accept its announcements. You can avoid this step and improve your security by adding some darknet connections to friends running Freenet (a couple friends will make it faster, more friends makes it unnecessary). At a network level, making the announcement process faster means making other nodes accept your announcements more quickly. Unfortunately, announcements are bad for network topology (see bug 3584). The connections made by announcements have the wrong properties, but they work (as long as there aren't too many of them); the result has to be fixed up by the path folding logic. My work so far suggests (weakly, with plenty of caveats; read my various other mails / flog posts on Freenet theory) that the opennet topology isn't bad, but neither is it as good as we'd like. That means I'm strongly against any changes that might make the topology worse that don't have simulation evidence that they're an improvement. Therefore, increasing the announcement accept rates is not a solution. So, in order to speed up announcing, we have to have other nodes accept your announcements more often, while simultaneously having those nodes accepting fewer announcements. Right now, we intentionally limit how many announcements we accept in order to preserve topology; we could do this with a more explicit rate limiting, that would probably improve both time for a new node to announce, and reduce the upper bound on how many bad announcement-based connections a node can have. (See bug 3585.) The other way to improve things is to have fewer other nodes sending announcements. That means they need to connect to the network without announcing. That's the old opennet peers mechanism: having nodes reconnect to nodes that they used to be connected to. This isn't trivial, due to some possible attacks and DoSes involving it, but with work it could be better than it is. See bugs 3580-3583 for some improvements that might help a lot. Evan Daniel ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] why does announcing take so long?
I restarted the Freenet node I installed on Windows after not running it for 24 hours or so, and so far its been several minutes and I only just got my first peer. What is Freenet doing during this time and why does it take so long? How can we speed it up? Ian. -- Ian Clarke CEO, Uprizer Labs Email: i...@uprizer.com Ph: +1 512 422 3588 ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
