CAIP-19: Add block number tag in query

[qizhou]

See discussions in #119

[ntn-x2]

I don't think it's correct to mix an identifier with a querying language. CAIP-19 identifiers should be used to identify assets. Adding a query part to it can be quite confusing.

I think it would make more sense to define a new CAIP which describes the querying language to use. Also because also a chain ID, or an account ID, might want to support this feature, to retrieve historical data.

[TimDaub]

I don't think it's correct to mix an identifier with a querying language.

I agree that it looks confusing syntactically and I wish we had other options. Is there something we could make this less looking like an non-deterministic query @qizhou?

CAIP-19 identifiers should be used to identify assets.

I think @qizhou and I agree with you. But our problem is that we believe CAIP-19 indeed doesn't identify assets at this point. It is a Universal Resource Location as the identity of the asset can change over time. Hence, to truly create an URI that is permanently accessible, we somehow need to add the block number. Now, I personally have little competence or understanding what should be the right symbol in the case and previously I had suggested the # symbol, which as @qizhou correctly pointed out is unfortunately stripped by the web browser (and hence often not sent to a backend).

I think it would make more sense to define a new CAIP which describes the querying language to use.

We're not trying this define a query language. This is an extremely important distinction.

[qizhou]

Perhaps we could use other symbols other than # if the query is not preferred? E.g., @?

[ntn-x2]

Not to feather our own's nest, but we have opened an issue in this very same space to integrate CAIP-19 into a new DID method. What that would do, is that it would enhance CAIP-19 with DID features, including an already standardised query language. In this way, it would be trivial to define a block_number query parameter in the DID method to do exactly what @qizhou was proposing here. Maybe you guys want to take a look at that and have the discussion going there?
The issue in this repo is here, while the new DID method draft is here.

[TimDaub]

block_number query parameter

block_number is not a query parameter, it's a fragment of an identifier. Anyone that is running CAIP-19 without a block_number is querying as there can be many results to one URL but only one result to an URI.

[ntn-x2]

@TimDaub what I am saying (and re-iterating) is that I do not think a block number should be part of the identifier itself. I think it should be some additional detail that might be required in some use cases.
For instance, if we assume verifiable credentials are issued to an CAIP-19 identified asset, the asset would not be identifier by the block number, as otherwise at each block number the identifier would change, which sounds a bit counter-intuitive for me.

Different is the case where the verifier of an asset's credential might want to retrieve the status of the asset at some past block, and it would do that with a query parameter, which would be defined in the DID spec linked above and taken care of by the DID resolver.

I think having the block number as part of the identifier would only introduce problems.

[TimDaub]

@ntn-x2 I actually agree with you that adding the block number as part of the identifier makes things much more complicated and I also agree with your line of reasoning, which is that:

For instance, if we assume verifiable credentials are issued to an CAIP-19 identified asset, the asset would not be identifier by the block number, as otherwise at each block number the identifier would change, which sounds a bit counter-intuitive for me.

But here's the safety concern that supports adding a block number.

Imagine an NFT with a cute kitty and the name "Cute kitty PFP," and then we have this new type of protocol that allows "liking" the NFT kitty using a Verifiable Credential where the issuer sign(CAIP-19WithoutBlock, "I like it") which results in a signature. Now. In this case, since CAIP-19WithoutBlock doesn't contain a block number, the user has signed whatever the latest state was at that point of the chain.

However, a few days later, now the operator of the NFT could come along and change various things:

• e.g., if their NFT contract was proxied and so they can upgrade the contract, now suddenly they could change the NFTs name and picture from a cute kitty to a scary wolf. Or they could change it so that it looks like the user had signed something else but a kitty.

And so therefore, it is fragile for us to identify an NFT asset without naming its block number if, in most cases, what is meant is the NFT in its current form.

Now: The herein proposed change is technically backward compatible as it'd allow us to craft a CAIP-19 identifier that puts "block_number=latest", but we should avoid using that when truly wanting to identify a temporal manifestation of a specific asset.

[bumblefudge]

I am struggling with the backwards-compatibility part. Are queries beginning with ? inherently/syntactically optional? I guess my question is:

Do today's "block-height-free" CAIP-19s default to "block_number=latest"? Is
:example-namespace:example-network:example-asset
still valid after the PR, and equivalent to
:example-namespace:example-network:example-asset?block_number=latest
?

My one concern here is that If there are systems that, for whatever reason, strip the ?... somehow along the way, they are effectively changing any ?block_number=123 into ?block_number=latest, which could conceivably introduce problems, or at least a security consideration... systems that support these query suffixes and systems that don't might interact unpredictably or insecurely, non?

[TimDaub]

Are queries beginning with ? inherently/syntactically optional? I guess my question is:

I'm not suggesting backward compatibility in the syntactical sense. CAIP-19 is in status: DRAFT, and so breaking assumptions should be allowed, right? What I mean is that the current implementation of CAIP-19 that doesn't include a block_number would then later be block_number=latest because that's what it is today (albeit implicitly).

Do today's "block-height-free" CAIP-19s default to "block_number=latest"?

Yes, this is my interpretation. Or let's say they're equivalent in where they're pointing towards.

My one concern here is that If there are systems that, for whatever reason, strip the ?... somehow along the way, they are effectively changing any ?block_number=123 into ?block_number=latest, which could conceivably introduce problems, or at least a security consideration

Fair.

Is :example-namespace:example-network:example-asset still valid after the PR

No, it's replaced by :example-namespace:example-network:example-asset?block_number=latest and that's fine because CAIP-19 status is Draft.

Perhaps we could use other symbols other than # if the query is not preferred? E.g., @?

I liked @qizhou's proposal of using e.g. "@".

[ntn-x2]

Imagine an NFT with a cute kitty and the name "Cute kitty PFP," and then we have this new type of protocol that allows "liking" the NFT kitty using a Verifiable Credential where the issuer sign(CAIP-19WithoutBlock, "I like it") which results in a signature. Now. In this case, since CAIP-19WithoutBlock doesn't contain a block number, the user has signed whatever the latest state was at that point of the chain.

I think this should be a concern of the verifiable credential layer OR of a querying language on top of identifiers, for which historic state can be queried. For instance, either the VC could have a block number as a claim, or an issuance date from which a given block number can be retrieved.

Different is if we want to assume that two CAIP-19 identifiers that only differ in block number are to be considered completely independent on each other: in that case adding a block number to the identifier would make sense.

[bumblefudge]

Discussed on today's call; will discuss further at inperson gathering in sept

[TimDaub]

Discussed on today's call; will discuss further at inperson gathering in sept

now also as a proposed agenda item: ChainAgnostic/Gatherings#7