listKnownParties from Daml Triggers

Questions
1

I would like to find out if there are any constraints or plans in having listKnownParties supported in the context of a Trigger.

I would like to have a Trigger which runs against a Ledger to correct the ACS to ensure that some contracts (either to all parties or to parties with a certain hint) are properly observed.

1 Like
2

There are no such plans. I can’t think of any particular constraints, but I might be missing something; we generally want to be cautious of what actions we add to the trigger and script languages.

I am not sure this feature would do what you want. Each trigger runs as a particular party, with a particular JWT access token; that trigger can itself only access contracts that the given party has access to, and can only add itself as signatory to anything. Do you have a party that observes all contracts you’re interested in checking this condition against?

Regardless, if you like, you might submit a feature request.

2 Likes
3

I think first it’s useful to take a step back: Daml is really designed for distributed, open-world networks. In an open-world setting building things around universal statements of the form “all templates”, “all parties”, … are usually problematic and are going to result in apps that cannot coexist nicely.

The best listKnownParties can give you is a temporary snapshot of all parties known to the participant (which does not necessarily include all parties on the ledger in distributed settings) and even that requires admin claims which are not available to a trigger.

So instead I’d recommend to change things around:
Rather than have the trigger read the parties from the party admin service, store the list of parties the trigger should interact with in a config contract. This contract can look as follows:

template Config
  with
    triggerParty : Party -- The party your trigger is running as
    otherParties : [Party]
  where
    signatory triggerParty
    key triggerParty : Party
    maintainer key

The trigger rule can then look for this contract and read the parties from that.

You are completely free to handle creation of that contract and updates how you want. This can range from a manual creation once to a process that polls listKnownParties periodically or something else depending on your usecase. I’d recommend against relying on the hint for this though. First, you cannot read the hint from the party management service, you can only set it on allocation. Second, it’s handled differently by different ledgers which makes it hard to write a portable app. Instead try to keep track of parties as they are allocated and use the resulting party ids directly.

Finally, depending on your usecase you might also be interested in multi-party submissions Roles in Daml - Introducing Multi-party submissions. I’m not quite sure I grasp what you are trying to achieve but it sounds like having one party as an observer on all contracts you want to share and then providing readAs claims for that party to everyone might also work.

5 Likes
4

Thank you for the contributions thus far :slight_smile: More contributions are certainly welcome.

The Config contract approach looks like it will address the need; given that I already have a Trigger to ApproveRoles - so I could exercise a choice to update the config contract whenever a role is approved for the party.

I considered leveraging multiparty submissions as the last resort and relying on the Daml Hub Public-party and an extra observer party as a fail-safe

2 Likes