Open SionoiS opened 2 weeks ago
This is a reasonable question, though one that will be more appropriately answered once Sync (and Store) is more integrated into our message propagation protocols. For now, it's simply an augmentation of Store and synced messages will only be accessible via store queries and/or store API
@SionoiS - Isn't sync
only considered to be used from within store nodes? Sorry but I can't quite see the issue now :)
@SionoiS - Isn't
sync
only considered to be used from within store nodes? Sorry but I can't quite see the issue now :)
True, it's mostly a UX problem and expectation.
True, it's mostly a UX problem and expectation.
ah okay , I wonder if it may help allowing sync == true
only if store == true
@SionoiS - Isn't
sync
only considered to be used from within store nodes? Sorry but I can't quite see the issue now :)True, it's mostly a UX problem and expectation.
From this point of view, IMHO, it is the missing SDK layer that could hide the "get me all messages I don't care from where" API. So without that layer we would just introduce more and more complex troubles into the node itself. Without outsourcing such logic we put wishful thinking into clients head (aka "This API will do for me anything I want").
I realized that a user expecting a
Filter
subscribe to return messages fromSync
is going to be disappointed...More generally, do we need a higher level
get me all the new messages from wherever
API?If we think about the flow of messages, a Waku node can output msgs to Relay, Filter and Sync. Inputs would be Relay, Light push, Sync. It would make sense that a msg from Sync is not relayed but should it be used by Filter?
:shrug:
WDYT? @waku-org/nwaku-developers @jm-clius