namespaces to extend polkadot/caip10 to include "implicit/not-yet-derived" CAIP-2

I realized that "polkadot:-:{address}" scheme would break CAIP-2 because - is no more a valid chainID than or null would be; then I re-read Tim's comment and realized I had misinterpreted it!

In any case, I'm still not sure this complexity is justified by real polkadot usage so I'm going to leave this PR open until I hear from people that have experience of that ecosystem and its practices.

Mar 27 '22 19:03 bumblefudge

Update: since caips#160, - (or rather, ---) could now be a valid CAIP-2. This might be a little too much "wildcard" for existing CAIP implementations, but I am generally favorable to this kind of pattern, as I have some use-cases in mind for namespace-wide checking of wallet identity (independent from chain-specific balance, for example)... pipe up if you'd like to see this finished and merged, polka-people! NB @paritytech

Dec 06 '22 14:12 bumblefudge

in terms of wildcards and non-chain IDs in the chainId segment of CAIP-10, there is now precedent in another namespace that may be relevant to this PR: https://github.com/ChainAgnostic/namespaces/pull/107

Mar 25 '24 15:03 bumblefudge