search

ssbc / ssb-config

standard configuration for ssb
MIT License
23 stars 18 forks source link

`override` argument doesn't actually override #11

Closed regular closed 6 years ago

regular commented 6 years ago

The argument called override is passed to rc as defaults. So overrides are overwritten by literally everything else, they are the lowest priority instead of the highest as the name would imply. This bit me today.

It would however be nice to actually have a chance to override specific config properties (without messing with process.argv)

It should be merge(rc(name, defaults), overrides) instead of rc(name, merge(defaults, overrides))

I'd make a PR, but this change would supposedly break a lot of code :(

regular commented 6 years ago

As a consequence, there's no way to override configfile settings in ssb-party. CC @clehner

regular commented 6 years ago

Ok, they are overrides for the baked-in defaults, that's what the name refers to, makes sense. Maybe the right place to address this would be ssb-party then?

regular commented 6 years ago

Yes, it's easy to solve there. Sorry for rambling :)

dominictarr commented 6 years ago

can you give me some context on what you need to override in ssb-party?

regular commented 6 years ago

Sure, it's for regular/ssb-electroparty I want the same client code to be able to be embedded into electron, as well as running "stand-alone" for easy development using e.g. budo.

In the electron case, I want to enable non-interactive auto-onboarding. The application binary contains an invite code and name to be used in an initial about message, as well as a set of feeds to auto-follow. (this is for human users as well as non-humans, think POI kiosk systems in a museum)

The electron binary spawns an sbot, if none is running already, this is done by ssb-party. The flow is this:

In Electron

  1. "Client code" (iinside electron's front-end/rendering process) creates keypair and stores in localStorage
  2. if no sbot is running, spawns sbot and inject's browser's pubkey into config.master[] (that's what I need the override for).
  3. then saves config to ~/.${config.appName}/config` only if that does not exist (to allow use of sbot CLI client for debugging)
  4. passes result of ws.getAddress() as part of the config object to client code. Client code uses its own instance of ssb-client

In the browser (development)

  1. envify bakes result of sbot ws.getAddress into code during build
  2. (same as above): browser generates keypair
  3. connection to sbot initially fails with instructions to add the public key to the config file, restart sbot and reload the page.

I like that the browser's private key never leaves the browser and that the sbot's private key never enters the browser. I also like that client code can be completely agnostic of the runtime environment (i.e. electron vs browser with local sbot vs browser with remote sbot). I develop with this setup for about a week now, and the interference between the two scenarios is minimal.