When user has created (or restored) only one wallet with Smapp, auto open it in new smapp session.
Importing a wallet means restoring a wallet from file or from mnemonic.
Wallets files directory - Smapp should persist wallet files it imported or created in {user_docs_dir}/smapp/ and not in a non-user-accessible directory.
Wallet Names
Each wallet must have a unique display name. When user attempts to import a wallet and there's already an existing wallet in the wallets files directory then prompt user to select a different name for the new wallet to avoid duplication.
When user creates a new wallet in smapp, try to find a unique name and set it automatically for the user. e.g. if user has 'Main Wallet' then name a newly created wallet 'Main Wallet 1'. User who cares about names should be able to rename an open wallet from the settings screen.
Wallet Metadata
Smapp should have additional metadata about each wallet that includes user settings for working in this wallet that where established as part of the restore wallet or new wallet flows. This metadata should include if the user worked with this wallet using a local managed node or a spacemesh api. It is useful to use a concept of Api Providers. In case of local managed node, the api is provided by the node. In case of an api specified by a url - the api is provided by the provider that provides the api endpoint. e.g. a public remote spacemesh api provider.
Metadata should also include the network-id that Smapp is configured to work with. Smapp currently supports only 1 network id but this will change in future versions.
When user creats or imports an additional wallet (beyond the first one that must be created in order to work with Smapp) then, on new app session, prompt the user to select which wallet to use in this app session. Once a user specified which wallet to open, configure Smapp to use the wallet's provider metadata. So, Smapp needs to have a notion of all wallets that the user worked with in the App and ideally this can be implemented w/o scanning folders every new Smapp app session.
When opening a wallet in a new app session, Smapp should connect to the provider that the user last worked with for this wallet. e.g. local node provider or remote api provider. In case of local node - it should start the managed node. In case of a remote provider - it should connect to its api.
Smapp should not automatically scan the wallets folder and silently import wallets to be used in the app. User must import explicitly each wallet he wants to use in Smapp. When a user restores/imports a wallet (from file or mnemonic) Smapp should prompt the user to specify the provider he wants to work with. e.g. local or remote. In case of a name conflict, Smapp should prompt the user to rename the wallet and ensure that name is unique.
In versions of Smapp beyond 0.2 we may give users the option to switch working with a wallet between providers. Once we do and the user changed provider for a wallet, Smapp should persist this metadata and use it in future app sessions.
Smapp does not need to enable users to import ALL wallets that the user has worked with in Smapp to another computer running Smapp or to same computer after a clean re-install of Smapp. User is expected to import the wallets one by one and provide the metadata for each import. e.g. set the provider...
Network Ids
Smapp currently has one network id that it should obtain from the config file for a local node provider and from the node api for a remote api provider. In the future we would like to add support for working with multiple networks with Smapp but for now we can assume only 1 network in Smapp.
A network-id is also included in the wallet's file and not in the meta-data smapp has about the wallet. This is a safety feature that is designed to enable helping users to avoid accidentally mixing wallets between networks by importing to Smapp a wallet with a network id which is different than the app's network id.. e.g. trying to use a testnet wallet on mainnet.
When a user imports a wallet into Smapp, the app should check the net-id in the wallet file and warn the user about a mismatch in case that it is configured to use a different network id. - if the user confirms working with this wallet with Smapp's current net-id then Smapp should update the net-id in the wallet's file to provide protection for future possible imports of that wallet to other instances of smapp and to other clients.
Requirements
Wallet File
Wallets files directory- Smapp should persist wallet files it imported or created in{user_docs_dir}/smapp/and not in a non-user-accessible directory.Wallet Names
Wallet Metadata
Smapp should have additional metadata about each wallet that includes user settings for working in this wallet that where established as part of the restore wallet or new wallet flows. This metadata should include if the user worked with this wallet using a local managed node or a spacemesh api. It is useful to use a concept of
Api Providers. In case of local managed node, the api is provided by the node. In case of an api specified by a url - the api is provided by the provider that provides the api endpoint. e.g. a public remote spacemesh api provider.Metadata should also include the network-id that Smapp is configured to work with. Smapp currently supports only 1 network id but this will change in future versions.
When user creats or imports an additional wallet (beyond the first one that must be created in order to work with Smapp) then, on new app session, prompt the user to select which wallet to use in this app session. Once a user specified which wallet to open, configure Smapp to use the wallet's provider metadata. So, Smapp needs to have a notion of all wallets that the user worked with in the App and ideally this can be implemented w/o scanning folders every new Smapp app session.
When opening a wallet in a new app session, Smapp should connect to the provider that the user last worked with for this wallet. e.g. local node provider or remote api provider. In case of local node - it should start the managed node. In case of a remote provider - it should connect to its api.
Smapp should not automatically scan the wallets folder and silently import wallets to be used in the app. User must import explicitly each wallet he wants to use in Smapp. When a user restores/imports a wallet (from file or mnemonic) Smapp should prompt the user to specify the provider he wants to work with. e.g. local or remote. In case of a name conflict, Smapp should prompt the user to rename the wallet and ensure that name is unique.
In versions of Smapp beyond 0.2 we may give users the option to switch working with a wallet between providers. Once we do and the user changed provider for a wallet, Smapp should persist this metadata and use it in future app sessions.
Smapp does not need to enable users to import ALL wallets that the user has worked with in Smapp to another computer running Smapp or to same computer after a clean re-install of Smapp. User is expected to import the wallets one by one and provide the metadata for each import. e.g. set the provider...
Network Ids
Smapp currently has one network id that it should obtain from the config file for a local node provider and from the node api for a remote api provider. In the future we would like to add support for working with multiple networks with Smapp but for now we can assume only 1 network in Smapp.
A network-id is also included in the wallet's file and not in the meta-data smapp has about the wallet. This is a safety feature that is designed to enable helping users to avoid accidentally mixing wallets between networks by importing to Smapp a wallet with a network id which is different than the app's network id.. e.g. trying to use a testnet wallet on mainnet.