Currently there is not strongly defined end to the fulfillment of a lift request.
The protocol should not allow such open ended operations, and the fulfillment of a list request should be defined.
It could be sniffed, as the recipient would know when it has ended by what it can walk.
It might receive a manifest, so the recipient can compare the manifest.
Or the server could publish its blocks that show its own records of service to this client, so that the client can compare what it received with what the servers own records say that it did.
Publishing some blocks that are unboosted by Lift is a cleaner solution that making further additions to the protocol.
Boosting using Lift should account for what it has asked to be Lifted already when it receives any new Pulses, since it should be using bitswap normally, but then boosting allows the servers to send down more than a Block at a time - the client should not ask via bitswap what it knows should be coming down by Lift.
Currently there is not strongly defined end to the fulfillment of a lift request. The protocol should not allow such open ended operations, and the fulfillment of a list request should be defined.
It could be sniffed, as the recipient would know when it has ended by what it can walk.
It might receive a manifest, so the recipient can compare the manifest.
Or the server could publish its blocks that show its own records of service to this client, so that the client can compare what it received with what the servers own records say that it did.
Publishing some blocks that are unboosted by Lift is a cleaner solution that making further additions to the protocol.
Boosting using Lift should account for what it has asked to be Lifted already when it receives any new Pulses, since it should be using bitswap normally, but then boosting allows the servers to send down more than a Block at a time - the client should not ask via bitswap what it knows should be coming down by Lift.