On Nov 26, 2012 6:05 AM, "Matthew Toseland" <t...@amphibian.dyndns.org> wrote: > > On Monday 26 Nov 2012 01:00:43 Juiceman wrote: > > We need more seednodes. It would be nice if this could be more > > automated and best if it could be done within Freenet itself. > > > > Assumption: > > The official Freenet website will be shutdown or blocked > > someplaces\everywhere Toad (or other project maintainer\s) live > > someday in the future. Development will need to go underground and > > from within Freenet itself. These officials will need to stay > > anonymous. > > Seednode operators live somewhere more free or only development of > > Freenet is illegal and seednode operators are willing to accepted and > > make connections. > > If the main website is blocked, and you are distributing a single official seednodes list, it's a fair assumption that the seednodes will also be blocked. IMHO we should walk before we try to run. You could try to avoid giving out all the seednodes, but that would mean dividing them up somehow, probably using a central server, and even if you can avoid a central server you would certainly need a way to partition it, e.g. by email address or IP address. Both email addresses and IP addresses are rather cheap, so just as with Tor, harvesting all the seednodes is likely to be ridiculously easy. Having said that the chinese seem to have started out by harvesting bridges via creating IP addresses and moved on to their 0day exploit that allows fingerprinting bridges directly; I'm assuming that will be fixed soon so they'll be back to harvesting. > > Actually there's a good chance that opennet is blocked completely in such a case. But it's very likely that the individual seednodes are. > > Only solution long-term is darknet. > > So "main site is blocked but seednodes are not" is a corner-case that may be worth some effort, but not very much. > >
Ok, the proposal still has merits in the automation aspects... > > Problems: > > We need a way that lists of volunteers can be compiled by whoever is > > releasing the official Freenet USK (updates, seednodes list, etc) > > This method cannot be spammable. > > Seednodes that go down should be deleted automatically. > Seednodes that don't connect should not be included in the first place. > > > Need users to opt-in by giving us consent. > > Volunteers need to be able to remove themselves from the official > > seednodes if they want. > > Need to be able to test volunteers firewalls and obviously not from > > the computer of the official maintainer. > > > > Proposal: > > Official seednodes do this work for us! > > I agree. See my previous proposal, which included various advanced verification features. Admittedly my proposal was rather complex, and I'm hoping to implement something simple in the near future. Of course I don't have time under Dec 6th, and if somebody else wants to take it on that'd be awesome... > > > > Major changes to routing code required? > > Add a flag field to noderefs "Seednode=true" If missing or 'false' > > this means a node is unwilling to volunteer. > > If not already implemented somewhere, all seednodes must insert a USK > > key (that can be polled by those that know the noderef\ARK) that > > contains a list of volunteers it has collected. Easiest would be to > > use a field similar to ark.pubURI in the noderef pointing to a USK. > > > > Implementation: > > When a node with "Seednode=true" has been up and connected for 15 > > minutes it starts accepting announcements from connecting nodes. The > > 15 minutes gives it time to settle in. Next it polls the official > > Freenet USK and checks if it is on the official seednode list. If yes > > it is an 'official seednode'. > > Is this the USK that is used by auto-update, that is uploaded only on a release? Or something else? > Your call. > > *The remainder of this email will only talk about official seednodes.* > > > > When a seednode accepts a newbie node for announcement it checks if > > that newbie node has its "Seednode=true" flag set. > > The flag should only be set if the node thinks it is eligible (it's port forwarded and has sufficient uptime and bandwidth), and the user has opted in. If the node thinks it is port forwarded and hasn't asked the user it should ask the user. Whatever they say, once they have answered, we don't ask again. > > Another problem is a node won't have the seednode flag set when it first announces. And if it's a good, high uptime node, like we want, we may need it to contact the seednodes without doing a normal announcement, just to add itself. Well, the user obviously hasn't used Freenet yet enough to decide to be a seednode. After they select the option, the very next time they announce they will be picked up. > > > If yes it puts this node on a list of potential volunteers. > > After 30 minutes of not being connected to each volunteer: > > The seednode tries to connect to the volunteer to test its firewall > > and that it accepts an announcement attempt. If everything looks good > > it adds this node to a list of volunteer nodes that can be inserted > > into the network. The reason we wait 30 minutes is to give the new > > volunteers time to settle into the network and make sure they stuck > > around. > > And even more importantly to make sure that any NAT tunnel between us and them has gone down. We need to be sure that the newbie is connectible from outside. The test doesn't work if we've been recently contacted by the node. > > Yes, I thought about that. Is 30 minutes a good amount? > > Seednodes insert their list of volunteers (hourly? daily?) to a USK > > key that can be polled by whoever is creating and inserting the > > official project USK seednodes list. This central person\node can > > compile a list from all the official seednodes and this central > > person\node can poll the volunteers arks and the "Seednode=true" flag > > to determine when to add or remove a seednode from the official > > seednodes list. If a node turns their "Seednode=true" flag to false > > then volunteers can come and go as needed. > > Does this mean that you want every seednode to contact every seednode? > > > > Something similar can be used to anonymously(to the maintainer) > > determine if an official seednode is defunct: Have official seednodes > > ping each other every so often and insert that info into a USK with > > 'last uptime' for each seednode. The maintainer can poll this info > > and remove seednodes from the official list based on whatever criteria > > he\she wants. > > IMHO it's easier to have the seednodes auto-remove non-responding seeds, and have the seeds add themselves automatically every 24 hours as long as they think they are valid and are not on the list. Of course we'd get connect to them (preferably get a different seednode to connect to the newbie) before we add them to the seeds list. I just wanted to make sure fake seednodes couldn't be easily flooded into the network.
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
