[tahoe-lafs-trac-stream] [Tahoe-LAFS] #517: make tahoe Tor- and I2P-friendly

[Tahoe-LAFS]

#517: make tahoe Tor- and I2P-friendly
-------------------------+-------------------------------------------------
     Reporter:  warner   |      Owner:  ioerror
         Type:           |     Status:  new
  enhancement            |  Milestone:  undecided
     Priority:  minor    |    Version:  1.2.0
    Component:  code-    |   Keywords:  privacy anonymity anti-censorship
  network                |  i2p tor-protocol usability
   Resolution:           |
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Comment (by warner):

 Yeah, the intention is that the plugin should make its decision based
 solely upon the "type", defined as "everything before the first colon".
 And everything after the first colon is up for grabs by the type: in
 particular, ipv6 raw addresses will look like `tcp:[fe80::1234:5678]:80`,
 so the type parser won't necessarily just split on colons. That rules out
 a signature of `hint_to_endpoint(pieces, reactor)`. The best we could
 probably do is `hint_to_endpoint(everything_after_the_colon, reactor)`,
 which then feels weird because we're no longer passing full hints around.

 Even if we continue passing full hints into the plugins, we might clean
 things up with the type-to-plugin dictionary you described. I'm not super
 happy about having the plugin return "None" to mean "decline to handle
 this hint". Let's see, that would obligate us to properly move the legacy
 "host:port" handling up out of the `DefaultTCP` plugin (since there'd be
 no way to register a hint type that would match it), but that's a good
 idea anyways. It makes it slightly more work to make a plugin that handles
 multiple types (like a combined "tor:/tcp:"-over-tor plugin), but really
 you just have to register a single plugin multiple times, no big deal.

 I was originally thinking `tub.register(plugin)` and then
 `plugin.hint_type` would be a statically-defined string, but now I'm in
 favor of `tub.register(hint_type, plugin)`.

 So that would change the `hint_to_plugin` implementation: no more
 fallback, and if the regexp fails then the hint was invalid and can be
 ignored (which is distinct from the previous "I don't claim this one, let
 some other plugin give it a try"). Ah, so we also need an "invalid hint"
 error which the !TubConnector can catch/log/ignore.

 I'll see if I can implement the latter before making the release. Thanks
 for the feedback!

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/517#comment:49>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage