Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Support the Pinning Services API #1213

Closed
hsanjuan opened this issue Aug 19, 2020 · 3 comments
Closed

Support the Pinning Services API #1213

hsanjuan opened this issue Aug 19, 2020 · 3 comments
Assignees
@hsanjuan
Labels
effort/days Estimated to take multiple days, but less than a week exp/wizard Extensive knowledge (implications, ramifications) required kind/enhancement A net-new feature or improvement to an existing feature P1 High: Likely tackled by core team if no one steps up status/in-progress In progress
Milestone
Release v1.0.0

Comments

@hsanjuan
Copy link
Collaborator

Describe the feature you are proposing

A unified API for pinning services has been proposed:

https://github.com/ipfs/pinning-services-api-spec

IPFS Cluster can support this by adding a new API module. It seems most functionality in the spec can be supported fairly easily. This is mostly a subset of the REST API with JWT token authentication and some additional transformations on the data (specific pin objects).
@hsanjuan hsanjuan added kind/enhancement A net-new feature or improvement to an existing feature exp/wizard Extensive knowledge (implications, ramifications) required P1 High: Likely tackled by core team if no one steps up effort/days Estimated to take multiple days, but less than a week labels Aug 19, 2020
@lidel
Copy link
Contributor

lidel commented Apr 15, 2021 •
edited
Loading

It would be fantastic if people could spawn own ipfs-cluster and use it as self-hosted pinning service:

Single-user MVP for private deployments (cloud, LAN) does not even need to have auth-token validation implemented.

@lidel lidel mentioned this issue May 11, 2021
Open
@lidel
Copy link
Contributor

lidel commented May 11, 2021 •
edited
Loading

@hsanjuan given that cluster already has /pins endpoint with bit different semantics, and we may to add "DAG import" endpoint to the spec that would most likely work bit differently than /add, would it make sense to add all this "pinning service business" under /service/pins|imports to make them coexist while having a very clear service part? Or would a separate HTTP port with pinning service endpoints easier to implement (given that we want to guard that with Authorization: Bearer <access-token>)?

@hsanjuan
Copy link
Collaborator Author

This would go as a separate module, on a separate listener as a fully separate API that can be enabled/disabled as needed, like the existing one and the ipfs-proxy one.

@lidel lidel mentioned this issue Jun 15, 2021
Merged
@alanshaw alanshaw mentioned this issue Jun 29, 2021
Closed
@hsanjuan hsanjuan added the status/in-progress In progress label Sep 13, 2021
@hsanjuan hsanjuan added this to the Release v0.14.2 milestone Sep 13, 2021
hsanjuan added a commit that referenced this issue Oct 7, 2021
@hsanjuan
api: Add the Pinning Services API module
c1062ef 
This fixes #1213. It adds partial support for the Pinning Services API with some caveats:

* RequestIDs == CIDs. This is a violation of the spec, as request IDs will not be unique etc.
* Pagination, name matching, metadata matching, ordering etc. are not supported in the List endpoint.
* The List endpoint only supports status filtering and cid query parameter.
* Created time property is not supported and always set to Now()

There is more work to do here: cleanup, extract useful types etc. and TESTS.
hsanjuan added a commit that referenced this issue Oct 19, 2021
@hsanjuan
api: Add the Pinning Services API module
efd63c9 
This fixes #1213. It adds partial support for the Pinning Services API with some caveats:

* RequestIDs == CIDs. This is a violation of the spec, as request IDs will not be unique etc.
* Pagination, name matching, metadata matching, ordering etc. are not supported in the List endpoint.
* The List endpoint only supports status filtering and cid query parameter.
* Created time property is not supported and always set to Now()

There is more work to do here: cleanup, extract useful types etc. and TESTS.
hsanjuan added a commit that referenced this issue Oct 20, 2021
@hsanjuan
api: Add the Pinning Services API module
4cbc197 
This fixes #1213. It adds partial support for the Pinning Services API with some caveats:

* RequestIDs == CIDs. This is a violation of the spec, as request IDs will not be unique etc.
* Pagination, name matching, metadata matching, ordering etc. are not supported in the List endpoint.
* The List endpoint only supports status filtering and cid query parameter.
* Created time property is not supported and always set to Now()

There is more work to do here: cleanup, extract useful types etc. and TESTS.
@lidel lidel moved this to Todo in @lidel's IPFS wishlist Nov 10, 2021
@lidel lidel mentioned this issue Feb 2, 2022
Merged
Repository owner moved this from Todo to Done in @lidel's IPFS wishlist Mar 14, 2022
This was referenced Mar 22, 2022
Open
Open
@lidel lidel mentioned this issue Mar 30, 2022
Closed
@lidel lidel mentioned this issue May 23, 2022
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@hsanjuan hsanjuan

Labels
effort/days Estimated to take multiple days, but less than a week exp/wizard Extensive knowledge (implications, ramifications) required kind/enhancement A net-new feature or improvement to an existing feature P1 High: Likely tackled by core team if no one steps up status/in-progress In progress
Projects
None yet
Milestone
Release v1.0.0
Development

No branches or pull requests
2 participants
@lidel @hsanjuan