[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 str4d):

 Replying to [comment:49 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.

 Fair enough. I guess then we just have to clearly document that plugins
 will definitely get "type:" at the start of the string, but everything
 else is allowed to be flexible.

 > 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)`.

 The idea I had is that the plugin must have a `type` attribute, like
 Twisted endpoint plugins have the `prefix` attribute used to identify
 them. If we wanted to support handlers with multiple types, then allow
 `prefix` to be either a string or a list of strings, and then add the
 handler to the dict in multiple places. Alternatively, having
 `tub.register(hint_type, plugin)` means that the user can optionally use a
 handler to handle only one or a few of the types it supports.

 This raises another point: if moving to the dict-style configuration, how
 do we handle the case where two plugins are registered handling the same
 type? Twisted simply uses the first plugin it finds that matches, ignoring
 others. The current setup does the same thing - the first plugin to match
 is used. But in a dict-style system, I expect it would be the last
 foolscap plugin added that is used, because it would replace existing
 ones. The alternative would be that once a handler for a type is added,
 subsequent adds are ignored until `tub.removeAllConnectionHandlers()` is
 called.

 >
 > 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.

 Sounds good.

 >
 > 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:51>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage