Implement timestamp post-processing

[bbenligiray]

Currently, Airnode uses the API call time as the timestamp of the signed data. This doesn't cover two use cases:

• We want Airnode to make an API call to an RPC endpoint to get chain data. We want timestamp to be the most recent block timestamp. (This is what Nodary does for LSD feeds at the moment.)
• The API that the Airnode call returns includes as timestamp field. We want timestamp to be that.

As a solution, I'm proposing a timestampPostProcessingSpecifications field at the same level as postProcessingSpecifications. This works exactly like postProcessingSpecifications, except output of that will be used as timestamp (rather than data).

This obviously requires a change in the OIS format. The field can be optional similar to postProcessingSpecifications, which makes this a non-breaking change.

EDIT: This requires changes in multiple projects.

• OIS - Implement new processing specification ois#117
• Docs (because of OIS change) - Document processing v2 vitepress-docs#669
• Commons - Implement processing v2 #32
• Airnode - Support processing v2 airnode#1914
• Pusher - Implement processing v2 signed-api#133

[bbenligiray]

@dcroote for visibility

[bbenligiray]

The alternative way of doing this is piggybacking on postProcessingSpecifications. In addition to defining an output, postProcessingSpecifications can define a timestamp. This is somewhat breaking in terms of a potential naming collision.

[Siegrift]

An alternative would be to create postProcessingSpecificationsV2 and change the format of the snippets. Couple of possibilities, some already mentioned on the call:

• Make it return values instead of assigning to output field. The output schema of the function would be {value, timestamp}
• Revisit how input data is passed. Currently input and endpointParameters and we risk a naming collision whenever we want to add new value. Making it inputData object helps with this because we can just add new keys to the object. This is still not bulletproof though.
• We could make the specification not be an array (not sure if anyone used this featrue).
• We could omit the environment and support just Node async. If the processing is a function that returns some value, we can wrap it in new Promise to force it to be async and await it.

[bbenligiray]

We could make the specification not be an array (not sure if anyone used this featrue).

I don't see how this is an improvement

We could omit the environment and support just Node async

It would be nice to have a Node (restricted) environment in the future once that stuff is more fleshed out so I'm not a fan of removing that field. I'm fine with forcing async though.

[Siegrift]

I don't see how this is an improvement

To me the array version feels like an unnecessary complexity. Both user has to think about why the specification is an array and we need to handle chaining the values through multiple processing snippets.

[bbenligiray]

We ended up never using it (says something for modular design imo) but considering that it's already there and working, I don't see the reason to remove it

[Siegrift]

I think you misunderstood this:

An alternative would be to create postProcessingSpecificationsV2 and change the format of the snippets.

I mean to create a new field which implements couple of improvements + delivers this new feature. We would still support the "legacy" post-processing though. We would ensure that only one of postProcessingSpecifications and postProcessingSpecificationsV2 is specified using OIS validation.

[bbenligiray]

For reference I had agreed with postProcessingSpecificationsV2 and was nit-picking above

[Siegrift]

As a note, this requires docs changes as well.

[Siegrift]

I've updated a bunch of PRs (links in the editted issue description).

[metobom]

Will ChainAPI use this change too?

[bbenligiray]

See https://api3workspace.slack.com/archives/C0436H2BJKE/p1700466668070539

[Siegrift]

All PRs have been implemented and all except Airnode (which is to be released) are released.