Currently, ww debug's subcommands target an arbitrary host, the one that with which the client happens to be connected. The debug commands take a <peer> argument, intended to be either an instance ID or a libp2p peer.ID. This should be used to designate the node being debugged.
The preferred way to achieve this is through the Anchor API, which still needs to be re-implemented after the major overhaul of the cluster.Host capability. As before, we want to define a Go interface for Anchor so that we can present a type-switch based API for interacting with various anchor types (cluster, host, in-host path...). Asking users to recast capability clients is bound to confuse them.
Note that only a partial implementation of anchor is needed, as only root and host anchors are required.
Marking this as a bug since the current CLI's behavior is covert, and basically just wrong.
Tasks
Most of these are subtasks of #57.
Currently,
ww debug's subcommands target an arbitrary host, the one that with which the client happens to be connected. The debug commands take a<peer>argument, intended to be either an instance ID or a libp2ppeer.ID. This should be used to designate the node being debugged.The preferred way to achieve this is through the
AnchorAPI, which still needs to be re-implemented after the major overhaul of thecluster.Hostcapability. As before, we want to define a Go interface forAnchorso that we can present a type-switch based API for interacting with various anchor types (cluster, host, in-host path...). Asking users to recast capability clients is bound to confuse them.Note that only a partial implementation of anchor is needed, as only root and host anchors are required.
Marking this as a bug since the current CLI's behavior is covert, and basically just wrong.
Tasks
Most of these are subtasks of #57.
AnchorAnchorAPI methods inclient.Nodeanchor.Host; ensure it provides access to a Host capabilityWalkfromww debug, type-assert foranchor.Host, and obtain debugger