feat: introduce IFilecoinServiceMetadata and apply it in FWSS

[rvagg]

Closes: #535

Need's @jennijuju's sign-off. We talked over the various permutations about this and she was going to decide what she wants to consume for the console.

My words of caution about this:

• Untrusted from any contract you don't know, always escape all output and even consider hiding because you never know what it's going to contain. Links shouldn't be clickable etc.
• For contracts you do trust, it's not really critical you have this because you presumably know what that contract is, but this would give those contracts the ability to adjust their own branding .. which implies you trust them enough to defer these strings to them.

[Copilot]

Pull request overview

Introduces a minimal on-chain service identity interface (IFilecoinServiceMetadata) and wires it into the Filecoin Warm Storage Service (FWSS) so consumers can retrieve name()/description() via eth_call, while updating deployment tooling and tests for the new initializer shape.

Changes:

• Add IFilecoinServiceMetadata interface and publish its ABI.
• Update FilecoinWarmStorageService to implement the interface and simplify initialize(...) to remove metadata parameters.
• Update deploy script, tests, and documentation to match the new initializer and metadata access pattern.

Reviewed changes

Copilot reviewed 14 out of 14 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
service_contracts/tools/warm-storage-deploy-all.sh	Removes SERVICE_NAME/SERVICE_DESCRIPTION requirements and updates initialization calldata.
service_contracts/test/ProviderValidation.t.sol	Updates proxy initialization to the new initialize(uint64,uint256,address) signature.
service_contracts/test/FilecoinWarmStorageServiceOwner.t.sol	Updates initialization calldata for the new initializer signature.
service_contracts/test/FilecoinWarmStorageService.t.sol	Updates initialization and refactors event/metadata tests to use IFilecoinServiceMetadata.
service_contracts/test/Abandonment.t.sol	Updates abi.encodeCall initializer args to match new signature.
service_contracts/src/IFilecoinServiceMetadata.sol	Adds the new metadata interface definition.
service_contracts/src/FilecoinWarmStorageService.sol	Implements IFilecoinServiceMetadata, hardcodes metadata, and removes initializer params/validation for metadata.
service_contracts/src/Errors.sol	Removes metadata-length validation error types no longer used.
service_contracts/README.md	Documents the new interface in the contracts README.
service_contracts/Makefile	Adds IFilecoinServiceMetadata to the ABI publishing list.
service_contracts/abi/IFilecoinServiceMetadata.abi.json	Adds ABI artifact for the new interface.
service_contracts/abi/FilecoinWarmStorageService.abi.json	Updates ABI for initializer signature change and adds metadata functions.
service_contracts/abi/Errors.abi.json	Updates Errors ABI to remove deleted error definitions.
README.md	Adds top-level documentation about service metadata and safe consumption guidance.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[rjan90]

#535 (comment)

[rjan90]

Chatted with Jennifer about the intended scope of the v1 Filecoin service metadata standard. The ask was that the initial version expose three fields:

• name() — a short service label
• description() — a concise description, capped at approximately 256 bytes and treated as untrusted display-only text
• homepage() — an optional, size-capped URL for technical documentation, specifications, or the service repository

I’ve created PR #559, stacked directly on this branch, which adds homepage(), updates the implementation and tests, and regenerates the affected ABIs.

[wjmelements]

There's still no reason to do this. At worst it provides an interface for misleading the public. At best it add information everyone already knows to a place nobody will see unless they already knew that information. The IERC20 comparison is wrong; services aren't composable like tokens because there is no common interface for interacting with them. This metadata doesn't help anyone interact with it on-chain, so it doesn't belong on-chain.

Can we please block this until we get a solc with my dispatcher fix? argotorg/solidity#16845 That would mitigate the gas impact on the other functions (though we'd still have to pay for the codesize increase).

[wjmelements]

What you really want is a curated registry with this information. That would provide the same information in a discoverable way but it wouldn't be self-identification, and would avoid all of the problems.

[jennijuju]

There's still no reason to do this. At worst it provides an interface for misleading the public. At best it add information everyone already knows to a place nobody will see unless they already knew that information. The IERC20 comparison is wrong; services aren't composable like tokens because there is no common interface for interacting with them. This metadata doesn't help anyone interact with it on-chain, so it doesn't belong on-chain.

Can we please block this until we get a solc with my dispatcher fix? argotorg/solidity#16845 That would mitigate the gas impact on the other functions (though we'd still have to pay for the codesize increase).

we need this info to make pay console get human readable info to the user. "Information everyone already knows" holds only for the single-operator FWSS case. Even for tokens, the comparison is to the metadata trio, not transfer semantics. name()/symbol() are likewise never consumed on-chain and likewise untrusted (every scam token calls itself USDC) — they exist so any wallet or explorer can render any token without a bespoke list. That is exactly what we need here, for user facing tooling, not for contract developers and composability was never what those methods were for.

[rjan90]

Rebased this PR onto the latest main and resolved the conflicts; all checks are green, so it should be ready for another review.

That said, I see there is still some discussion around these changes. It would be good to reach a decision soon, as this is currently gating the M4.5 contract upgrade: either we land it before the upgrade proceeds or agree to defer it.

[jennijuju]

@rjan90 Will and I have talked through the concern and how we will use this in our tooling, and we are okay to move forward now!