Background
Currently, our store receives an entire MeshNetworkClient. This looks awkward because testing the triple store in isolation requires us to pass a MeshNetworkClient and the stores constructors (e.g. triple store constructor) is given a structure that allows it to communicate with other participants, which is unexpected at the call-site.
Potential extra problem: changes and refactors of the MeshNetworkClient may leak into the different stores.
User Story
No response
Acceptance Criteria
Minimize the interface given to the store preventing giving the entire store a mean to communicate.
This could be solved using a trait instead.
Resources & Additional Notes
Important origin of the design #1645 (comment)
Followup design #4227
Comment disapproving design https://nearone.slack.com/archives/C0912BTG51T/p1787584751389389?thread_ts=1787581151.367629&cid=C0912BTG51T
Background
Currently, our store receives an entire
MeshNetworkClient. This looks awkward because testing the triple store in isolation requires us to pass a MeshNetworkClient and the stores constructors (e.g. triple store constructor) is given a structure that allows it to communicate with other participants, which is unexpected at the call-site.Potential extra problem: changes and refactors of the MeshNetworkClient may leak into the different stores.
User Story
No response
Acceptance Criteria
Minimize the interface given to the store preventing giving the entire store a mean to communicate.
This could be solved using a trait instead.
Resources & Additional Notes
Important origin of the design #1645 (comment)
Followup design #4227
Comment disapproving design https://nearone.slack.com/archives/C0912BTG51T/p1787584751389389?thread_ts=1787581151.367629&cid=C0912BTG51T