SgtPooki
commented
2 years ago Problems
- Count is not scalable
- Supporting multiple status filters in a single query is difficult and may force pinning providers into certain implementations
Missing
- Paths (more info from @lidel)
- Pinning of IPNS
- Pinning a CAR
Required
Removing
PinResults
- Count (see #86)
- Visible in settings page in IPFS Desktop (Can get metrics)
- Command line for Kubo
ipfs stat ...(No metrics) - Currently used for pagination implementations: Are there more pins I can get by calling the API again?
- Not required for pagination: If returned results count <= max_results, there is more content.
- We can modify clients so that we always add 1 to count (when there is more content) so existing logic is supported.
- Requirement for before/after to be Dates.
Updating/Editing (Without breaking changes)
- Deprecate count
- "hacky" count support in clients. (@sgtpooki to supply details)
Updating/Editing (With breaking changes; v2)
- Remove count
- Add property for "nextToken" or similar name to act as cursor
Count could be replaced with "hasMore" boolean flag.- Update before so that we support arbitrary before tokens. This means they can be:
- Dates
- ... anything.
- In this case, the Pinning Provider would need to return the before tokens in response so client could continue a query when there are more results.
- Don't necessarily need before & after.
- Spec should only require providers to allow a single status string, but they should also support array of statuses.
- Optional properties:
- Mark 'match' property as optional
- Update docs/spec to more 'forcefully' encourage properties in the 'meta' field
- % of data/dag for a CID that has pinned or been processed.
Discrepancies/Problems
- Cluster cannot paginate
- Cluster cannot do count
Car file pinning (@Jorropo to add details here)
- Does pinning car files sound reasonable?
- Pin car file roots
- Spec shouldn't require anything beyond the requirement
BigLep
tbd