You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now we have some in-flight functionality for Whisper V6: #784
As it stands, we can write in support for this in web3.shh but I want to figure out a future proof way to do this. I see the following problems coming down the road.
API differences between nodes (parity, geth, ...)
API differences across protocol versions (v5, v6, v???)
How it could be fixed.
When you have middleware, everything looks like a middleware...??
Dealing with API differences across different nodes is an issue that exists in the eth_ namespace as well. Currently, we can mostly address these with middlewares, or intentionally not address them but raise helpful errors.
Namespace by node
Alternatively we could implement submodules like w3.geth.shh and w3.parity.shh but that adds some development and testing overhead.
Namespace by version
For dealing with actual changes between protocol versions... not clear. Versioning the actual module might make sense, i.e. web3.shh.v6.WhisperModule. Still poses some usability hurdles.
Separate package
We could move web3.shh to it's own package web3-shh and require installation of the separate package and manual addition of the shh module.
The text was updated successfully, but these errors were encountered:
swarm could still end up with web3 support in some fashion, but the team is off with their own agenda these days. separate ticket required if necessary.
What is wrong
Right now we have some in-flight functionality for Whisper V6: #784
As it stands, we can write in support for this in
web3.shh
but I want to figure out a future proof way to do this. I see the following problems coming down the road.How it could be fixed.
When you have middleware, everything looks like a middleware...??
Dealing with API differences across different nodes is an issue that exists in the
eth_
namespace as well. Currently, we can mostly address these with middlewares, or intentionally not address them but raise helpful errors.Namespace by node
Alternatively we could implement submodules like
w3.geth.shh
andw3.parity.shh
but that adds some development and testing overhead.Namespace by version
For dealing with actual changes between protocol versions... not clear. Versioning the actual module might make sense, i.e.
web3.shh.v6.WhisperModule
. Still poses some usability hurdles.Separate package
We could move
web3.shh
to it's own packageweb3-shh
and require installation of the separate package and manual addition of theshh
module.The text was updated successfully, but these errors were encountered: