add formik post

README.md

@@ -7,7 +7,17 @@ Analytics are handled by Plausible.
 See: https://plausible.io.
 
 I use web analytics for personal use only; I don't sell web analytics data.
-In my experience, if you use an adblocker such as [uBlock Origin](https://github.com/gorhill/uBlock), the Plausible tracking script will be blocked by default and your activity won't be tracked.
+In my experience, if you use an ad blocker such as [uBlock Origin](https://github.com/gorhill/uBlock), the Plausible tracking script will be blocked by default and your activity won't be tracked.
+
+## Spell Checking
+Spell checking is done using [cspell](https://cspell.org/).  
+The following assumes you have npm installed.
+Install cspell globally:  
+`npm install -g cspell@latest`  
+Verify that cspell is installed and is in your $PATH:  
+`cspell --version`  
+
+cspell configuration is handled via `cspell.json`. For more information, see the [cspell configuration docs](https://cspell.org/configuration/).
 
 ## Support My Work
 https://juniperspring.xyz/posts/support-me/

content/posts/bidirectional-totp/index.md

@@ -14,7 +14,7 @@ Time-Based One Time Password (TOTP) authentication is extremely beneficial.
 It lets you quickly add two‑factor authentication (2FA) to online accounts according
 to a simple and open standard. Simply scan a QR code into a TOTP app like [Aegis](https://github.com/beemdevelopment/Aegis).
 As long as you have access to your phone, you can then use the TOTP app to generate 2FA codes whenever need be.
-No risk of [simswapping](https://en.wikipedia.org/wiki/SIM_swap_scam), no need for SMS reception or a phone number, and no need for proprietary 2FA apps.
+No risk of [SIM swapping](https://en.wikipedia.org/wiki/SIM_swap_scam), no need for SMS reception or a phone number, and no need for proprietary 2FA apps.
 
 **But TOTP as it's currently widely implemented has a shortcoming; it doesn't prevent phishing attacks.**
 Click a link in an email that redirects to a phishing website; the phishing website mimics one of your favorite websites.

content/posts/digital-organization/index.md

@@ -35,7 +35,7 @@ Digital minimalism for me is about striking a balance between the utility of my
 
 ## Dotfiles in VCS
 
-I never understood the benefits of keeping my dotfiles in source control until I started doing it as part of my [init](https://github.com/librick/init) repo. The main drawback is additional complexity. You have to maintain the contents of the repo, authoring commits whenever you make substantial changes to your setup. The source of truth for your settings is no longer your machine. This also means that you have to be diligent about maintaining any related VCS repos whenever you subtantially change your local setup.
+I never understood the benefits of keeping my dotfiles in source control until I started doing it as part of my [init](https://github.com/librick/init) repo. The main drawback is additional complexity. You have to maintain the contents of the repo, authoring commits whenever you make substantial changes to your setup. The source of truth for your settings is no longer your machine. This also means that you have to be diligent about maintaining any related VCS repos whenever you substantially change your local setup.
 
 Further, if the point of keeping dotfiles and scripts in a VCS is so that you can access it anywhere, thought should also be given to git mirrors and ensuring the availability of your repositories.
 
@@ -68,7 +68,7 @@ and that those passwords are accessible and up-to-date (via KeepassXC and Syncth
 
 With my current setup, my mobile account passwords are stored in a KeepassXC database that gets mirrored by Syncthing between my laptop and my phone.
 So long as I have access to either device, I have access to my passwords. If I update my mobile passwords on either device, any changes are automatically
-propogated to all devices. This is particularly useful as some passwords are for websites (e.g., for financial sites) that I access on both devices.
+propagated to all devices. This is particularly useful as some passwords are for websites (e.g., for financial sites) that I access on both devices.
 
 ### Syncing Phone Pictures
 

content/posts/dnssec/index.md

@@ -28,7 +28,7 @@ The textual representation of ECDSA public keys depends partially on whether it
 
 The field size of NIST P-256 is 256 bits, or 32 bytes. An uncompressed ECDSA public key consists of an x and y‑coordinate, and since each coordinate is a field element (i.e., for NIST P-256, is at most 32 bytes in length), an ECDSA public key for Curve P-256 requires 64 bytes, not including a prefix. When the (well-known) prefix 0x04 is prepended, the total length is 65 bytes. 
 
-The prefix is used to quickly differentiate between uncompressed (0x04) and compressed (0x02, 0x03) form. Compressed form takes advantage of the property that the y‑coordinate of an ECDSA public key can be unambiguously derived given the curve equation, x‑coordinate, and a odd-even flag (prefix).  Solving the curve equation for y given x yields two posible values for y. One solution is always even, one solution is always odd. By prefixing the compressed form with a well-known byte (0x02 for even, 0x03 for odd), the public key can be unambigiously specified with a total of $$32+1=33$$ bytes.
+The prefix is used to quickly differentiate between uncompressed (0x04) and compressed (0x02, 0x03) form. Compressed form takes advantage of the property that the y‑coordinate of an ECDSA public key can be unambiguously derived given the curve equation, x‑coordinate, and a odd-even flag (prefix).  Solving the curve equation for y given x yields two possible values for y. One solution is always even, one solution is always odd. By prefixing the compressed form with a well-known byte (0x02 for even, 0x03 for odd), the public key can be unambiguously specified with a total of $$32+1=33$$ bytes.
 
 ## ECDSA Key Format for DNSKEY
 When used in DNSKEY records, ECDSA public keys are given in uncompressed form. References to some of the relevant RFCs are given below. Practically, this means that the DNSSEC public keys for juniperspring.xyz should each be $32*2=64$ bytes long when no prefix is used. These keys are always *exactly* 64 bytes long, probably because the RFCs strictly specify uncompressed form (i.e, a prefix would be redundant) and because small DNS records are desirable.
@@ -62,7 +62,7 @@ Each of the resulting hex strings are 128 chars (64 bytes) long and do not conta
 At the time of writing, the juniperspring.xyz domain is provided by Namecheap.
 The Namecheap web interface provides a toggle for enabling DNSSEC for the domain (DNSSEC is disabled by default).
 ![DNSSEC in the Namecheap management interface](namecheap-dnssec.png)
-Apparently, Namecheap uses `ECDSAP256SHA256` as the signature algorithm by default, generates the requisite keypairs, and (I assume) stores the private keys on Namecheap's servers. You can check the resulting DNSSEC records with an online tool provided by Verisign Labs[^6].
+Apparently, Namecheap uses `ECDSAP256SHA256` as the signature algorithm by default, generates the requisite key pairs, and (I assume) stores the private keys on Namecheap's servers. You can check the resulting DNSSEC records with an online tool provided by Verisign Labs[^6].
 
 ## On the Ethereum DNSSEC Oracle
 Having a working knowledge of DNS and DNSSEC enables a better understanding of the Ethereum Name Service (ENS)[^7] and the Ethereum DNS Oracle[^8]. Submitting a proof to the DNSSEC oracle is significantly more expensive (multiple times the cost of purchasing juniperspring.eth for four years) than purchasing a `.eth` domain.