## Tech skills

* Rust programming language experience, including:

#### KERI infra

* Crypto skills:
* knowledge of symmetric/asymmetric algorithms;
* knowledge of cryptographic hash functions;
* establishing shared secret key [optional];
* familiarity with `JWM`, `JWE`, `JWS` and other building blocks from `JSON Web` family [optional];
* Rust concurrency programming paradigms (threads and futures);
* "Rust meets REST API experience", ie. with `Rocket` crate;
* Network programming:
* building efficient TCP clients;
* experience with text/binary protocols;
* Familiar with kademlia protocol [optional]

#### KERI

point 1 and 2 from KERI infra +
* FFI layer -- preparing and exposing facades to other programming languages;
* WASM platform -- required/optional, but looking into the future, where WASM will become a light JVM, we might have ready-to-ship for WASM code already built.

#### TDA -- Flutter / fullstack preferred

* Dart programming language experience;
* Flutter framework experience;
* knowledge of BLoC pattern / CLEAN architecture;
* Pixel perfect attitude;
* Experienced with multiplatform basic building blocks creation with native languages (and consuming them from within Flutter):
* Java/Kotlin -- Android
* ObjC/Swift -- iOS
* Experienced with app release process in Apple / Google environment.

## Soft skills

* To be open minded with positive attitude. Our tech world that we are operating in is vast and grasping the crucial concepts is essential for problem solving on a daily basis.
* To be self-organized as we work 100% remotely.

# Scope of work to be done

## KERI infra

Primary goals:
* Aim production ready DHT implementation for KERI identifiers discovery mechanism. Use existing solutions if possible / adapt if necessary;
* Controller network / Validator network. In other words it means that any two parties, no matter whether it is issuer, holder or verifier, are able to employ their set of witnesses or watchers to unambiguously detect whether given KEL may be trusted. Any party may furthermore have at the same time own set of witnesses or watchers as it may be event-giver and event-sourcer at the same time.

Secondary goals:
* –

### Building blocks

#### Discoverability
##### DHT

* Evaluate existing [kademlia](https://crates.io/keywords/kademlia) implementations / pick one;

References:
* Resolver [KERI WP, 7.41, p61](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
* https://docs.google.com/presentation/d/1hknEsGJlP5blETmPOw91FZyaOPwer6wnmnIWMlVUHKc/edit#slide=id.p
* https://docs.google.com/document/d/1URYyPf5BaMEmTSEtdQiNrxjDUPz3qLUiOhW-w67sDM4/edit

##### Percolation graph theory

Its a new concept for discovery that supplants or obviates the need for a DHT. Percolation graph theory (see Wikipedia) measures the degree and rate of information flow through a network modeled as a graph. You can model weakly and strongly connected graphs and spanning graphs. Invasive Percolation Graph Theory can model attacks on the graph where bogus (invalid duplicitous non-verifiable etc) information supplants or is supplanted by valid (consistent non-duplicitous, verifible) information. In VC exchange issuance and then later presentation. The provider of information already must have at its disposal all information needed for the receiver to verify what is being provided. This means that all the information may be percolated, it does not need a global lookup. For example Issuer to Holder. Issuer must already have all the information to issue and can give it to the holder so that now the holder has all the information it needs to verify the issuance. Holder to verifier now the holder has given all the information a verifier needs to verify the presentation. That information may include references to verifiable data registries (service endpoints) as wells as KELs or TELs. With SAIDs this makes percolated discovery easier because each node may reference a highly available service endpoint of its choosing to store and forward all information that has been percolated to it in a de-duplicated sense. As a result discovery may be percolated through the network.

^ AFAIK this helps as an extension to DHT, not as a replacement? Isn't it how the torrent network operates?
Also important: the more granular or the more distributed information is, the more complex the overall architecture becomes. This PT assumes, as far as I understand, that parties get intormation when they're in a direct contact. It means that a lot may happen with the information itself as it passes through the parties, similar to Chinese whispers game.

#### Controller network

* Query mode;
* Ability to efficiently access seals anchored in IXN events. Currently it is only possible via brute force mode, so iterating all the events in KEL;
* Ability to bootstrap from a certain state. Currently each KERIOX restart requires parsing all the KEL's from scratch, which in a system with thousands of thousands of KEL's must go wrong;
* Keri’s agreement algorithm for consensus control establishment (`KA^{2}CE`)

- [ ] Alternative impl on Kafka for KERI infra -- to be considered/discussed:
>Both Apache Kafka and Flink provide libraries for building scalable event processing
streams for data intensive applications. The features and semantics may differ somewhat.
Nonetheless, the KERI core stater verification engine can be implemented as either a Kafka
streams application or a Flink ProcessFunction. This allows implementation of KERI witnesses
and validators as Kafka or Flink streams. The witness receipt validation function of a KERI
Judge may also be implemented as a Kafka or Flink stream. Thus the whole KERI DKMI may
be hosted on scalable Kafka or Flink clusters.[KERI WP, p120](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)

Comment: as we already have pretty advanced KERIOX impl regarding processing (but on the other hand we dont have such advanced brokerage), pros/cons need to be considered whether Kafka is an alternative.

##### NFR

* As a continuation to last Friday call:
* who will bootstrap the witnesses network?
* who will bootstrap and maintain validator network?

Note that all the parties, so whether witnesses or the others may play with the same controller, but in a different context, as the controller may be controller on its own and a validator at the same time.

#### Validator network

* Watcher / Juror / Judge are essential -- impl as a feature in KERIOX;
* Duplicitous event log (DEL) -- basic building block for duplicity game so a Juror playground;
*