Update caip-294 to fit extension id as valid target type (caip-341)

[ffmcgee725]

• Update caip-294 to fit extension id as valid target type 👉🏾 caip341

[adonesky1]

We should also add this property / description to CAIP-282 here

[adonesky1]

Also the expected type should be modified here on CAIP-295: targetOrigin should be nested in the new target object. And we should make the CAIP to define/establish the origin type as a pending todo

[jiexi]

Do we envision a world in which a wallet supports multiple transports/interfaces. If so, do we think it makes more sense for those to all be defined in one Wallet announcement event, or in several separate wallet announcement events?

Currently I'm thinking that it should be one wallet announcement event, but that doesn't work with the current data structure. In that case perhaps something like this makes more sense again

{
  uuid: '1-1-1-1',
  icon: 'blah',
  name: 'wallet name',
  rdns: 'io.wallet',
  target: {
    caip314: 'abcdefghijklmnop',
    caip315: true,
    caip316: {
      someOtherThing: 'hello'
    }
  }
}

[adonesky1]

Do we envision a world in which a wallet supports multiple transports/interfaces. If so, do we think it makes more sense for those to all be defined in one Wallet announcement event, or in several separate wallet announcement events?

Worth discussing. I would think wallets would generally tend towards supporting one entrypoint/transport for any given context and tell the dapp this is the one to use in this context (platform/browser). Otherwise you're imposing a burden on dapps/libraries to add logic to decide between these options.

But perhaps I'm being short sighted and there are good reasons for offering multiple transport options

[bumblefudge]

is this ready to go when ChainAgnostic#341 is merged?