Skip to content

FIP-0107: Add API Behaviour Specifications and Migration Guide #1173

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

rvagg
Copy link
Member

@rvagg rvagg commented Jun 30, 2025

This change addresses the open questions in FIP-0107 regarding API behaviour for implicit messages by adding comprehensive specifications for how existing APIs will handle implicit messages while maintaining backward compatibility.

There is still one slightly open question in here, suggesting either the addition of a new ChainGetAllParentReceipts API or a new form ChainGetParentReceipts on the currently under development /v2 that takes a new options parameter. We could come back and close that off once we've decided (it might depend on timing of this FIP).

Copy link
Member

@BigLep BigLep left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great updates @rvagg . This seems like it's very ready at this point for someone else even to pick it up and implement.


**Option 1 - New API**: `ChainGetAllParentReceipts` - returns all receipts including those for implicit messages. This API would return the same results as `ChainGetParentReceipts` before activation of this FIP, but would include additional receipts for implicit messages after activation.

**Option 2 - v2 API**: As of the time of writing, development has begun on the Lotus v2 APIs. It is expected this will eventually lead to extension of [FRC-0104 Common Node APIs](https://github.com/filecoin-project/FIPs/blob/master/FRCs/frc-0104.md). This opportunity could be used to break APIs and introduce an options object that would allow optional inclusion of implicit messages. e.g. `ChainGetParentReceipts` could add a new paramter that would change the returned list to prevent filtering: `{ includeImplicits: true }`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good to have enumerated both options. I would bias towards this as a forcing function to engage and get usage on v2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants