Thanks for this post. Agree in principle to not having a Store API. The purpose of Waku having a strictly reduced/simplified API would exactly be to negotiate a clean interface with Status. If it turns out that Status protocols couldn’t function without a Store API as is, it’s a good opportunity to review that part of Status’s Waku usage (given new knowledge about SDS integration, etc) until we are aligned on the leanest possible, useful Messaging API.
@Ivansete usually my approach to interface design would be that everything is “private” or internal until we have a clearly expressed (and evaluated) requirement for a function or configuration to be exposed publicly. In this case, I think the separation of the abstracted public layer to the expert layer that allows finer control should only be internal. This means that if in future we do identify a clear need for some “expert” features, we could cherrypick them out into the API. 