I'd suggest that a plan of what is needed/wanted is the first step. How do we do this? The wiki??? I know you main devs seem to use irc, but I'm not in the US, so I can't easily contribute via that medium (i.e. tz issues).
I'd say write up a plan and send it to the list. As a first though to be knocked about: - can we use the multi-introducer developments to manage node clustering? I don't see how that helps. What I think is needed is: 1) Decide if we are going to trust storage nodes to express the variables that are correlated honestly. I think it's at least near impossible not to trust them and make progress. 2) Decide if we are going to have each node express its correlation state, or put this in the introducer or similar. I vote for per-node config. 3) Design a mechanism by which a server node can advertise some properties to clients, like "location=US/Massachusetts/Cambridge/BBN". Display this in the WUI, and make it obtainable in the CLI. 4) Design a first-cut protocol for encoding what we care about into properties. I sent a zeroth-cut proposal in the previous paragraph :-) 5) Design a way to take a list of nodes with their location properties and make the peer selector/balancer spiffier. I think this is replacing 'shares.happy' with a more nuanced claim. Perhaps just have a way for people to write their own rules and link it in, and we can experiment for a while. A possible rule is "on at least 4 servers that differ in city". Or "at least 5 servers, with at least 3 cities, and no 2 of which share a site". This rapidly gets messy. But it can be individualized code as long as it's easy to write.
pgpzdb15hkzUy.pgp
Description: PGP signature
_______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
