[Fix] Import sync_node and chain_selector

[jaoleal]

What is the purpose of this pull request?

• Bug fix
• Documentation update
• New feature
• Test
• Other:

Which crates are being modified?

• floresta-chain
• floresta-cli
• floresta-common
• floresta-compact-filters
• floresta-electrum
• floresta-watch-only
• floresta-wire
• floresta
• florestad
• Other: .

Description

This Changes only add sync_node and chain_selector to lib.rs of crates/floresta-wire/src/lib.rs so them can be detected by docs.

Notes to the reviewers

it was

and you can see the difference running cargo doc --open in 3aa7203

Checklist

• I've signed all my commits
• I ran just lint
• I ran cargo test
• I've checked the integration tests
• I've followed the contribution guidelines
• I'm linking the issue being fixed by this PR (if any)

[jaoleal]

Just added some other little changes that i was seeing on the go.

All docs related.

[JoseSK999]

All these pub use p2p_wire::{modules} are not compiled for wasm32. I don't know the exact reason (cc @Davidson-Souza), but we would do the same if it's important.

[Davidson-Souza]

It won't build for wasm because it doesn't have TcpSockets. We need to make this optional and allow to use something like websockets to work.

[jaoleal]

Ill add the feature gate.

how serious is this non-std thing ? I think its prudent to make some tracking issue or a discussion to expose the state of some crates being able to compile for non-std.

[Davidson-Souza]

This crate doesn't work for no-std. I've added this so one can use floresta (the crate) on wasm but as long as they build their own transport.

[Davidson-Souza]

There's a genuine question to be made here: do we want to export ChainSelector and SyncNode? There's not much usage into using them in isolation, they are usually spawned by RunningNode.

[jaoleal]

There's a genuine question to be made here: do we want to export ChainSelector and SyncNode? There's not much usage into using them in isolation, they are usually spawned by RunningNode.

Even if one cant use them for something individual with the whole module itself, i do still think we should expose its docs as a floresta-wire module atleast...

[Davidson-Souza]

There's a genuine question to be made here: do we want to export ChainSelector and SyncNode? There's not much usage into using them in isolation, they are usually spawned by RunningNode.

Even if one cant use them for something individual with the whole module itself, i do still think we should expose its docs as a floresta-wire module atleast...

It would be easier to explain in the current docs all the stages, but without exporting them.

The current approach exposes them into the API. But leaking something that's not meant to be used is a bad practice.

Now that I'm thinking about it, the utreexo node should default to running node, so people don't need to care about it

[jaoleal]

Now that I'm thinking about it, the utreexo node should default to running node, so people don't need to care about it.

So, in the end we will actually remove the running node export ? (because its a internal of floresta-wire ? )
And in floresta-wire docs we explain its existence ?
And a follow up to

"the utreexo node should default to running node"

[Davidson-Souza]

Now that I'm thinking about it, the utreexo node should default to running node, so people don't need to care about it.

So, in the end we will actually remove the running node export ? (because its a internal of floresta-wire ? ) And in floresta-wire docs we explain its existence ? And a follow up to

"the utreexo node should default to running node"

Yes, this is what I'm pending towards. Is there a use-case where someone would say: "I just want to figure-out what's the best chain of headers", or "I have this chain of headers, please download and check every block on it and return"?

[jaoleal]

Is there a use-case where someone would say: "I just want to figure-out what's the best chain of headers", or "I have this chain of headers, please download and check every block on it and return"?

The only way to answer this question is reflecting what we want this project to became.

we already follow a modular approach to develop features here but, how modular we want them to be ? modular enough so one can take a module and its methods to use the way he wants ? IMO, yes.

[JoseSK999]

I think the chain selector seems more likely to be useful on its own (perhaps someone wants to use it but implement custom logic for the sync, e.g. a ZKP sync). But the ibd-and-then-return component doesn't seem useful on its own.