I contributed to Deno

I’ve been developing with Node.js for a while now and I have been enjoying it quite a bit, despite some of its flaws. Overall its been a great experience and I am a big node.js fan.

Much to my surprise however a new project called Deno has emerged. After taking a look at it I realized it is essentially a spiritual successor to node.js but it’s also better than node in pretty much every single way… Well, every way except for its ubiquity! There are tons of high quality open source modules for node which just don’t quite work with Deno out of the box. Deno took a hard line stance on its adoption of ESM modules, which is actually better than common.js, and enables a variety of other features such as not needing npm at all anymore… Its just that ESM is not very wide spread and is only backwards compatible with commonjs modules with some hacks that only work about 75% of the time it seems.

Deno also has a few areas which are still underdevelopment related to certs, TLS and websockets. But fortunately the project has a very active and responsive team of developers! I noticed an issue I was having related to connecting to an internal site due to my CA certificates not being loaded and took the time to debug it. Eventually I figured out that the propery CA cert was stored in my systems keystore and Deno couldn’t find it there. So I managed to find a simple rust crate which supported loading certificates right out of the keystores for each major platform and figured out it was pretty trivial to integrate it in with the crates Deno was already using to do TLS! The Deno developers worked with me to craft the proper changes and do some necessary refactoring and testing, and now I am a Deno contributor.

Here’s my commit:




Tao of Leo Proven Right, Once Again

I was just reading about UTC and saw this tidbit of history

The official abbreviation for Coordinated Universal Time is UTC. It came about as a compromise between English and French speakers.

Coordinated Universal Time in English would normally be abbreviated CUT.
Temps Universel Coordonné in French would normally be abbreviated TUC.

UTC does not favor any particular language.

Therefore the abbreviation UTC was selected because everyone hated it equally 🤣

Tao of Leo #33

A committee that makes fair decisions will not choose the best solution, but the one everyone hates equally.

Using ngrok as an external process

I don’t know why it took me so long to figure this out but it turns out that the ngrok client has an api that you can access locally. That means you can run ngrok external to your process and then call to it to get the public tunnel information. This is very handy as ngrok doesn’t really like starting and stopping as rapidly as you may want while developing a server.

This means rather than using the ngrok package on npm for your local development, look towards docker hub:


I added an entry to my docker-compose.yml file like so:

version: '3'
    image: wernight/ngrok
      - 4040:4040
      NGROK_PORT: 4000
      NGROK_PROTOCOL: http

Next in your code, after staring the containers, simply call the service from your application code:

const { status, data } = await axios.get('http://localhost:4040/api/tunnels')
const { tunnels } = data
const { public_url } = tunnels.find(t => t.proto === 'https')
this.publicEndpoint = public_url

The ngrok tunnel will stay alive as your server restarts over and over.

npm update all dependencies to their latest version

Here’s a little one-liner I came up with that I had a hard time googling for:

$  npm outdated | tail -n +2 | awk '{print $1}' | xargs -I % sh -c 'npm i %@latest --save-exact'

It will simply update each outdated dependency to their latest version, I recommend using --save-exact but that’s optional.

Nothing too fancy but hopefully it saves me a headache later when I have to search for it again!

Shamir’s Secret Sharing

I made a little website that allows you to encrypt and decrypt shared secrets using Shamir’s Secret Sharing algorithm:


It was just a fun little project that I decided to do, nothing ground breaking. I used an existing library on npm (shamir) for the encryption and decryption, the rest was just hooking it up to a UI and getting some technical details around static sites and AWS hosting worked out.

One interesting thing I learned while implementing this is that while you only need a quorum of keys to decrypt the secret you also need them to be put into the correct index in the input. Which makes sense when you think about how the algorithm works, but I didn’t immediately realize this.

Full source code for the site is available here: https://github.com/justinmchase/bewmdone.com

I’ve been thinking about what happens to my data and accounts if I were to die suddenly. I’m not planning on that happening any time soon but you never know. I’d like to think that my wife and kid(s) could theoretically have the information they need to recover my accounts and get access to my data if I were to pass away but I’m not real thrilled with the available options I’ve come up with so far.

I don’t really want to give any one source all of the keys to the castle for example. I don’t know how practical or cost effective it is to be putting everything down on paper and storing it in a safety deposit box either. On the other hand, with this method I could give various friends and family members all their own keys, which by themselves are not enough to see the secrets, and then ask them to send the parts they have to my wife upon unexpected death.

It might make an interesting business model if there was a service that generated the shared keys and kept one key but refused to release the key except upon receipt of a death certificate. Then that service could generate key trios for you and whoever you want to grant access to and neither party can individually see your secrets until the death event and they come together to unlock it…

A little morbid, I know! But an interesting subject.