new CAIP - Transaction Object Addressing

[bumblefudge]

Design questions still pending input:

• Note: Titusz' proposal was for addressing transactions within blocks, by slot #; here, instead, I was thinking specifically of transactions that can be queried directly from indexers and/or block explorers.
• Should transactions-within-blocks be added to New CAIP - Block Addressing model #220 ? If so, does that change anything about what's in and out of scope for this CAIP scheme?
• Block explorers tend to display information like position-in-block, which can't be derived from the transaction object itself; are those worth including in such a scheme? I assume not, particularly if transactions-within-a-block are addressable from New CAIP - Block Addressing model #220, as mentioned above. But worth checking with the group
• Should a property that's an array be queryable (i.e. ..123deadbeef4.inputs[1]), or should the scheme just allow you to fetch the whole array and you need to dive into it after getting back the whole array?

Would you all be open to a meeting to discuss, @TimDaub @titusz @ntn-x2 @sposth ?

[ntn-x2]

Don't have much context on the origin of this PR, but overall it looks a good starting point.

One main grip I have, as I also had for CAIP-19 identifiers for the erc-based namespaces, is the possibility to link between identifiers that refer to the same resource. Specifically, I think that a tx referred to by a CAIP of this category and a tx referred to by a CAIP as in https://github.com/ChainAgnostic/CAIPs/pull/220/files should semantically be considered the same resource. I don't see any resolution process defined in these CAIPs, meaning that they only deal (as far as I understand) with identifiers, and not with resolving any aliases between them.

[bumblefudge]

I don't see any resolution process defined in these CAIPs, meaning that they only deal (as far as I understand) with identifiers, and not with resolving any aliases between them.

But wouldn't that have to live in each namespace's profile of this CAIP, since there no common/universal assumptions that can be made even about the resolvability or uniqueness/non-uniqueness of these identifiers?

[bumblefudge]

Discussed today with member @ajunge from notabene.id - this CAIP is worth reviving, useful to a project they're working on, but there may be corner cases around ZCash or Monero or other privates not covered by 221 or 220-- may justify a third