>> * 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 provide this feature? What would the config file options look like? I am reminded of the "introducer-less" feature I helped add to Leif's truckee branch. Each storage server has an entry in the config file... well in this case instead of specifying ALL of the storage server info we are only interested in specifying the storage server connection hint override. Or I suppose instead of a full connection hint string the client config override option could just specify a transport network layer "type" such as "tor" or "ipv4"... Am I on the right track or should we just design and implement this feature later when Tor integration is completed? If you went to a friend's house who participates in the same grid as you do... and you brought your laptop with you then you might also want to set an "override storage endpoint descriptor string" so that your tahoe client connects to the local address. >> * It could be desirable to have a server listen on both an onion >> address and a LAN address. agreed. especially in light of the upcoming "direct onion service". > Hm. Foolscap's API makes it pretty easy to listen in multiple ways (you > call tub.addListener(spec) multiple times). I'm not sure how to best > express that from the Tahoe side, though. "--listen=X,Y"? "--listen=X > --listen=Y"? > > I suppose you could hack it by having tahoe listen on TCP port X, > configure your Tor HS to forward onion connections to localhost:X, and > then advertise "HOST:X,onion:HS.onion:80". ouch. i'd like to avoid telling users to do that. i prefer your second method to express it: "--listen=X --listen=Y" > 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 exit-node style. Who > would it protect? useful it is. safe... it depends on threat model. i think we'll see the upcoming "direct onion services" being used in a intentionally deanonymized fashion to consume fewer resources on the tor network. >> * It could be desirable to connect to some servers via different >> addresses than they are advertising (say, because you know its LAN >> address). > > Huh, that's tricky. I can imagine a local override table, something that > says "if you ever want to talk to host X, use this hint Y instead of > whatever their FURL said". But that'd be kinda wacky. Did I really > implement such a thing? :). yes... a local override table. wacky it is. I suppose the "introducer-less" feature is a override table of sorts and could be used for this purpose right now? >> 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! > > Having a server listen on both .onion and .i2p at the same time makes a > lot more sense to me than onion+TCP. agreed. _______________________________________________ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
