I think that this coming alpha is at a good time. Performance has always been a hinderance to the usability of freenet, and it appears to be much faster just recently. One benchmark that I noticed is from AnotherIndex, the "time it takes to try every key in the database" has gone down from *weeks* (e.g. 2.1 weeks) to hours (i.e. 20.7 hours).
Concerning versioning as it relates to the alpha; whereas it appears that the alpha is to be a branch in the svn (feature-frozen, bug fix only?), what is the plan for the discretionary versioning between 'alpha' nodes and 'trunk' nodes? Mandatory build releases in the past have been understandably hasty but it seems if we are beginning to present freenet as commonly usable the stability of long release periods (or only minor patches) would be needed. Certainly at some point there will be a separate auto-update key; if not for the alpha then stable/beta release, no? I'm presently in favor of a separate update key for the alpha nodes. Even if it is not effectively used as such (e.g. on a build, publish it to both keys), wouldn't it be a lot easier to fork if we wanted to later? Or I suppose we could at any time change the key in the auto- update for the trunk... so maybe not. Whenever that occurs, since the major issue is not informing 'trunk' nodes of what build versions to communicate with (as it can be hard- coded into the Version.java), but the unmodified 'alpha' (or later, beta or stable) nodes communicating with potentially errant 'trunk' nodes... One idea is to have an official USK for the last-good-trunk- version which the alphas could fetch to know which versions beyond them are blessed by the devl team, or even an option not to communicate with a node which does not claim to be stable. Concerning the general routing theory; the more I ponder about it, the more I think that dungeons and subnets will always be a problem with a computer-meta-level small world network. Consider the large case! If a big country has a firewall (like China), even if Freenet is used inside and outside of that country, there would be expected to be very few connections between the two networks. Inside China (in this case) there would be a viable freenet, and outside there would be a viable freenet but due to the few connections between them, keys could not be effectively fetched or put one to the other. Would it help to have an network-id along with a small world location? An integer could be randomly chosen on startup, a node favors the network-id of it's peers (probabilistically), if a node finds that two of it's connections are not routing to the same actual-network (which is to say, it is the connecting node to a dungeon or subnet) it could advertise different network id's to those connections to pressure the dungeon/subnet to have a different id, and that the id might spread into the dungeon the node will favor an id the routing for which generally works (or simply... the last one which worked). But even with the ID... what do you do with it? I suppose you need a conventional routing table, or something like ng-routing, to tell that "network #4 is reachable through peer-connection #2". And the routing algorithm would change from [find the location, search HTL nodes] to [find a network not in the 'tried' list, find the location, search HTL nodes]... and possibly a less-agressive RNF (like network-route-not- found; if a network is requested and we don't know where it is, or if all our known networks are 'tried'). Ehh... it's an idea. -- Robert Hailey
