We are currently checking the validity of the farmer address in the monorepo code (and of course, in SDK).
I believe, it is also important to check the validity of that address in applications like CLI (and maybe in other applications in the future). Because, the user should know the supplied reward address is not valid, even before they start the farming. Accepting a reward address as input, then later on displaying an error related to farmer address, after farming process is started, I believe will not be a good UX.

For solution, maybe we shouldn't check the validity of the farmer address in the farm function, but expose the function to check the validity of the reward address in the SDK?

SDK currently does not support Stream with a known end point. However, we do know when the stream will end.
When SDK side implements that, revamp the progress bar in accordance with the example in the link: https://github.com/console-rs/indicatif/blob/25afbed1ae264c95bf39bf88dc5b86941c65d543/examples/iterator.rs

Turn Subspace Network text into an ASCII art for the CLI app.

Scenario: Running verbose to see events
	Given I am farming
	When I run `subspace-cli farm --verbose`
	Then I should see the logs
	But I should not see a progress bar

Probably, we cannot display a static progress bar whilst logs are streaming to the terminal screen. I will still search my options for that, since I want to enable the progress bar also for the verbose mode. If it seems highly unlikely/impossible, we will only display logs in this mode.

We need to update the default configuration to support the Gemini 3 testnet out of the box.

Should be able to send the process to background, and also bring back to foregroung.

Background:

Scenario: Sending job to the background
	When I run `subspace-cli farm --background`
	Then I should start the farming process
	And I should get access back to my terminal

Foreground:

Scenario: Bringing back the jobs to the foreground
	When I run `subspace-cli farm --foreground`
	Then I should bring back my farming process
	But I should NOT start a new farming instance.

Needs research, might be a Large issue depending on the research progress.

This crate was polluting the logs previously, but things might have changed and there could be important info within this logs. If this crate is not polluting the logs anymore, enable it back again.

I am getting an error when attempting to farm after wiping an existing plot. Steps to reproduce:

1. I have an existing plot
2. run subspace-cli wipe
3. run subspace-cli init with 1MB plot size
4. run subspace-cli farm

I receive the following error:

Update:
I am getting this error even when I don't have an existing plot (i.e. I clear all related files to start from scratch).

UPDATE 2:
This appears to be driven by plot size, 1MB doesn't gives the above error, 10MB works.

What is the feature you would like to see?

Some users are getting confused because of this. And this is an advanced option since most people will not run an executor by default.

Code of Conduct

• I agree to follow this project's Code of Conduct

CLI probably interprets every message SDK sends for the solution stream (even for the notifications on not found a solution). This leads to incorrect amount of farmed blocks displayed in the application.

Scenario: Running quietly
	Given I am farming
	When I run `subspace-cli farm`
	Then I should see a progress bar
	But I should not see any logs

Implementing the progress bar should be the bottleneck for this issue. Will probably use the emitted events from the SDK side for keeping track of the progress.

This will be the default option for running a farmer. Displaying logs will be an optional feature.

📋 CLI Spec

• Follows the XDG Base Directory spec
• Generates a Default TOML config (exact fields TBD)

The CLI should allow the ability to generate a default config, like so:

# $HOME/.config/subspace/settings
[farmer]
address = "WALLET_ADDRESS"
plot_directory = ""
plot_size = "100GB"
opencl = false

[node]
chain = "gemini-2a"
execution = "wasm"
blocks-pruning = 1024
state-pruning = 1024
validator = true
name = "hostname"
port = 30333
unsafe-ws-external = true # not sure we need this

Given I do not have a config
When I run `subspace init`
Then I should be prompted to generate a config

At the moment, CLI only supports single plot farming.
To support multi plot farming, we have to do the following:

• change the init process, so that user can enter multiple plot directories and sizes
• change the read from config function, so it can parse the config with multiple directories and sizes supplied
• change the farm function api

If there is no subspace-cli folder present under the config folder, the application outputs this message:

could not read your config. There could have been a breaking change, or you may have an ill-formed config file. Wipe will continue...

However, it may be misleading. Simplifying the message as such will be helpful:

could not read your config. Wipe will still continue...

What happened?

Once you init you are prompted with the various questions to start the node & farmer.

Specify the chain to farm (defaults to 'Gemini3c', press enter to use the default):

If the user types what is listed they are given an error

given chain: `Gemini3c` is not recognized!

When left blank it works fine and uses the default of gemini-3c

Version

CLI v0.1.7 Alpha

platform

• linux
• windows
• macos

Expected behavior

to show the proper chainspec default of gemini-3c

Code of Conduct

• I agree to follow this project's Code of Conduct

When user kills the application via ctrl+c, we should exit gracefully (meaning close the farmer and node first, before exiting the program).

Scenario: Getting information on the farmer
	Given I am farming
	When I run `subspace-cli info`
	Then I should see information on the farmer instance

The information can be the following:

• is a farmer instance active, if so, the status of that instance:
  SYNCING 40% - (process ID) connected to Gemini-2a
• how much reward they gained in total (need block explorer integration for this, let's do this later)
• how much space they pledged
• how much space is pledged in total (by the network) - check this formula https://github.com/subspace/block-vote-authorship-collector

Considering these will be available to CLI via SDK, this should be fairly easy to implement

Following the merge of the initial SDK API, let's implement the farm functionality for CLI.

S - if error is originating from CLI (sync with Ivan)
Scenario: Encountering an error while syncing
	Given I am farming
	When I encounter an error while syncing
	Then I should see the error

S - if error is originating from CLI (sync with Ivan)
Scenario: Encountering an error while farming
	Given I am farming
	When I encounter an error while farming
	Then I should see the error

In both scenarios, we should also add a link and a bit of guidance along with the explanatory error message -> guiding the user on what to do, and where to submit this.

For example: Please submit this error to our forums: https://forum.subspace.network/

We will have a config file (namely, settings.toml).
For this, we need some information from the user. These inputs should be validated (right now, no input validation is performed)

These information are:

• reward_address: check if it is a valid rewards address (already done)
• plot_location: check if that location exists, if not, indicate that this is not a valid directory?
• plot_size: should be an integer (I'm using bytesize library as it is being used in the monorepo here)
• chain: don't know what criteria this should be (please check the comment below)
• hostname: any valid string (I'm allowing only ascii characters for now)

@achiurizo , there are some questions on this. I can start working on this after we finalize the decisions

📋 #11

how much space is pledged in total (by the network) - check this formula https://github.com/subspace/block-vote-authorship-collector

• unit tests
• integration tests

1 minute of farming/syncing on cli app generates 270MB log file for a minute, on info level.

a snippet of it:

Witness(b2ad4c30be568f4a0b84c219de9bc2523b6c7d6278659150c39144f3df5b2358b0bb9aea03c16362e82b5cba0f005a3d), chunk_offset: 11, chunk: Scalar(Fp256(BigInteger256([0, 0, 0, 0]))), chunk_signature: ChunkSignature { output: [164, 61, 143, 217, 188, 190, 77, 159, 71, 46, 121, 52, 107, 2, 60, 159, 106, 76, 195, 45, 128, 107, 234, 166, 155, 105, 175, 86, 205, 160, 206, 30], proof: [187, 227, 173, 184, 75, 12, 159, 17, 54, 138, 45, 79, 129, 250, 98, 247, 191, 234, 125, 111, 229, 237, 234, 246, 118, 133, 32, 76, 231, 181, 102, 4, 224, 134, 72, 9, 111, 63, 204, 7, 75, 251, 7, 6, 123, 193, 112, 19, 169, 28, 255, 21, 198, 195, 192, 69, 141, 65, 33, 75, 217, 229, 19, 14] } } }, signature: Signature(36604d0cab28323f3d9e092b6e8265dbf23b2ee8612e920bb278d3256626830fc22ce90b2d06e563e9f1a7486e29e51695d29c5fca323c046b96838b03671b87) } })), UncheckedExtrinsic(None, RuntimeCall::Subspace(Call::vote { signed_vote: SignedVote { vote: V0 { height: 49, parent_hash: 0x9915030f32d0c42e81bb777f518913268f1fba98bb9a129996bc5dff347d3b6f, slot: Slot(1669728081), solution: Solution { public_key: Public(8aecbcf0b404590ddddc01ebacb205a562d12fdb5c2aa6a4035c1a20f23c9515 (5FCrnqeS...)), reward_address: 4293fb9aea85efb34d793411cb267b193483a2fdd82c298eddf4bd2e75bf561f (5DZzyf1s...), sector_index: 7171417552293855675, total_pieces: 256, piece_offset: 648, piece_record_hash: [14, 207, 168, 106, 82, 179, 247, 85, 248, 160, 173, 61, 48, 9, 227, 213, 245, 200, 20, 147, 135, 95, 239, 205, 173, 89, 75, 104, 115, 102, 111, 23], piece_witness: Witness(b18ddec00d3f5e1db95f639be03e6e39e38fc03249678cc69e631a9cec884d948b6f983e9e42238de57176b715380071), chunk_offset: 2, chunk: Scalar(Fp256(BigInteger256([13915182645856025956, 3787607775296346781, 8535057218921434334, 517550843366021485]))), chunk_signature: ChunkSignature { output: [48, 220, 177, 103, 27, 250, 208, 42, 21, 4, 249, 99, 179, 91, 231, 58, 10, 203, 181, 201, 217, 66, 152, 228, 186, 5, 83, 133, 21, 163, 219, 27], proof: [19, 2, 92, 58, 41, 95, 23, 184, 95, 43, 248, 178, 60, 231, 10, 183, 40, 114, 83, 105, 204, 52, 175, 242, 253, 3, 213, 123, 116, 112, 153, 7, 1, 228, 67, 98, 22, 222, 28, 20, 132, 19, 180, 200, 110, 46, 175, 97, 231, 77, 12, 194, 5, 32, 244, 44, 169, 238, 241, 137, 158, 42, 214, 9] } } }, signature: Signature(dade1584fa4c0a08d9e10a3e66719ce0e1dd2f16f41c4ff9ddf8113f644bfa5c9f2f689cf83ea6c28f68374697c097470f1d01e4c57260b51baf2c046ae9fa81) } })), UncheckedExtrinsic(None, RuntimeCall::Subspace(Call::vote { signed_vote: SignedVote { vote: V0 { height: 49, parent_hash: 0x9915030f32d0c42e81bb777f518913268f1fba98bb9a129996bc5dff347d3b6f, slot: Slot(1669728081), solution: Solution { public_key: Public(8aecbcf0b404590ddddc01ebacb205a562d12fdb5c2aa6a4035c1a20f23c9515 (5FCrnqeS...)), reward_address: 4293fb9aea85efb34d793411cb267b193483a2fdd82c298eddf4bd2e75bf561f (5DZzyf1s...), sector_index: 7171417552293855675, total_pieces: 256, piece_offset: 648, piece_record_hash: [14, 207, 168, 106, 82, 179, 247, 85, 248, 160, 173, 61, 48, 9, 227, 213, 245, 200, 20, 147, 135, 95, 239, 205, 173, 89, 75, 104, 115, 102, 111, 23], piece_witness: Witness(b18ddec00d3f5e1db95f639be03e6e39e38fc03249678cc69e631a9cec884d948b6f983e9e42238de57176b715380071), chunk_offset: 3, chunk: Scalar(Fp256(BigInteger256([5799019878922390275, 16612572090561750123, 10384159087734527808, 6867273993153903219]))), chunk_signature: ChunkSignature { output: [138, 72, 187, 21, 56, 218, 242, 79, 167, 104, 242, 204, 203, 116, 60, 200, 1, 255, 52, 142, 197, 82, 210, 182, 251, 91, 10, 136, 229, 10, 253, 48], proof: [242, 89, 169, 147, 197, 125, 209, 61, 170, 197, 17, 94, 0, 241, 227, 167, 22, 52, 3, 234, 15, 2, 80, 173, 198, 242, 235, 46, 148, 200, 60, 0, 18, 205, 84, 116, 12, 254, 216, 233, 73, 167, 219, 136, 13, 217, 88, 54, 44, 220, 221, 176, 56, 54, 170, 172, 74, 179, 234, 79, 15, 242, 229, 2] } } }, signature: Signature(ac1dc17a78bb344ff5ed7f4ba7912399eb19338e009e984591a26211daccb81e810dff4de0e62d3d82b19416d4131534714b8d759750f512e20d9580ed661789) } })), UncheckedExtrinsic(None, RuntimeCall::Subspace(Call::vote { signed_vote: SignedVote { vote: V0 { height: 49, parent_hash: 0x9915030f32d0c42e81bb777f518913268f1fba98bb9a129996bc5dff347d3b6f, slot: Slot(1669728081), solution: Solution { public_key: Public(8aecbcf0b404590ddddc01ebacb205a562d12fdb5c2aa6a4035c1a20f23c9515 (5FCrnqeS...)), reward_address: 4293fb9aea85efb34d793411cb267b193483a2fdd82c298eddf4bd2e75bf561f (5DZzyf1s...), sector_index: 7171417552293855675, total_pieces: 256, piece_offset: 648, piece_record_hash: [14, 207, 168, 106, 82, 179, 247, 85, 248, 160, 173, 61, 48, 9, 227, 213, 245, 200, 20, 147, 135, 95, 239, 205, 173, 89, 75, 104, 115, 102, 111, 23], piece_witness: Witness(b18ddec00d3f5e1db95f639be03e6e39e38fc03249678cc69e631a9cec884d948b6f983e9e42238de57176b715380071), chunk_offset: 4, chunk: Scalar(Fp256(BigInteger256([0, 0, 0, 0]))), chunk_signature: ChunkSignature { output: [164, 61, 143, 217, 188, 190, 77, 159, 71, 46, 121, 52, 107, 2, 60, 159, 106, 76, 195, 45, 128, 107, 234, 166, 155, 105, 175, 86, 205, 160, 206, 30], proof: [134, 209, 160, 150, 34, 43, 19, 89, 146, 43, 61, 123, 83, 222, 115, 95, 216, 17, 136, 155, 218, 246, 219, 231, 41, 202, 88, 64, 146, 126, 91, 0, 23, 130, 241, 176, 22, 255, 143, 66, 161, 190, 21, 69, 136, 182, 25, 182, 122, 109, 6, 110, 103, 113, 76, 226, 55, 77, 159, 49, 49, 29, 201, 9] } } }, signature: Signature(969b5d51a2a79141a33682e777618d8d60d904283538979b554f3407a82da919e7bcb728e9048b6325295bf4d5b2fe9b091a4e87f666254c483f084ec0a8b488) } })), UncheckedExtrinsic(None, RuntimeCall::Subspace(Call::vote { signed_vote: SignedVote { vote: V0 { height: 49, parent_hash: 0x9915030f32d0c42e81bb777f518913268f1fba98bb9a129996bc5dff347d3b6f, slot: Slot(1669728081), solution: Solution { public_key: Public(8aecbcf0b404590ddddc01ebacb205a562d12fdb5c2aa6a4035c1a20f23c9515 (5FCrnqeS...)), reward_address: 4293fb9aea85efb34d793411cb267b193483a2fdd82c298eddf4bd2e75bf561f (5DZzyf1s...), sector_index: 7171417552293855675, total_pieces: 256, piece_offset: 648, piece_record_hash: [14, 207, 168, 106, 82, 179, 247, 85, 248, 160, 173, 61, 48, 9, 227, 213, 245, 200, 20, 147, 135, 95, 239, 205, 173, 89, 75, 104, 115, 102, 111, 23], piece_witness: Witness(b18ddec00d3f5e1db95f639be03e6e39e38fc03249678cc69e631a9cec884d948b6f983e9e42238de57176b715380071), chunk_offset: 5, chunk: Scalar(Fp256(BigInteger256([0, 0, 0, 0]))), chunk_signature: ChunkSignature { output: [164, 61, 143, 217, 188, 190, 77, 159, 71, 46, 121, 52, 107, 2, 60, 159, 106, 76, 195, 45, 128, 107, 234, 166, 155, 105, 175, 86, 205, 160, 206, 30], proof: [229, 5, 245, 115, 0, 234, 186, 76, 80, 110, 89, 169, 28, 146, 197, 175, 217, 129, 54, 185, 155, 40, 58, 138, 69, 132, 138, 205, 224, 242, 251, 6, 167, 34, 26, 219, 132, 47, 30, 196, 112, 36, 5, 9, 240, 74, 222, 251, 197, 158, 64, 203, 228, 0, 166, 16, 16, 157, 179, 161, 247, 190, 41, 10] } } }, signature: Signature(1efe7f307940fac592fcad70acda0cdfdb1c80

The whole file is like that. I don't think info level should throw that much information. This should have been debug or maybe something even lower level imo.

When I modify my settings.toml to an invalid size, this prevents the subspace-cli wipe command from working. Here's an example:

[farmer]
address = 'ADDRESS'
plot_directory = '/home/achiurizo/.local/share/subspace-cli/plots'
plot_size = '10 MB' # offending change here
opencl = false

[node]
chain = 'dev'
execution = 'wasm'
blocks_pruning = 1024
state_pruning = 1024
role = 'Full'
name = 'achiurizo'
listen_addresses = []
rpc_method = 'Auto'
force_authoring = false

[chains]
dev = 'that local node experience'

While subspace init does prevent me from initially setting an incorrect plot size, it's entirely possible that I can modify the settings.toml after. We should still be able to wipe regardless of that change.

📋 #11

how much reward they gained in total (need block explorer integration for this, let's do this later)

When we will have Farmer struct, that can be built without starting the farmer instance, I will revamp the logic of info command and get rid of the short-term strategy of summary file.

Ongoing discussion...

What is the feature you would like to see?

Currently, for each new farmed block, we are printing a new line with the total amount of farmed blocks.

Instead, we can just update the total farmed block count in the existing line.

This should drastically improve the UX

Code of Conduct

• I agree to follow this project's Code of Conduct

We are not using some of the fields in the config.toml file.
These values are initialized with a default value.
And because of this inconsistency (storing them in the config file, but not using them), there are some code duplication in the CLI.
I've another struct, consisting of only the necessary fields.

We shall revamp the config.toml file when we are ready to farm using an actual public chain spec, and decide which values do we actually need.

Also, we maybe should have an optional flag for the init config, that will allow further customization for the node fields.

Lastly, we should consider removing the chain field from the config.toml file, and make it part of the node field. This will make more sense from the code POV.

Currently, waiting for the release.yml to be reviewed.

The loading bar is freezing, prompting users to believe the application is frozen. For the time being users can refer to the logs and will see that progress is being made, but this is still sub-optimal for users and their experience.

What is the feature you would like to see?

Enabling dev and devnet chain in CLI can be helpful in general. They are exposed in SDK, so it shouldn't be hard to implement the support for CLI

Code of Conduct

• I agree to follow this project's Code of Conduct

The following do have default values:

• hostname: HOSTNAME
• plot_size: 1GB
• chain: gemini-1
• plot_location:
  • Linux: Resolves to $XDG_DATA_HOME or $HOME/.local/share.
  • macOS: Resolves to $HOME/Library/Application Support.
  • Windows: Resolves to {FOLDERID_RoamingAppData}.

If these all sound ok, I can start implementing these.

Initialization does not create parent directories and the error is simply ignored. This behavior has already caused some problems. See https://discord.com/channels/864285291518361610/1050203487469850694.
https://github.com/subspace/subspace-cli/blob/e651ddf2ca3aa5881c3667daa67811818b94539f/src/config.rs#L147

What is the feature you would like to see?

For the DSN, having an to supply provider storage should be the default option, since this can prevent some bugs related to syncing (max limit reached).

Code of Conduct

• I agree to follow this project's Code of Conduct

@i1i1 this is both relevant to SDK and CLI.
In the settings.toml, we have this:

[node]
chain = "gemini-2a"
execution = "wasm"
blocks_pruning = 1024
state_pruning = 1024
validator = true
name = "NODE_NAME"
port = 30333
unsafe_ws_external = true # not sure we need this

How should we translate these information to SDK's node methods?

    let node: Node = Node::builder()
        .mode(NodeMode::Full)
        .name(node_name)
        .build(node_directory, chain_spec::gemini_2a().unwrap())
        .await
        .expect("error building the node");

We either change the contents for node in settings.toml, or make some changes in SDK side.

The problems:

• chain_spec does not accept a string in SDK
• NodeMode does not 100% corresponds to -> blocks_pruning = 1024, state_pruning = 1024, validator = true
• no execution field in SDK
• I don't know about this: port = 30333
• and this: unsafe_ws_external = true # not sure we need this

What is your take on these?

We are currently unable to forcefully close the application if it gets stuck on graceful shutdown.

use the box host name when generating the default host name

Related to #21

Both plotting progress tracker and solution tracker may try to write to the file at the same time

When plotting with the CLI on Windows 11, the log file will consume the rest of the available space on the device. In my case I had ~90GB free, and was attempting a 25GB plot. After running the cli I face this error

      at C:\Users\runneradmin\.cargo\git\checkouts\substrate-7bc20b373ca3e834\6d57dbc\frame\executive\src\lib.rs:404
   1: sc_service::client::client::import_block
      at C:\Users\runneradmin\.cargo\git\checkouts\substrate-7bc20b373ca3e834\6d57dbc\client\service\src\client\client.rs:1722
   2: subspace_cli::commands::farm::prepare_farming
      at src\commands\farm.rs:152

And then the log file proceeded to fill up the remaining space available, in this case ended up being a 46GB log file.

leaving me with 0 Bytes available on my system

When running subspace-cli init, the prompt follows with a "Lift Off!" command:

Ready for lift off! Run the follow command to begin:
`./subspace-cli farm`

For folks that have downloaded the release binaries, the binary name may not match this (like ./subspace-cli-ubuntu-x86_64-v0.1.0-alpha). We should make this output match the actual binary name or just simply the prompt to just tell the end-users to run farm