Yes it might be. I also have code in a PR that might be of help. I have had no time to come back to it yet.
> On Feb 14, 2021, at 21:28, Diego L.L. <dieguit...@gmail.com> wrote: > > Hello Antoine, thanks, I'll come up with some PR in that direction then. > > Also, may be the issue #58[0] some kind related to my use case? > > [0]: https://github.com/apache/incubator-tuweni/issues/58 > >> On Sun, Feb 14, 2021 at 11:29 PM Antoine Toulme <anto...@toulme.name> wrote: >> >> An interface to BlockchainRepository makes sense, and you general approach >> sounds good. >> >> Cheers, >> >> Antoine >> >>>> On Feb 14, 2021, at 17:19, Diego L.L. <dieguit...@gmail.com> wrote: >>> >>> >>> Hi Tuweni users, >>> >>> I'm building a component to stand between a node and the outside world, >>> with the intention to prevent certain Transaction (0x02) messages to reach >>> the node if they don't satisfy a given set of conditions. >>> >>> This component only requires to be able to maintain a rlpx channel open >>> with its peers but I would like to rely the state/blocks storage to a >>> trusted node. >>> >>> I was able to successfully connect a VertxRLPxService to a peer but It was >>> instantly disconnected because it was unable to answer GetBlockHeaders >>> (0x03) properly. >>> >>> I was willing to give a try to implement a custom BlockchainRepository to >>> inject into the VertxRLPxService that resolves each call through JSON-RPC >>> calls, but then I realized it's not an interface and also kind of coupled >>> to Lucene. >>> >>> Of course I haven't faced how I would instrument the messages yet, but I'm >>> trying baby steps, being the first one to keep the channel open with the >>> peer. >>> >>> So, my questions here would be if I'm on the right path for this component >>> I want to build, and also if you are open to contributions on adding the >>> mentioned abstraction for the BlockchainRepository. >>> >>> With kind regards. >>> -- >>> diego >> > > > -- > diego
