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
I wonder if the network backend should have an abstract base class (interface)... that forces implementation of 5 main methods...
And allow a formal way of extending the PrivateKey class with additional 3rd party methods.
The reason I'm thinking this is that there are a number of different service providers and will probably be more in future. Not to mention things like mAPI (merchant API), ElectrumX, and other chain indexers.
and I simply don't have time to keep up with it all and support all of them.
This is especially true for _unwriter's tools which I want to support but I'm stretched a bit thin to formally include it in an optimal way... perhaps there's a way to cleanly outsource this via a standardized network interface + plugin-like model? (Then _unwriter tool devs can be free to build out their own bitsv extensions as they see fit)
The text was updated successfully, but these errors were encountered:
I think overall, a plugin model would be nice because I could limit the scope of bitsv "core" so that I can keep up with it over time whilst bitsv can still stay relevant
but empower other devs to add value in their own diverse ways with their own github repos in a way that allows us to scale our productivity in parallel.
I don't want to be a gatekeeper either or a rate-limiter for anyone.
Shower thought:
I wonder if the network backend should have an abstract base class (interface)... that forces implementation of 5 main methods...
And allow a formal way of extending the PrivateKey class with additional 3rd party methods.
The reason I'm thinking this is that there are a number of different service providers and will probably be more in future. Not to mention things like mAPI (merchant API), ElectrumX, and other chain indexers.
and I simply don't have time to keep up with it all and support all of them.
This is especially true for _unwriter's tools which I want to support but I'm stretched a bit thin to formally include it in an optimal way... perhaps there's a way to cleanly outsource this via a standardized network interface + plugin-like model? (Then _unwriter tool devs can be free to build out their own bitsv extensions as they see fit)
The text was updated successfully, but these errors were encountered: