Have we ever thought of the possibility of having the http json api allowing to query simultaneously as two or more parties and return the union of the result?
Also on the exercise and create path could the json api accept a command where 2 or more parties are authorizers (so we could potentially exercise a conjunction choices)?
Rationale:
Read path - The multiple party read path will help a lot in performing data disclosure on applications that consume the json api. For example if we want to publicly disclose contracts then we can have a special party (ie the public party) that we can add as an observer. Then we mint JWTs that can read as both as Alice and the public party and query using that.
Write path - For the write path of create and exercise, this will help in modeling user groups with specific authorities over the active contracts on the ledger. For example if we want at some point to grant Alice the ability to exercise a choice on an existing contract we would have to have a disjunction choice and explicitly add Alice to the list of disjunction parties before she can exercise that choice. Instead, we make the choice exercisable by a single party (ie some admin) and simply give Alice the token to exercise that. The subtlety here is that Alice is not necessarily a party on the ledger but an actual person that can read and write as multiple parties.
Reading as multiple parties is not supported but theoretically possible, as there is a support for multi-party subscriptions on the Ledger API. Still, I would discourage it: this is just my opinion, but I believe there is an inherent advantage in keeping streams for separate parties separate, as you can easily reason about a single party at a time and not mix up together data that should have been segregated per party. Even if it’s intended for public disclosure, having something acting as the hub for publicly available contracts is something I would value as an app developer. On the practical side, single party subscription can also be faster than multi-party ones, because multi-party subs require the server to compute who the intended witness is for every event returned (whereas in the single party sub it’s clear that whomever is receiving an event is a witness). This, of course, comes into play when you have to perform at scale.
Writing
Writing as multiple parties is not possible via the Ledger API, so it’s not possible on the HTTP JSON API either, since it runs on top of the Ledger API.
@stefanobaghino-da Dimitri also wanted to know if we’ve ever considered the multi-party write flow, and if not, why not
On the public read party: the problem with this is that you’ll only ever be able to see those contracts’ data, you’ll not be able to interact with them or use them in a choice using your own party. That’s severely limiting the usability of that approach imo.
Thanks for the clarification @georg - yes it would be nice to know if the write path was ever considered and dismissed.
On the read path I would argue that it is a major benefit for displaying public data (or groups of data) on your application (even though you can’t fetch them in your choices). It’s not very different from the case where your party is merely an observer on a contract but not a controller. You can still see the choices but if you try to take any you will get rejected.
This sounds reasonable to me. A new copy of the contract with Alice added to it has to be created and approved/accepted by all signatories. This is by design. What if one of the signatories does not want Alice exercising a choice on the contract or does not want Alice to be able to read this contract?
This does not sound right. Granting Alice admin rights you cannot control what Alice can read and exercise. Alice becomes a super user with access to all contracts that Admin can access. This also means you will end up with multiple counter-parties/entities being admins.
I remember the discussion with @dtanabe when we decided to make it impossible to have super users in JSON API .
Dimitri, what exact problem are you trying to solve?
Almost in every app I wrote in DAML I run into the need for a way to broadcast data to all parties. If we would allow reads as multiple parties, the above would be a simple solution for this. You could just define a ‘broadcast’ party and give all parties read access as ‘broadcast’.
This would mean that anyone could become an observer without contract signatories approval, which would violate the entire purpose of signatories. I think a flag to enable broadcast to every party on the ledger should be added to the DAML template. We have observers, something like observed-by-everybody: Bool. When signatories are signing a contract they will have to accept the fact that the contract can be broadcasted to every party.
BTW, it is pretty easy to add support for multi-party reads to JSON API, but I think it would open a way to violate contract privacy.
@drsk To enable this vision it would be convenient if the react bindings had the ability to specify what party is making a request (within a DamlLedger context), to avoid having to go into the ledger api.
I can’t quite follow this. The contract would be designed in a way that you add the ‘broadcast’ party explicitly to the observers, so it’s clear in the DAML code itself that such a contract is broadcasted. So no change to the privacy rules or change to the signatory purpose.
Actually, for this idea it wouldn’t be necessary. Because a party would get a JWT token where it has the right to read as the broadcast party, so there is no need to switch the acting party context.
If DLT operator can give Alice permission to read contracts as Broadcast party, technically the same DLT operator, can make a mistake and let Alice read contracts as Bob… contract signatories will not have any control over this, they won’t even be notified about this mistake.
If someone who controls the identity/keys infrastructure of a party makes a mistake, then you’ll be in trouble in any case. I think this observation is independent of the question, whether multiple parties should be allowed in readAs.
That is not the point… My personal opinion that canReadAs and canActAs break the ledger privacy model and allow someone else besides signatories to give access to observe and exercise choices on contracts.
If I sign an IOU with Alice, I would NOT like the idea that let’s say the government or a bank can make this contract visible to everyone else. It should be between me and Alice and nobody else.
It’s nice to see that this thread has gained some traction. Let me try to clarify a bit more.
I also agree with @drsk that there is no violation of signatories happening just a re-think of what is actually a Party in DAML. DAML in its authorization model never accounted for how parties map to actual users with log in information. It is also not opinionated as to whether a party is an individual or a legal entity or a group of people. It is simply a mechanism for calculating permissions for updating a the active contract set and for disclosing part of that contract set. Mentioning Alice and Bob in our starter example as parties IMO is a good way to start but soon enough falls short when designing a production use-case.
For the read side it has become apparent that we do need a mechanism for reading public data. In DABL we have already introduced the concept of a PublicParty where you can get its Party value from a well known endpoint as well as get a JWT for it without any special permission. Then the app developer is burdened with performing multiple calls (one for the public party and one for the logged in user of the app) in order to properly render the desired state. Therefore a mechanism where a single call can return both public and user authorized data without compromising the principles of the DAML ledger is a win.
For the write side it gets a bit more complicated. As I understand it, the ledger api itself needs to change in order to support multiple submitters. I would have loved all along to be able to do something like submit [alice, bob] create Agreement with .. where agreement has both alice and bob as signatories. This is already the case with conjunction choices that can be taken in the body of other choices as long as the set of authorizers is a superset of the controller parties in the conjunction choice. Having the ability to outright create contracts with multiple signatories or outright exercise conjunction choices will enable faster upgrades and simpler workflows without I THINK (and that’s something that I need a language expert to answer. perhaps @Martin_Huschenbett or @meiersi) compromising the ledger model.
A use case for the write path by using a JWT for multiple parties is that of user groups. Alice has her own token for a Party on the ledger. However she is upgraded to an admin which is a party on the ledger and now can read and write as a both parties.
She can go ahead an exercise a choice that is modeled for the admin party since on every choice she takes she submits a set of authorizers containing her party and the admin party (ie a superset of the controllers that the choice needs).
Another use case is that of fetching ‘public’ contracts (where the public party is the observer or signatory). Think about the case where Alice exercises a choice where she is the controller and that choice needs to make use of some reference data where the public party observes. Since the public party is in the set of authorizers, it can be used for fetching the public contract in the body of the choice that Alice takes.
In the ledger model, a commit is allowed to have multiple requesters, although the current DAML Ledger API offers the request functionality only to individual parties.n
.