Allow application code to decide whether or not to accept a gift

[ivank]

"[In the future] there might even be an option to turn off introductions altogether." (using-foolscap.html)

It would be nice if incoming/pending gifts could pass through a Tub-level (?) application-defined function that decides whether or not to accept the gift. This would allow the application to do interesting things, including restrictions by gifter, destination address, or general throttling.

[Brian Warner]

Bumping this one: while describing Foolscap's "gift" mechanism to daira and dawuud (in the context of adding Tor support), both were rather surprised that a Tub could be caused to connect to arbitrary IP addresses. They understood that this was a necessary property of a system that could transparently handle references to arbitrary objects (living on arbitrary remote Tubs), but felt that Tahoe doesn't have a need for this feature right now (cross-server share transfer might be the most likely use case, but even that doesn't involve passing a Gift into a *client*), so they'd feel more comfortable if clients could just turn this feature off altogether.

[Brian Warner]

I guess this should be configured with tub.setOption("accept-gifts", False) before starting the Tub (at which point inbound connections can occur and supply their-reference sequences, which is what triggers the Gift connection protocol).

[Brian Warner]

fixed in [812616ce]