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: 62334f6e06
ℹ️ 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".
|
|
||
| | Field | Type | Required | Description | | ||
| |-------|------|----------|-------------| | ||
| | `methodDetails.chainId` | number | OPTIONAL | Tempo chain ID. If omitted, the default value is 4217 (Tempo mainnet). | |
There was a problem hiding this comment.
Set methodDetails.chainId default to the same value used by the other Tempo method drafts (specs/methods/tempo/draft-tempo-charge-00.md:154 and specs/methods/tempo/draft-tempo-session-00.md:543 both use 42431). Keeping 4217 here means clients that omit chainId will derive signatures and did:pkh identifiers on a different chain than existing Tempo payment flows, which can cause valid subscription credentials to fail verification or be charged on the wrong network.
Useful? React with 👍 / 👎.
…on guidance - Remove placeholder review notes from intent and tempo method specs - Add T3 network upgrade requirement for TIP-1011 features - Rename 'Tempo Network' to 'Tempo' in ASCII diagrams - Add Access Key Isolation section: servers SHOULD use one key per subscription for fault isolation; documents risks of key reuse including shared TokenLimit, wider blast radius, and bulk revocation
| date: 2024-06 | ||
| --- | ||
|
|
||
| --- abstract |
There was a problem hiding this comment.
I'm curious if there is a doc on the motivation? Eg, why build subscriptions into the tempo layer vs utilize a billing system and then create payment on Tempo? Not a statement of judgement, just trying to understand the product goals.
| | `amount` | string | Fixed payment amount per billing period in base units | | ||
| | `currency` | string | Currency or asset identifier (see {{currency-formats}}) | | ||
| | `periodSeconds` | string | Billing period duration in seconds | | ||
| | `subscriptionExpires` | string | Subscription expiry timestamp in {{RFC3339}} format | |
There was a problem hiding this comment.
why does a subscription need to expire? Eg, if you sign up for a service like Netflix there is not expiration
There was a problem hiding this comment.
that's fair -- I think we could have this be optional and only have a firm expiry if desired
alternative we could remove and add later as an optional field to reduce API surface
| |-------|------|-------------| | ||
| | `amount` | string | Fixed payment amount per billing period in base units | | ||
| | `currency` | string | Currency or asset identifier (see {{currency-formats}}) | | ||
| | `periodSeconds` | string | Billing period duration in seconds | |
There was a problem hiding this comment.
what is the start date? Often subscriptions do not start now() but anchored to something like UTC midnight.
|
|
||
| # Terminology | ||
|
|
||
| Subscription |
There was a problem hiding this comment.
This is a fairly narrow definition, that does not match the billing perspective, which might be fine, but who is the audience for this concept and would they be confused?
One other thought - given the big definition difference between this subscription and a billing subscription - should we consider another name (maybe 'recurring')?
| `methodDetails`, but MUST define exact activation semantics if they do | ||
| so. | ||
|
|
||
| The billing anchor for a subscription is the time activation succeeds. |
There was a problem hiding this comment.
services even such as Netflix support resetting the billing cycle anchor - is that a trapdoor decision here?
|
|
||
| | Field | Type | Description | | ||
| |-------|------|-------------| | ||
| | `amount` | string | Fixed payment amount per billing period in base units | |
There was a problem hiding this comment.
most subscription systems do not take a fixed amount, but rather a price and quantity, and compute the amount. Eg, you are buying 5 seats to a SaaS system
2 participants
No description provided.