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.

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

docs: clarify use of provider hints #72

Merged
merged 14 commits into from
Feb 10, 2021
1 change: 1 addition & 0 deletions .gitignore
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
super-linter.log
25 changes: 17 additions & 8 deletions ipfs-pinning-service.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -106,19 +106,28 @@ A pin object can be removed via `DELETE /pins/{requestid}`.

## Provider hints

Pinning of new data can be accelerated by providing a list of known data
sources in `Pin.origins`, and connecting at least one of them to pinning
service nodes at `PinStatus.delegates`.
Pinning service will use DHT and other discovery methods to locate pinned
lidel marked this conversation as resolved.
Show resolved Hide resolved
content, however it is a good practice to provide additional provider hints to
lidel marked this conversation as resolved.
Show resolved Hide resolved
speedup the discovery phase and start the transfer immediately, especially if a
lidel marked this conversation as resolved.
Show resolved Hide resolved
client has the data in own datastore, or knows of other providers already.
lidel marked this conversation as resolved.
Show resolved Hide resolved


The most common scenario is a client putting its own IPFS node's multiaddrs in
`Pin.origins`, and then directly connecting to every multiaddr returned by
a pinning service in `PinStatus.delegates` to initiate transfer.
`Pin.origins`, and then attempt to connect to every multiaddr returned by a
pinning service in `PinStatus.delegates` to initiate transfer. At the same
time, pinning service will try to connect to multiaddrs provided by the client
lidel marked this conversation as resolved.
Show resolved Hide resolved
in `Pin.origins`.
lidel marked this conversation as resolved.
Show resolved Hide resolved


This ensures data transfer starts immediately (without waiting for provider
discovery over DHT), and direct dial from a client works around peer routing
issues in restrictive network topologies such as NATs.
issues in restrictive network topologies such as NATs, firewalls etc.
lidel marked this conversation as resolved.
Show resolved Hide resolved


**NOTE:** connections to multiaddrs in `origins` and `delegates` arrays should
lidel marked this conversation as resolved.
Show resolved Hide resolved
be attempted in best-effort fashion, and dial failure should not fail the
pinning operation. When unable to act on explicit provider hints, DHT and
lidel marked this conversation as resolved.
Show resolved Hide resolved
other discovery methods should be used as a fallback by pinning service.
lidel marked this conversation as resolved.
Show resolved Hide resolved


## Custom metadata
Expand Down Expand Up @@ -430,7 +439,7 @@ components:
uniqueItems: true
minItems: 1
maxItems: 20
example: ['/dnsaddr/pin-service.example.com']
example: ['/ip4/203.0.113.1/tcp/4001/p2p/QmServicePeerId']

Origins:
description: Optional list of multiaddrs known to provide the data
Expand All @@ -440,7 +449,7 @@ components:
uniqueItems: true
minItems: 0
maxItems: 20
example: ['/p2p/QmSourcePeerId']
example: ['/ip4/192.0.2.42/tcp/4001/p2p/QmSourcePeerId', '/ip4/198.51.100.14/udp/4001/quic/p2p/QmSourcePeerId']

PinMeta:
description: Optional metadata for pin object
Expand Down