The gang and I are very lucky to live in a San Francisco neighborhood where we have markets, a family owned pharmacy, and family-owned restaurants, coffee shops, and delis all about a ten block walk from the house. Here’s the haul from our Farmers Market that we walk to along with our local butcher shop and dim sum bakery a few weeks ago.

Consequently when I saw a mention of local-first software,[via] I was intrigued. (As a side note, the presenter, Maggie Appleton, at one point in the not to distant past, worked with Elicit, a research paper summarizing AI startup with an office in Oakland, so kind of surprisingly local, but I digress.) 

It turns out that local-first development advocates for keeping the data for an app offline, i.e. keeping the data with the person who created or is using that data by default. But, what happens to collaboration? Well, the local, offline data is synched to the cloud when a connection is available allowing for collaboration while also creating a bit of a task to keep everything synched.

Another aside: reading this local-first article turned me on to why my Bluetooth keyboard locks up when on airplanes. Google Docs synchs on a keystroke by keystroke basis. I have discovered this before as proven by a dim memory that I used to keep a local, (there’s that word again), html page on my personal devices. That page contained only a html text input control. I could free-type into that control at breakneck speeds, and then cut and paste blocks of text at a time into more formal location such as Google Docs.

Point being, local-first is a good idea, an idea I have believed in for quite a while as proven by implementation history if not by my knowledge of what to call it. I do love what its’s called though.

I’m slowly but surely working though what local-first looks like with respect to our QSO mapping apps. Here are some thoughts

• F2 data from ionosondes (probably good since it’s for a specific date, time, and location, and caching it at least momentarily will speed up our QSO mapping apps.)
• Elevation profiles (doesn’t seem useful yet since each QSO path is pretty unique)
• QSO physical addresses and locations (reduces geocoding calls and QRZ lookup calls)

Also of Interest: