You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The metadata V16 is capable of expressing type information only.
One of the shortcomings of V15 is that the metadata cannot express code functionality.
This would be beneficial for users like subxt. For example, subxt could rely on the hashing functionality exposed in the metadata WASM blob to remove the Hashing type (equivalent of system's pallet Hashing). Expressing the hashing functions will reduce our code and allow us to be more generic in targeting different chains.
There's also the need from the community to place various methods in the metadata (extracted from the forum post).
One concern with this approach is that some users in the future will add the signing function of extrinsics to the metadata, or a similar function that exposes the private key (or sensitive data) to the "untrusted" WASM blob.
That said, I would still opt for this functionality in the metadata to offer a better user experience for developers.
Currently, this can be done as explained in this comment of the forum post via CustomValueMetadata fields.
Raising this to get your feedback before thinking of the technical approach 🙏
The metadata V16 is capable of expressing type information only.
One of the shortcomings of V15 is that the metadata cannot express code functionality.
This would be beneficial for users like subxt. For example, subxt could rely on the
hashing
functionality exposed in the metadata WASM blob to remove theHashing
type (equivalent of system's pallet Hashing). Expressing the hashing functions will reduce our code and allow us to be more generic in targeting different chains.There's also the need from the community to place various methods in the metadata (extracted from the forum post).
One concern with this approach is that some users in the future will add the signing function of extrinsics to the metadata, or a similar function that exposes the private key (or sensitive data) to the "untrusted" WASM blob.
That said, I would still opt for this functionality in the metadata to offer a better user experience for developers.
Currently, this can be done as explained in this comment of the forum post via CustomValueMetadata fields.
Raising this to get your feedback before thinking of the technical approach 🙏
Maybe part of: #4520
// cc @paritytech/subxt-team @bkchr @skunert
The text was updated successfully, but these errors were encountered: