ignored config parameters

[zoedberg]

The following issues are related to this project and rgb-node.

1. in the ffi library, the function start_rgb, after collecting user's configuration in a rgb::i9n::Config struct

   e.g. Config { stash_endpoint: Ipc("/tmp/rgb-node/testnet/stashd.rpc"), contract_endpoints: {Fungible: Ipc("/tmp/rgb-node/testnet/fungibled.rpc")}, network: Testnet3, threaded: true, data_dir: "/tmp/rgb-node/" }

   it calls rgb::i9n::Runtime::init(config) which constructs rgbd::Opts using only some of the parameters of the configuration (rgbd::Opts contains: verbose, bin_dir, data_dir, contracts (list of contract names, without endpoints), threaded, network).

   This means that stash and contract endpoints are ignored. In fact they always get created in the default path ({data_dir}/{network}/). Do we want to provide the users with the possibility to set these endpoints or should we just remove them from the sdk?

2. calling start_rgb with threaded: true spawns a thread calling rgbd::main_with_config with the rgbd options. This call spawns two deamons: stashd and fungibled. But in doing that, it loses several configuration options, from here you can see that only data_dir is retrieved from configuration. In fact network gets always set to the default value (testnet), both when calling it from the sdk and from the shell using the binary (in the latter case the only way to change the network is setting the RGB_NETWORK env variable)

3. to launch rgb in embedded mode we need to launch the daemons with specific inproc endpoints (which require host[:port] syntax, not a path). currently, with the bugs just described we cannot set them

---

I've reported these 3 problems together here (even if most of problems are related with rgb-node) because I think they need to be discussed together.

Moreover I'd like to understand why we need all of those Config and Opts structs:

$ git grep "struct Opts"
src/cli/config.rs:pub struct Opts {
src/contracts/fungible/config.rs:pub struct Opts {
src/rgbd/config.rs:pub struct Opts {
src/stash/config.rs:pub struct Opts {

$ git grep "struct Config"
src/cli/config.rs:pub struct Config {
src/contracts/fungible/config.rs:pub struct Config {
src/i9n/config.rs:pub struct Config {
src/rgbd/config.rs:pub struct Config {
src/stash/config.rs:pub struct Config {

some Opts/Config couples match, others don't, it's not clear to me. Is this duplication really necessary? From what I can see you're using config when launching a thread and opts when launching a new process. Am I correct?

[UkolovaOlga]

@dr-orlovsky

[dr-orlovsky]

@zoedberg all three problems are clearly bugs/misimplementation by the developer who was doing this part of the code. I agree they have to be fixed (i.e. we need to fill in all configuration fields and use them properly, so the endpoints are needed).

Regarding the duplications of structs, they are configs for different daemons or setup environment (integration, cli etc). Shared parts can be moved into a separate shared config like I did in LNP Node, but this is not a big priority for now and will be done anyway when I will be refactoring RGB Node to the best practices I used in LNP Node (there is a lot of other stuff which can be improved/made more efficient in this regard)