Add a config option to change the scrape behavior for listed trackers

[josecelano]

Relates to: #1268

Context

When the tracker is running in listed mode (whitelist) and the client performs an scrape request you get a list with all requested torrents even if some of them are not included in the allowed torrents list.

Current behavior

For the announce request, the request is rejected immediately (in the controller) and the client receives an error.

For the scrape request, there is no check at the controller level. All requests reach the domain layer. The scrape handler includes all the requested torrents in the response. However, torrents that have not been included in the whitelist return zeroed stats.

Proposal

For me, It's confusing to return always data for non-allowed torrents because there is no way to know if that torrent is not allowed or there is no data for the torrent because there are no peers yet.

I think there are some alternatives:

1. Return zeroed data for the not allowed one (what we are doing right now).
2. Return info only for the allowed ones.
3. Return an error.

• With a generic message indicating that at least one of the requested torrents is not allowed.
• With a message indicating the list of non allowed infohashes.

I think option 2 is the best because:

• The client can know anyway if a torrent is included in the list or nor by making an announce request for that torrent.
• The client can stop scraping non allowed torrents because it would have a way to know that the torrent is not allowed, directly from the scrape response.
• If we confirmed that is the common behavior, we would follow the non-official but common practices.

NOTE: If we just change the response that would be a breaking change because clients always expect to receive one item for each torrent in the response. If we decide to simply change it it should be done in the next major version. Alternatively we can add a new config option to let the admin decided which beauvoir wants to enable.

AI research

Prompt:

I'm a software developer and I'm maintaining an open-source project called Torrust Tracker. It's a BitTorrent tracker written in Rust. The tracker implements the `scrape` requests returning stats about some requested infohashes. The tracker can also run in `listed` mode meaning actions are only allow on a list of predefined torrents. 

In the current implementation for the scrape the tracker always return a list with all the requested torrents (up to a maximum) even if the torrent is not included in the whitelist. In those cases the tracker return empty (zeroed) stats.

I was wondering if that is the correct behavior because when the client receives empty stats for a torrent It cannot derive from the response if the torrent is not allowed (whitelisted) or there are no metrics for that torrents yet.

I think excluding the torrents for the results would be a better approach. I would like you to analyse both approaches deeply considering:

- What other popular tracker implementations do
- Other alternatives like allowing the tracker admin to decide what to do in this cases
- What other similar protocols do in this cases
- Pros and cons for the options I have proposed and new alternatives you can add

I want you to reply as an expert in BitTorrent protocols and experienced developer in this type of protocols or similar.

Claude 3.5 Sonnet (Anthropic):

As someone who has worked extensively with BitTorrent protocols and distributed systems, I'll analyze this situation comprehensively.

First, let's look at how other major tracker implementations handle this:

1. OpenTracker: Excludes non-whitelisted torrents from scrape responses
2. Ocelot (What.CD/Private Trackers): Only returns data for whitelisted torrents
3. Chihaya: Configurable behavior, but defaults to excluding non-whitelisted torrents

The current standard practice seems to favor excluding non-whitelisted torrents from responses.

Let's analyze the approaches:

**1. Current Implementation (Return Zero Stats)**
Pros:
- Maintains a consistent response structure
- Clients get responses for all requested infohashes
- Simpler client-side handling (no need to check for missing entries)

Cons:
- Ambiguous meaning of zero stats (non-existent vs. non-whitelisted)
- Potentially misleading for clients
- Wastes bandwidth including unnecessary entries
- Could leak information about tracker's whitelist implementation

**2. Excluding Non-whitelisted Torrents**
Pros:
- Clear semantics: if it's not in the response, it's not tracked
- Bandwidth efficient
- Follows principle of least privilege
- Consistent with private tracker implementations
- Better security (doesn't leak whitelist information)

Cons:
- Clients need to handle partial responses
- Slightly more complex response handling

**3. Configurable Approach**
Pros:
- Flexible for different use cases
- Administrators can choose based on their needs
- Can implement different behaviors for different security levels

Cons:
- More complex implementation
- Potential for inconsistent behavior across tracker instances
- Additional configuration maintenance

Looking at similar protocols:

1. DNS: Returns NXDOMAIN for non-existent domains rather than empty records
2. LDAP: Returns no entry rather than empty data for non-existent objects
3. HTTP: Returns 404 rather than empty content for non-existent resources

The common pattern in similar protocols is to exclude non-existent resources rather than return empty data.

**Recommendation:**

Based on this analysis, I recommend:

1. Primary Recommendation: Change to excluding non-whitelisted torrents from scrape responses
   - This aligns with industry standards
   - Provides clear semantics
   - Better security
   - More efficient

2. If flexibility is important, implement as a configurable option:

pub enum NonWhitelistedTorrentBehavior {
    Exclude,           // Don't include in response
    ReturnZeroStats,   // Current behavior
    ReturnError        // Return specific error code
}

The change would involve:

pub fn handle_scrape(&self, infohashes: Vec<InfoHash>) -> ScrapeResponse {
    let mut response = ScrapeResponse::new();
    
    for infohash in infohashes {
        if self.is_whitelisted(&infohash) {
            if let Some(stats) = self.get_torrent_stats(&infohash) {
                response.add_torrent(infohash, stats);
            }
        }
        // Non-whitelisted torrents are simply omitted
    }
    
    response
}

This approach:
- Is more secure
- Follows protocol conventions
- Is more efficient
- Provides clear semantics
- Aligns with how private trackers typically operate

Remember to document this behavior clearly in your API documentation so clients know what to expect.

o1 (OpenAI):

Below is a discussion from the viewpoint of someone who has worked with various BitTorrent trackers, maintained open-source implementations, and studied protocol behavior in similar contexts. I’ll start by describing what commonly happens on other trackers, then lay out the possible approaches for handling “scrape” requests for torrents that are not on a whitelist.

──────────────────────────────────────────────────────────
1. Common Practice in Popular Tracker Implementations
──────────────────────────────────────────────────────────

1.1. Official or Highly Used Trackers  
• Many large or “official” trackers (e.g., private trackers, specialized trackers) operate on a whitelist, but they often maintain their own rules for scrape responses.  
• Some trackers—especially older, closed-source ones—simply do not respond with data for torrents that are not tracked. They omit unknown or unlisted torrents from the scrape response entirely.  
• Others deliberately include all requested infohashes in the scrape response but set the stats to zero if the torrent is not recognized. This approach stems from the original concept of the scrape being a public endpoint with minimal overhead.  

1.2. OpenTracker / Public Trackers  
• The open-source “opentracker” is a well-known minimalistic implementation that often returns zero stats for infohashes it doesn’t track. Because these trackers don’t do whitelisting in the typical sense, they don’t need to omit anything.  
• Some privacy-focused or private trackers (e.g., XBT Tracker or Chihaya) have configurable mechanisms. In some modes they omit unrecognized torrents, in others they show them with zero stats.  

From this perspective, hosting an option or a configuration mechanism is not uncommon. Some trackers default to “show all with zero stats,” whereas others default to “omit unknown infohashes.”

──────────────────────────────────────────────────────────
2. Analysis of Approaches
──────────────────────────────────────────────────────────

Approach A: Always Return All Requested Infohashes (With Zeroed Stats for Non-Whitelisted)  
• Behavior: The scrape response always contains entries for all requested infohashes, but those not recognized or not on the whitelist have 0 seeders, 0 leechers, etc.  
• Pros:  
  1. Informative in the sense that a client learns that the torrent is known by the tracker… or at least the tracker responded with “we have zero stats.”  
  2. Minimally invasive approach: easy for clients that request the entire set of infohashes; they can correlate the results in the same order they were requested.  
  3. Easy to implement.  
• Cons:  
  1. Ambiguity for clients: zero stats might mean “no peers yet” or “torrent is not tracked or whitelisted.” The client cannot distinguish between these two scenarios.  
  2. In a private/whitelist scenario, you might not want to reveal that a torrent is disallowed or get “tipped off” that the torrent is unknown.  
  3. Inefficient if the client is requesting many infohashes and the majority are not whitelisted (the user might prefer a more explicit response).  

Approach B: Omit Non-Whitelisted Tors from Scrape Results  
• Behavior: Return only infohashes that are recognized/whitelisted, ignoring the rest.  
• Pros:  
  1. Clearer signal to the client that the requested torrent is not tracked: it simply doesn’t appear.  
  2. Saves bandwidth if many requested infohashes are known to be invalid or not whitelisted.  
  3. Adheres to how some private trackers operate, making it consistent with “if we don’t track it, we don’t talk about it.”  
• Cons:  
  1. The client might wonder if the tracker is ignoring the infohash or if the request got truncated somewhere. This can be mitigated by partial or error-like responses, but it can still be ambiguous without a consistent specification on the client side.  
  2. Some users or clients might prefer the uniform “N results for N queries” approach, especially if they rely on the order of responses.  

──────────────────────────────────────────────────────────
3. Possible Middle-Ground or Configurable Approaches
──────────────────────────────────────────────────────────

3.1. Configurable “Scrape Handling” Setting  
• Tracker administrators could choose:  
  1. “Return all with zero stats” (current approach).  
  2. “Omit those not whitelisted” (private-torrent approach).  
• This is arguably the most flexible solution: let the site’s or project’s policy guide the behavior.  

3.2. Separate Flags in the Response  
• A more advanced approach might be to include an explicit marker (flag) indicating a torrent is not tracked or is disallowed. However, the standard BitTorrent scrape response format is not designed to carry arbitrary metadata. You often have a dictionary with seeds, leeches, etc.  
• Introducing non-standard fields runs the risk of poor client compatibility.  

3.3. HTTP Status or Partial Errors  
• Some trackers that run behind an HTTP server can do partial responses with 404 (Not Found) or 200 (OK) but with a narrower set of results. However, direct client code that expects the “bencoded” scrape structure typically expects it for all requested infohashes.  

3.4. Rate-Limiting or Throttling Unwanted Infohashes  
• An additional concept: if many requests come in for unwhitelisted torrents, some trackers will eventually block the requests or drastically reduce the quality of the data. This is orthogonal to your question but relevant for tracker policy.  

──────────────────────────────────────────────────────────
4. Considering Similar Protocols
──────────────────────────────────────────────────────────

4.1. DNS Query Behavior  
• DNS resolvers either return “NXDOMAIN” (non-existent domain) or an empty result—both are explicit. This parallels the question of whether to respond with “no peers” or omit the entry.  
• Typically, DNS doesn’t return partial or ambiguous data. It returns an authoritative answer or an error code. By analogy, this might suggest an “omitting unknown torrents” approach is more consistent with the idea of an authoritative tracker.  

4.2. RESTful/GraphQL APIs with “Sparse Fieldsets”  
• In REST or modern APIs, partial results are common when some resources are invalid. Typically, the response might skip invalid resources (or attach an error field). However, that’s because the schema is more flexible—BitTorrent’s bencoded scrape is historically quite minimal.  

──────────────────────────────────────────────────────────
5. Detailed Pros & Cons
──────────────────────────────────────────────────────────

Below is a more focused comparison table for the two main approaches (plus a hybrid idea):

Approach A: Return All Infohashes (Zero Stats If Not Whitelisted)
• Pros:  
  – Simpler, no new metadata needed.  
  – The client or aggregator can see a one-to-one mapping of requested infohashes.  
  – Less likely to break naive clients that expect as many scrape entries as were requested.  
• Cons:  
  – Clients cannot differentiate a whitelisted torrent with zero peers from a non-whitelisted torrent.  
  – Potentially wastes response bandwidth if there are many non-whitelisted torrents.  

Approach B: Omit Non-Whitelisted Infohashes
• Pros:  
  – Makes it clear the tracker is not tracking certain torrents at all.  
  – Could be considered more “secure” or “private,” since you’re not giving out any information about those torrents.  
  – In many private trackers, you simply never see data for torrents not recognized by the system.  
• Cons:  
  – Clients might be confused if they expect one entry per infohash—some older or naive client libraries might incorrectly handle fewer results.  
  – Requires you to be careful in how you document the behavior, so clients know that “missing torrent = not tracked.”  

Approach C: Configurable Policy
• Pros:  
  – Flexibility to accommodate different user communities, from public to heavily private.  
  – Administrators can decide based on the environment which approach is most consistent.  
• Cons:  
  – Must maintain and test multiple modes.  
  – Could confuse new users of your tracker if the difference in modes is not adequately documented.  

──────────────────────────────────────────────────────────
6. Recommended Path Forward
──────────────────────────────────────────────────────────

Based on both historical usage and the advantages of clarity, it can be quite appealing to omit the torrents that are not on the whitelist. This provides an unambiguous signal: if the torrent does not appear, it is not recognized by the tracker. That said, some older or simpler clients might always assume the scrape returns the same count of items as requested. Therefore:

1. Consider a Configurable Approach:  
   – Default to “omit unlisted/whitelisted torrents from results”—this is closer to how a private tracker typically behaves, and it’s unambiguous.  
   – Provide a config or compile-time setting to “include all requested infohashes (with zero stats).” This keeps backward compatibility for any client or user base expecting that behavior.

2. Provide Clear Documentation:  
   – In your README or documentation, explicitly state how the tracker responds in “listed” mode or “open” mode.  
   – Mention that when a torrent is not recognized, it is omitted (in the default setting).  

3. If You Want Extra Transparency:  
   – You could offer an extended scrape format that includes a “whitelisted: bool” or “tracked: bool” field. But know that this will likely not be standard bencoded data. Some advanced peers or private ecosystems might appreciate this. However, you must ensure it doesn’t break clients that expect the standard bencoded structure.

──────────────────────────────────────────────────────────
Conclusion
──────────────────────────────────────────────────────────

In summary:  
• Returning zero-row stats for unrecognized torrents is a common minimalistic design, but it can be ambiguous.  
• Omitting unrecognized torrents from scrape results is often the clearest from a “private or whitelist” stance and aligns with practices of many private trackers.  
• Ultimately, introducing a configurable knob in Torrust Tracker is the most flexible solution. You can default to one behavior (likely “omit unrecognized for clarity”), but still allow advanced or legacy usage to return all requested infohashes.  

This approach makes sense from both a user-experience perspective (those expecting a private tracker) and a developer perspective (existing code that might rely on consistent counts). Providing such flexibility, while clearly documenting it, is likely to satisfy the broadest range of use cases.

Gemini Flash 2.0 (Google Vertex):

Okay, let's dive deep into this issue of handling `scrape` requests on a whitelisted (or "listed") BitTorrent tracker, specifically in the context of your Torrust Tracker project. This is a nuanced issue with no single definitive "correct" answer, but a careful consideration of the trade-offs is essential.  I'll approach this as someone with experience in distributed systems, networking protocols, and the specific subtleties of BitTorrent.

**Understanding the Problem**

The crux of the problem is information leakage. By returning *something* for a disallowed infohash, even if it's all zeros, you're implicitly revealing that the tracker *knows* about that infohash but isn't serving it.  This can be valuable information to someone trying to circumvent your whitelist.

**Analyzing Approaches**

Here's a breakdown of the approaches you've identified, plus some additional alternatives:

1.  **Current Behavior: Return Zeroed Stats for Disallowed Torrents**

    *   **Pros:**
        *   Simplicity of Implementation:  Easiest to implement as it involves minimal conditional logic.
        *   Potentially Less Client Error Handling: Some clients *might* expect to receive a response for every requested infohash in the scrape request.  Skipping some might lead to unexpected errors (though well-behaved clients *should* handle this).
    *   **Cons:**
        *   Information Leakage:  As discussed, reveals the existence of the infohash and the fact that it's not whitelisted.  This is the biggest concern.
        *   Incorrect Interpretation: Clients may not understand this behavior. They might think the torrent *exists* but has no peers, seeds, or activity, leading to confusion.
        *   Wasted Bandwidth:  While small, sending zeroed data for many disallowed torrents adds up.

2.  **Proposed Behavior: Exclude Disallowed Torrents from the Scrape Response**

    *   **Pros:**
        *   More Secure (Less Information Leakage): Doesn't reveal anything about disallowed torrents.  The client simply doesn't know if the tracker has ever heard of that infohash.
        *   Clearer Semantics:  A missing torrent from the scrape response clearly means "I don't serve this" or "I don't know about this."
        *   Improved Privacy: The client does not know if the torrent is actively being tracked, or even if it actually exists on that tracker.
    *   **Cons:**
        *   Potentially More Complex Client Handling: Clients need to be robust enough to handle partial responses.  While most well-written clients should do this correctly, it introduces a potential point of failure.
        *   Slightly More Complex Implementation: Requires filtering the response to remove disallowed torrents.

3.  **Alternative: Return an Error Code in the Scrape Response**

    *   Instead of zeroed data, return a specific error code (defined in a custom extension) for disallowed torrents.  This error code could be something like "TORRENT_NOT_ALLOWED" or "TORRENT_NOT_FOUND".
    *   **Pros:**
        *   Explicit Information:  The client knows specifically *why* it's not receiving data.
        *   Potentially Useful to Clients:  Clients can log this information or take specific actions (e.g., stop trying to download that torrent).
    *   **Cons:**
        *   Requires Protocol Extension: Requires the client to be aware of and support the custom error code. This makes it less compatible with standard BitTorrent clients.
        *   Information Leakage: Still reveals the existence of the disallowed torrent, albeit with a reason.
        *   Increased Complexity: Necessitates introducing new message formats and error handling in both the tracker and the client (if it implemented).

4.  **Alternative:  Configuration Option for Tracker Admin**

    *   Introduce a configuration option that allows the tracker administrator to choose between:
        *   Returning zeroed stats (Option 1)
        *   Excluding disallowed torrents (Option 2)
        *   (Potentially) Returning an error code (Option 3)
    *   **Pros:**
        *   Flexibility: Admins can choose the behavior that best suits their needs and security posture.
        *   Cater to Different Use Cases: Some admins may prioritize compatibility over security or vice versa.
    *   **Cons:**
        *   Increased Complexity: Adds more configuration options to your tracker.

**What Other Trackers Do**

This is where it gets tricky, as there's no universally standardized behavior. The BitTorrent protocol is quite loosely defined. However, here's what I've observed:

*   **Private Trackers (Typically Whitelisting):** These trackers often choose to *exclude* disallowed torrents from the scrape response. The emphasis is on security and avoiding information leakage. They're more willing to assume their users are using modified or custom clients.
*   **Public Trackers:** Often serve a very broad range of torrents and generally don't have strict whitelists. The issue of excluding non-existent torrents from scrape requests is a bit different, but they often also choose to *exclude* them if the tracker has no record of them (because they were never announced).

**What Other Similar Protocols Do**

In other distributed systems and protocols where access control lists (ACLs) are used:

*   **Authentication/Authorization Failures:** The prevailing best practice is to *fail silently* when a request is denied due to missing permissions. You generally don't want to reveal to a potential attacker that the resource exists but they lack access.
*   **API Design:**  APIs often return 404 NOT FOUND for resources that the user doesn't have access to, even if the resource technically exists.  This is to avoid leaking information about the system's internal structure.

**Recommendation**

Considering the trade-offs, my **strong recommendation** is to **exclude disallowed torrents from the scrape response (Option 2)** for your Torrust Tracker. Here's why:

*   **Security:**  Minimizes information leakage, which is crucial for whitelisted trackers.
*   **Clarity:**  Avoids the ambiguity of zeroed stats.  A missing entry means no service.
*   **Alignment with Best Practices:**  Mirrors the approach taken by many private trackers and adheres to principles used in secure API design.

**Addressing Potential Client Issues**

*   **Documentation:**  Clearly document this behavior in your Torrust Tracker's documentation.  Explain that clients should expect partial responses and handle them gracefully.
*   **Client Testing:** As you implement this change, test against a variety of existing BitTorrent clients to identify any compatibility issues.
*   **Consider a Configuration Option (Optional):** If you are concerned about the client-side implications, seriously consider implementing the configuration option discussed above. Allowing a tracker administrator to set the desired behavior would go a pretty long ways towards resolving issues.

**Code Considerations**

*   **Efficiency:**  Ensure your filtering logic is efficient.  Use appropriate data structures (e.g., a hash set for your whitelist) for fast lookups during the scrape request processing.

**In summary:** While there are valid arguments to be made for retaining zeroed stats, the security benefits of excluding torrents from the scrape response are compelling, especially for a whitelisted tracker where information security is paramount. Just be prepared to document this clearly and test against a variety of clients.

Grok 2 1212 (xAI)

As an expert in BitTorrent protocols and an experienced developer in this field, I'll analyze the issue you're encountering with the `scrape` request behavior of your Torrust Tracker, especially in the context of its `listed` mode. I'll consider your two proposed behaviors and extend the discussion with additional considerations and alternatives.

### Current Implementation Analysis

Your current implementation in the `scrape` request returns stats for all requested torrents, including those not present in the whitelist, with empty (zeroed) stats for non-whitelisted torrents. This behavior raises the ambiguity you pointed out: a client cannot discern whether a torrent with zeroed stats is not whitelisted or simply has no activity.

### Proposed Approach 1: Returning Empty Stats for All Requested Torrents

**Pros:**
- **Consistency in Response Format:** The client always receives a response containing all the requested torrents, maintaining a consistent structure in the response which might simplify client-side parsing and handling.
- **Non-disclosure of Whitelist:** By returning zeroed stats for non-whitelisted torrents, you don't explicitly reveal which torrents are not allowed, which could be considered a privacy or security feature.

**Cons:**
- **Ambiguity:** As you noted, clients cannot distinguish between non-whitelisted torrents and torrents that are simply inactive or new.
- **Potential for Misinterpretation:** Clients might incorrectly interpret the zeroed stats as a sign to retry scraping or a false indication that the torrent has no peers or seeds.

### Proposed Approach 2: Excluding Non-Whitelisted Torrents from Results

**Pros:**
- **Clarity:** Clients receive only the stats of whitelisted and active torrents, clearly indicating which torrents are actually part of the tracker and available for scraping.
- **Efficiency:** Clients receive fewer data, potentially reducing bandwidth usage and improving response times.

**Cons:**
- **Variable Response Format:** Clients need to handle variable-length responses, which might complicate the parsing logic on the client side.
- **Disclosure of Whitelist Information:** By excluding non-whitelisted torrents, you implicitly reveal which torrents are allowed on the tracker.

### Analysis of Popular Tracker Implementations

1. **Opentracker:** This tracker does not implement a whitelist but has been known to ignore requests for torrents not found in its database. This implies a natural form of "exclusion" for non-existent torrents, similar to Approach 2.

2. **Chihaya:** A high-performance tracker designed for use with private trackers. It generally operates under strict policies and might only return data for torrents that match predefined criteria, which aligns closer to Approach 2.

3. **BEP (BitTorrent Enhancement Proposals):** The BEP 48 proposal discusses tracker protocol extensions, but does not specifically address the behavior for whitelisted trackers. However, general practices in BEP suggest clarity and efficiency (Approach 2) would be favored.

### Alternatives and Configurability

**Configurable Behavior:**
- Allow the tracker admin to configure the response behavior for non-whitelisted torrents. Options could include returning zeroed stats, excluding them, or returning an error status for non-whitelisted torrents.
- **Pros:** Flexible to different operational requirements and security/privacy policies.
- **Cons:** Increases complexity in both server and client implementations due to varied possible responses.

**Return Error Status for Non-Whitelisted Torrents:**
- Instead of zeroed stats or exclusion, the tracker could return an error status or a special value indicating the torrent is not allowed.
- **Pros:** Provides clear feedback to clients while not exposing the whitelist.
- **Cons:** Clients need to handle an additional type of response, which might complicate their logic.

### Other Similar Protocols

In the realm of other P2P protocols like those used by IPFS or Dat, clarity and efficiency (similar to Approach 2) are often prioritized to optimize network usage and performance. However, these protocols typically don't implement whitelisting in the same way as BitTorrent trackers might.

### Recommendations

Given the analysis:
1. **Adopt Approach 2 (Exclusion from Results):** This is likely the most efficient and clear approach for clients, aligning with general trends in both BitTorrent and broader P2P networking.
2. **Consider Configurability:** Implement options that allow admins to choose how the tracker responds to requests for non-whitelisted torrents. This flexibility could cater to different security and operational needs without overly complicating the client's parsing logic.

By implementing these recommendations, your Torrust Tracker can improve its usability and flexibility, catering to a broader range of use cases and operational policies.

cc @da2ce7 @mario-nt @grmbyrn

[da2ce7]

R1 (summary) - I tend to agree with the analysis.

Summary of Scrape Behavior Options for Whitelisted Trackers:

1. Current Approach (Return Zero Stats):

   • Pros: Simple, consistent response structure.
   • Cons: Ambiguity (can’t distinguish disallowed vs. inactive torrents), bandwidth waste, potential info leakage.

2. Exclude Non-Whitelisted Torrents:

   • Pros: Clear semantics (missing = disallowed), aligns with private trackers (e.g., Chihaya), bandwidth-efficient, secure.
   • Cons: Requires clients to handle partial responses; older clients might misinterpret omissions.

3. Configurable Behavior:

   • Allow admins to choose between exclusion, zeroed stats, or error codes.
   • Pros: Flexibility for public/private use cases.
   • Cons: Adds complexity; potential inconsistency across instances.

Industry Consensus:

• Exclusion is recommended for clarity and security, mirroring private trackers and protocols like DNS/HTTP.
• Optional configurability accommodates legacy needs but prioritize omission as the default.

Implementation Advice:

• Use efficient whitelist checks (e.g., hash sets).
• Document behavior clearly to guide client developers.
• Test with major clients to ensure compatibility with partial responses.

Bottom Line: Switch to excluding non-whitelisted torrents by default, offering configurable options if needed. This balances security, clarity, and efficiency while aligning with industry norms.