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