how does a RP know their setup is successfuly able to complete a job?

[AquiGorka]

I've been thinking on an approach to target specific nodes for a job, we could use that here. The idea is that we have a special syntax or an attribute to a job target=<node_public_address> or module: target_node_public_address__cowsay:v0.0.4, then when the matchmaking happens we do not send the job spec to nodes that are not the targeted public address.

A first iteration will work with us implementing this at the job creator or solver service level, but an ideal solution would also check if the DealAgreed transaction comes with some signature from the pk for the targeted public address.

Once the mechanism is in place, the node user can trigger any job they want and target their own node.

[richardbremner]

I'm not too sure of the mechanisms, but I feel like an ideal solution would be that the deal can only be won by the target resource provider

[AquiGorka]

The current allowList (Modules) mechanism goes like this (it is the solver's controller): loop through open deals and find a match that allows the module to be executed. I've asked @noryev to refactor the allowList from a []string (module_id + version, eg cowsay:v0.0.4) to a more flexible structure:

[{
  ModuleId string
  Version string
  Enabled bool
}]

eg:

[{
  ModuleId: "lilypad-tech/cowsay"
  Version: "v0.0.4" <- should allow pattern matching ([reference](https://devhints.io/semver))
  Enabled: true
}]

Then, the solver will not offer the job to the resource provider if there is no match with the set criteria.

Now that this has been identified and refactor into a more flexible structure, we can also add a target([]string) param to running cli jobs. When the solver is trying to find a match, it should also consider if the job offer includes a target (or targets) and give the deal to the first target it can find, we can assume the list is sorted in the order of preference if there is more than one target

What about onchain jobs and deals made outside of our stack?

Other software can be listening in on the blockchain and try to agree to a deal even if the criteria does not match, that's why I mentioned the smart contract "accepting" the deal agreed tx could also do some checks to see if the job is targeted.

[AquiGorka]

Some extra content for the options when setting the allow modules:

Allowlist is empty: matches everything
Allowlist only has enabled false items: matches everything, except the prohibited items
Allowlist only has enabled true items: matches nothing, except the allowed items
Allowlist has both (enabled and disabled): matches nothing, except the allowed items