How to simulate admin party locally?

Questions
1

using SDK 2.2.0, daml/hub-react 2.2.0

End Goal:
Locally, Admin party ID needs to be publicly discoverable. I have triggers running as the admin, so if I send / transfer assets to the admin, the trigger will automatically accept etc. For example, locally, I run this trigger, the user, as shown, is ledger-user “admin”, I am able to hardcode the ledger-user.

daml trigger --dar triggers.dar \
             --trigger-name AcceptSwapTrigger:acceptSwapTrigger \
             --ledger-host localhost \
             --ledger-port 6865 \
             --ledger-user "admin"

I can achieve the automated workflows fine when the app is deployed on hub.
When deployed on Damlhub, I can use useAdminParty() from the @daml/hub-react library. This returns the party ID, meaning when logged in from any account, I can send / transfer assets to this admin party.

Problem
Locally, how can a user send a contract to the “admin party”, if I need the party ID, but the party ID is generated on the go? Can I some how use the ledger-user, eg “admin” and get the PartyID ?

In the screenshot below, I want to make a swap with the “default Party”. On hub, clicking the “use Default Party” gets the partyID from useAdminParty.

Screenshot 2022-06-04 at 10.41.59 AM
Screenshot 2022-06-04 at 10.41.59 AM1084×826 29.1 KB

2

In create-daml-app, it uses an alias contract,

From the daml 2.0 article,
Create-daml-app addresses this by writing alias contracts on the ledger with associate human-readable names with the party id. These alias contracts are shared with everyone via a public party.

Would it be correct to say that the only way to create a publicly identifiable admin party is to create an alias contract? and this would only be used for local development to simulate the admin party?

3

On the highest level, somewhere you need to create a mapping from human readable name (admin in your example) to the underlying party id and you need to distribute that mapping to all ledger API clients that need access to this.

There are a few options for this:

  1. Create a contract on-ledger that stores this (the alias) mapping and distribute it via readAs for a public party.
  2. Create a contract on-ledger that stores this and distribute it via observers. This gets somewhat difficult if you need a very large and/or dynamic set of parties that get access to this.
  3. Don’t store anything on-ledger, instead distribute that mapping outside of the ledger, e.g., provide a web API that exposes this. This is similar to what hub does by providing an endpoint for default parties.

I think you are slightly conflating production usage with the specific APIs on hub: All of these 3 options can be used during development and in production and usually you need to chose one in both. Now Hub has builtin concepts for the default parties and also some form of aliases and if you use those you go more towards 3. But you can also use 1 and 2 on hub and that’s in fact what create-daml-app does (option 1) if you run it on hub.

4

Thanks, will go with option 1.