Need to separate testnet data from live

[blakebyrnes]

• Add an ARGON_CHAIN env var (dev, testnet, local testnet, mainnet)
• Add a flag to cli --testnet, --local-testnet, --mainnet is default
  • Use it to add a nested dir to all data directories if set
  • default to tesnet in .env.production and dev for .env.test and .env.development
    We have a number of places in the codebase where data is stored in a /ulixee or /argon. This has been ok, but with a rollout of a testnet, we are starting to have a problem where mixing this data is problematic and confusing.
  • Mainnet is default and should be the default location
  • Maybe you have to add a —testnet or —local-testnet flag for commands that don’t hit mainnet or they fail once you connect?
    • If you specify a url, it should look up the env before creating dir

        curl -H "Content-Type: application/json" \
        -d '{"jsonrpc":"2.0", "id":1, "method":"system_chainType", "params":[]}'  https://rpc.argon.network/

Chain Ids.

We have a notion of a chain id in the localchain and notary now so they at least won’t connect to a different chain after first use. Chain Id is one of the following “chains”, but also a genesisHash of the chain.

• Devent
• Local Testnet
• Testnet
• Mainnet

Cloud Nodes are Pegged to Networks

When you boot up a cloud node, it is pegged to a network. However, currently all the datastores and everything else will be mixed together. This has some benefits, but is also confusing for things like tracking revenue and logs. Co-mingling everything in a single set of files and directories is an option, but we made a cloudnode a single localchain setup. To allow a cloudNode to attach to multiple networks, you’d need to essentially tell the cloudNode what is its Testnet Localchain, what’s it’s Mainnet Localchain, etc. This is viable, but adds internal complexity.

UX Problems:

1. It’s hard to know without a UI change which wallets are hitting which chain id right now
2. Do you think of these Datastores as “spanning” chains, or is it preferable to think of all the data as bucketed by network. I’m not sure there are many benefits to seeing the current Desktop design with mixed chains
3. Can’t tell what revenue you’re seeing in the Datastores
4. If you test locally, you are mixing your testnet data with your devnet data
5. Once you have real money, mixing it with test money will be confusing and scary feeling.

Types of Data Currently Mixed

Data Element	Description	Per-Network or Global
user-profile.json		Per-Network
- Datastores		Per-Network
- LocalchainPaths		Per-Network
- InstalledDatastores		Per-Network
- datastoreAdminIdentities		Per-Network
- gettingStartedTasks		Global
- defaultAdminIdentityPath		Per-Network
datastores (raw files)	Configs for network, actual datastores, stats, query log, credits, dbxs, data, etc	Per-Network
datastore-deployments.jsonl	This tracks where all we’ve deployed datastores. Should probably be a shared list that includes a network	Global
hosts	This is used for tracking running ips of machines locally. Since this is just for localhost, I’m not sure we need to change this at all. The only possible need is if this gets used on a machine hosting multiple cloudnodes that run different networks	Global
config	this only has a datastoreOutput dir globally, which I’m not sure is really needed. Seems more per-project> Possibly just remove this as a global option and move to datastores	Global
identities	Just a dump for global identities	Global
networkIdentity.pem	This is the admin identity for a cloud node. We might want to make this different per network to enforce differences	Per-Network
user-querylog.jsonl	tracks all queries	Per-Network
payments-(localchain-address	broker-host).json	track payment spend
credits	track credit spend	Per-Network
ulixee/query-hero-sessions		Per-Network
ULX_DATABROKER_DIR	db for the broker itself	Per-Network