Mobile Linking and multichain URI schemes

[LeslieOA]

Mobile Linking and multi-chain URI schemes

Has a standard for chain specific wallet URI schemes ever been explored (as a CAIP or otherwise)?

I imagine as a developer (on iOS) I'm likely an edge case; but I've always found the mobile multi-wallet and multi-chain UX a little jarring and wondered if having chain specific URIs could help?

On iOS, it seems that the most recently installed wallet assumes control of it's supported URI schemes, so a wc:// URL will launch Family even though I have Pera, MetaMask and Rainbow installed.

For example, a dapp would present chain-appropriate URLs:

e.g.

Chain	URI Scheme
Algorand	wc-algorand://
Bitcoin	wc-bitcoin://
Cardano	wc-cardano://
Ethereum	wc-ethereum://

...and a mobile wallet would register all chain URI schemes it supports:

• AVM (Algorand) compatible:

  • wc-algorand://

• Bitcoin (Bitcoin Script?) compatible:

  • wc-bitcoin://

• EVM (Ethereum) compatible:

  • wc-ethereum://
  • wc-polygon://
  • wc-gnosis://
  • wc-base://

I'll admit, I've not yet explored what would work best for Substrate based chains (would that fallback to the multi-EVM chain example above?).

Mobile wallets currently have inconsistent URI schemes registered:

• Coinbase Wallet (multi-chain): bitcoin://, ethereum://, litecoin://, wallet:// and likely others
• Family: family://
• Pera: algorand-wc://, perawallet-wc://, algorand:// and perawallet://

Maybe I'm thinking too small here: could this be expanded for use for things like payment links also?

Is wc-{chain} too limiting?
Would network-ethereum, chain-ethereum, crypto-ethereum, be best?

e.g.

Wallet Connect

chain-ethereum://wc:7f6e504bfad60b485450578e05678ed3e8e8c4751d3c6160be17160d63ec90f9@2?relay-protocol=irn&symKey=587d5484ce2a2a6ee3ba1962fdd7e8588e06200c46823bd18fbd67def96ad303&methods=[wc_sessionPropose],[wc_authRequest,wc_authBatchRequest]

Payment Links

See BIP 21 - URI scheme for making Bitcoin payments and Algorand URI scheme

chain-algorand://TMTAD6N22HCS2LKH7677L2KFLT3PAQWY6M4JFQFXQS32ECBFC23F57RYX4?amount=150500000

Has any of the above been explored before (and found to be a unworkable)?
Would cooperation on this be unlikely with major wallets?

Let me know your thoughts and if this is worth drafting a CAIP.

---

Context: I'm building a cross platform mobile Algorand wallet

[LeslieOA]

…anyone? 🥹

[LeslieOA]

To clarify, I guess I'm looking for the most "future proof" or extensible "grammar" to use for these URI's.

[bumblefudge]

Here's a list of the main URIs and how they could be presented by a wallet app:

1. Blockchain and environment links: in-app explorers, switch to network
2. Wallet/account links: profile preview, send to wallet
3. Payment transactions: send, receive, etc
4. Token/asset/NFT: send, receive (add), etc
5. Smart contract/app: if it's methods are publicly available, a simple interface for invoking said methods
6. There are others like account import/export

So, I think the CASA mental model to date has been that CAIP 2/10/19/etc identifiers are pointers to networks/actors/chainstate respectively. There have been some discussions that never ended in another CAIP asbout how to address non-asset chainstate like transactions or witness objects in UTXO, it might be worth going through those to get a sense why there isn't already a CAIP for each of those types of addressable things. For the most part, we like to have 2 or more independent concerns (i.e. companies or FOSS projects) that would use a given identifier syntax or UX pattern before we formalize a CAIP, since that tends to make things a little more hardened and objective just by dint of more perspectives and incentives.

More generally, though, you'll notice that CAIPs mostly specify NOUNs, not VERBs. data models for transactions or receipts, identifier schemes, etc. URIs are generally used for nouns, so I think turning events and methods into nouns might be a bit of a square peg in a round hole; can you say a little more about why a URI specifically is useful for each method and action taken in the system, as opposed to each record in the system? That part is confusing me a little, I feel like I'm missing step 0 of the thought process.

[bumblefudge]

(also as a sidenote, I would mention that in addition to the naming collision with our illustrious alliance, there is also a commercial bitcoin wallet named casa! it's hard to be the alliance for discussing wallet tech when there are not one but two wallets with the same name-- terrible SEO! 😅 )

[LeslieOA]

(also as a sidenote, I would mention that in addition to the naming collision with our illustrious alliance, there is also a commercial bitcoin wallet named casa! it's hard to be the alliance for discussing wallet tech when there are not one but two wallets with the same name-- terrible SEO! 😅 )

Oh no, entirely! 😅

"Casa" is just an abbreviation. The full name is "Casa Famiglia Wallet" (or it will be in app stores, similar to "Pera Algorand Wallet"). It's currently non-commercial and open-source (FOSS). I will make sure not to abbreviate in messages here to clarify the distinction.

🙏🏾

[LeslieOA]

Here's a list of the main URIs and how they could be presented by a wallet app:

1. Blockchain and environment links: in-app explorers, switch to network
2. Wallet/account links: profile preview, send to wallet
3. Payment transactions: send, receive, etc
4. Token/asset/NFT: send, receive (add), etc
5. Smart contract/app: if it's methods are publicly available, a simple interface for invoking said methods
6. There are others like account import/export

So, I think the CASA mental model to date has been that CAIP 2/10/19/etc identifiers are pointers to networks/actors/chainstate respectively. There have been some discussions that never ended in another CAIP asbout how to address non-asset chainstate like transactions or witness objects in UTXO, it might be worth going through those to get a sense why there isn't already a CAIP for each of those types of addressable things. For the most part, we like to have 2 or more independent concerns (i.e. companies or FOSS projects) that would use a given identifier syntax or UX pattern before we formalize a CAIP, since that tends to make things a little more hardened and objective just by dint of more perspectives and incentives.

More generally, though, you'll notice that CAIPs mostly specify NOUNs, not VERBs. data models for transactions or receipts, identifier schemes, etc. URIs are generally used for nouns, so I think turning events and methods into nouns might be a bit of a square peg in a round hole; can you say a little more about why a URI specifically is useful for each method and action taken in the system, as opposed to each record in the system? That part is confusing me a little, I feel like I'm missing step 0 of the thought process.

Thanks for this. You're quite right (regarding nouns vs. verbs); and I guess this is what I'm trying to explore (and eventually at least "formalise" for future work on at least ARC-300 for Algorand VM based chains).

The "step 0" was effectively:

• "Why isn't every resource addressable on a blockchain?"
  • Read: Could we standardise on URI/URLs for most if not all resources on a blockchain?
• "Why can't every action be described in a URL/URI on a blockchain?"
  • This one I can agree with you on regarding if a URI is "fit for purpose" in this case, but then I look to the web's query parameters: e.g. https://www.google.com/search?q=blockchain

It does feel that with the correct standardised action parameters this could be workable.
Ease of implementation for libraries (or individuals) is my current thought.

P.S. Step "-1" was more "Can we just standardise on URI schemes for opening mobile wallets based on the chains they support!?" (see my initial post).

[glitch-txs]

I'm not sure about this, what if your app supports more than one chain? which schema would you use?

[glitch-txs]

isn't the dapp only able to use one schema at a time?
Let's say a dapp supports chain A and B, and there's a wallet that only support A and another wallet that only support B. Then the dapp should choose one schema either for A or B when it actually supports both

[LeslieOA]

@glitch-txs Ah, I see what you mean and agree: for what we're proposing, it would be best to stick to one schema for all chains, irrespective or VM.

Using your (read: @WalletConnect's) chain ID's, in theory, Kieran's example would then be:

evm://transaction?chain_id=eip155:1&...
avm://transaction?chain_id=algorand:wGHE2Pwdvd7S12BL5FaOP20EGYesN73k&...

Let's imagine how this could work with WC's pre-existing Chain IDs.
Let's also:

1. Allow the technology/VM prefix (e.g. eip155:, algorand:) to be dropped when using a VM scheme (i.e. evm, avm, etc)
2. Also have a chain-agnostic scheme that could be used by wallets that are multi-chain and multi-VM

 

e.g.

A multi-chain EVM wallet would support:

• Ethereum Mainnet: eip155://transaction?chain_id=1&...
• Polygon Mainnet: eip155://transaction?chain_id=137&...
• Base Mainnet: eip155://transaction?chain_id=8453&...
   

A multi-chain AVM wallet would support:

• Algorand Mainnet: algorand://transaction?chain_id=wGHE2Pwdvd7S12BL5FaOP20EGYesN73k&...
• Voi Testnet: algorand://transaction?chain_id=algoraand:XnoWtviVVJW5LGivNFc0Dq14V3kqaXu&...
   

A truly multi-chain wallet would support all of the following:

• Ethereum Mainnet:

  • chain://transaction?chain_id=eip155:1&...
  • eip155://transaction?chain_id=1&...

• Polygon Mainnet:

  • chain://transaction?chain_id=eip155:137&...
  • eip155://transaction?chain_id=137&...

• Algorand Mainnet:

  • chain://transaction?chain_id=algorand:wGHE2Pwdvd7S12BL5FaOP20EGYesN73k&...
  • algorand://transaction?chain_id=wGHE2Pwdvd7S12BL5FaOP20EGYesN73k&...

• Voi Testnet:

  • chain://transaction?chain_id=algorand:IXnoWtviVVJW5LGivNFc0Dq14V3kqaXu&...
  • algorand://transaction?chain_id=IXnoWtviVVJW5LGivNFc0Dq14V3kqaXu&...
     

Note: chain: as a genuinely wallet and chain agnostic URI scheme (it could possibly be caip:)

I personally am less concerned with the naming conventions of scheme or VM groupings, but it would be good to have a standard, and I'd be happy to adopt WC's.

Kieran has previously (and repeatedly, haha) made a great point about using genesis hashes as the unique ID for all chains:

chain://transaction?genesis=0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3&...

chain://transaction?genesis=wGHE2Pwdvd7S12BL5FaOP20EGYesN73k&...

As these URI's are generally not expected to be typed by hand/human; I'm also for this proposal.

P.S. avm is used here for Algorand tech based chain grouping as there currently isn't an official nomenclature efforts between Algorand Technologies/Foundation and Voi Networks.

[kieranroneill]

@glitch-txs you're right, why restrict it?

@LeslieOA I did like your idea of caip (not a fan of chain, too generic. What's to stop the OEM/OS just deciding they want to use chain now?)

Also, to extend my opinion, I am a fan of prefixing enhancements with the proposals number, i.e. caip0045:// (or whatever the URI scheme's proposal number will be). It also acts a kind if versioning too!

[bumblefudge]

What's to stop the OEM/OS just deciding they want to use chain now?)

Indeed, my concern with the protocol segment of URIs is that all of this is fragile in multiple ways: collisions (someone else could register a URI with protocol segment avn or algorand for some unrelated purpose or acronym collision here and then browsers and OSs alike will just override/redirect your URIs in at least a browser-extension context...

there HAS been talk of registering caip with iana (ipfs://, eth://, and dweb:// are all registered, albeit at the lowest level of security, provisional, as there is no RFC or equivalently-formal document defining the syntax of each URI scheme to date!) but I'm unclear how many of your use-cases would be part of a spec CASA could ship (even as an internet-draft with no standing in IETF) since CASA is a fairly slow-moving entity and it feels like many of the things you want to formalize in a URI syntax are more like implementation-specific conventions rather than hardenable syntaxes for a unified protocol.

i may have to percolate on this a bit, so far the only things I think are hardened enough to justify an IANA registry are CAIP2/10/19 strings, which are just addresses/pointers that dereference to straight-forward objects in chainstate. i had not contemplated things like method calls being part of that scheme... those feel like a very different beast! let me percolate on it a bit, i have been meaning to schedule some kind of open-house or forum with parties interested in a caip:// URI scheme in the coming months and if i do i'll definitely ping you here to make sure you're invited.

[LeslieOA]

What's to stop the OEM/OS just deciding they want to use chain now?)

Indeed, my concern with the protocol segment of URIs is that all of this is fragile in multiple ways: collisions (someone else could register a URI with protocol segment avn or algorand for some unrelated purpose or acronym collision here and then browsers and OSs alike will just override/redirect your URIs in at least a browser-extension context...

there HAS been talk of registering caip with iana (ipfs://, eth://, and dweb:// are all registered, albeit at the lowest level of security, provisional, as there is no RFC or equivalently-formal document defining the syntax of each URI scheme to date!) but I'm unclear how many of your use-cases would be part of a spec CASA could ship (even as an internet-draft with no standing in IETF) since CASA is a fairly slow-moving entity and it feels like many of the things you want to formalize in a URI syntax are more like implementation-specific conventions rather than hardenable syntaxes for a unified protocol.

i may have to percolate on this a bit, so far the only things I think are hardened enough to justify an IANA registry are CAIP2/10/19 strings, which are just addresses/pointers that dereference to straight-forward objects in chainstate. i had not contemplated things like method calls being part of that scheme... those feel like a very different beast! let me percolate on it a bit, i have been meaning to schedule some kind of open-house or forum with parties interested in a caip:// URI scheme in the coming months and if i do i'll definitely ping you here to make sure you're invited.

Please do (re: percolating, and genuinely appreciate the time/input on this)!

Yes: I imagine this would take a long while or likely never see the light of day as a CAIP, but thought it best to get input from yourselves as you're a lot more embedded in this.
At "worst": discussions and feedback will inform ARC-300. At best ("ideally"): a broader cross-VM/chain guideline if not standard?

When you do schedule an "open house", I and @kieranroneill would very much be interested in joining, so much appreciated. 🙏🏾

[silverpill]

Multichain URI scheme has been discussed in the past, although the proposed scheme (caip:N:) probably won't work for mobile linking: #67 #243

[LeslieOA]

Thanks for linking these @silverpill.

Glad caip has already been decided on for chain agnostic URI/URN/URLs.

I'm still reading through the web of conversations and documents #67 and #243 link to.
Would you say the current thinking is to forgo adding the CAIP standard number part of the URI scheme?
I understand the thinking, but I'd hope not, as it doesn't seem necessary.

I feel CAIP-19 has already done a lot of the heavy lifting (based on the work of CAIP-2 and 10).

Just throwing ideas around, but it could look something like...
 

Send asset URI

 
Ethereum Mainnet - CryptoKitty #771769

A CAIP-19, where a wallet would give a user the option of viewing or sending the asset

caip://eip155:1/erc721:0x06012c8cf97BEaD5deAe237070F9587f8E7A266d/771769

The above, with the address to send to pre-populated

caip://eip155:1/erc721:0x06012c8cf97BEaD5deAe237070F9587f8E7A266d/771769?sendTo=0x403b9331A9935CF16108Aa055Ba636Ef3A9f4b20

Non-conforming to CAIP-19

caip://eip155:1:0x403b9331A9935CF16108Aa055Ba636Ef3A9f4b20?transfer=erc721:0x06012c8cf97BEaD5deAe237070F9587f8E7A266d/771769

 

Algorand Mainnet - Governance NFTs by Pera Wallet - Lucky Governor

caip://algorand:wGHE2Pwdvd7S12BL5FaOP20EGYesN73k/arc3:820590321

caip://algorand:wGHE2Pwdvd7S12BL5FaOP20EGYesN73k/arc3:820590321?sendTo=RCN4XS53BDBHG76TDMIHUGSXGXRIBS3YKYCDYYK7NUERX6XLFOLFZCCCHI

caip://algorand:wGHE2Pwdvd7S12BL5FaOP20EGYesN73k:RCN4XS53BDBHG76TDMIHUGSXGXRIBS3YKYCDYYK7NUERX6XLFOLFZCCCHI?transfer=arc3:820590321

Note: In this context, 'transfer' simply refers to the name of the action, not the transfer method in a smart contract. Also note chains with custom protocol-level assets (such as Algorand's ASAs and Cardano's Native Tokens).
 

Examples of adding/opting-in to an asset

Algorand Mainnet - Governance NFTs by Pera Wallet - Lucky Governor

caip://algorand:wGHE2Pwdvd7S12BL5FaOP20EGYesN73k/arc3:820590321?approve=RCN4XS53BDBHG76TDMIHUGSXGXRIBS3YKYCDYYK7NUERX6XLFOLFZCCCHI

Stellar Pubnet - Winter Stones

caip://stellar:pubnet/:GD67QVDZ55L3M7IBS3HTJ3PZZ4R3FQGKUZNXD2Y5TZP4PVOWPMRQMOEP?approve=GDUY7J7A33TQWOSOQGDO776GGLM3UQERL4J3SPT56F6YS4ID7MLDERI4

Mobile/deep linking wise, I did notice one URL that doesn't seem to trigger:

Will look into later on Android. Seems a URI may be safer than a URL.

 

@pedrouid Was caip registered with IANA in the end?

[silverpill]

Would you say the current thinking is to forgo adding the CAIP standard number part of the URI scheme?

I think CAIP number is necessary for use cases discussed in linked issues, but the deep linking use case is different and your proposal might make more sense here.