chore: clarify internal message flow

[SionoiS]

I realized that a user expecting a Filter subscribe to return messages from Sync 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?

🤷

WDYT? @waku-org/nwaku-developers @jm-clius

[jm-clius]

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

[Ivansete-status]

@SionoiS - Isn't sync only considered to be used from within store nodes? Sorry but I can't quite see the issue now :)

[SionoiS]

@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.

[Ivansete-status]

True, it's mostly a UX problem and expectation.

ah okay , I wonder if it may help allowing sync == true only if store == true

[NagyZoltanPeter]

@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").