Curio and Boost node count on probelab.io

[yiannisbot]

Notes from a discussion raised in the #probe-lab channel in FIL Slack. Replicating here to identify next steps.

---

From @snadrus:

Note: This doesn’t measure Curio adoption, which was released 8 months before Curio-Markets.

Curio usage isn’t easy to quantify as it does not “call home” or have any other behavior SPs may not want. That’s to welcome code contributions so that Curio workflows represent most SP scenarios.

Those graphs don’t show Curio-Markets which replaced Boost last year to better serve the upcoming paid deal needs. We can run the available tool if you’d like: we did a few months ago and saw usage Curio-Market usage for PLFIF.

Boost-on-Curio users all migrated to Curio-Markets and we’ve deprecated Boost: We haven’t been asked by anyone to install it or investigate any problem in about a year. The remaining Boost users who are still running it aren’t engaged, although we are concerned about our ability to reach Chinese miners who may be out of the loop.

Their methodology must have changed from just counting user-agents (that page 404s) since Forest doesn’t have a user-agent & Lotus hasn’t had one for over 2 years. Curio (SP software) talks to the chain through Lotus (chain daemon), so some percent of those Lotus nodes represent Curio.

From @LexLuthr:

Those numbers are just wrong. There is no way Boost is as low as 85 nodes.

As @eshon noted, we should find ways to get more accurate with the numbers, or add notes/explanations as to what the plots are showing.

[yiannisbot]

For Curio nodes: we agree with the comments. It's not quite possible to quantify Curio adoption, as Curio is not a node type in the network. Note that what we show on probelab.io is the the view of the network and in particular the DHT network.

One central question therefore is: is there a node identifier or similar for Curio nodes? If we could come up with a way to find Curio nodes, how can we deduplicate them so that we arrive at an accurate count?

---

For Boost nodes: there could be two reasons why we don't see as many boost nodes as there are in the network:

• they don't advertise the boost agent version and therefore default to being seen as a lotus node.
• they're in China and we can't reach the node.

[snadrus]

Curio is communicating with the dht via Lotus or sometimes Forest. The healthiest decentralized tracking of Curio adoption would resemble some extension of the user agent concept to include the tools that communicate through that network node.

We experimented with this for Boost by changing its user agent to Boost-on-Curio when it was configured in that way.

Perhaps lotus and forest could offer some API to announce toolkits in use? With the proliferation of minor tools, this could help grow the whole network in realizing what is available in the ecosystem.

Nobody wants the black mark of being the first tool that calls home. But if it is a network wide good, then it helps everybody, including the toolkit makers.
This is reminiscent of how vehicles in the 1950s never had seatbelts, until it was law: no maker wanted to be the first, even though they saw the good of it.

[yiannisbot]

@snadrus getting back to this: can you clarify what's the relation between Lotus and Curio, i.e., can there be multiple Curio nodes for one Lotus node (or the other way round)?

[snadrus]

There is almost always multiple Curio nodes per Lotus node as storage and compute require different hardware. The opposite is also possible for failover and load balancing purposes, though with few takers.

…

On Wed, Jul 9, 2025, 6:00 AM Yiannis Psaras ***@***.***> wrote: *yiannisbot* left a comment (probe-lab/website#181) <#181 (comment)> @snadrus <https://github.com/snadrus> getting back to this: can you clarify what's the relation between Lotus and Curio, i.e., can there be multiple Curio nodes for one Lotus node (or the other way round)? — Reply to this email directly, view it on GitHub <#181 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOU4LS3KHC54FJRV7TVK4T3HTY3LAVCNFSM6AAAAACAGMGUS2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTANJSGE4TOMZRHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[yiannisbot]

@BigLep @jennijuju need some help here as well (feel free to redirect). Here's some context and a question (see also above for more details):

• ProbeLab is crawling the Filecoin DHT and reporting agent version distribution as seen through the DHT - see: https://probelab.io/filecoin/dht/2025-27/#agent_types_avg_1d_plot-plot for Week 27.
• However, our numbers from looking at the network only cannot be accurate - see discussion further up.
• As @snadrus suggests, the only way to get accurate numbers for Curio adoption is [quoting] through some extension of the user agent concept to include the tools that communicate through that network node.

My question is: is FilOz willing to implement something like this in order for us to be able to deduplicate Curio nodes and have more accurate numbers on probelab.io? If not, then unfortunately, there isn't much we can do to have a more accurate count and adoption view of Curio - of course, ideas more than welcome, in case we're missing something.

[LexLuthr]

I am not sure why we keep going back to DHT and libp2p. Why is that more reliable than on-chain info? This just seems like a waste of efforts in my experience.

[pwrepo]

@LexLuthr your slack notes here for tracking:

Curio no longer uses libp2p and will remove it. DHT is unreliable for market node discovery (Boost/Curio). Use on-chain info and attempt connections for reliable discovery. Lotus’ DHT only identifies Lotus daemons, not storage providers. To connect to Curio, send a GET request to the market address; “Hello World!\n- Curio” confirms Curio.

See Boost’s implementation at https://github.com/filecoin-project/boost/blob/main/cmd/boostx/stats_cmd.go for tracking adoption. Connections may require retries or fail due to firewalls. A Curio-aware approach is needed.

[pwrepo]

[yiannisbot]

I've been wanting to update this issue for some time now. Does the new distribution look closer to what is expected @pwrepo @LexLuthr: https://probelab.io/filecoin/dht/2025-40/#agent_types_avg_1d_plot-plot ?

[snadrus]

node counts look good, but the other numbers are difficult for use to verify with how many SPs block us.