Is it right that I cannot extract template signatories using the DAML LF API Type Signature app?

Questions
1

I cannot see this in the skeleton/Asset template details returned by the DAML LF API Type Signature app:

Main:Asset
Template(Record(IndexedSeq((issuer,TypePrim(PrimTypeParty,IndexedSeq())), (owner,TypePrim(PrimTypeParty,IndexedSeq())), (name,TypePrim(PrimTypeText,IndexedSeq())))),DefTemplate(Resolved(Map(Archive -> Map(None -> TemplateChoice(TypeCon(TypeConName(d14e08374fc7197d6a0de468c968ae8ba3aadbf9315476fd39071831f5923662:DA.Internal.Template:Archive),IndexedSeq()),true,TypePrim(PrimTypeUnit,IndexedSeq()))), Give -> Map(None -> TemplateChoice(TypeCon(TypeConName(db89f71fb6ece132c9103f1ce984feb6f123f621072d35b389485798eac3fc6e:Main:Give),IndexedSeq()),true,TypePrim(PrimTypeContractId,IndexedSeq(TypeCon(TypeConName(db89f71fb6ece132c9103f1ce984feb6f123f621072d35b389485798eac3fc6e:Main:Asset),IndexedSeq()))))))),None,Vector()))

This is not part of DAML-LF?

2

To your question in the subject, yes, that is right.

api-type-signature deliberately excludes everything that wasn’t interesting for codegen, JSON API, or its other downstreams in the daml codebase. That includes every feature that requires actually evaluating Daml expressions, such as signatories.

1 Like
3

Thanks, Stephen, in this case if I want to write some code to get the signatories, my best chance is to parse the source code, right?

4

No matter what, the best source is probably the intermediate parsed form of Daml-LF that is part of the process of parsing into the api-type-signature form. What you do with that really depends on what you mean by “get the signatories”.

Because signatories is a pure expression where the template is in scope, and can therefore call any Daml function, you technically need a full Daml engine to determine the signatories from each contract payload. That’s one of the reasons that the Ledger API returns signatories and observers: so that API clients have a defunctionalized way to inspect the stakeholders specific to each contract.

If you want to only support a subset of possible signatories expressions, then I would start with the ArchivePayload intermediary that you have as part of parsing into the api-type-signature form, and then you have two options:

  1. open the proto in the ArchivePayload and drill down until you find the associated DefTemplate. Consider the param_interned_str and signatories; have a look at the expression structures generated there for the subset you want to support.
  2. run that through Decode.decodeArchivePayload. Drill down through that and you’ll find these GenDefTemplate[Expr] structures that have a param telling you the bound variable representing the template, and signatories and observers, which are expressions. If you’re only supporting a subset, then these expression structures should follow specific patterns.

Both of these are hairy, and the second is even more internal code than api-type-signature, but still much easier than parsing Daml source.

5

I want to classify templates based on if they need the approval of a business entity or not. Because the entity is named consistently in the template payload fields, the signatory expression is probably fine for me.

Thank you for these hints, I will try to utilize them.

Update: another workaround which comes to my mind is to filter the signatories of the contract instances of a running ledger with the contracts we are speaking about.

6

This is why the contract data structures in the Ledger API and JSON API always include a list of signatories/observers for each contract. It’s assumed that clients can’t in general associate a stakeholder set with the template as a whole abstraction, so are relying on the participant to just report the correct result of that expression for each contract.

1 Like