Probe IDs

[jsdelivr]

Probe IDs

[patrykcieszkowski]

But that would mean you can target one particular probe and DDoS it - regardless of whether intentional or not. I can imagine a situation, where an incident happens, and engineers wanting to make sure their servers ara available in the area, would pick the first server from the list and start probing; whereas right now, we shuffle the order of probes, so even if we were to implement more sophisticated matching system - multiple requests would be spread accross many probes.

[jimaek]

Yes, that's a risk :(
So you suggest not even trying to solve the above use-case?

[patrykcieszkowski]

We could expand the location query mechanism to sticky values - meaning, they would have to complement one another, as opposed to what we do now - match every location query individually

I think ID matching does make sense, but if we ever do it - it should be behind a paywall, so its controlled

[patrykcieszkowski]

We could expand the location query mechanism to sticky values

We could do something like this:

[
    {
        "type": "nested",
        "value": [
            {
                "type": "country",
                "value": "gb"
            },
            {
                "type": "network",
                "value": "virgin media limited"
            }
        ],
        "limit": 1
    }
]

the logic behind:

• we add a new type, accepting Location[] as a value
• the type can only be used top level
• second-level filter (filter inside nested type) can't supply limit value
• values within the nested type are filtered for common match.

[jimaek]

We implemented the filters part. @MartinKolarik any thoughts on unique IDs and using them to target probes?

[MartinKolarik]

At this point, I see no reason to allow it. We could consider it later if there's a good use case.

[jimaek]

Then I'll close it and see if anyone opens a new issue about it