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

Common protocol parameter format #886

Open
troyronda opened this issue Oct 13, 2020 · 3 comments
Open

Common protocol parameter format #886

troyronda opened this issue Oct 13, 2020 · 3 comments
Labels
Milestone

Comments

@troyronda
Copy link
Collaborator

troyronda commented Oct 13, 2020

Are there any generic Sidetree protocol parameters that should have a common format?

Here are our current trustbloc parameters:

{
  "genesisTime": 0,
  "multihashAlgorithm": 18,
  "maxOperationCount": 10,
  "maxOperationSize": 200000,
  "compressionAlgorithm": "GZIP",
  "maxAnchorFileSize": 1000000,
  "maxMapFileSize": 1000000,
  "maxChunkFileSize": 1000000,
  "patches": [
    "replace",
    "add-public-keys",
    "remove-public-keys",
    "add-services",
    "remove-services",
    "ietf-json-patch"
  ],
  "signatureAlgorithms": [
    "EdDSA",
    "ES256",
    "ES256K"
  ],
  "keyAlgorithms": [
    "Ed25519",
    "P-256",
    "secp256k1"
  ]
}
@csuwildcat
Copy link
Member

Hmm, there are some params like this called out in the spec, so I think this comes down to style guide choices if we want to codify some of them with a JSON-based example. The current style guide I believe we chose indicates we would want to use uppercased and underscored names for const/config params: https://google.github.io/styleguide/jsguide.html#naming-constant-names

@OR13
Copy link
Contributor

OR13 commented Nov 10, 2020

IMO these belong in the "sidetree version" response, exposed via the REST API....

@sandrask
Copy link
Collaborator

@thehenrytsai I may have misunderstood your comment here:

// TODO: Issue #766 - Remove temporary assumption on reveal value being calculated using the same hash algorithm

I will remove hashAlgorithm parameter since it looks like it was never meant to be different hash for commitment double hashing

@decentralgabe decentralgabe added this to the V2 milestone Feb 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants