Well, this became more of an adventure that I’d originally wanted but, after learning some BLE and, with the help of others (Thanks Jonatha, JsBergbau), I’ve sample code that connects to 4 Xiaomi 2nd gen. Thermometers, subscribes to readings and publishes the data to MQTT. From there, I’m scraping it using Inuits MQTTGateway into Prometheus. Repo: https://github.com/DazWilkin/gomijia2 Thanks|Credit: Jonathan McDowell for gomijia and help JsBergbau for help Background I’ve been playing around with ESPHome and blogged around my very positive experience ESPHome, MQTT, Prometheus and almost Cloud IoT.

I’m noodling the utility of a Transparency solution for Rust Crates. When developers push crates to Cargo, a bunch of metadata is associated with the crate. E.g. protobuf. As with Golang Modules, Python packages on PyPi etc., there appears to be utility in making tamperproof recordings of these publications. Then, other developers may confirm that a crate pulled from cates.io is highly unlikely to have been changed. On Linux, Cargo stores downloaded crates under ${HOME}/.

I’ve written previously (Google Trillian for Noobs) about Google’s interesting project Trillian and about some of the “personalities” (e.g. PyPi Transparency) that I’ve build using it. Having gone slight cra-cra on Cloud Run and gRPC this week with Golang gRPC Cloud Run and gRPC, Cloud Run & Endpoints, I thought it’d be fun to deploy Trillian and a personality to Cloud Run. It mostly (!) works :-) At the end of the post, I’ve summarized creating a Cloud SQL instance to host the Trillian data(base).

<3 Google but there’s quite often an assumption that we’re all sitting around the engineering table and, of course, we’re not. Cloud Endpoints is a powerful offering but – IMO – it’s super confusing to understand and complex to deploy. If you’re familiar with the motivations behind service meshes (e.g. Istio), Cloud Endpoints fits in a similar niche (“neesh” or “nitch”?). The underlying ambition is that, developers can take existing code and by adding a proxy (or sidecar), general-purpose abstractions, security, logging etc.

Update: 2020-03-24: Since writing this post, I’ve contributed Golang and Rust samples to Google’s project. I recommend you start there. Google explained how to run gRPC servers with Cloud Run. The examples are good but only Python and Node.JS: gRPC comes to Cloud Run gRPC in Google Cloud Run Missing Golang…. until now ;-) I had problems with 1.14 and so I’m using 1.13. Project structure I’ll tidy up my repo but the code may be found:

I wrote recently describing Python and Golang clients for OriginStamp based on OriginStamp’s API’s swagger spec. As a way to pursue learning rust, I’ve been forcing myself to write examples using rust. I’m honestly finding learning rust tough going and think I’m probably better to revert to the “Learning Rust” tutorials. That said, herewith an explanation of building a rust client using an OpenAPI (!) generated SDK from OriginStamp’s swagger spec.

Google has released a new Golang SDK for protobuf. In the [announcement], a useful tool to redact properties is described. If like me, this is somewhat novel to you, here’s a mashup using Google’s Protocol Buffer Basics w/ redaction. To be very clear, as it’s an important distinction: Version Repo Docs v2 google.golang.org/protobuf Docs v1 github.com/golang/protobuf Docs Project Here’s my project structure: . ├── protoc-3.11.4-linux-x86_64 │ ├── bin │ │ └── protoc │ ├── include │ │ └── google │ └── readme.

ESPHome is a very interesting project. I’d not heard of it until this week and am surprised that it isn’t more newsworthy. I’m always tinkering with IoT stuff, have a couple of Wemos D1 ESP8266s. They are brought out occasionally for learning. I’ve been using them this week with ESPHome. I’m looking to buy some Xiaomi BLE temperature sensors and thinking I could read the temperatures from these using the ESPs (thanks to ESPHome) and publish the data to MQTT.

Recently, I wrote about some initial adventures with OriginStamp Using OriginStamp’s UI or API, submitting a hash results in transactions being submitted to Bitcoin, Ethereum and a German newspaper. Using the API, it’s possible to query OriginStamp’s service for a proof. This post explains how to verify such a proof. The diligent reader among you (Hey Mom!) will recall that I submitted a hash for the message: Frederik Jack is a bubbly Border Collie The SHA-256 hash of this message is:

I wrote recently about some exploration of Timestamping with OriginStamp. Since writing that post, I had some supportive feedback from the helpful folks at OriginStamp and plan to continue exploring that solution. Meanwhile, OriginStamp exposed me to timestamping and trusted timestamping and I discovered freeTSA.org. What’s the point? These services provide authoritative proof of the existence of a digital asset before some point in time; OriginStamp provides a richer service and uses multiple timestamp authorities including Bitcoin, Ethereum and rather interestingly a German Newspaper’s Trusted Timestamp.