removing IP-address autodetection, Tor integration

[David Stainton]

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 <leif at synthesize.us> 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
> tahoe-dev at tahoe-lafs.org
> https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev