Antonio

@rflechtner I guess because of the `parse` -> `resolve` renaming, this could not be included in a patch release for the SDK, so we have to wait for the next...

@rflechtner I see your point. Indeed the AssetDID spec v1 was designed since the beginning to be a simple wrapper around CAIP identifiers. The goal would be for it to...

@rflechtner our current release strategy do not capture this case when a feature is deployed on Peregrine and not on Spiritnet. Nevertheless, I don't see any blockers from making this...

0.35 has been released, so this will also have to change to the new version.

We migrated to a different repo and peer dependencies, this PR is not relevant anymore.

We have developed a (for now) minimal Rust crate for use in our blockchain runtime: https://github.com/KILTprotocol/kilt-node/tree/develop/crates/assets. It works in no_std environments and it uses as few dependencies as possible.

@oed thanks for the prompt response. I don't think on-chain attestations are something that concern only Polkadot. If anything, Polkadot does not care about attestations at all. It's us, KILT,...

I would be down for it. I was always assuming that the asset namespace would be generic enough to basically declare anything we want as an asset class. But I've...

@oed I have gone the key CAIP specs few times, and never found a mention that CAIP-19 is per blockchain. Where is that mentioned? Cause my assumption was that you...

So if assets are only valid within a given chain, then how would we define the concept of "attestation"? Should we need two different specs to refer to Ethereum-based and...