turbo-src / turbosrc-namespace

Usage

Build namespace service

docker build -t namespace-service:latest .

Pull postgres image.

docker pull postgres:13.7-bullseye

Launch containers.

docker-compose up --build

Run tests

Enter bash or shell session in service container (see docker ps for name).

docker exec -it <service container> bash

Run tests.

./test-server/run-tests.sh

Remove containers when done:

docker-compose down

Functions and their return values if request is successful

createUser

201

getContributorID

a string with the contributor id (ethereum address)

getContributorName

a string with the contributor's name (github login)

getContributorSignature

a string with the contributor's signature (ethereum key)

turbosrc-namespace's Issues

Some of createRepo functionality should be here, not in the vote engine.

When this issue is resolved, they'll appear to be two createRepo endpoints, one in vote engine and the other in namespace. But don't worry about that for now. For me details see Rationale below if needed.

Also the following endpoints:

getRepo

setRepo

setRepo must allow any of the fields of Repo to be modified.

Repo

Create a createRepo endpoint in namespace. This includes a graphql namespace endpoint. You only need it in namespace. No need to create a related endpoint as such in turbosrc-service, for now at least.

It's like createUser, but instead of populating a Contributor asset that maps a contributor_id to name, it populates the following something like this:

const Repo = db.define("repo", {
  repo_name: {
    type: Sequelize.STRING(),
    unique: true,
  },
  repo_id: {
    type: Sequelize.STRING(),
    unique: true,
  },
  contributor_id: {
    type: Sequelize.STRING(),
  }
  repo_signature: {
    type: Sequelize.STRING(),
    unique: true,
  },
  app: {
    type: Sequelize.STRING(),
    defaultValue: "TBD",
  },
  metadata: {
    type: Sequelize.STRING(),
    defaultValue: "TBD",
  },
});

repo_id is the Ethereum public address.

repo_signature is the Ethereum private key. This a bit of a misnomer, but it's okay for now.

We'll be generating ethereum addresses and keys for this also, but you don't need to do that right now.

contributor_id is the contributor that "turbosrc'd" the repo.

repo_uri is the remote location of the repo turbosrc'd against (e.g. <gitHosterDomain>/<userName>/<repoName>)

app will be the endpoint to the turbosrc, namely turbosrc-service. In the future, it could be a resource that points to a contract, or simply the contract address, or something to that effect.

metadata is just metadata. Could be anything. We'll of course limit what and how big the field can be at some point.

Rationale

These are just some background details, not necessary to resolve this issue.

The turbosrc-service should pass repo_id to the engine on createRepo. It's a unique ID. So it must get that as the repo will have a 'readable name' and 'uuid name'. turbosrc-service will get the repo_id from turbosrc-namespace, then use that value to pass to engine to createRepo.

The vote engine createRepo will soon be called initRepo, or something to that effect, to avoid confusion.

Just a caveat for prosterity: users ethereum keys they hold in their wallet's (if they choose and if the functionality is implemented) is not with this is. It's under hood implementation easing transition when users take control of wallets. At the moment, the ethereum keys is no more than an internal 'password' that the user has nothing to do with right now.