space-meridian / roadmap

High-level roadmap for Filecoin Station
https://starmap.site/roadmap/github.com/space-meridian/roadmap/issues/1
0 stars 0 forks source link

Spark: Sunset Graphsync retrievals #158

Open bajtos opened 2 months ago

bajtos commented 2 months ago

There is no ecosystem interest in using Graphsync for retrievals; we want everyone to move to HTTP retrievals (using the protocol described in IPFS Trustless Gateway Specification). Based on what I've been told, Curio, the Boost successor, will operate completely over HTTP only, it won't support Graphsync at all.

For a brief period of time, Spark did support only deals advertising the availability of HTTP retrievals. However, there were only ~500 of such deals, so we quickly reintroduced Graphsync back.

Because Graphsync is the default used by Boost, and it's the fastest & easiest path for SPs to be compatible with Spark, we are seeing an increasing number of SPs that are advertising the availability of Graphsync retrievals only. (About 20% of retrievals happen over HTTP, 80% over Graphsync.) While this is great for the short term, as it drives the overall RSR up, it creates a future pain point for SPs - they will need to revisit their configuration when Spark drops support for Graphsync. Would it be better for them to configure IPNI & Retrievals for HTTP from the beginning instead of doing it for Graphsync first and HTTP later?

OTOH, maybe we don't need to drop support for Graphsync yet: when Boost becomes deprecated, and providers migrate to Curio, the Graphsync vs HTTP problem will go away organically.

Other aspects to consider:

juliangruber commented 2 months ago

While this is great for the short term, as it drives the overall RSR up, it creates a future pain point for SPs - they will need to revisit their configuration when Spark drops support for Graphsync.

I'm wondering here about the upgrade path from Boost to Curio - if all SPs upgrade to Curio before Spark switches to HTTP only, they won't need to change their configuration.

bajtos commented 2 months ago

While this is great for the short term, as it drives the overall RSR up, it creates a future pain point for SPs - they will need to revisit their configuration when Spark drops support for Graphsync.

I'm wondering here about the upgrade path from Boost to Curio - if all SPs upgrade to Curio before Spark switches to HTTP only, they won't need to change their configuration.

Exactly. That's why I am debating whether we should prioritise dropping Grapsync or whether things will sort out themselves.

Then there is Venus & Venus Droplet, the alternative implementation of SP software. I don't know the status of supporting Graphsync vs HTTP there.

juliangruber commented 2 months ago

Do you know expected timelines for the Curio migration?

bajtos commented 2 months ago

Do you know expected timelines for the Curio migration?

I've been told they want to release the first public version in 2-3 months.

juliangruber commented 2 months ago

I think the relevant timeline is by when they're expecting SPs to have migrated - since this is the point we could switch to HTTP only.