BRI-2 task list

[bitwiseguy]

Overview

This epic lists remaining tasks related to the BRI-2 stack.

Tasks

• [ ] [dashboard] dockerize the dashboard microservice
• [ ] [dashboard] cleanup unused components/files
• [ ] add P2P messenger service (likely NATS)
• [ ] create an API gateway microservice that will support the standard API spec
  • [ ] enforce authentication on all client requests
• [ ] create a system level integration test suite
• [x] create a makefile or npm scripts for quickstart build, run, and test
• [ ] enable multi-tenancy (multiple users share same baseline stack)
• [ ] integrate L2 scaling solution between user and mainnet (which L2?)
• [x] integrate Codefi Orchestrate (at a minimum use key manager service)
• [x] [zkp-mgr] use gnark's Solidity exporter feature
• [x] [zkp-mgr] write general "consistency" circuit
• [x] [zkp-mgr] dockerize the zkp-mgr microservice
• [ ] [zkp-mgr] write the HelloWorld circuit(s)
• [ ] [zkp-mgr] write an automated test suite to check processing of http requests
• [ ] add support for VCs/DIDs in phone book
• [ ] add consensys or bri-2 as a provider of the @baseline-protocol/api package

Questions

• Should workgroups be the top level of data hierarchy? Or workflows could serve this purpose?
• Should the multi-tenant design approach be shared db or separate db per user?

[jack-garvin]

Data hierarchy of WorkGroups vs WorkFlows. WorkGroups are a collection of DIDs associated with a Workflow. A 'WorkFlow first' approach provides more flexibility on the timing and sequence of creating DIDs, WorkFlows, and WorkGroups.

I have been thinking, "ALL DIDs MUST be created first, then ALL DIDs MUST be included in a GPB." But then I started thinking about how the DIDs are actually used in a WorkFlow. For ease of WorkFlow construction, DIDs should be identified while defining the WorkFlow. In the end, all DIDs required for a given WorkFlow will be evaluated for inclusion in the GPB.

Not all DIDs will need to be discoverable in a GPB. A WorkGroup is a collection of 'public' DIDs that are discoverable AND private DIDs that are specific to a single WorkFlow but not publish in the public-facing GPB. ALL DIDs can be registered with the GPB but some DIDs are flagged as private, do-not-publish. This method keeps a 'master' list of DIDs (GPB), WorkFlows, and WorkGroups without creating unnecessary dependencies.

There are two paths to completing a WorkFlow.

One path is WorkGroup centric: Create DID > list in the GPB > assign DIDs to WorkGroup > assign WorkGroups to WorkFlows

• ALL final WorkFlows MUST be created AFTER relevant DIDs are included in the GPB.
• ALL final WorkFlows MUST include AT LEAST one DID.

The other path is WorkFlow centric:

1. Create Global Phone Book (GPB) (no DIDs required) >
2. Create WorkGroup (no WorkFlow required) >
3. Create WorkFlow > (no DID required) >
4. Create/Assign DIDs for the WorkFlow >
5. Create/Assign DIDs to a WorkGroup >
6. Create/Update GPB with relevant DIDs (public & private)

Notes

• ALL DIDs are stored in the GPB.
• Only relevant DIDs are published in the GPB.
• DIDs are created according to the WorkFlow requirements.
• Allows creating WorkFlows and WorkGroups independent of each other.
• ALL WorkFlows MUST be assigned at least one DID.

[ognjenkurtic]

@Kasshern @skosito @Ybittan @biscuitdey This discussion might be relevant for our work on the SRI. Keeping it open so that we can discuss.