Migrate InboundService Mempool, SyncService to zebra-? crate

[dconnolly]

zebrad and zebra-rpc inter-dependency (e.g., mempool service's Request type)

What should we call it? Any weird things to keep in mind?

[dconnolly]

Idea: zebra-services

[dconnolly]

Also, zebrad-services?

[teor2345]

Seems very generic, we also have network and state services.

[jvff]

I agree it's rather generic, but we are including services which don't share a common description :/

If it helps, my thought process is that I'd rather have a generic broad name than a specific but confusing or fragile name.

[teor2345]

What about zebra-node-services?

(I don't have a strong opinion here.)

[teor2345]

Ideas:

• zebra-sync
• zebra-share
• zebra-distribute (not quite right, too long?)

[teor2345]

I'd also like to move the update_progress function to the new crate. It's useful functionality that doesn't depend on anything else in zebrad.

zebra/zebrad/src/commands/start.rs

Lines 303 to 308 in 1896943

	/// Logs Zebra's estimated progress towards the chain tip.
	async fn update_progress(
	network: Network,
	latest_chain_tip: impl ChainTip,
	sync_status: SyncStatus,
	) {

If we move all these components, then zebrad is left with setup, the main loop, argument processing, and monitoring. Also, anyone who wants to create a different app can do it using the new crate.

[jvff]

We could also create more than one crate, like zebra-mempool and zebra-sync 🤔

[teor2345]

We could delay that decision, and create more crates later as we need them.

[jvff]

Another idea, based on @dconnolly's suggestion to use common traits yesterday at the meeting: have a zebra-services crate that only includes Request and Response types for all services (network, state, mempool, inbound, sync, ...), and maybe it could be a crate that depends on little else (perhaps only zebra-chain?).

[jvff]

Thinking more about this, I think it's the simplest solution that unblocks me while still keeping our future options open. I can:

1. Create a zebra-services crate
2. Move only the mempool Request and Response to it
3. Update zebrad to import those types from the new crate

In the future we can still:

1. Rename the crate
2. Add more Request and Response types as I suggested
3. Move the actual service implementations to the new crate

[teor2345]

we could limit it by just moving the mempool Request and Response for now

We also need to move Gossip, and replace the MempoolError in Response::Queued with BoxError.
(So we don't pull in all the mempool storage error types.)

I agree this is the minimal change we need.

[teor2345]

How do you feel about the name zebra-node-services?

This distinguishes the new crate from the low-level network, state, and consensus crates.

(I don't have a strong opinion here.)

[jvff]

No strong opinion either 😅

Maybe it's best to call it that now to reduce confusion with larger states, and we can change it in the future if we think of a better name 🤔

[dconnolly]

sgtm 👍

[teor2345]

These crate changes are blocking the mempool lightwalletd APIs, which are otherwise ready to go.

I was hoping we could quickly:

• pick a name
• create a new crate
• move a few files
• update dependency paths
  and then get on with the actual lightwalletd work.

@conradoplg how did you want to pick a name here?

[teor2345]

I think we might have reached a conclusion in this thread:
#3598 (comment)

[gustavovalverde]

If there's consensus and a PR, I'd recommend turning this discussion into a ticket (there's an action here for that), so it can be added to ZenHub for tracking and closed when the PR is merged @jvff @teor2345

[dconnolly]

I think zebra-node-services works: #3598 (reply in thread)