yay! i'm excited for this native Tor integration project. The default Tahoe-LAFS+Txtorcon behavior will persist hidden service key material to a private client config directory... however I'm sure that ephemeral storage nodes would easily be possible as well;
I envision ephemeral Tahoe-LAFS onion service nodes would be configured as such via a combination of a tahoe.cfg setting specifying a ephemeral=True listening endpoint paramater as well as SystemD unit files that caused the periodic restart of the Tor and Tahoe-LAFS processes. Anyway aside from epemeral HS... I was thinking that ideally the Tahoe-LAFS user would select whether to launch a new tor process or to use an existing tor process. Either the location of tor would be known or guessed... or the socks port and control port must be known... and we'd also want to provide the location of the tor control port cookie auth file. Qubes users for instance might want their laptop's instance of Tahoe-LAFS to run in a separate vm from the vm running tor. Other users might not care as much and prefer the convenience of auto-launching tor. Further I think by default weather the user is using the auto-launched tor process or a preconfigured tor process.... client Tor connections and onion service connections should utilize the same tor process. We'll be using our own "transport plugin" system for Foolscap... and each of these transport plugins will utilize client and server endpoints. However, we won't be limited by the endpoint options exposed to the Twisted endpoint parser plugin system... because of using our own plugin system... we can instantiate endpoint objects however we want; with or without the help of the endpoint parser plugin system. _______________________________________________ tahoe-dev mailing list [email protected] https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
