Design Doc: Provider Contexts #2311
Conversation
…implifies POV concerns
| ```rust | ||
| #[pallet::call_index(1)] | ||
| pub fn propose_to_add_application( | ||
| origin: OriginFor<T>, |
There was a problem hiding this comment.
@wilwade should we separate add and update as separate extrinsics, assuming we can handle both with an optional application index
On similar lines do we enable updating provider data via governance in same fashion?
There was a problem hiding this comment.
Hmm....
- I think we can just make them set functions. Simplifies the setup.
- Re-Provider Data. This makes me wonder again about an
Application 0default instead of having Provider Data and Application data. Is there any other way we could unify these? Perhaps apropose_to_set_provider_applicationthat takes an optional application id and if no application id it sets the provider level? Not sure if that makes it more confusing over having two extrinsics or not.
There was a problem hiding this comment.
@wilwade we can enforce a default application (atleast 1) to exists and using provider data we can create one on registration. Provider may choose to update it later but the provider data tied to provider registry wont be updated? That way we are'nt making it overly complex
What you think?
There was a problem hiding this comment.
We can see how that works, but we do want to be able to update the provider information as well so not sure it gets us far unless we just "don't" have provider information and only have application information.
There was a problem hiding this comment.
That's true, it's better if we can just follow same model on both applications and provider side for issuing updates that way it's more nuanced even with some extra code.
I will capture that in this document
Goal
The goal of this PR is to layout a design doc for storing Provider Contexts on chain. This would allow a provider to have one or more applications and provider user consumed logos and names (in multiple languages).
Closes #2269