skywire icon indicating copy to clipboard operation
skywire copied to clipboard

improvements to skysocks-client

Open 0pcom opened this issue 2 years ago • 1 comments

With the addition of the multi-proxy configuration, there have been some undesirable alterations to the behavior of the cli. Feedback is welcome on these suggestions

Undesireable changes

  • A public key can only be specified via flag, not as argument

-- We should accept the public key to connect to as an argument as well as via flag

  • a single running instance of the proxy can't be stopped with skywire-cli proxy stop

-- If there is only one instance of the proxy running, that instance should be stopped

-- If there is more than one instance running, the default instance should be stopped.

-- If there are more than one running instance and neither is the default, then error / prompt to use --all or --name (or --pk or pk as arg)

  • should also be able to specify a public key to proxy stop instead of just name because the previously run command which started the proxy can just be edited to stop it

-- proxy stop should work as well with the as argument

@mrpalide what do you think of this?

Possible improvements

Additionally, I suggest a flag such as --auto for starting multiple instances of the proxy, and which will start them on different ports, counting up from port 1080, skipping any already bound port.

skywire-cli proxy start --auto <pk1> <pk2> <pk3>

the naming convention should be automatic as well, and perhaps numbered instead of named ; else just use the first and last few characters of the public key.

A note on the config

any proxy which is started is written to the config by the visor API. If it was actually written there by the cli and the config was watched by the visor, that would be one thing, but it doesn't make a lot of sense if you want to start 100 proxies to have them all be configured in the visor's config. It's more of a configuration at runtime when starting a proxy, though the way we have it currently it's possible to manually configure autostart.

This is something we will need to figure out a better solution for going forward, but I don't have a suggestion to address that currently.

i can only state that no change to the config which is made currently persists updates, on linux. See the package documentation wiki article for details on this.

0pcom avatar Dec 14 '23 13:12 0pcom

Some improvements have been made, though not all. This ticket should be updated

0pcom avatar Mar 23 '24 14:03 0pcom