discuss: supporting passkey and event hooks for private tracker

[scratchmex]

I think we can get this implementation to work in a private tracker environment with

• passkey in announce url /announce/<passkey>
• event hooks in announce GET requests

It will be under a feature flag as the metrics are right now, so no performance impact on disabled

This will enable to make private tracker extensions

I am up to try to implement them but want to have an opinion on the dev leads here to see if they are up to accept that direction

[greatest-ape]

Hi,

This was previously discussed in #27. I developed a proposal for a solution, with DB stored procedures acting as an "event hook". However, the OP didn't seem to try it out, and I closed the issue a year later.

I think that what makes this difficult to do well in general is that I don't want to add specific code for individual private tracker implementations, but the best solutions would indeed be ones that are tightly coupled with existing other code, DB design and so forth. aquatic will not be very fast if it has to make a DB call for each request, so one would like to use some sort of cache for that, and so on. In the end, aquatic is really just meant to be the most performance public tracker implementation, and private trackers are a different problem space.

I think a better solution would be to write a custom tracker stack tailored to one's existing private tracker code. Logic from from https://github.com/greatest-ape/aquatic/tree/master/crates/http_protocol could be reused. One could probably get very far with a solution utilising, for instance, tokio and Redis. Another option would be to switch to a Rust implementation with private tracker support, such as https://torrust.com/ .

I unfortunately don't have a lot of time for aquatic nowadays, in particular for new features, integrations and so forth, so I will not be likely to work on private tracker support, in particular given that I don't think it is the optimal solution.

[scratchmex]

Thanks for the elaborate response.

You mention you don't want to have private tracker stuff in the code because it will impact performance, which I agree with. But what about having these specific blocks under a compile feature flag? And the code related will be a different module which won't get complied into the public version

I have taken a look into torrust before but I just like your implementation more because it's standalone

[greatest-ape]

Fair enough. But it’s also the question of designing it, implementing it, and critically, maintaining it. I’m not completely opposed to the idea, but for the time being, I can’t commit to it. However, you can leave the issue open if you’d like.