Expose an extra zmq socket for publishing data for stateful clients in farcasterd
@TheCharlatan, would be nice to have pointers from your previous work on the syncer, or a minimal patch exemplifying it?
The idea here is to introduce a third socket, aside ctl and msg, only used by farcasterd and stateful clients, correct? Does the swap-cli (which is not state-full in my understanding) continue to use the ctl socket or the new one? Can we control the node through the new one too [make, take, etc] (or is it just a log push kind of communication channel)?
23:31 <TheCharlatan/libera> I think they just expose a raw zmq socket, what we should think about more is the data format we want to use.
23:33 <TheCharlatan/libera> We could either add a loopback to every service that does this, or create a new service that handles the subscriptions.
23:34 <TheCharlatan/libera> I would prefer a new service that all daemons can send their stuff to and then expose a raw zmq socket there.
23:38 <TheCharlatan/libera> I think we can then use internet-2 Connection type, like here: https://github.com/farcaster-project/farcaster-node/blob/main/src/syncerd/bitcoin_syncer.rs#L395
23:39 <TheCharlatan/libera> Except instead of push, we'd probably want to use pub/sub, right?
00:57 <zkao> I'd say the intend is to allow people to use zmq clients to build statefull clients in their favorite programming language
nope, ctl and msg are buses, please refer to the original lnp/bp documentation: https://github.com/farcaster-project/farcaster-node/blob/main/doc/lnp/lnp_node_arch.jpeg
This is kind of supported now, you can get continuous progress reports when subscribed and can mimic being a client service.