Running the Example

The following is a guide on how to run the Rebase front-end demo. A hosted example can be found here.
rebase/demo/witness at main · spruceid/rebase
GitHub
Running the Example Dapp
rebase/demo/dapp at main · spruceid/rebase
GitHub
This is a thin client for usage with the witness service found in rebase/demo/dapp. 

After cloning, but before running, it will need to be configured via the .env file (located at rebase/demo/dapp/.env).
To use WalletConnect in the front end, an INFURA_ID will need to be set in the .env file at the root of dapp , but this is optional. 
WITNESS_URL MUST be set in the .env as is expected to be the host of the worker. If using the instructions in the next section and running the worker locally, then it would be "http://localhost:8787"
If you want to use an existing Witness rather than running your own, WITNESS_URL="https://rebasedemo.spruceid.workers.dev"
will work.

To run the Dapp locally: 
cd rebase/demo/dapp
npm i
npm run dev
Then the UI should be running on localhost:3000 and simple to operate. Signers can be connected through the header and claims can be created by visiting the available option at the top of the main page.
The witness flow UIs should have easy to instructions for a user. 

Next is a guide to running the Cloudflare Worker which acts as a witness for Rebase claims. This could also be deployed as a traditional web server, but a stateless worker is sufficient for all existing flows.
Running the Witness
Requires 
A Cloudflare account
​Wrangler​
API keys for any relevant resources
You need a Cloudflare account, a pubicly hosted did:web instances, and the Account ID needs to go in wrangler.toml.
The worker needs several secrets set using the wrangler secret putcommand -- the details of which are outlined in this repository's secrets.md found here. 

The worker also needs a publicly hosted did:web key. How to create and expose one of those is described here.

If you don't want to set up this infrastructure, you can point the dapp from the last step to https://rebasedemo.spruceid.workers.dev
All secrets must be set, but any that are unneeded can be set to an empty string ("") and will then be overlooked. The secrets that must be set (even if empty) are:
REBASE_SK, the private key used to sign the VCs, exact format described below.
DID_WEB the did:web identifier following the format of did:web:<URL_HOST_OF_REBASE_PUBLIC_KEY>. This corresponds directly to REBASE_SK being the public key DID document that pairs with the secret JWK.
GITHUB_USER_AGENT (Required to enable GitHub flow) is the user agent that will be sent to GitHub when querying its public API.
SENDGRID_BEARER_TOKEN secret is an API token for use with the SendGrid API, generated by using the SendGrid API Dashboard.
SENDGRID_FROM_ADDRESS secret is the email address from which the challenge will be sent, it should correspond to a controlled address/domain under the SendGrid account which generated the SENDGRID_BEARER_TOKEN.
SENDGRID_FROM_NAME secret is the name that will appear as the owner of the SENDGRID_FROM_ADDRESS in the UI of email clients.
The SENDGRID_SUBJECT_NAME is the name of the service as displayed in the subject of the challenge email. This subject is generated as format!("Verifying ownership of {} {} for {}, subject_type, subject_id, SENDGRID_SUBJECT_NAME)`.
SOUNDCLOUD_CLIENT_ID (Required to enable SoundCloud flow) is the ID used to interact with SoundCloud v2 API. Discovery of the Client ID is described in secrets.md.
SOUNDCLOUD_LIMIT (Required to enable SoundCloud flow) must be an integer between 0 and 201 exclusive (1 through 200 inclusive). Suggested to be set to 100.
SOUNDCLOUD_MAX_OFFSET (Required to enable SoundCloud flow) is the number of search results to try before giving up (the total tested will be SOUNDCLOUD_MAX_OFFSET + SOUNDCLOUD_LIMIT, since it starts at 0). SOUNDCLOUD_MAX_OFFSET + SOUNDCLOUD_LIMIT must be less than or equal to 10k. Suggested to be set to 900.
TWITTER_BEARER_TOKEN (Required to enable the Twitter workflow) is the bearer token from Twitter to the application developer using the Twitter API.
The private key is expected to be a JWK. You can generate one with didkit generate-ed25519-key.
​
This key is also expected to have a corresponding did:web and be hosted at the appropriate URL. How to construct this is outlined here.
To deploy the worker to a live instance, one can run:
$ wrangler publish
However, for development, you will often want to use: 
$ wrangler dev
This will launch the worker to listen on localhost:8787.
Regardless of where it's deployed, the worker responds to three routes /instructions, /statement and /witness, each expect a POST. The routes respectively expect the POST body to conform to:
#[derive(Deserialize, Serialize)]
pub struct InstructionReq {
    #[serde(rename = "type")]
    pub instruction_type: InstructionTypes,
}
​
#[derive(Deserialize, Serialize)]
pub struct StatementReq {
    pub opts: StatementTypes,
}
​
#[derive(Deserialize, Serialize)]
pub struct WitnessReq {
    pub proof: ProofTypes,
}
Details on InstructionTypes, StatementTypes and ProofTypes can be found in the Witness SDK README and the Witness Endpoints Document.
Last modified 5mo ago