whitelist/filtering of torrent info hashes about bittorrent-tracker

[astro]

Alternatively, letting the user override Server.prototype._getSwarm() will allow custom peer database backends. I wouldn't want to keep all that data in v8 when running a huge tracker.

[feross]

I see, so we could support filter by treating a null return value from _getSwarm as an indication that the torrent should not be tracked. That should work for @pwmckenna's use case.

@astro One other thing to figure out: how will you determine when the properties of the returned swarm object (swarm.complete, swarm.incomplete, swarm.peers) is changed? You need to know when values change in order to update the custom storage backend.

[pwmckenna]

While filtering could piggyback on the storage adapter solution, they feel like very different issues. I'd find an explicit solution more intuitive than one where I have to override a method and return a value that is understood to mean "I'm intentionally not supporting this swarm because its hash doesn't match a whitelist". Certainly not tied to the api I suggested, but I'd prefer to not override something to return null to achieve whitelisting.

[pwmckenna]

with regards to the storage adapter...i took a quick look and realized that everything in there assumes synchronous gets/sets. to convert everything to async, do you have a preference of supporting lib (async/q/etc...), or just straight callbacks all the way through?

[feross]

@pwmckenna, fair enough. I would accept a PR that added a filter option, as demonstrated in your initial code example.

If we need flow control, I prefer using run-parallel, run-series, run-auto, etc. which are just extracted out of async.

[feross]

@pwmckenna Astro's getSwarm changes are in, so it would be pretty easy to send a PR to add filtering now.

[feross]

Implemented in #57 and released as 3.0.0.