spec: advertise Tempo charge supported modes#243
Conversation
Spec Preview
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 811a0baa47
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| For zero-amount charges, mode negotiation does not apply. Clients use a | ||
| `type="proof"` credential regardless of `supportedModes`. |
There was a problem hiding this comment.
This new requirement says zero-amount charges MUST use a type="proof" credential, but the rest of this draft only specifies credential payloads and server verification logic for type="transaction" and type="hash" (see the credential and verification sections later in this same file). That leaves zero-amount flows without an interoperable wire format or validation procedure, so independent implementations can’t consistently process compliant zero-amount credentials.
Useful? React with 👍 / 👎.
| If `supportedModes` is omitted, clients MAY assume both `pull` and | ||
| `push` are supported for backwards compatibility with version 00 | ||
| implementations. |
There was a problem hiding this comment.
Allowing clients to assume both modes when supportedModes is omitted conflicts with the new statement that servers only MAY support push: a server that supports only pull can still omit supportedModes, and a compliant client may then pick push and fail unnecessarily. This creates avoidable interoperability failures unless the spec requires servers to include supportedModes whenever they do not support both modes (or defines omission as a stricter default).
Useful? React with 👍 / 👎.
Adds Proof Payload section with EIP-712 domain/types, verification procedure, and receipt generation. Addresses Codex review feedback that type=proof was referenced but never formally defined.
2 participants
Summary
Not all servers want to support both tempo modes (push and pull).
Servers could decline pushes, but if they client sends a push payment ahead of decline, they would lose funds. This PR addresses this failure case by allowing servers to predeclare their supported methods first