Support multiple pre-configured relays

[maximbaz]

I'm using multiple relays depending on who I'm sending to or receiving files from. For example if I send a file to myself I might use my own relay, if someone sends a file to me they might use their own relay, but I can also imagine in some cases there is a need to use a dedicated relay that is not to be used for other reasons (maybe due to some particular restrictions, e.g. work vs personal use).

The current design of configuration files allows you to have two files, send.json and receive.json, where you can put most commonly used relay configs for sending and receiving respectively. This already helps, but is not very convenient once you must use another relay, because you either need to edit the file, or provide both relay address and password on CLI.

What if there was another file, say relay.json, with a list of relays and their corresponding settings (unique ID, addresses, ports, passwords), and then send.json and receive.json would just reference to those definitions and only specify the default relay to use for sending and receiving files.

Then, if I want to send using the default relay as configured in send.json, I would just do croc send myfile.txt

If I want to send using a custom relay, I would specify it via CLI flag, maybe like croc --relay john send myfile.txt and croc will find this relay in the config and use all corresponding values for a relay with ID john (address, password).

When you send a file, croc prints a command to run on the receiving end, and it already today specifies the relay, like croc --relay <relay-address> some-code-word. This could be changed to use relay ID instead, and again, when I execute this command, I again don't want to type relay address and password in the CLI, instead I would much prefer croc to match this relay ID to the corresponding relay configuration in relay.json.

What do you think?

(it doesn't have to be a separate relay.json file, we could totally duplicate the relay configs in the existing json files if that is simpler)

[schollz]

I think that sounds great. A relay.json is totally fine, that may be the easiest way to implement. If you want to submit this is a PR, I will definitely accept!

[maximbaz]

I think the change itself is quite simple, but the most challenging part here is backwards compatibility, how much do you want of it?

Both in terms of a client app... (say you had your relay settings configured in send.json, and now all those fields are no longer read, is it okay to ask user to manually re-configure their stuff in a new relay.json file (or using --remember), or do you want some sort of migration, where croc will try to create relay.json based on what it sees in send.json and receive.json?)

... and in terms of cross-client compatibility (say I have updated my local croc, and when I do croc send it tells me a command for receiving end where --relay is an ID and not IP address or hostname, but on the receiving end they still use older croc which doesn't understand IDs in --relay field, is it okay to expect users to realize this themselves?)

If we don't deal with backwards compatibility, would you want to simply bump major version, so that it's clearer to users that something has changed?

[ProactiveServices]

To jump on this bandwagon - it would be handy if the user could use --relay none and --relay default to use no relays or the default relay, respectively.

[roomcays]

It would be very nice feature to be able to choose croc configuration from CLI when running (thanks to self-hosting possibility I do have couple of relays for different "environments" and I end up with manipulating files from under ~/.config/croc manually :( ).

[github-actions[bot]]

Stale issue message