-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add support for hash, content type, and multiple URLs as service endpoints #235
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would move the URL checks to an implementation for ServiceEndPoints
, see below.
I am also unsure, whether the VersionMigratorTrait
should be in primitives. It probably should be moved to a new pallet Trait
instead. We definitely need to make the migration template more generic and move most of the code to a Trait
pallet eventually. Of course, this is out of scope for this PR.
Apart from that, LGTM.
} | ||
} | ||
|
||
impl<T: Config> VersionMigratorTrait<T> for DidStorageVersion { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will try to make this version migration more generic in the next week or future. But since we should wait for paritytech/substrate#9165 to be available in a release, it might not make sense to start with this before.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes please, I think that would be great as we will eventually need it for other pallets as well. I can also take care of this if you don't manage to do it before you leave.
total_weight | ||
} | ||
|
||
fn old_to_new_did_details<T: Config>(old: deprecated::v1::DidDetails<T>) -> DidDetails<T> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we might not even need a migration since we just remove one field and initiate a new one with default None
. But better to be safe.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we need a migration here in case there are entries with a ServiceEndpointUrl. The new code would try to parse the URL into the new Struct.
/// | ||
/// In this way, the migrator can access the pallet's storage and the pallet's | ||
/// types directly. | ||
pub trait VersionMigratorTrait<T> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure whether we want to introduce a new Trait
pallet for this instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps it would make sense. But at the moment kilt_primitives
was the only place I could put it in without creating any dependencies between KILT pallets. I guess also the storage migration stuff deserves to be put in a different crate, perhaps the same as the one for traits.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. I am fine leaving it be for this PR and then we handle it correctly in another PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for resolving the issue around cargo test
. LGTM now!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
- The standard error in the benchmarks is suspiciously high.
- a few opinions on naming
total_weight | ||
} | ||
|
||
fn old_to_new_did_details<T: Config>(old: deprecated::v1::DidDetails<T>) -> DidDetails<T> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we need a migration here in case there are entries with a ServiceEndpointUrl. The new code would try to parse the URL into the new Struct.
fixes KILTProtocol/ticket#1505
This PR modifies the service endpoints of a DID by adding the possibility to specify a hash of the pointed service endpoints document, a content type to allow other entities to correctly parse the document, and up to three URLs to fetch the document from. The logic about what URL to use in case there are more than ones for a given resource are out of the scope of the chain code.
To do so, the PR updates the
DidVerificationKeyUpdateAction
and makes it more generic into aDidFragmentUpdateAction<FragmentType>
that is then used for both verification key updates withDidFragmentUpdateAction<DidVerificationKey
and for service endpoint updates withDidFragmentUpdateAction<ServiceEndpoints>
, withServiceEndpoints
being:I have not migrated this struct to use
BoundedVec
, but I hope that is fine. We have one more parameter in the trait's Config calledMaxEndpointUrlsCount
which specifies how many URLs can be included in aDidFragmentUpdateAction
for the service endpoints. We decided to go with three which seems like a reasonable number to provide good redundancy to the data.How to test:
cargo test --all --all-features --all-targets
or simplycargo test -p did
Custom types
JS-Types
Checklist:
array[3]
useget(3)
, ...)