So Tahoe's current default, when you create a client+server node with
"tahoe create-node", is to:
* allocate an unused TCP listening port number
* run iputil (or ifconfig/etc) to figure out all your IP addresses
* build ADDR:PORT foolscap "connection hints" for all of them
* concatenate the hints
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*
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 express
On 6/18/15 2:56 PM, David Stainton wrote:
> What would happen if the foolscap transport plugin state directory was
> removed but the tahoe.cfg config file remained intact?
With the implementation I'd been considering, it would basically just
re-generate the listener. If that resulted in a differen
On 6/18/15 1:02 PM, Leif Ryge wrote:
> * 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.
How would a client know which ones are "mine" vs
On Thursday 18 June 2015 12:31:16 Brian Warner wrote:
> thoughts?
In the latest release I added a feature allowing specifying a hostname of AUTO
to use autodetection in combination with a fixed hostname. We could keep AUTO
as an option but require the user to specify it explicitly in tub.locatio
On 6/18/15 12:31 PM, Brian Warner wrote:
> * tahoe create-node --listen tcp:0:hostname=example.com
I thought of one problem with this: in the long run, we want to move
away from Foolscap and use (signed) HTTP for storage-server requests. So
we'll want a way to specify that Tahoe should listen on
Brian Warner writes:
> But is that.. useful? Safe? You aren't hiding the server's address.. I
> guess you're making life easier for clients who want to come in via Tor
> (we could make them prefer the onion address, and avoid exit nodes), but
> it'd be slower than the usual tor-to-the-public-IP e
Yes the "direct onion services" are a very good feature for the Tahoe
+ Tor combo... especially with regards to how most people would like
to use tools like Tahoe-LAFS to transfer largish amounts of data.
Furthermore if/when we release Tahoe+Tor integration I'd like to write
a short little release
David Stainton writes:
> I think Tahoe-LAFS "default Tor quickstart" settings would include
> configuration parameters specifying to use a txtorcon launched tor
> process. More advanced users may specify tahoe.cfg parameters to
> utilize the tor control port of an existing tor process.
>From txt
>> * 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.
>
> How would a client know which ones are "mine" vs someone else's?
How would we pr
> 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 o
Just for the record, it is *very* difficult to get a Tahoe-LAFS client
running on Debian 8 to connect to an onion grid. A Tahoe-LAFS code
contributor recently reports having to modify the source of torsocks
so that it works with Tahoe... !!
I'm going to CCC camp... however it doesn't make much sen
On 19/06/15 07:36, Chris Kerr wrote:
> On Thursday 18 June 2015 12:31:16 Brian Warner wrote:
>> thoughts?
>
> In the latest release I added a feature allowing specifying a hostname of
> AUTO
> to use autodetection in combination with a fixed hostname. We could keep AUTO
> as an option but requi
Also, perhaps changing the keyword to 'AUTODETECT' rather than 'AUTO' might
make the configuration easier to understand.
On Thursday 23 July 2015 16:07:37 Daira Hopwood wrote:
> On 19/06/15 07:36, Chris Kerr wrote:
> > On Thursday 18 June 2015 12:31:16 Brian Warner wrote:
> >> thoughts?
> >
> >
On 23/07/15 16:54, Chris Kerr wrote:
> Also, perhaps changing the keyword to 'AUTODETECT' rather than 'AUTO' might
> make the configuration easier to understand.
-1; people are unlikely to find out about "AUTO" except by looking at the
docs or by following someone else's advice, and in both those
Hi Brian Warner and everyone else too,
There's some really good examples of how to use the txtorcon's Tor
hidden service endpoints... that also demonstrate how to properly
determine the generated .onion address from the fired IListeningPort:
https://github.com/meejah/txtorcon/blob/master/examples/
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
David Stainton writes:
Cool, tahoe via Tor :)
If txtorcon is missing features needed for this, let me know what you
need.
Also, I just merged David's "tor:" endpoint stuff, which makes txtorcon
depend on txsocksx now...
> Anyway aside from epemeral HS... I was thinking that ideally the
> Tahoe-
Dear Meejah,
I appreciate all the work you've put into the txtorcon project. I am
very excited about this Tahoe-LAFS integration.
> Cool, tahoe via Tor :)
free NAT penetration via Tor onions means Tahoe-LAFS will be *much*
more useable... and we can possibly change our thinking of all
Tahoe-LAFS
20 matches
Mail list logo
