Raptorlicious: planning

1) The SparkFun ATECC508A does not work with the Heltec Cubecell but it does work with a Heltec LoRa WiFi ESP32.

With a Heltec CubeCell I get:

inputBuffer: 43,F9,C3,6F,89,64,62,33,78,BD,C0,68,D4,BC,E0,7E,D1,7C,8F,A4,86,F9,AC,C,26,13,CA,3C,8C,30,6D,7B,1C,D3,67,17,B8,AC,5E,4F,EA,8A,D2,3D,C8,D0,78,3C,23,18,EE,4A,D7,A8,D,B6,E0,2,6A,D0,B0,72,A2,4F,64,FF,FF,

(in the script this is reflected by: "Failure to generate This device’s Public Key"

With a Heltec LoRa WiFi ESP32 I get:

inputBuffer: 43,F9,C3,6F,89,64,62,33,78,BD,C0,68,D4,BC,E0,7E,D1,7C,8F,A4,86,F9,AC,C,26,13,CA,3C,8C,30,6D,7B,B6,1C,D3,67,17,B8,AC,5E,4F,EA,8A,D2,3D,C8,D0,78,3C,23,18,EE,4A,D7,A8,D,B6,E0,2,6A,D0,B0,72,A2,4F,D8,64,

This is described more fully in
http://community.heltec.cn/t/debugging-faulty-cubecell-i2c-connection-to-cryptographic-authentication-chip-atecc508a/2300

and

https://gist.github.com/bshambaugh/07fc95c7b129a2614c6bbc2288f124b5

I believe that the Wire.h library provided with the CubeCell times out giving the last part of the message out of order. This happens with a 64 byte public key and a 32 byte random message. (look up data out of order on I2C connections)

2) Upload the protothreading/multithreading video that you have to the Arduino thread on the YouTube website. (this is useful if you have multiple sensors going to a single ESP32)

3) interoperability of SSI
"There are 3 credential formats that are in harmony with the VC spec, that are not mutually interoperable. Until we solve that problem, cross-ledger SSI will probably not happen."
"it’s going to be easier for Sovrin to support the simple crypto of the other formats, than for the other formats to upgrade their crypto to support Sovrin-style credentials."
https://blockimpact.tech/2019/12/05/%E3%80%90hyperledger-x-tykn%E3%80%91interview-with-daniel-hardman-chief-architect-at-evernym-and-technical-ambassador-at-hyperledger/

edit see:
https://www.w3.org/TR/vc-data-model/
https://w3c.github.io/did-core/

"In practice, this means that what is needed for VC interoperability is JSON processing, along with pre-configured ‘@context’ definitions. Having dynamically resolvable contexts and doing JSON-LD processing is not strictly necessary for an interoperable VC ecosystem. However, these features may add additional semantic data capabilities that are useful for many kinds of implementations."
https://medium.com/mattr-global/jwt-vs-linked-data-proofs-comparing-vc-assertion-formats-a2a4e6671d57

Try this:
CQL channel: https://www.youtube.com/channel/UC4FSvHYsdEnLz6-dpWyzKxQ
CQL Tutorial: https://www.categoricaldata.net/tutorial.html

FQL tool: https://github.com/CategoricalData/FQL (I think it has JSON). The later CQL tool has more theory and???
https://www.youtube.com/watch?v=GizBg4M3bII&t=16m11s (Intro to Functorial Data Migration)
seeAlso: https://www.w3.org/TR/shacl/

Sovrin DID spec: https://sovrin-foundation.github.io/sovrin/spec/did-method-spec-template.html
Thread in w3cCCG: https://lists.w3.org/Archives/Public/public-credentials/2020Aug/0079.html

4) Get the cryptochip to work with a ledger. either sovrin or bigchaindb

"About DID docs with multiple keys (different curves), one of the examples I found was here: https://w3c.github.io/did-core/#example-17-various-public-keys. There is also a key type registry, which we maintain in CCG: https://w3c-ccg.github.io/ld-cryptosuite-registry/ " -- kimhd

also understand the credentials format a little better

5) Set up an antenna for https://homeport.network/. It may be Andreas Spiess LoRa sensor video that works out the best. Messing around with a Yagi and gpredict and the standard prodcedure for talking to satellites (like on rtl-sdr) will help. see the antenna post, 1 or 2 posts ago. more complicated (https://github.com/Blockstream/satellite) .

6) any other threads you started in CCG.

7) multi-threading if you have cubecell + cubcell + .. = ESP32. protothreading and multithreading video.

for the communcation between the servers with the sensor data:
http://tutorials.jenkov.com/java-concurrency/index.html

8) see also:
https://medium.com/decentralized-identity/a-universal-resolver-for-self-sovereign-identifiers-48e6b4a5cc3c
https://medium.com/decentralized-identity/overview-of-decentralized-identity-standards-f82efd9ab6c7

https://medium.com/decentralized-identity/the-universal-resolver-infrastructure-395281d2b540

https://docs.google.com/presentation/d/1uOM6F2yArFAM42L_O9WUMHlAP_a8hZg8oTn9he8hv7I/htmlpresent

https://medium.com/decentralized-identity/overview-of-decentralized-identity-standards-f82efd9ab6c7
https://medium.com/transmute-techtalk/the-business-case-for-interoperability-a1a2b884297d

focus on 7 levels of why.

This is what you are after. (well you need to redraw it) Anything cryptochip related will be coupled on the I2C bus with the BH1750 sensor. Anything mmADT related will be between the databases.