Do I understand it correctly, that !Delegate z6MkgEMYod7Hxfy9qCvDv5hYHkZ4ciWmLFgfvm3Wn1b2w2FV would be equivalent to this?

- !And
  - !Node z6MkgEMYod7Hxfy9qCvDv5hYHkZ4ciWmLFgfvm3Wn1b2w2FV
  - !AnyDelegate

If there’s a priority choice between the two, I’d rather see !AnyDelegate first, as !Delegate {nid} seems more like added convenience

Another idea could be to have !Canonical instead of !AnyDelegate.

My reasoning for this is that heartwood devs have already dubbed the top-level namespace “canonical” (see https://radicle.zulipchat.com/#narrow/channel/369277-heartwood/topic/.E2.9C.94.20Anyone.20can.20push.20on.20the.20default.20branch.3F/near/526355388)

I want to support !AnyDelegate

The use case behind this is that typically the maintainers of a project are the ones for which CI should run by default. Today, it is possible to achieve this by manually inserting the node IDs of all the project delegates. However, node IDs can change - even if the people behind them don’t. Having some kind of !Delegates filter would avoid the need for reconfiguration of the CI broker whenever the list of node IDs changes, making the broker more ergonomic: it serves the intent (allow CI for maintainers), without forcing the broker operator to manually provide/maintain that list of node IDs, for what can be a large list of repositories.

This is especially relevant in the context of radicle.garden, where we’ll have a lot of repositories for which we really don’t want to manually have to maintain the list of delegates for each broker instance we’re running on behalf of the user. Changes to delegates may even happen outside of radicle.garden, at which point it becomes painful to have to keep track of project identity document changes just to be able to reconfigure the CI broker accordingly.

https://radicle.zulipchat.com/#narrow/channel/452370-radicle-ci/topic/.E2.9C.94.20.5BFeature.20request.5D.20Filter.20jobs.20to.20only.20run.20for.20delegates/near/545589244

“For delegates, please use the DID format (like in the identity payload), not a plain Node ID as suggested in the root comment of linked issue.”

AnyDelegate has now been added in 0dc74cf8e7dee37d0a94005440bfe51f5e669e8f.

I’ll leave this issue open for when Delegate DID needs to become distinct from Node DID