Closed noahlevenson closed 1 year ago
Just dumping this note here as a reminder to discuss it with the group before launch:
We expose a lot of Broflake's low level configuration to config server. This means it's the responsibility of config server (and the human adding Broflake settings to proxies.yaml) to serve a proxies.yaml with sane and correct Broflake settings. You can definitely create wacky combinations of settings which will cause Broflake to misbehave!
Because Broflake is so modular and configurable, Broflake itself doesn't really have opinions about what a "correct" Broflake client is.
Broflake's default values are safe and sane. So if you omit a value in proxies.yaml, things are unlikely to go wrong.
But if you specify an override in proxies.yaml, Broflake assumes you know what you're doing. It will let you specify routing tables of any size, adjust the bus buffer arbitrarily, set strange values for NAT or ICE failure timeouts, etc.
Dumping more notes from this week's catchup meeting:
Turning Broflake on for 1% of users is probably plenty. Less than 1% might be preferable, if it's possible.
For ad domains, look up EasyList, AdBlocker, AdButler lists...
Addressed here: https://github.com/getlantern/config-server/pull/280
This is related but it seems like we're living without it so I'm gonna close this issue for now:
Config server must serve configurations which enable Broflake for some subset of users.
What subset of users? I believe someone suggested maybe we should serve Broflake-enabled configurations to development mode users? (I don't really know what that means.)
What domains should we include in Broflake-enabled configurations?
cc: @oxtoacart