# Semantics of witness\_parties in the gRPC API **URL:** \ **Category:** App Development\ **Tags:** ledger-api\ **Created:** [June 24, 2020, 9:15am UTC](https://forum.canton.network/t/semantics-of-witness-parties-in-the-grpc-api/724 "2020-06-24T09:15:08Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![oggy](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/oggy/32/109_2.png) [@oggy](https://forum.canton.network/u/oggy)\ **Post date:** [June 24, 2020, 9:15am UTC](https://forum.canton.network/t/semantics-of-witness-parties-in-the-grpc-api/724/1 "2020-06-24T09:15:08Z")
A few questions about the `witness_parties` for a `CreatedEvent` or an `ExercisedEvent` in the gRPC API. The value of this field is said to be determined by `TransactionFilter`. 1. what if I get the transaction through a `GetTransactionById` call, that has no such filter? I assume that these are then the `requesting_parties`? 2. is there any way to get the information about the witnesses not hosted on the local node? Can I supply non-local parties in the transaction filter (putting authentication concerns aside)? 3. the description of the field for `CreatedEvent` says its value are the informees of the event in one case, and contract stakeholders in another. But the [Projections](https://docs.daml.com/concepts/ledger-model/ledger-privacy.html#projections) section of the ledger model defines informees of Create actions exactly as the stakeholders, so I don’t see what the difference is ---
**Author:** ![stefanobaghino-da](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/stefanobaghino-da/32/7057_2.png) [@stefanobaghino-da](https://forum.canton.network/u/stefanobaghino-da)\ **Post date:** [June 24, 2020, 10:09am UTC](https://forum.canton.network/t/semantics-of-witness-parties-in-the-grpc-api/724/2 "2020-06-24T10:09:17Z")
The whole idea of having the witness parties in the response is simply to allow the client of a multi-party request to distinguish to which party an event is visible among those included in the request. The answer to 1 is that `witness_parties` is going to be the intersection between the `requesting_parties` and the witnesses for a given event. The answer to 2 is more complicated, as it largely depends on the ledger implementation. There are ledgers that may want to guarantee that a party is not automatically visible to any participant. You can supply a non-local participant in the transaction filter, but on privacy-preserving ledger implementation you will only be able to see those events that involve said party on that specific participant, not the whole set of events regarding that party on other participants). The answer to 3 is that unfortunately the Ledger API does not use the same vocabulary as the ledger model document. The proper term to be used instead of _informees_ is probably _witnesses_ (but I could be wrong). ---
**Author:** ![oggy](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/oggy/32/109_2.png) [@oggy](https://forum.canton.network/u/oggy)\ **Post date:** [June 24, 2020, 10:49am UTC](https://forum.canton.network/t/semantics-of-witness-parties-in-the-grpc-api/724/3 "2020-06-24T10:49:50Z")
Thanks! Do you mind if I then submit a PR to change the “informee” in the comments, since “informee” isn’t used anywhere else in the gRPC docs? Obviously, `witness_parties` cannot be the full witnesses as defined by the ledger model, since the full witnesses might not be known to the party (nor the participant). In general, a party whose projection is rooted at an action `A`, shouldn’t learn the non-informee witnesses of `A`. For context: I’m implementing auto-synchronization for submitted transactions in a distributed setting (Canton), such that you can submit a command at one participant, and wait until all involved participants have seen it. The lack of such sync has been a source of a lot of bugs in demo apps written for Canton, and is a reason why DAML Script is currently not very usable in a distributed setting. Implementing the sync requires learning the full witnesses of a transaction (these are always known to the submitter), but I think I can abuse the solution with non-local parties for the time being. ---
**Author:** ![stefanobaghino-da](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/stefanobaghino-da/32/7057_2.png) [@stefanobaghino-da](https://forum.canton.network/u/stefanobaghino-da)\ **Post date:** [June 24, 2020, 10:54am UTC](https://forum.canton.network/t/semantics-of-witness-parties-in-the-grpc-api/724/4 "2020-06-24T10:54:00Z")
> [@oggy](#): > > Thanks! Do you mind if I then submit a PR to change the “informee” in the comments, since “informee” isn’t used anywhere else in the gRPC docs? Not at all. I believe there are many misnomers in our code and docs, the more we can fix, the better.