owned this note
owned this note
Published
Linked with GitHub
# OCA Repo v2
- Rewrite to Rust, too many deps in Rust
- entities (OCA CB, OCA Bundle, Overlays) versioned and controlled via microledgers
https://github.com/THCLab/microledger
https://github.com/the-human-colossus-foundation/microledger-spec/blob/main/microledger.md
- Currently microledger serialization/deserialization to any representation is missing.
- Consider CESR for ML serialization
- search engine (Meta overlay, OCA CB attributes, label overlay) along with i18n support
- REST API
- `POST /namespaces body: { namespace.cesr }` Creates manageable namespace (JSON with CESR-based attachments of list of identifiers controlling the namespace along with signatures of those identifiers)
- `GET /namespaces/{namespace}/bundles/said` gets bundle version for `SAID`
- `GET /namespaces/{namespace}/bundles/change-history?before=said&after=said`
- `POST /namespaces/{namespace}/bundles body: { bundle.cesr }` creates ML instance
- `PUT /namespaces/{namespace}/bundles/SAID body: { bundle.cesr }` updates ML instance of SAID (if owned)
- `GET /namespaces/{namespace}/bundles?limit=&offset=`
- `GET /bundles/search?query=bleble&namespace=`
### Entities versioning
```
OCA Bundle
Overlay
Capture base
OCA Bundle <-> Capture Base + Overlays
(dig1, [len, capture base digest1, len, digest overlay 1, len, digest overlay 2])
(dig2, [len, capture base digest1, len, digest overlay 1, len, digest overlay 2])
(dig4, [len, capture base digest2, len, digest overlay 1, len, digest overlay 2])
OCA-KLI
OCAFILE stuff
(dig cb1, [len(op), op])
(dig cb2, [len(capture base digest1), capture base digest1, len(op), op])
```
- via https://en.wikipedia.org/wiki/Adjacency_list
- two ways storage (up and down) seen on the left and right on the diagram below

# Keys vault
An online, WEB-based service that keeps identifiers along with encrypted private keys for further operations.
## Assumptions:
- Anyone might have as many identifiers as desired.
- Identifiers are transferable (in KERI nomenclature)
- Identifiers are spawned in a multisig fashion, where the threshold is (1/2, 1/2). Identifiers must meet the threshold for recovery mechanism.
- First `1/2` of the treshold holds the ownership of `something you know`. In other words
ug
- REST API
- `POST /identifers/spawn`
creates a nontransferable Identifer and returns it to the requestor via an `ACDC`. Such ACDC is a proof-of-ownership of given Identifier
- `POST /identifers/sign body: { proof-of-ownership: ACDC, payload-to-be-signed: ... }`
- Each Keys Vault instance has his own nontransferable Identifier
- To sign a payload, Keys Vault gets only a digest of the payload and signs the digest. Thinking of SAD's, assuming such a SAD: `{ "ble": "blee", "bla": "efrg", "said": ... }`, it is enough to deliver to Keys Vault only the digest (`said`) to sign the whole payload.