Closed lidel closed 4 years ago
⁉️ replaced "pin type" with more flexible depth It can represent direct (0) and recursive (-1) pins just fine, but opens more advanced strategies in the future. ⁉️ GET /pins/?cid=Qm&depth=1 could return pin status of arbitrary subtree (open question: how to represent indirect pins in PinStatus object? add indirect Status enum?)
I'm not sure if filtering based on pin depth is possible right now. As far as I'm aware all current pinning services (including Pinata) only track pinned items by the root CID.
@obo20 fair enough, could be revisited in the future, if needed.
For now, I believe we should be ok with simplified depth
filter (recursive/direct).
As long cid
filter accepts an array of CIDs to provide a way of addressing need described in #1
This overall seems fine to me, although I've got a few thoughts/questions about pinning service flow and the pinning objects we're introducing here.
ipfs pin add --with-service=mypinner QmXYZ
to immediately ship the data to the pinning service that we could run into problems if QmXYZ
is not already published to the DHTpin object
that we'll have to wait for the DHT to finish providing before the pinning service can find the data. We'll likely want to not even send the HTTP request until the DHT put is completed
N
objects?@aschmahmann good catch! I failed to document that aspect, fixed now.
Pinned data may not be present at a pinning service and at the same time pin object creation should not be a blocking operation. User may be pinning big data set that takes time to transfer and we don't want CLI and other tools to hang. Instead of waiting for remote pinning to finish, cid-of-pin-object is returned immediately in PinStatus
response, and can be used for periodical status checks later.
I've added Pin object lifecycle
to the spec and missing PinStatus
responses required for async status checks of ongoing pinning operations.
Pin status/progress check can be done via GET /pins/{cid-of-pin-object}
or GET /pins?cid={cid-being-pinned}
.
Right now Status
is an enum string with values like "pinning" vs "pinned", but I wonder if ability to return % value would be more flexible / useful for UIs here. Thoughts?
Right now Status is an enum string with values like "pinning" vs "pinned", but I wonder if ability to return % value would be more flexible / useful for UIs here. Thoughts?
I'd skip this for now. This could come back in the meta object for pins that are in progress.
Q: how specific should the status reporting be? Right now Status is an enum string with values like "pinning" vs "pinned", but I wonder if ability to return % value would be more flexible / useful for UIs here. Thoughts?
I don't think % pinned is currently possible, but we could certainly provide statuses that signify the object is currently being fetched. For reference, this are the current statuses we have in Pinata's system when pinning by CID.
Obviously not all of these would apply to every service, but I do think it would be good to have a standard set of statuses that we can all agree on.
This version is following spec drafted during Pinning Summit where we switched API to operate on "pin objects" with some improvements based on initial feedback and discussions received from the community this week.
This is by no means the finished spec: goal is to close some topics and kick-off discussions on remaining items.
Changes in this PR
:question: – needs clarification or further discussion ⁉️– potentially controversial
replicationParam
with a free formmeta
skip
andlimit
parameters (closes #12)Status
enum in which pin object can exist at a pinning service (for now those are just strings)depth
It can represent direct (0
) and recursive (-1
) pins just fine, but opens more advanced strategies in the future.⁉️GET /pins/?cid=Qm&depth=1
could return pin status of arbitrary subtreedepth
is just a simple filter (direct/recursive)Documentation Preview
Docs for
feat/pinning-summit-variant-v0.0.2
branch can be viewed at:cc @pooja @jacobheun @aschmahmann @achingbrain @autonome @gozala @momack2 @olizilla @obo20 @sanderpick