Potential problem with `GET /pins` statuses

[obo20]

Right now I'm seeing the current list of potential statuses as resolving, retrieving, pinned, failed, expired, unpinning

Some potential problems for us here:

Active pinning operations Right now our database models are organized in such a way that we have two separate tables:

• User IPFS Pins - These are items that have been successfully pinned to Pinata (either by direct file upload or our pinByHash endpoint, which searches the IPFS network for content). These items can also have a "date_unpinned" date attribute if the user decided to unpin the item.
• Pin Jobs - This is a list of jobs created by our pinByHash endpoint. Essentially this is a list of active / or failed pinning operations that users have asked our nodes to pin.

I'm not sure we'd be able to accommodate this endpoint in its current iteration without doing a lot of fancy postgres maneuvering that would likely impact performance pretty heavily. Is there a reason why we're grouping succeeded pins in the same queryable list as "in progress / potentially failed" pins?

Pin Expiration We currently have no concept of "expired" pins in Pinata. We just bill our users at the end of the month based on how much data they stored and for how long. Could we potentially add an "unpinned" status to this list as well?

Unpinning We also don't have a concept of unpinning. As soon as the request is made to unpin data, we unpin it within that same API call.

[lidel]

Thank you for this feedback, it is very useful (confirms "expired" and "unpinning" were not that useful)

I think we could simply rename expired to unpinned and remove unpinning one – please check #26 and comment if that would work.

Is there a reason why we're grouping succeeded pins in the same queryable list as "in progress / potentially failed" pins?

It is mostly a product of keeping API spec simple, and filtering by a set of known Status enum values.

If we merge resolving and retrieving into pinning, then user could find all "pending" pins via &status=pinning and we could make status filter take a single status instead of array.

I believe that would solve the performance problems you described. Thoughts @obo20?

[obo20]

@lidel The biggest problem is when the user searches by "all" or doesn't pass in any filters.

Our pinned items and our pinning jobs have are two completely different tables / models in our database. As a result we wouldn't be able to return both in one call unless we completely got rid of any additional filtering / sorting

[lidel]

@obo20 What if we make GET /pins without filter return only pinned items? see #28

[obo20]

Are you saying that users will basically only be able to return 1 status of pins at a time?

[lidel]

@obo20 That's the idea – would that help or make things worse?

Alternative: keep status filter as array, and Pinata would simply return error Bad Request (400) with Error.message explaining unpinned can't be used together with other statuses.

I don't have strong preference here – which way is easier for you?

[obo20]

@lidel I think that (the one status at at time solution) would be doable and probably the most flexible option for all providers to accommodate.

Also for clarification, pinning is the status that we wouldn't be able to combine with other statuses.