What would happen if the foolscap transport plugin state directory was removed but the tahoe.cfg config file remained intact?
In that error case when the Tor-Foolscap plugin is used, the correct behavior would be to exit with an error telling the user that the Tahoe-LAFS configuration file expresses the desire to advertise a particular onion address but the key material to do so is not present. Too bad! Should we have some sort of "reset-advertised-endpoint" command line tool? It would make it possible to recompute the advertised name based on new input for a dynamic server endpoint (e.g. tcp:0 or onion:80); and it writes the resulting new client side endpoint descriptor string to the tub.location section of the tahoe.cfg. I'd like to use some of my "fun-Fridays" to help clean up the truckee branch so that we can get it merged into trunk. I do like the idea of a heterogeneous grid even though it will not have any anonymity for the storage node operators. Users could select their desired transport for upload or downloading. Furthermore this multi-introducer feature makes it seem like: grids are sets and using multiple introducers gets the union of the sets. But then anonymity policy filters this union... With the "introducerless" feature it should be possible for users to use a variety of grids... and perhaps even a variety of transport protocols with which to talk to those grids. However from their Tahoe client gateway's perspective it is talking to a single grid. Would this even be a desired usage? Perhaps if there were several ipv4+onion heterogeneous grids... some of these grid members might be friends with members of another grid. They could exchange introducer FURLS and use the multi-introducer feature to learn about all the other grid nodes. After that they each have the option to use the "no-introducer" feature to write their static list of storage servers... servers from the union of 2 or more grids. I would think that after combining several grids into one very large grid that you'd want a non-Reed-Solomon erasure encoding scheme more suited for a different set of trade-offs. I'm excited at the prospect of Tahoe-LAFS gaining both a flexible API for storage backend AND network transports; it really seems like we are giving our users and potential developers to tools to surprise us with their own creative solutions to problems. David On Thu, Jun 18, 2015 at 1:02 PM, Leif Ryge <[email protected]> wrote: > On Thu, Jun 18, 2015 at 12:31:16PM -0700, Brian Warner wrote: >> [snip] > > This all sounds great to me! But there are a few edge cases which shouldn't be > forgotten: > > * It could be desirable to connect to a grid (possibly of non-onion storage > servers) using Tor to reach all of the servers *except* the user's own > servers, which are reachable via their LAN or VPN. > > * It could be desirable to have a server listen on both an onion address and > a > LAN address. > > * It could be desirable to connect to some servers via different addresses > than they are advertising (say, because you know its LAN address). > > OK so maybe these are all variations on the same use case, which happens to be > how I want to use Tahoe :) > > I think per-server connection preferences should be exposed via the > introducerless mode which you (Brian) mostly implemented long ago but left > commented out and which David made work in the truckee branch[1]. Speaking of > which, I really need to bring that up to date with the last 6 months or so of > Tahoe development... I'll try to work on that in the near future. > > I'm looking forward to being able to use the i2p grid (which I believe is the > largest and longest running public tahoe grid) and the onion grid > simultaneously! > > ~leif > > [1]: https://github.com/leif/tahoe-lafs/blob/truckee/NEWS.rst > _______________________________________________ > tahoe-dev mailing list > [email protected] > https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev _______________________________________________ tahoe-dev mailing list [email protected] https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
