Initial PR for SIP1 #863

csuwildcat · 2020-09-16T22:03:19Z

No description provided.

docs/spec/did-uri.md

docs/spec/processing.md

docs/spec/resolution.md

package.json

OR13

Concrete examples should be provided or new issues should be opened to track that they should be provided at some future date.

Compression and its relation to HASH_ALGORITHM should be documented... I am in favor of explicitly stating the compression algorithm, and always saying when it is used.

Alternatively a subroutine can be defined which normatively describes the process of getAddress... namely:

const getAddress = (buffer: Buffer)=> {
  const compressed = COMPRESSION_ALGORITHM ( buffer )
  const cid = HASH_ALGORITHM ( compressed )
  return cid;
}

Since IPFS internally supports this and other "utilities", test vectors for the IPFS defaults should be provided, I opened #861

You may choose not to define compression in this PR, but the CID system is currently not actually defined.

You may consider just using multiformats more directly... eliminate the "optionality" and rely on IPFS and Multiformats normatively for all CIDs for the CAS.

Co-authored-by: Orie Steele <orie@transmute.industries>

…tree into SIP1

troyronda · 2020-09-29T19:48:01Z

docs/spec/did-uri.md

-DID URI strings may include additional values that are used in resolution and other activities. The standard way to pass these values are through _DID URL Parameters_, as defined by the [W3C Decentralized Identifiers](https://w3c.github.io/did-core/) specification.
-
-Many DID Methods require a period of time (which may be indefinite) between the generation of a DID and the DID being anchored/propagated in the underlying ledger system, and other layers for which propagation delays may apply. Sidetree introduces the `initial-state` _DID URL Parameter_ to enable resolution of unpropagated and unpublished DIDs. To use a Sidetree-based DID immediately after generation, the controller ****MUST**** include the `initial-state` _DID URL Parameter_ in the DID URI string, with the value being a string composed of the [_Create Operation Suffix Data Object_](#create-suffix-data-object) and the [_Create Operation Delta Object_](#create-delta-object), separated by a period (`.`), as follows:
+In many DID Methods, there is a period of time (which may be indefinite) between the generation of a DID and the DID operation being anchored, propagagted, and processed in the underlying distributed ledger/storage network. In order to account for this, Sidetree introduces an equivalent variant of Sidetree-based DIDs that is _self-certifying_ and _self-resolving_, known as the [_Long-Form DID URI_](#long-form-did){id="long-form-did"}. The [_Long-Form DID URI_](#long-form-did) variant of Sidetree-based DIDs enables DIDs to be immediately resolvable after generation by including the DID's initial state data within the [_Long-Form DID URI_](#long-form-did) itself. A [_Long-Form DID URI_](#long-form-did){id="long-form-did"} is the [_Short-Form DID URI_](#short-form-did) with an additional colon-separated (`:`) segment appended to the end, the value of which is composed of the [_Create Operation Suffix Data Object_](#create-suffix-data-object) and the [_Create Operation Delta Object_](#create-delta-object) separated by a period (`.`), as follows:


s/propagagted/propagated

I love how long these lines are, and how unnecessarily hard it is to work on this spec, thanks for using spec-up.

Long lines are orthogonal to the tooling, and we can change that in a number of ways.

troyronda · 2020-09-29T20:00:52Z

docs/spec/file-structures.md

+
+### Core Proof File
+
+Core Proof Files are [compressed](#compression-algorithm) JSON Documents containing the cryptographic proofs (signatures, hashes, etc.) that form the signature-chained backbone for the state lineages of all DIDs in the system. The cryptocraphic proofs present in Core Proof Files also link a given operation to its verbose state data, which resides in an related [Chunk File](#chunk-files).


s/cryptocraphic/cryptographic

troyronda · 2020-09-29T20:02:39Z

docs/spec/file-structures.md

+
+### Provisional Proof File
+
+Provisional Proof Files are [compressed](#compression-algorithm) JSON Documents containing the cryptographic proofs (signatures, hashes, etc.) for all the (eventually) prunable DID operations in the system. The cryptocraphic proofs present in Provisional Proof Files also link a given operation to its verbose state data, which resides in an related [Chunk File](#chunk-files).


s/cryptocraphic/cryptographic

… processing kills

csuwildcat · 2020-10-14T19:26:50Z

@OR13 I do not understand your comments about the hashing algorithm, but can we please just address it in a subsequent commit related specifically to that, because I really need to get this one in, before all the string changes are added.

OR13 · 2020-10-14T19:29:13Z

@OR13 I do not understand your comments about the hashing algorithm, but can we please just address it in a subsequent commit related specifically to that, because I really need to get this one in, before all the string changes are added.

open an issue related to the concern you don't understand, link it to the PR and I will approve.

troyronda · 2020-10-14T19:47:22Z

docs/spec/processing.md

@@ -45,20 +45,21 @@ Regardless of the ledger system an implementer chooses, the implementer ****MUST

 ### Anchor File Processing

-The follow sequence of rules and processing steps must be followed to correctly process an [Anchor File](#anchor-file):
+The follow sequence of rules and processing steps ****must**** be followed to correctly process an [Anchor File](#anchor-file):


troyronda · 2020-10-14T19:53:10Z

docs/spec/did-uri.md

+Format of Short-form DID URI:
+
+```html
+did:METHOD:<did-suffix>


Of course, METHOD may also create hierarchy (e.g., reference a network or testnet) as part of the DID string.

Some examples: https://identity.foundation/sidetree/spec/#method-versioning

troyronda · 2020-10-14T19:54:16Z

docs/spec/did-uri.md

-DID URI strings may include additional values that are used in resolution and other activities. The standard way to pass these values are through _DID URL Parameters_, as defined by the [W3C Decentralized Identifiers](https://w3c.github.io/did-core/) specification.
+In many DID Methods, there is a period of time (which may be indefinite) 
+between the generation of a DID and the DID operation being anchored, 
+propagagted, and processed in the underlying distributed ledger/storage 


s/propagagted/propagated

troyronda · 2020-10-14T19:54:34Z

docs/spec/did-uri.md

+[_Create Operation Suffix_](#create-suffix-data-object) data and the 
+[_Create Operation Delta_](#create-delta-object) data, encoded 
+via the implementation's [`DATA_ENCODING_SCHEME`](#data-encoding-scheme). 
+The [_Long-Form DID URI_](#long-form-did) data payload segment ****must not**** 


troyronda · 2020-10-14T20:00:34Z

docs/spec/processing.md

@@ -70,35 +71,54 @@ Confirm how we handle ops where there was not a previous op found.

 ### Map File Processing

-The follow sequence of rules and processing steps must be followed to correctly process a Map File:
+The follow sequence of rules and processing steps ****must**** be followed to correctly process a Map File:


The follow => The following
MUST

troyronda · 2020-10-14T20:01:44Z

docs/spec/processing.md

+
+### Core Proof File Processing
+
+The follow sequence of rules and processing steps ****must**** be followed to correctly process an [Core Proof File](#core-proof-file):


The follow => The following
MUST

troyronda · 2020-10-14T20:03:00Z

docs/spec/processing.md

+
+### Provisional Proof File Processing
+
+The follow sequence of rules and processing steps ****must**** be followed to correctly process an [Provisional Proof File](#provisional-proof-file):


The follow => The following
MUST

troyronda · 2020-10-14T20:03:34Z

docs/spec/processing.md


 ### Chunk File Processing

-The follow sequence of rules and processing steps must be followed to correctly process a Chunk File chunk:
+The follow sequence of rules and processing steps ****must**** be followed to correctly process a Chunk File chunk:


The follow => The following
MUST

troyronda · 2020-10-14T20:13:04Z

docs/spec/resolution.md

@@ -84,7 +84,7 @@
                1. Set the _Next Update Commitment_ value to `null`.
                2. Exit [update operation processing](#update-operation-processing) and advance to [compiled state processing](#compiled-state-processing).


Note: we still have an open issue on update processing errors. #834

troyronda · 2020-10-14T20:46:45Z

LGTM as an initial PR (can iterate on top).

csuwildcat · 2020-10-15T02:27:28Z

Separated compression clarifications into this issue: #888

csuwildcat · 2020-10-17T13:11:29Z

@OR13 I separated the one issue about selection and specification of the exact compression process, so can you please approve this now?

csuwildcat added 2 commits September 16, 2020 14:57

Initial PR for SIP1

38063d8

Merge branch 'master' into SIP1

ff843d3