Nathan Eisenberg <[email protected]> writes: >> True, but the paranoid will not want to publish them. (And if you're >> not paranoid, why are you using tahoe-lafs?) > > Don't forget the service provider/datacenter model should be accounted > for in the naming convention - ie, these two nodes are sitting on top > of eachother in the same cabinet, or are two blades in the same blade > chassis, or they live on a virtualization cloud and 'move' from > physical processing node to physical processing node.
Agreed. So I think grids that deal with that will want to define how to express it, and write rules to parse. I think solving the general case is too hard. >> True, but the paranoid will not want to publish them. (And if you're >> not paranoid, why are you using tahoe-lafs?) > > Because it's cool / offers great data survivability / is fairly unique > in its implementation. There are plenty of deployed Tahoe grids that > are internal-use-only out there, where the servers are all 'trusted' > (in that a 3rd party is no more likely to get control of a storage > node than of the introducer or gateway). True - I was partly kidding. But giving a symbolic name when the recipient doesn't need to know the coordinates is a least-privilegy way of operating, and putting fine-grained location data when it isn't necessary seems to go against the grain.
pgpCSZDNBEvF1.pgp
Description: PGP signature
_______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
