There have been some compliaints (was it @ahdinosaur?) about the degree to which things depend on ssb-config.
I think one thing here is that default settings live here, creating an awkward peer dependency.
One idea is move all the config into the modules that need them. say, those plugins hold a default-config.json file.
hmm, but caps are an awkward case - because currently they are set in under the caps object,
all caps together, not with their related settings. Maybe this is better? or maybe caps should be handled specially? It might make more sense to just have a single cap (actually that ship has already sailed) that is then hmac'd by each purpose. or maybe have that + an particular caps can be overridden?
There have been some compliaints (was it @ahdinosaur?) about the degree to which things depend on ssb-config. I think one thing here is that default settings live here, creating an awkward peer dependency. One idea is move all the config into the modules that need them. say, those plugins hold a
default-config.json
file.hmm, but caps are an awkward case - because currently they are set in under the
caps
object, all caps together, not with their related settings. Maybe this is better? or maybe caps should be handled specially? It might make more sense to just have a single cap (actually that ship has already sailed) that is then hmac'd by each purpose. or maybe have that + an particular caps can be overridden?thought train was triggered by: default
peerInviteCap
https://github.com/ssbc/ssb-peer-invites/pull/7