bshambaugh/BlinkyProject

Possible Use Cases

There are two guys: Joe and Sam. Joe has a few ESP32 devices with various sensors and widgets attached. So does Sam. Sam is getting to know Joe, and would like to provide him access to some sensors. He also wants to store his sensor data in a distributed way because he doesn't trust the big cloud providers. He also like the immutable web of trust, but does not want to settle on a particular blockchain. Sam creates a ceramic document that gives Joe access to the data come from some his sensors and widgets, and even to an even fewer number he gives Joe to ability to turn on and off the sensor or the widget.

In another use case a teacher is teaching a training class and wants to give pupils access to lockers and equipment (golf carts, power tools) and rooms to stay they night , but does not want the hassle dealing with physical keys. The teacher just wants things to work once the pupil satisfactorily completes the training. For this did-jwt-vc is considered.

In another use case someone thinks it would be great to have augmented reality where the holder of an NFT is able to unlock gates, grab an electronically enabled unicorn plush toy from the stuffed animal vendor, or who knows...

Perhaps using this underlying tech, referred to some as a protocol development, in a real world scavenger hunt adventure game could be interesting. By combining verifiable credentials, OCAPs (like UCAN that allow for off network) and embeedded devices motors, lights, sensors, etc could be activated based on a players progression in the game.

--> (edit) OCAPS: zcap-ld (https://w3c-ccg.github.io/zcap-spec/#capabilities-vs-access-control-lists,https://github.com/WebOfTrustInfo/rwot5-boston/blob/master/draft-documents/lds-ocap/lds-ocap.md) --> (edit) UCAN: https://twit.tv/shows/floss-weekly/episodes/681, https://github.com/ucan-wg/, https://github.com/web3-storage --> (edit) for your game notice that hashes are determininstic but not reversabile and cryptographic signatures are verifiable (for visiting one station after the other you could hash then sign data, then gossip to all of the nodes to find the signer? ...I had an elegant paper sketch that might have more....must find)

Ramblings ... "People are good at verifying digital credentials with computers and cell phones, but not so much if you want to open a gate or do it over a low bandwidth extended network. Brent Shambaugh 10 minutes ago I haven't seen many electronics projects associated with NFTs either. Brent Shambaugh 9 minutes ago NFTs seem to be totally a digital construct, like a picture of a dog, cryptographically verified to an owner....but they are not cryptographically verified to an electronic device in the physical dog collar Brent Shambaugh 7 minutes ago the dog collar cannot make cryptographically provable assertions about any health care its had, who his or her parents and siblings are .... etc... Brent Shambaugh 6 minutes ago For the longest time there have been hardware wallets for Bitcoin. Brent Shambaugh 6 minutes ago Maybe I am just reinventing the wheel around this. Brent Shambaugh 8 minutes ago I don't know. I've learned a lot. " Interesting, ERC-721 (non-fungible tokens) mentions physical assets: https://eips.ethereum.org/EIPS/eip-721

Adding LoRa could allow for greater geographic coverage. I was able to pull data from a Cubecell transmission a third of a mile away.

Rough draft

----> edit: some of the bidirectional LoRa code was put together here: https://www.youtube.com/watch?v=EjLkEAJZ0sY (Bidirectional Communication Between Heltec ESP32 Lora and Heltec CubeCell) 12:31
remote signer code:
12:31
https://github.com/bshambaugh/BlinkyProject/blob/master/CubeCellandHeltecESP32_try[…]ta_from_NodeJS_server_and_sendback_later_movebackToCubecell.ino :doughnut: (edited)
12:32
move this code to the CubeCell. For now it is incubating on the ESP32. Aside from the device (CubeCell) the communication mechanism will also change. Websockets over Wifi will become LoRa. (edited)
12:35
This is to add talking to ceramic functionality to the Node.js server: https://github.com/bshambaugh/BlinkyProject/tree/master/CubeCellandHeltecESP32_try7/esp8266_shop_websockets/CeramicToDo
12:36
This is what I am going to try to use on the Node.js side to talk to the :doughnut: code as a remote signer. https://github.com/bshambaugh/BlinkyProject/blob/master/CubeCellandHeltecESP32_try[…]8266_shop_websockets/custom/verifySignature/verifySignatureQ.js

(well that last link didn't work, try: This came later https://www.youtube.com/watch?v=VhFydpFg2wg which is basically a hack of https://esp8266-shop.com/blog/websocket-connection-between-esp8266-and-node-js-server/ , https://github.com/bshambaugh/BlinkyProject/blob/master/CubeCellandHeltecESP32_try7/esp8266_shop_websockets/CeramicToDo/esp8266_shop_websockets_try5/websocket_example.js

Here is a visual representation of how the code will fit together:

The code I have been working on is particular to the P-256 curve. I had hoped that development would inform my general understanding of ceramic integration. Some of the code will be re-used if another cryptographic curve is used (particularly the code on the Heltec LoRa ESP32 and CubeCell as well as the general flow of the code on the CeramicToDo). Finding an edge device on the network has been an idea explored and current research and/or thinking suggests this will combine a did:key (unique identifier provided by the cryptographic co-processor re-written) and some form of index of the ceramic network. At least my gut feeling has been that it might be better to persist data stored from sensors in SkyNet/SkyDB and integrate this with ceramic as in an earlier tutorial provided by Ceramic. That is, use the ceramic network to point to data stored by distributed or cerntralized means. An experiment where data was cleaned by means of a ccryptographic signature (data is signed and when decrypted must match the original message before encryption) and placed in a SQL database (without the use of ceramic) has already been performed. This is linked to below, and was demonstrated in shambezi's Blinky Project YouTube channel. It is hoped that the data for the verifiable credentials will stay in ceramic, and all the edge devices will be doing is signing CIDs or StreamIDs (see May 2021 Ceramic Community call with Joel Thor (@oed)).

Here is a link to an early SkyDB + IDX Workshop. https://medium.com/ceramic/idx-and-skydb-joins-forces-for-a-future-of-web3-hackathon-83eff179a9a1 (IDX and SkyDB join forces for a future of Web3 hackathon - Nov 2 - 23 , 2023) . SkyDB + IDX Workshop (https://www.youtube.com/watch?v=-Y36JvYXwrw).

I predict I will follow this example code ceramic ToDo
This will require a P-256 version of key-did-provider-ed25519 .

I will call this something like key-did-provider-P256 (edit now here: key-did-provider-p256) or key-did-provider-NIST (if I want to support P-256, P-384, and P-521 by the same provider). This key-did-provider will depend on did-jwt, rpc-utils , and dids . The resolver for the key-did-provider is being implemented here PR 1884.

Edit, Marth 12th, 2022: Here is an example of early code for the remote signer in the folder: createWebSocketServer2_2 . Try to plug in with this: https://github.com/decentralized-identity/did-jwt/blob/master/docs/guides/index.md#creating-custom-signers-for-integrating-with-hsm

Support for did-jwt for P-256 for the provider is described here: PR 212 and being implemented here: did-jwt (I believe this needs to be done). rpc-utils and dids do not need to be changed.

I tried to explain my thoughts to Joel with Ceramic in May: twitter post about Joel
He seemed to calm my worries about the data packets verifying updates being too large for LoRa to handle, since he claimed that they would be CIDs (streamIDs in ceramic in think). StreamID description in CIP-59.

Ceramic eloquently allows a blockchain to maintain state, but minimized data and writes: see CIP-69 for Ceramic blockchain Anchoring. for how Ceramic describes its Architecture.

For now, this Playlist gives earlier evolution of the Blinky Project. Much, if not all, of the The Ceramic Network work is not included.
Blinky Project on YouTube)

Here is an earlier sketch of the architecture.
alt text

Here is the Cubecell pushing data to the ESP32 in the earlier architecture:

Here is the ESP32 receiving data from the ESP32 and pushing it to the NodeJS server: ESP32

Here is the NodeJS server receiving data from the ESP32: NodeJS_One

Here is the NodeJS server receiving data from the ESP32 and writing to a SQL database and rebroadcasting on websockets: NodeJS_Two NodeJS_Three

More stuff to consider once Ceramic Network is linked in:

https://github.com/decentralized-identity/did-jwt-vc (for verifiable credentials) https://www.w3.org/TR/vc-data-model/ (for verifiable credentials). The goal would be to only have the LoRa device see streamIDs, and let ceramic take care of long JSON documents needed for credentials. Geovane Fedrecheski eloquently went into the difficulties of LoRa handling at IIW32A - session 12E. To get this working with and Agent talking to the Node.js server, which talks to the ceramic network, consider Bjorn Hamel's excellent talk: Adventures in Self-Soverign Identity .

For Authorization, consider looking at: Authorization Capabilities for Linked Data v0.3. Thank you to the W3C CCG Mailing List. Further exploration for this by Ceramic is described in this blog post which talks about CACAO in the context of "Capability Based Security for Ceramic".

https://github.com/ceramicnetwork/nft-did-resolver (for NFTs) [It seems you would use key:did with 3ID, and 3ID with NFT] seeAlso: 3ID method CIP-79

Sensor data needs to be transmitted securely. The first experiment only considered authentication. Ockam is looking at secure channels, and is familiar with SSI like Ceramic/3Box/uPort is: friendly discussion , homepage. See also X3DH & Diffe Hellman. Also, I am not sure this will help (if it is desireable to bring in Ockam). Ockam has a preference for Rust, which can be framed in the form of C like exisitng ESP32 code has using this library? To integrate Node.js with Rust also see: Rust is the Future of JavaScript Infrastructure.

Elliptic curves can be generated on an ESP32 without the use of a cryptographic co-processor. See libraries Elliptic-Curve-on-ESP32 and micro-ecc . Perhaps there will be issues with securing and preserving the private keys?

https://medium.com/ceramic/idx-and-skydb-joins-forces-for-a-future-of-web3-hackathon-83eff179a9a1 , https://www.youtube.com/watch?v=-Y36JvYXwrw (skydb, possible sensor data storage option) seeAlso: Encrypted Data Vaults and whatever Ceramic is trying to integrate with.

Consider funding schemes: https://www.youtube.com/watch?v=IV59r4JcOIg, Superfluid: DeFi Surf Lesson - Money Streaming https://github.com/bshambaugh/thegraphReactApp/tree/master/src (early superfluid experiments) http://bshambaugh.org/MNDF_Project.html (MNDF Project) https://www.helium.com/ (compare)

Extended LoRa. https://github.com/RbtsEvrwhr-Riley/CellSol (Extended LoRa/simple apps), https://github.com/G4lile0/tinyGS (Extended LoRa)

Finding stuff on Ceramic: https://tiles.ceramic.community/ , https://thegraph.com/en/ (future index ceramic), https://www.youtube.com/watch?v=wrV7cMebwyE (The Graph 🛠 Building Rich APIs on top of Ethereum with The Graph - Nader Dabit - Web3Weekend), https://github.com/mdaquin/Watson-Indexer- (Inspiration)

Better data management. Investigate Applied Category Theory. Alan Ransil from Protocol Labs (https://research.protocol.ai/) showed some interest in it at the ACT Workshop. Dr. Spivak was there and separately Dr. Wisnesky who has been working with him suggested I checkout "Formal Modelling and Application of Graph Transformations in the Resource Description Framework by Benjamin Braatz" (https://core.ac.uk/display/57704480). Also consider https://jena.apache.org/documentation/io/rdf-json.html , https://dashjoin.medium.com/json-schema-schema-org-json-ld-whats-the-difference-e30d7315686a , https://json-schema.org/understanding-json-schema/about.html , and Semantic Sensor Data Search in a Large-Scale Federated Sensor Network , http://ceur-ws.org/Vol-839/calbimonte.pdf , https://github.com/cloudprivacylabs (Layered Schemas), Dr. Joshua Shinavier: Dragon (see: https://www.meetup.com/Category-Theory/), https://github.com/inkandswitch/cambria-project, Brooklyn Zelenka may have mentioned ACT in a blog post on https://fission.codes/ , migration instead of global source of truth in HL Ontology (https://www.youtube.com/watch?v=bk36__qkhrk : Dr. Spivak Categorical Databases). More information was presented in a presentation at IIW35 in the repository Explorations-of-Category-Theory-for-Self-Sovereign-Identity.

It should be noted, that the Ceramic Network was demonstrated to work with an ESP32 on November 11th, 2022. A demo at table #8 was then done. A demo video is going to come. See the results here. The utilized code was remoteT4 and the code run on the ESP32 was in the remoteSigner branch in the platform.io created main.cpp.