Update: 2020-09-24 Three updates since I wrote the post: gcloud alpha cloud-shell get-mount-command ${DIR} It’s possible to use sshfs to mount the Cloud Shell home directory locally: DIR=/path/to/dir gcloud alpha cloud-shell get-mount-command ${DIR} Which generates something of the form: sshfs [[USERNAME]]@[[HOST]]: ${DIR} \ -p [[PORT]] \ -oIdentityFile=~/.ssh/google_compute_engine \ -oStrictHostKeyChecking=no You may then code --new-window ${DIR} curl command may lack .sshHost curl’ing the cloudshell.googleapis.com endpoint will result in a null value for .

Google’s tutorial didn’t work for me. In this post, I’ll help you get this working. https://developers.google.com/assistant/conversational/quickstart Create and set up a project This mostly works. I recommend using the Actions Console as described to create the project. I chose “Custom” and “Blank Project” You need not enable Actions API as this is done automatically: For the console work, I’m going to use Google’s excellent Cloud Shell. You may access this through the browser or through a terminal:

Chatting with one of Google’s Trillian team, I was encouraged to explore Trillian’s Map Mode. The following is the result of some spelunking through this unfamiliar cave. I can’t provide any guarantee that this usage is correct or sufficient. Here’s the repo: https://github.com/DazWilkin/go-trillian-map I’ve written about Trillian Log Mode elsewhere. I uncovered use of Trillian Map Mode through Trillian’s integration tests. I’m unclear on the distinction between TrillianMapClient and TrillianMapWriteClient but the latter served most of my needs.

I’ve spent time recently playing around with WebAssembly (WASM) and waPC. Rust and WASM were born at Mozilla and there’s a natural affinity with writing WASM binaries in Rust. In the WASM examples I’ve been using for WASM Transparency, waPC and MsgPack and waPC and Protobufs. I’ve created 3 WASM binaries: complex.wasm, simplex.wasm and fabcar.wasm and each is about 2.5MB when: cargo build --target=wasm32-unknown-unknown --release The Rust and WebAssembly book has an excellent section titled Shrinking .

I’ve been playing around with a proof-of-concept combining WASM and Trillian. The hypothesis was to explore using WASM as a form of chaincode with Trillian. The project works but it’s far from being a chaincode-like solution. Let’s start with a couple of (trivial) examples and then I’ll explain what’s going on and how it’s implemented. 2020/08/14 18:42:17 [main:loop:dynamic-invoke] Method: mul 2020/08/14 18:42:17 [random:New] Message 2020/08/14 18:42:17 [random:New] Float32 2020/08/14 18:42:17 [random:New] Float32 2020/08/14 18:42:17 [random:New] Message 2020/08/14 18:42:17 [random:New] Float32 2020/08/14 18:42:17 [random:New] Float32 2020/08/14 18:42:17 [Client:Invoke] Metadata: complex.

As my reader will know (Hey Mom!), I’ve been noodling around with WASM and waPC. I’ve been exploring ways to pass structured messages across the host:guest boundary. Protobufs was my first choice. @KevinHoffman created waPC and waSCC and he explained to me and that wSCC uses Message Pack. It’s slightly surprising to me (still) that technologies like this exist with everyone else seemingly using them and I’ve not heard of them.

A digression thanks to Sal Rashid who’s exploring WASM filters w/ Envoy. The documentation is sparse but: How to write WASM filters for Envoy… There is a Rust SDK but it’s not documented: proxy-wasm-rust-sdk I found two useful posts by Rustaceans who were able to make use of it: Extending Envoy with WASM and Rust Extending Istio with Rust and WebAssembly Here’s my simple use of the SDK’s examples.

Following on from waPC & Protobufs, I can now remotely invoke (arbitrary) WASM functions: Client: The logging isn’t perfectly clear but, the client gets (a previously added) WASM binary from the server (using the SHA-256 of the WASM binary as a unique identifier). The result includes metadata that includes a protobuf descriptor of the WASM binary’s functions. The descriptor defines gRPC services (that represent the WASM functions) with input (parameters) and output (results) messages.

Google has a new Golang Protobuf API, APIv2 (google.golang.org/protobuf) superseding APIv1 (github.com/golang/protobuf). If your code is importing github.com/golang/protobuf, you’re using APIv2. Otherwise, you should consult with the docs because Google reimplemented APIv1 atop APIv2. One challenge this caused me, as someone who does not use protobufs and gRPC on a daily basis, is that gRPC (code-generation) is being removed from the (Golang) protoc-gen-go, the Golang plugin that generates gRPC service bindings.

Following on from waPC & Protobufs and a question on Stack Overflow about Cloud Functions, I was compelled to try running WASM on Cloud Functions no JavaScript. I wanted to reuse the WASM waPC functions that I’d written in Rust as described in the other post. Cloud Functions does not (yet!?) provide a Rust runtime and so I’m using the waPC Host for Go in this example. It works! PARAMS=$(printf '{"a":{"real":39,"imag":3},"b":{"real":39,"imag":3}}' | base64) TOKEN=$(gcloud auth print-identity-token) echo "{ \"filename\":\"complex.