NamespaceUtils contrusctNamespaces should only use namespace when generating methods and events instead of namespace and chainId.

[AyushBherwani1998]

Is your feature request related to a problem? Please describe.
The problem with using NamespaceUtils constructNamesapces is that it always needs chainId, when it should only take namespace for the methods and events.

Describe the solution you'd like
{"eip155:personal_sign"} instead of {"eip155:1:personal_sign"} should be accepted

[AyushBherwani1998]

Happy to raise a PR with the fix. The issue arrises when it's used in Multicoin wallet and requires to create methods and event dynamically which is not ideal.

[bumblefudge]

Hey there Ayush:

This is an interesting proposal, which actually speaks to one of the wonkier bits of EVM design to date. As specified and implemented, wallets and dapps don't really have a "wildcard" that can safely be used, and the coming chaos of rollups and ZK rollups in particular makes "cross-chain" assumptions particularly fraught. For this reason, the CAIP-25 protocol which WC namespaces abstract out is very explicit and verbose-- each authorization object that dapp and wallet persist, negotiate, and iterate (modelled on an OAuth3 RAR, if you're curious on the design backstory) is scoped to either a single chain, or an enum of chains with the same authorizations.

What we found when researching use-cases and corner-cases for CAIP-25 was that some dapps and dapp<>wallet trust models/permissioning models have a common list of methods they need across all [EVM] chains, and need to be able to extend that list over time. The way to do this is an authorization object scoped to all of eip155, which over time requests additional chainIds be added to the chains array. Other usecases with different trust models or permissioning flows, however, need fine-grained authorization, different methods for each chain (some read-only, some with smart-wallet signing, some with in-wallet-signing only, for example) and these benefit from separate authorization objects (scoped to a specific chain each) persisted across the session, that add chain-specific methods 1-by-1. It sounds like you're in the former camp but not seeing those options in the namespace builder, maybe?

[AyushBherwani1998]

Hey @bumblefudge that's for detailed explanation. It does sound valid for wallets and dApps having fine control over methods and events for specific chain. However, in the current implementation, the SDK emits the list of methods and events which are not mapped 1-1. It iterates over the user given set of methods and events to generates the list of methods and events.

[bumblefudge]

sorry, not sure i understand.

if you need different methods and/or events per chain, you need to use separate scopeObjects (they're called "namespaces" in the sdk). if you need the same methods and events for 1 or more EVM chains, you can just create a namespace object that is scoped to all of EVM and put 1 or more chains int he chains array within it. is there something about the SDK you're using that makes one of those two strategies not work as described? could you link me to where the SDK is interpreting the namespace objects in a way that contradicts one or both of these options? i don't see the disconnect.