From 9f11f2ab754c0b140cfd4171a6a9bf9142fc0f08 Mon Sep 17 00:00:00 2001
From: Marcin Rataj <lidel@lidel.org>
Date: Thu, 13 Aug 2020 15:43:12 +0200
Subject: [PATCH] fix: disambiguating *.providers fields

Closes #41
---
 ipfs-pinning-service.yaml | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/ipfs-pinning-service.yaml b/ipfs-pinning-service.yaml
index 27634f4..89ba724 100644
--- a/ipfs-pinning-service.yaml
+++ b/ipfs-pinning-service.yaml
@@ -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
@@ -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
@@ -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
@@ -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'
 
@@ -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'
 
@@ -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:
@@ -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: