valist-io / valist Goto Github PK

We should use this library to normalize the package.json content.

https://www.npmjs.com/package/read-package-json

Restrict changing project type to if releases.length == 0

Otherwise leave available in the contract for manual change if absolutely necessary

Valist needs a mechanism for building and pinning multiple architecture's artifacts?

Ideally various build artifacts would be pinned with corresponding metadata to a folder and users would then vote on the folder CID versus an individual release CID.

"awesome" repo for projects hosted on Valist

• Ability to vote on keys (ADD, REMOVE)
• Ability to self-rotate key

'$ valist org:key exampleOrg grant <key>',
'$ valist org:key exampleOrg revoke <key>',
'$ valist org:key exampleOrg rotate <key>',

Need to support EIP712 sigs for Go SDK so that the Go CLI can use metatxns!

• Port logic from https://github.com/valist-io/reproducible into Golang

See example below.

$ npm install -g --registry=https://app.valist.io/api/npm @valist/cli
$ valist
$ zsh: command not found: valist

This should detect if you are a repoAdmin, and if you are, show the text "Manage Access" instead of "View All"

Should be able to directly use keystore files or choose to import them into the keychain/secure storage

Should follow standards set by widely used node/wallet software:

https://github.com/ethereum/wiki/wiki/Web3-Secret-Storage-Definition

Depends on #98 and #99

• Consume valist.yml
• Run Reproducible to build the artifact into out

valist build should run all build steps minus the publish steps

CLI / SDK should support lerna monorepos https://github.com/lerna/lerna

• Ability to consume valist.yml

Examples:

type: node
org: test
repo: node
tag: 0.0.1-rc.3
install: npm install
build: npm run build

type: go
org: test
repo: go
tag: 0.0.2
meta: README.md
build: make all
out: dist or dist/

type: go
org: test
repo: go
tag: 0.0.2
meta: README.md
build: make all
out: dist
artifacts:
    linux/amd64: bin/lin000x/hello-world
    darwin/amd64: bin/macz/hello-world

• setup local chain
• pull down example projects repo
• simulate build/publish

• Ability to generate a keystore
• Ability to use said key as a signer
• Ability to nickname each key
• Multiple accounts

valist account:new

# outputs: Successfully created new account: 0x12344321 as NICKNAME

valist account:import PATH_TO_KEYSTORE NICKNAME

# outputs: Successfully imported account: 0x12344321

valist account:export PATH_TO_KEYSTORE NICKNAME

# outputs: Successfully exported account: 0x12344321

valist account:list

# nickname: 0x12344321
# nickname2: 0x987656789

valist account:default 0x12344321 or valist account:default NICKNAME

valist publish             (defaults to accounts[0])

valist publish --account=nickname or valist publish --account=0x1234321

Error handling should be handled anywhere in the relay that error messages could pop up

• Ability to create a repo
• Ability to update repo metadata
• Ability to fetch repo metadata

We need a go program to automatically pull all NPM packages hosted on npmjs.com into an IPFS node

The CLI should be able to import and export user account keys.

We also need to figure out a strategy for Magic accounts.

• Ability to create organization
• Ability to update org metadata
• Ability to fetch org metadata

When running a valist publish outside of the valist docker instance there is not currently a streamlined way to ensure that the local build environment is reproducible.

To enable reproducible environments on local machines valist publish will invoke the docker api to build the users included dockerfile/build script from their local project, then execute the build of the image and copy the built artifact from the running container to the host machine.

To perform these actions we have created the reproducible library by leveraging the docker api for node package Follow the status of the reproducible library at: Valist Reproducible GitHub:

An example call to reproducible looks something like this:

  await reproducible.runBuild({
      image: 'build-test',
      outputPath: `${process.cwd()}/tests/dist`,
      artifacts: ['main'],
   });

Should be able to run something like:

valist org:threshold exampleOrg 3

or

valist repo:threshold exampleOrg exampleRepo 3

Hardhat ABIs make go cry when importing directly, need to convert a bit to get go to play nicely with hardhat artifacts

The valist.yml file currently allows for custom docker images by specifying the image property.

This should also support the ability to pass in a custom Dockerfile that's within the same repo. It's also currently possible to not specify the build and install properties in the yml, which combined with this, would allow for a completely custom build process.

Our Valist contract should only manage orgIDs rather than mapping orgIDs to global namespaces.

A separate ValistRegistry contract should handle the governance of linking orgIDs to names. This would allow individuals/organizations/DAOs to deploy custom mappings that the relay can use as the source of truth.

This creates a federated model that also enables multi-chain compatibility.

When Valist launches a DAO in the future, it will become the new default source of truth for the relay. In the meantime, the default will be governed by Valist, while still enabling orgs/individuals to deploy their own.

CLI should be able to run all of the same functions as the relay website.

Add to example projects
Add to documentation pages

If dev does not have a keypair yet, and they try to create an org from the CLI, generate a new key automatically and display to the user

When running valist keygen and the developer already has a key, warn and prompt the user if they want to overwrite the key

• Ability to vote on keys (ADD, REMOVE)
• Ability to self-rotate key

'$ valist repo:key exampleOrg exampleRepo grant <key>',
'$ valist repo:key exampleOrg exampleRepo revoke <key>',
'$ valist repo:key exampleOrg exampleRepo rotate <key>',

• updating Access Control Pages
• showing list of pending votes

When using the --registry flag on an npm install, and installing a dependency that is only available on Valist and not on npmjs.com, subdependencies are not resolved.

Steps to reproduce:

npm init -yy
npm install --registry=https://app.valist.io/api/npm @valist/sdk

This creates a package-lock.json file with the following contents:

{
  "name": "testing",
  "version": "1.0.0",
  "lockfileVersion": 2,
  "requires": true,
  "packages": {
    "": {
      "version": "1.0.0",
      "license": "ISC",
      "dependencies": {
        "@valist/sdk": "npm:sdk@^0.3.4"
      }
    },
    "node_modules/@valist/sdk": {
      "name": "sdk",
      "version": "0.3.4",
      "resolved": "https://gateway.valist.io/ipfs/bafkreihuomgtyukg5rdrpgpqzwinubh3d7i2c4bygxb5ecgst5b4jidrde"
    }
  },
  "dependencies": {
    "@valist/sdk": {
      "version": "npm:[email protected]",
      "resolved": "https://gateway.valist.io/ipfs/bafkreihuomgtyukg5rdrpgpqzwinubh3d7i2c4bygxb5ecgst5b4jidrde"
    }
  }
}

In the last block, the @valist/sdk object should actually contain the full list of dependencies that were listed in the package.json within @valist/sdk, like so:

"dependencies": {
    "@biconomy/mexa": "^1.5.15",
    "@typescript-eslint/eslint-plugin": "^4.25.0",
    "encoding": "^0.1.13",
    "eslint": "^7.27.0",
    "eslint-config-airbnb-typescript": "^12.3.1",
    "eslint-plugin-import": "^2.23.3",
    "eth-sig-util": "^3.0.1",
    "ipfs-http-client": "47.0.1",
    "node-fetch": "^2.6.1",
    "web3": "^1.3.6",
    "web3-core": "^1.3.6"
  }

This is very likely due to the fact that we return an empty object for dependencies in our npm registry api, at this line: https://github.com/valist-io/valist/blob/master/relay/pages/api/npm/%5B...releaseName%5D.ts#L48

In previous versions of NPM, we could get away with a second npm install without the registry flag, which would force the dependency resolution. However, this is no longer the case with 7+, and was never a good flow anyway so we'll need to fix this.