Our protocol implementations exist is @waku/core, and offer opinions on the usage such as:
using multiple peers
message dedeplication (for filter)
These opinions are assumptions we have made, and they sit close with the code for the protocol's purest implementation.
Problems with having a general SDK-like functionalities with protocol implementation:
increases complexity by trying to have a great API while being bound by protocol definition
mixed abstraction level. Protocol implementation is one level. Using protocols in a ways that increase reliability, reduces bandwidth usage etc are one level above
makes the code less forkable and readable: 99% developers are not expected to ever touch core protocol implementation. But 80/20 rules says 20% of developers will fork or inspires themselves from general SDK to do their own custom usage of the protocols.
finally, the protocol implementation should be simple and straightforward for readability and comparisons with the specs. Sebago avoid mixing abstraction levels.
Proposed Solutions
It would be a better approach to decouple opinions as much as possible from the protocol implementation, thus keeping it as close to pure, while introducing opinions within @waku/sdk.
This also allows us flexibility in terms of the different APIs we can provide for each protocol.
This is a change request
Problem
Our protocol implementations exist is
@waku/core, and offer opinions on the usage such as:These opinions are assumptions we have made, and they sit close with the code for the protocol's purest implementation. Problems with having a general SDK-like functionalities with protocol implementation:
Proposed Solutions
It would be a better approach to decouple opinions as much as possible from the protocol implementation, thus keeping it as close to pure, while introducing opinions within
@waku/sdk.This also allows us flexibility in terms of the different APIs we can provide for each protocol.
Acceptance Criteria
Notes