On Wednesday 23 January 2008 21:38, David Sowder wrote: > The node should do it's own tests first and then ask the user. The node > has a pretty good idea if it is externally accessible. > > The seednodes.fref file should probably some random subset of the total > pool, once we have a auto-harvesting, possibly giving the same client > the same random subset for some period of time. The entries in > seednodes.fref should probably auto-expire after some time period, once > we have auto-harvesting, relying on the seednodes themselves to > "re-announce" to the central location. > > Clients need a method to auto-update their seednodes list. > > I could probably do the server-side PHP coding, but I can't say how long > it'll take me, but once there's a "go" and I get started actually coding > the PHP, it shouldn't take too terribly long.
That would actually be quite helpful. The problem is that there needs to be some security: ideally we'd like a random node to verify at random times each node added to the list. However, a basic verification e.g. email round-trip might be enough to start with. > > Colin Davis wrote: > > Again, I'm not the right guy to ask, but- The node can't test to see if > > it's externally accessible, and we can't trust it when it says it can > > get outside. It's safer to test externally. > > > > Julien Cornuwel wrote: > > > >> What about the node doing all the tests to know if it's eligible to be > >> a seednode and then, if it is, ask the user ? > >> > >> > >> Colin Davis a ?crit : > >> > >>> I admit that I'm woefully ignorant when it comes to proper design, > >>> and I'm not among the smartest people in the room. > >>> That said, these don't seem like difficult problems- Certainly it's > >>> because I'm missing the complexity. > >>> > >>> I think it the installer should present the option, because that's > >>> when users are most likely to hit Yes. > >>> They don't want to futz with things.. If the question comes up, and > >>> there is no default answer (As I showed before), They'll think about > >>> it, then choose. > >>> > >>> I'm not entirely convinced that emu having a list of 10-20% of the > >>> user's IPs is a horrible thing. > >>> Keep in mind- We do not have to give this entire list out to each > >>> requester, nor do we have to accept data into the list without > >>> testing it. > >>> It's only added to the list if the user explicitly chooses to do so, > >>> and even then, we're not sharing it. > >>> > >>> Imagine if you will that there is a PHP script on > >>> freenet-project.org.. The script takes in a noderef, and saves it to > >>> a file on the machine. [1] > >>> A helper application then attempts to connect to the Noderef.. It > >>> records if it is successful or failure and the time/date. > >>> The helper app loops through all the submitted noderefs, and > >>> continues to store their success/failure and the time/date. > >>> > >>> When we find that we've successfully connected to the node over a > >>> long enough time span, it then gets added to VerifiedNodes.txt > >>> > >>> When you start Freenet for the first time, the installer can ask > >>> "Would you like to download the freshest set of seed nodes? Having > >>> the freshest set of seed nodes allows freenet to get started much > >>> faster. Without it, it may take up to a day to become integrated into > >>> the network" > >>> > >>> When they make a request to freenet-project.org/getSeeds.php, we > >>> return 20 random seeds from the VerifiedNodes file. > >>> > >>> The helper app continues to test nodes from the VerifiedNodes.txt.. > >>> If it hits a certain number of failures to connect, it removes the line. > >>> > >>> > >>> Assuming there were a way to pass Freenet a noderef from the command > >>> line, and get back a success or failure when trying to connect, this > >>> is something that I could code up in a bash script in about an hour, > >>> and I'm not a very good programmer. I'd be happy to help if you'd like. > >>> > >>> I'm sure I'm missing the complexity somewhere. > >>> > >>> -Colin > >>> > >>> > >>> > >>> [1] Or SCP's it to another machine to do the processing. That doesn't > >>> matter for this conversation. > >>> > >>> > >>> > >>>> it. We also (for obvious reasons) don't want the seednodes.fref to > >>>> become something like the yellow pages for opennet (where not everyone > >>>> but almost everyone has an entry and no checks are being made). > >>>> The reasons are: > >>>> - - freenet is anonymity software, we don't want to publish an almost > >>>> complete list of our users > >>>> - - if there are many nodes installed and uninstalled, the list becomes > >>>> crappy, because many entries lead nowhere, it will take even longer for > >>>> new users to connect > >>>> - - the seednodes.fref should stay under a few MB > >>>> - - we don't want it spammed or even worse flooded with entries from > >>>> attackers > >>>> > >>>> > _______________________________________________ > 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: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080124/c44109b2/attachment.pgp>
