Sync as a replacement for Filter and Light push

[SionoiS]

@prem

Store based reliability is used to determine whether messages sent by a lightClient are received by the network i.e beyond the service/full node the lightClient is interacting with. This basically means Store is not used to established reliability for the last mile (i.e lightClient ↔ serviceNode) alone but rather till second to last mile i.e beyond the serviceNode and hence increases the probability that a message has permeated into the network .

I didn’t know that, make sense!

@prem

In order to achieve something similar with RBSR, a lightClient will have to initiate sync with multiple nodes in the network to ensure messages sent by the node and it is supposed to receive are not missed. If we start to think in this direction, i am wondering how will it be different than gossipsub which also uses a type of sync mechanism with short-term message-cache but with more nodes.

The advantage of RBSR is that the state required (a message cache) to operate is already needed for a light client anyway. GossipSub is also more complex than a simple sync because of the mesh formation and long lived connections.

@prem

what is the latency that we ensivion though?

We can design the protocol to minimize this but syncing require at least one round-trip. If the light node also use Filter we gain efficiency because we fetch and push new messages at the same time.

@prem

Will this be a storage overhead?

Bandwidth overhead as we need to sync and then send messages. We can store as few messages as we need, I don’t think it would be a problem.