refactor: use Chain type for FilBeam retriever config

[bajtos]

Replace FilecoinNetworkType with Chain from synapse-core in FilBeamRetriever, reading the retrieval domain from chain configuration instead of hardcoding network-to-domain mapping.

Refs:

• This is a follow-up for refactor: move FilBeam domain to chain configuration #570
• Targeting refactor: viem in payments #569

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	synapse-dev	6cf8b3e	Commit Preview URL Branch Preview URL	Jan 28 2026, 04:36 PM

[bajtos]

@rvagg re: #570 (comment)

a better port number might be advisable because I think we include it in the default retrieval path

Would you like me to change the devnet FilBeam domain in this PR? What value do you suggest?

[bajtos]

Re-posting another relevant comment:

How do you feel about using filbeam.localhost:8080 for devnet? It won't work out of the box, but it's possible to configure your machine to make that hostname work, plus the hostname is IMO descriptive enough to make it clear what's going on when somebody tries FilBeam retrievals for devnet pieces.

[bajtos]

There is one more caveat that I realised just now: We are always using HTTPS protocol for FilBeam retrievals. That's fine for mainnet and calibration testnet, but probably too difficult to set up for local devnet 🤔

[rvagg]

And here's my concern about port 8080, we always wrap the FilBeam retriever an attempt it on local retrievals: pieceRetriever = new FilBeamRetriever(baseRetriever, network) so that's always going to be hitting 8080 which could contain anything and may be running something that's not going to fail-fast like we want it to which could screw up testing in surprising ways.
Hence, my preference for using a more random port number if you have to hardwire something at all. I think we have the option of leaving it undefined for devnet and then doing a skip in FilBeamRetriever when we find we don't have a defined endpoint. Then if there's ever a use in devnet where we're testing this then the onus is on the developer to supply a chain with that defined. I think that can work with this chain structure?

[bajtos]

Hence, my preference for using a more random port number if you have to hardwire something at all. I think we have the option of leaving it undefined for devnet and then doing a skip in FilBeamRetriever when we find we don't have a defined endpoint. Then if there's ever a use in devnet where we're testing this then the onus is on the developer to supply a chain with that defined. I think that can work with this chain structure?

Yes, I think that's the best option! I'll also log a warning when we fall back to direct retrievals.

[bajtos]

In 7d1438a, I reworked chain.filbeam to null for devnet, and modified code reading chain.filbeam to fall back to direct retrieval from the SP with and log a warning to the console.

This PR is ready for final review and merging as far as I am concerned.

I think that the CI failure is inherited from #569 which is the target of my PR. Fixing the CI checks in #569 is out of the scope of this pull request.

@rvagg @hugomrdias LGTY now?

[rvagg]

lgtm, up to Hugo how it lands though cause it's on to his branch