diff options
| -rw-r--r-- | proposals/0002-hypercore.md | 9 | ||||
| -rw-r--r-- | proposals/0003-http-pinning-service-api.md | 278 |
2 files changed, 283 insertions, 4 deletions
diff --git a/proposals/0002-hypercore.md b/proposals/0002-hypercore.md index 3b6e4ac..bafcedb 100644 --- a/proposals/0002-hypercore.md +++ b/proposals/0002-hypercore.md @@ -7,7 +7,7 @@ Type: Standard Status: Draft (as of 2018-02-21) -Github PR: (add HTTPS link here after PR is opened) +Github PR: [Draft](https://github.com/datprotocol/DEPs/pull/4) Authors: [Paul Frazee](https://github.com/pfrazee), [Mathias Buus](https://github.com/mafintosh) @@ -62,7 +62,7 @@ A sample flat tree spanning 4 blocks of data looks like this: The even numbered entries represent data blocks (leaf nodes) and odd numbered entries represent parent nodes that have two children. -The depth of an tree node can be calculated by counting the number of trailing 1s a node has in binary notation. +The depth of a tree node can be calculated by counting the number of trailing 1s a node has in binary notation. ``` 5 in binary = 101 (one trailing 1) @@ -321,10 +321,11 @@ IPFS is designed for immutable hash-addressed content, but it provides a mechani # Unresolved questions [unresolved]: #unresolved-questions -- Is there a potential "branch resolution" protocol which could remove the [linear history requirement](#linear-history-requirement) and therefore enable users to share private keys freely between their devices? Explaining the risks of branches to users is difficult. (This is being explored.) +- Is there a potential "branch resolution" protocol which could remove the [linear history requirement](#the-linear-history-requirement) and therefore enable users to share private keys freely between their devices? Explaining the risks of branches to users is difficult. (This is being explored.) # Changelog [changelog]: #changelog -- 2018-02-21: First full draft of DEP-0002 submitted for review.
\ No newline at end of file +- 2018-02-19: First full draft of DEP-0002 submitted for review. +- 2018-02-21: DEP-0002 accepted as "Draft" diff --git a/proposals/0003-http-pinning-service-api.md b/proposals/0003-http-pinning-service-api.md new file mode 100644 index 0000000..93ab01a --- /dev/null +++ b/proposals/0003-http-pinning-service-api.md @@ -0,0 +1,278 @@ + +Title: **DEP-0003: HTTP Pinning Service API** + +Short Name: `0003-http-pinning-service-api` + +Type: Standard + +Status: Draft (as of 2018-04-18) + +Github PR: [Draft](https://github.com/datprotocol/DEPs/pull/19) + +Authors: Paul Frazee + + +# Summary +[summary]: #summary + +An HTTP API for adding and removing Dat data. + + +# Motivation +[motivation]: #motivation + +Users frequently make use of "pinning services" to keep their Dat data online +independently of their personal devices. By specifying a standard API for +accessing pinning services, we can integrate interfaces for these services to +Dat clients (including the Dat CLI and Beaker Browser). For example, in the Dat +CLI, it will be possible to execute commands such as: + +``` +dat publish --name myarchive my-pinning-service.com +``` + + +# Service description (PSA) document +[service-description]: #service-description + +Servers should host the PSA service-description document at `/.well-known/psa`. +It may be fetched using a GET request. This document will fit the following schema: + +```json +{ + "PSA": 1, + "title": "My Pinning Service", + "description": "Keep your Dats online!", + "links": [{ + "rel": "https://archive.org/services/purl/purl/datprotocol/spec/pinning-service-account-api", + "title": "User accounts API", + "href": "/v1/accounts" + }, { + "rel": "https://archive.org/services/purl/purl/datprotocol/spec/pinning-service-dats-api", + "title": "Dat pinning API", + "href": "/v1/dats" + }] +} +``` + +You can read more about the [PSA Service Discovery +Protocol](http://web.archive.org/web/20180418164539/https://github.com/beakerbrowser/beaker/wiki/PSA-Web-Service-Discovery-Protocol). + +The PSA document must provide links to two API resources: the User Accounts +API, and the Dat Pinning API. These resources should be indicated by the +`https://archive.org/services/purl/purl/datprotocol/spec/pinning-service-account-api` +and `https://archive.org/services/purl/purl/datprotocol/spec/pinning-service-dats-api` +rel-types, respectively. (These rel-types will need to be updated +with the final URLs for their specifications.) If either API is absent from +the PSA document, the service will be rejected. + + +# User accounts API +[user-accounts-api]: #user-accounts-api + +The user-accounts API should provide the following resources: + +``` +POST /login Create a new session with an existing account. +POST /logout End a session. +GET /account Get information about the account attached to the current session. +``` + +## POST /login +[user-accounts-api-post-login]: #user-accounts-api-post-login + +Create a new session with an existing account. + +Request body (JSON). All fields required: + +``` +{ + username: String + password: String +} +``` + +Handler should generate a session and return the identifier in the response. +Response body (JSON): + +``` +{ + sessionToken: String +} +``` + +## POST /logout +[user-accounts-api-post-logout]: #user-accounts-api-post-logout + +End a session. + +Request should include [authentication header](#authentication). + +## GET /account +[user-accounts-api-get-account]: #user-accounts-api-get-account + +Get information about the account attached to the current session. + +Request should include [authentication header](#authentication). + +Response body (JSON): + +``` +{ + username: String, the accounts username (required) + email: String, the accounts email (optional) + diskUsage: Number, how much disk space has the user's data taken? (optional) + diskQuota: Number, how much disk space can the user's data take? (optional) + updatedAt: Number, the Unix timestamp of the last time the user account was updated (optional) + createdAt: Number, the Unix timestamp of the last time the user account was updated (optional) +} +``` + +If `diskQuota` is not included or is set to 0, the service is acting as a "registry" and will not host the files. + + +# Dat pinning API +[dat-pinning-api]: #dat-pinning-api + +The dat pinning API should provide the following resources: + +``` +GET / List all Dat data pinned by this account. +POST /add Add a Dat to this account's list of pins. +POST /remove Remove a Dat from this account's list of pins. +GET /item/:key Get information about a Dat in the account's list of pins. +POST /item/:key Update information about a Dat in the account's list of pins. +``` + +## GET / +[dat-pinning-api-get-root]: #dat-pinning-api-get-root + +List all Dat data pinned by this account. + +Request should include [authentication header](#authentication). + +Response body (JSON): + +``` +{ + items: [{ + url: String, dat url + name: String, optional shortname assigned by the user + title: String, optional title extracted from the dat's manifest file + description: String, optional description extracted from the dat's manifest file + additionalUrls: Array of Strings, optional list of URLs the dat can be accessed at + }] +} +``` + +## POST /add +[dat-pinning-api-post-add]: #dat-pinning-api-post-add + +Add a Dat to this account's list of pins. + +Request should include [authentication header](#authentication). +Request body (JSON): + +``` +{ + url: String, required url/key of the dat + name: String, optional shortname for the archive + domains: Array of Strings, optional list of domain-names the dat should be made available at +} +``` + +## POST /remove +[dat-pinning-api-post-remove]: #dat-pinning-api-post-remove + +Remove a Dat from this account's list of pins. + +Request should include [authentication header](#authentication). +Request body (JSON): + +``` +{ + url: String, required url/key of the dat +} +``` + +## GET /item/:key +[dat-pinning-api-get-item]: #dat-pinning-api-get-item + +Get information about a Dat in the account's list of pins. Key must be the +pubkey of the dat. + +Response body (JSON): + +``` +{ + url: String, dat url + name: String, optional shortname assigned by the user + title: String, optional title extracted from the dat's manifest file + description: String, optional description extracted from the dat's manifest file + additionalUrls: Array of Strings, optional list of URLs the dat can be accessed at +} +``` + +## POST /item/:key +[dat-pinning-api-post-item]: #dat-pinning-api-post-item + +Update information about a Dat in the account's list of pins. Key must be the +pubkey of the dat. + +Request body (JSON): + +``` +{ + name: String, optional shortname for the archive + domains: Array of Strings, optional list of domain-names the dat should be made available at +} +``` + + +# Authentication +[authentication]: #authentication + +Clients should use the [User accounts API](#user-accounts-api) to fetch a +session token from the service. This token should be included in the +`Authentication` header using the `Bearer` scheme. + + +# Error responses +[error-responses]: #error-responses + +All error responses should respond with a JSON body which matches the +following schema: + +``` +{ + message: String +} +``` + +The content of `message` will be displayed to the user. It should explain the +error and, if appropriate, give steps for solving the issue. Other fields may +be included in the response. + + +# Rationale and alternatives +[alternatives]: #alternatives + +- The motivations and drawbacks of the PSA Service Document are discussed +[here](http://web.archive.org/web/20180418164539/https://github.com/beakerbrowser/beaker/wiki/PSA-Web-Service-Discovery-Protocol#motivation). +Without a description format, it becomes difficult to handle user +authentication. We would probably need to use the HTTP Basic scheme and remove +any mechanisms for registering new accounts. + + +# Unresolved questions +[unresolved]: #unresolved-questions + +- Does the registration flow need to be included in the spec? + + +# Changelog +[changelog]: #changelog + + - 2018-03-31: First full draft of DEP-0003 submitted for review. + - 2018-04-18: DEP-0003 accepted as "Draft" + |