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

fix: disambiguating *.providers fields #50

Merged
merged 2 commits into from
Aug 14, 2020
Merged

fix: disambiguating *.providers fields #50

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
9f11f2a
fix: disambiguating *.providers fields
lidel Aug 13, 2020
b804e4d
Merge branch 'master' into disambiguating-providers
lidel Aug 14, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 12 additions & 12 deletions ipfs-pinning-service.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -33,7 +33,7 @@ A full list of fields and schemas can be found in the `schemas` section of the [
The `Pin` object is a representation of a pin request.


It includes the `cid` of data to be pinned, as well as optional metadata in `providers` and `meta`.
It includes the `cid` of data to be pinned, as well as optional metadata in `origins` and `meta`.


### Pin status object
Expand Down Expand Up @@ -80,13 +80,13 @@ A pin object can be removed via `DELETE /pins/{cid-of-pin-object}`.
## Provider hints

Pinning of new data can be accelerated by providing a list of known data
sources in `Pin.providers`, and connecting at least one of them to pinning
service nodes at `PinStatus.providers`.
sources in `Pin.origins`, and connecting at least one of them to pinning
service nodes at `PinStatus.delegates`.


The most common scenario is a client putting its own IPFS node's multiaddrs in
`Pin.providers`, and then directly connecting to every multiaddr returned by
a pinning service in `PinStatus.providers` to initiate transfer.
`Pin.origins`, and then directly connecting to every multiaddr returned by
a pinning service in `PinStatus.delegates` to initiate transfer.


This ensures data transfer starts immediately (without waiting for provider
Expand Down Expand Up @@ -297,7 +297,7 @@ components:
- status
- created
- pin
- providers
- delegates
properties:
id:
description: CID of pin object; can be used to check status of ongoing pinning
Expand All @@ -312,8 +312,8 @@ components:
example: "2020-07-27T17:32:28Z"
pin:
$ref: '#/components/schemas/Pin'
providers:
$ref: '#/components/schemas/ServiceProviders'
delegates:
$ref: '#/components/schemas/Delegates'
meta:
$ref: '#/components/schemas/StatusMeta'

Expand All @@ -327,8 +327,8 @@ components:
description: CID to be pinned recursively
type: string
example: "QmCIDToBePinned"
providers:
$ref: '#/components/schemas/DataProviders'
origins:
$ref: '#/components/schemas/Origins'
meta:
$ref: '#/components/schemas/PinMeta'

Expand All @@ -341,7 +341,7 @@ components:
- pinned # pinned successfully
- failed # pinning service was unable to finish pinning operation; additional info can be found in meta[status_details]

ServiceProviders:
Delegates:
description: List of multiaddrs designated by pinning service for transferring any new data from external peers
type: array
items:
Expand All @@ -351,7 +351,7 @@ components:
maxItems: 20
example: ['/dnsaddr/pin-service.example.com']

DataProviders:
Origins:
description: Optional list of multiaddrs known to provide the data
type: array
items:
Expand Down