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 #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 #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 ?

[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