Suppose my participant has a party Owner and two users, alice and bob, both of which can act as Owner.
Parties always leave an on-ledger trail by the very nature of how Daml works, but what about users?
How could the operator of the participant audit the interactions with the Ledger API so to link a specific call back to a user?
Command submissions log the application id which corresponds to the user id. So that provides some way to trace back command submissions to individual users.
So the application ID must match the user ID in every call to the Ledger API?
Yes at least if you’re running with auth (which you should do in any production system where you care about auditing). You can also omit the application id in those cases since it is redundant.
That’s great to hear, thanks. This means that the CommandCompletionService effectively serves as a possible source for full auditability that takes into account both a user (by virtue of the matching application ID) and party, is that correct?
Yes although I think logs are often a better option for this. They are present even for commands that get rejected on submission (so never produce a completion) and you don’t need to worry about getting tokens as the participant operator to query the completion stream.
I see, thanks!
Logs do not have the same persistence requirements/behavior as our ledger. I ultimately think we need some way to reconcile users set state and the ledger’s offset.
Given the recommendation how does one tell the difference between actual applications? I can see that there are two distinctions that an operator would want to investigate.
Does user Alice mostly use HTTP-JSON or a custom integrations?
How does it interact with ledger metering? For example if I have 1k Users as part of an organization that I’d like to charge for their activity, would I have to aggregate all 1k Users, and how would I reconcile the history of user changes across a given period to figure out the right number of ledger events?
For your second question: Metering is tied to application ids which ties it to users. See Participant Metering — Daml SDK 2.4.0 documentation for details.
I did read that link. My point is that filtering by application when asking for usage via metering is not that useful anymore. An operator would have to store a history of users tied to a real world use case to aggregate charges against that use case, which in the past they were able to consider an “application”.
I think there are two orthogonal concerns and an application does not necessarily map 1-1 to users on your node.
Not sure I’m following. As mentioned above, the participant enforces that application id = user id. You don’t get a choice. Are you asking for a new feature where this restriction does not apply and you can filter on different dimensions (whether that’s called application id or something else) than just user?
Yes. I meant “application” in a different sense, one where many users are using the same application.
From an operator perspectives one would want to aggregate at that application (maybe because they’re the ones collecting the fees) as opposed to the users that use the application.
I understand how tying users to applications makes sense in a broader world where everyone gets a participant node sailing on a sea of domains. But not in the current environment.