Making contracts public by default
Hello,
What’s the easiest way/workaround to making some contracts public by default?
Great question. A few related discussions are below but it also depends on what you mean by making contracts public. Do you mean that once a template is instantiated into a contract you want all parties to be able to see the contract?
Hi Alex, no worries, this is the place to ask questions! Beware you may get different answers here. I would not go down the route of making the ProductType public. I think there is a simpler solution here. You could add a choice CreateProduct: Product on ProductType, and specifically use the choice first syntax to pass the producer as an argument to the choice - this way you don’t need to maintain an explicit list of observers. However, you should ask yourself: is every producer allowed to cre…
@Jean_Safar Remember that access to contracts depends on the Party that is performing the lookup, not other contracts. You could “hardcode” the name of a global party, and then have that global Party serve the data to other users. That global party would be responsible for updating that data and also accepting (ex. via triggers) requests to access that data. Ideally, you would manage access to that global contract via a simple key so that the observers could look up that data. template GlobalDa…
And welcome to the forum. Hope you find everything you need here.
Thank you for your reply Anthony. To answer your question, yes, we want that once a template is instantiated into a contract, all parties should be observers/subscribers by default. One example will be to allow admins create system wide emergency broadcasts. I have looked at the broadcast example code here but it requires a Party to know about a contract and then request for permissions on it, what we want though is an easy way to discover “unknown contracts before making subscription/observer requests”. ref: ex-models/Broadcast.daml at 28992eb589109a6a03914ad02d9fe3ab174a80a3 · digital-asset/ex-models · GitHub
Alex and I are actually exploring the same problem domain so it may be beneficial to schedule a joint call with you/another experienced person in attendance to resolve some the design bottlenecks we are currently experiencing.
Definitely a good use case and a good question
In DABL, we have allocated a special party on the ledger that we have designated for Public use.
You can read a bit about it here https://docs.projectdabl.com/api/#public-party
At a high level, it’s a party that anyone can get a read-only JWT token for. When you add the Public party to a contract, anyone can fetch that contract through the ledger API
Worth noting is that on your client side applications you can use more than one Party. So for Eric’s solution your users would have 2 parties. One being a public party that can see the contracts you want to be public, and their own party that works with contracts that are specific to them.
This looks like a promising solution. Would there be any portability issues between blockchain platforms if we started off by relying on the DABL public party?
Our implementation resides in the auth / token management layer - not in the ledger layer. If you were to implement a similar token authorization scheme on top of another ledger, it would work there as well.
As far as the ledger is concerned, there is a party like any other which is the stakeholder to a set of contracts. At the ledger API auth level, we understand that is a special party that anyone can fetch a read token for. You would need to replicate that function but your DAML is 1:1 the same on any other ledger.
