This PR adds functionality for the autopilot privacy mapper that enables to selectively reveal data that otherwise is obfuscated by default. This is necessary in order to support more advanced autopilot features, such as the soon to be added automatic channel open service. In this case it is necessary to communicate litd's node pubkey to the service (via GetInfo) in order for it to be able to make high-quality node suggestions, taking the nodes's position within the graph into account. Uncovering pubkeys will also be necessary in order to know the peers with which force closes have happened, to not open new channels, or to check whether channels with liquidity already exist. It is nevertheless important to still obfuscate precise channel balances and other information. This is why privacy flags are introduced (in the auto open example it is the ClearPubkeys flag), which define the precise deobfuscation within a session for the following interaction points:
Feature configuration:
Features can be configured (not used yet by any feature) to define algorithmic behavior, for example one can imagine to specify peers to preferentially open channels with. Currently, those node ids are obfuscated, but for automatic channel opens it will be important to know the identity of the nodes in order to respect the user's preference.
Feature rules:
Feature rules define the boundaries within which autopilot is allowed to operate. This includes a peer restriction rule. In the example of automatic channel opens, the service needs to know the pubkeys for nodes not to open channels with.
Firewall intercepted calls from autopilot to litd:
As explained above, certain APIs need to reveal the pubkeys of peers in order for the autopilot to function correctly.
Privacy obfuscation remains on by default and AutoFee's privacy properties remain unaltered. Features can be registered together in a single session, whereby the session's privacy flags will be the union of privacy flags of all the features (which is why feature registration is recommended to be done in individual sessions). When linking sessions, privacy flags must be preserved accross the linked sessions, which is checked by autopilot.
This PR adds functionality for the autopilot privacy mapper that enables to selectively reveal data that otherwise is obfuscated by default. This is necessary in order to support more advanced autopilot features, such as the soon to be added automatic channel open service. In this case it is necessary to communicate litd's node pubkey to the service (via
GetInfo) in order for it to be able to make high-quality node suggestions, taking the nodes's position within the graph into account. Uncovering pubkeys will also be necessary in order to know the peers with which force closes have happened, to not open new channels, or to check whether channels with liquidity already exist. It is nevertheless important to still obfuscate precise channel balances and other information. This is why privacy flags are introduced (in the auto open example it is theClearPubkeysflag), which define the precise deobfuscation within a session for the following interaction points:Feature configuration: Features can be configured (not used yet by any feature) to define algorithmic behavior, for example one can imagine to specify peers to preferentially open channels with. Currently, those node ids are obfuscated, but for automatic channel opens it will be important to know the identity of the nodes in order to respect the user's preference.
Feature rules: Feature rules define the boundaries within which autopilot is allowed to operate. This includes a peer restriction rule. In the example of automatic channel opens, the service needs to know the pubkeys for nodes not to open channels with.
Firewall intercepted calls from autopilot to litd: As explained above, certain APIs need to reveal the pubkeys of peers in order for the autopilot to function correctly.
Privacy obfuscation remains on by default and
AutoFee's privacy properties remain unaltered. Features can be registered together in a single session, whereby the session's privacy flags will be the union of privacy flags of all the features (which is why feature registration is recommended to be done in individual sessions). When linking sessions, privacy flags must be preserved accross the linked sessions, which is checked by autopilot.