Software is equal parts fun and enfuriating. I wrote my first programs in BASIC back in eighth grade on the Apple IIe at school, and an TRS-80 Color Computer 2 at home. Things were simple back then, and it was possible for a young child to hold a decent model of a programming stack in their head. Things are much more complicated these days. What wasn't fun back then was finding information on how to use the tools in front of you. The amount of information available to folks these days is just overwhelming.

In college I learned C and Java as seperate class courses taken on my own initiative. This was a great introduction to low level programming, along with verbose Object Oriented programming. I never really enjoyed to slow edit and compile process of the two languages. Later I learned Python, and it's accessibility and immediate feedback was great. I was hooked and used it to rapidly prototype.

After ten or so years of using C and Python mostly, I got tired of the conflict of structured programming, imperative programming, OO and functional programming styles. Since Python allows for some semblance of these styles of programming, many teams that I worked wih fought over what style was more elegant, or right for a project. This felt disturbing, so I looked for a more opinionated language.

Around 2015, I started dabbling with the LISP family of languages, taking on Emacs as my editor of choice, created mini projects in Common Lisp, elisp, scheme and finally Clojure. While I was wary of the JVM and javascript, which Clojure(script) is hosted on, I loved the opinionated functional programming style that Clojure uses. I was hooked, and it's been my preference ever since. uLisp is a nice addition for microcontrollers that need to be talked to and updated in a live manner.

Warren

One of my first play projects to learn Clojurescript was a maze game. The idea is that you are a mouse, rescuing rabbits that are being hunted by a weasel in their warren, which is a vast algorithmically drawn maze. As you go along, you find rabbits, which give you the ability to dig through walls, and carrots which you use to feed the rabbits and keep them from running away. You can also run into the weasel, which will kill you, ending the game. I never drew out any assets, so the mouse, rabbits, carrots and weasel are just svg circles. I should revisit and polish it up a bit. You can play it here, or check out the Github repo.

Scratch

Scratch is the working title for an application that I've been building in Clojurescript using the Secure Scuttlebutt p2p protocol. The name will likely change with time, as I don't want to conflict with the existing MIT visual programming language Scratch. The application defies my abilities to put into a simple phrase, or even elevator pitch. So here is a semi long form explanation, which hopefully will result in something more concise over time.

The tool will on the outset be familiar to those that are familiar with Inventory/Resource Management systems (REA, ERP, etc.), the key difference is that I'd like to make a decentralized application where every individual or household could participate, without their information being reliant upon any one companies servers or infrastructure. The tool is meant to give each user sovereignty over their data, and usage of the platform. It's my hope that this will reduce the social construction of needs, and allow individuals the tools to build some self autonomy, while still nurturing interdependence and strengthen our ties to our communities. As opposed to being reliant on corporations and institution with incentives to promote artificial needs, which create dependence on institutions alone. Each individual has the capability to create, maintain, heal, care and perform a variety of essential roles for ourselves and others. Yet we've become blind to these capabilities, making ourselves reliant on the professional classes and industrial institutions. As a decentralized tool, this lack of reliance allows anyone access to the tool regardless of their political or economic standing, or even access to the greater Internet, and it allows them to participate in the economy along with any other person or group that wants to offer up their goods and services. To do so requires the network effects of every individual having access to such tools, and having the tool be simple enough that anyone can be productive who is mildly familiar with a computer.

Now that I've shared an overarching goal, let me step back and describe the tool itself as simply as possible.

So I'm going to posit that everyone is familiar with the concept of a Recipe. A recipe being a description of all the tasks needed to make something, and the ingredients and equipment one needs to accomplish said tasks. I'll start here as it's important to start with the familiar and build upon that. The concept of a recipe is simple, but it's fundamentally rich in it's uses in other coordination tasks and accounting processes. So much so that there are new areas of describing Physics (see Constructor Theory) based upon this simple model of information. I'll write more on this later, I hope.

A recipe contains an Ingredient list. This is a list of all of the items that you'll use and transform into the final product. This ingredient list can be easily pulled out of a recipe and transformed into a shopping list. And if you know what you already have at home, on your shelves, you can remove these items and only purchase the items that you need.

Keeping track of what you have in your home, or other location is called Inventory Management. Instead of looking at your shelves every time you need to decide if you need to purchase something, one can simply have a computer keep track of these numbers, using the quantities of specified in the recipes you make to subtract out items each time you follow the recipe. This theoretical quantity on hand (QOH) comes from taking what you have, entering it when you restock your pantry, and allowing the system to keep track of what is removed as you make recipes. If you schedule out your weeks meals or production, then they system can even predict future usage, and track what is used throughout, or help you make a more thorough shopping list for the week/month/year ahead.

Now these numbers are theoretical, so every now and then you'd want to make a physical count and bring the numbers back in line, just in case something spoiled, or was misplaced.

You inventory falls under the larger category of your resources. Your resources also include time, energy and money. Money is generally expected to be traded for other resources, it's just a placeholder for these goods, so I'll leave that alone for now. Time and energy are often neglected in most recipes, but are sometimes called out when they are important. For example a recipe may tell you how long and what temperature a cake needs to cook for in the oven. This specifies the time needed, and essentially the energy embodied into the cake through the cooking process. Energy being power x time, and the setting of an equipment determines how much power is consumed when running that equipment. Anyways, the amount of energy used to make an item is an advanced accounting technique that most disregard, but one can imagine that as time goes by, we as a society may become more critical of these aspects, as one should be when running a business or household.

What's more, if you don't have a good supplier of any one item, but you have a recipe for creating that item, then you are still able to reproduce the original recipe, you just have to obtain the ingredients for producing the item that you can't purchase, and follow the steps to reproduce it. This is essential for bootstrapping a supply chain when in areas where these don't already exist.

Recipes also contain a list of equipment used. If you have two recipes that both use the oven, at different temperatures, then you know that you cannot do them at the same time. But likewise if you and another household member both want to bake something, and the recipes call for the same temperature, then all you need to determine is whether or not both dishes will fit in your oven at the same time. Interesting, this could make scheduling the use of the kitchen or other parts of a location easier.

Once again, if you don't have access to a piece of equipment, but you have a recipe for producing it, then with some added effort one can find a way to creating the equipment from available resources.

If it's not already clear by now, the product of a recipe is an item that can be used in other recipes, by you or others. This means that it is also a product that could be exchanged in a marketplace, for other goods and services, including money. The product of a recipe is usually the same as the name of a recipe, like Chocolate Chip Cookies, Grandma's Lasagna, or AAA batteries. You may be thinking that last one is strange, as you shouldn't be eating AAA batteries, but the point is that a recipe need not result in food. It can also produce other physical goods like hammers or laptops (with a sufficiently complex recipe).

Eventually one would want to account for inputs and outputs of a process:

Energy + Equipment and their settings + Human Labor + Ingredients --> Products + Waste (energy and physical waste streams)

Which leads us to the idea of scheduling. A recipe contains a list of tasks that need to be done. Some of these tasks need to be done in order, the product of one task feeds into the next task. Sometimes tasks can be done concurrently, one person can make the sauce, while another person makes the dough. Or you can make the sauce weeks ahead of time and store it in the freezer to be used at will.

The final product is usually the title of the recipe, like Chocolate Chip Cookies, Grandma's Spaghetti, or AAA battery. This product is something that could be used as an ingredient in another recipe, or as an inventory item that you want to keep track of. When a recipe is applied, your Inventory is adjusted to show this. New items are created, and the ingredients used are depleted. If the item is something you want to sell in the Marketplace, then the available quantity to be sold should also be adjusted, allowing others to know that they are available in stock.

A peer to peer Marketplace of goods and services is an important part of a functioning society. We need an easy means of coordinating with others that doesn't involve a thrid party skimming profits off the top of our transactions, and using their own algorithms to control whose products and services are seen. Instead each individual gets to decide what manufacturers they follow, and have a direct feedback loop. A consumer is given the ability to express their needs and wants (for product variations that concern them) as well as give feedback that can be viewed by other consumers. As purchases are verifiable the feedback that a consumer makes can be linked to an actual purchase, allowing for other consumers to verify that they're able to review the product, and see if any updates to the manufacturers process (recipe!) has been made since then to remedy the issue. Whats more, each manufacturer now has a better idea of why folks are or are not purchasing from them, and what changes are important to their customers.

From experience, the hardest part of hiring a person or group for a service (a carpenter, massage therapy, dog walker, baby sitter, etc.), is vetting whether or not they are reliable and capaple of doing the job. With a peer to peer feedback loop, one can see the recommendations of people within your network that have verified transactions with that individual. Fake reviews are unlikely because you can verify that the feedback are from feeds that you follow, or have available from friends. This is the opposite of most existing marketplaces, where the majority of feedback is given by fake accounts set up by the company themselves or third party influencers.

An economy relies upon the flow of value, be it resources or services. When corporations control the marketplaces where Gigs and Products are found and engaged, then there is an economic insentive to control how these are shown, and to skim a percentage of the profits on each transaction. This is an important place for peer to peer (p2p), or perhaps we should say Peer for Peer (P4P) technologies to step in. When each individual can communicate freely to other peers on their network without an intermediary, they are allowed to control how their search results function, who has access to their information, and how their information is presented to other peers. This makes the marketplace more informative to each individual, whether they are acting as a producer, or as a consumer of good and services.

Once again the recipe plays a crucial role Scratch's marketplace. A product is linked to it's recipe at the time of production. Therefore if a recipe changes over time, a consumer knows what ingredients went into their product when they purchased it. They can track the providense of the items that went into their product. Lot tracking, or the ability to track a particular production lot, in case there is a product recall becomes easy for all consumers, as it's visible in the production logs stored in each producers public ledger (more on this later). A consumer can view these ledger details and see the source of each stage of production, allowing them to make informed decisions who they are supporting, how much embodied energy went into the product. Products made from local items becomes more apparent. Businesses that support their workers and do not rely on invisible labor. Stark mismatches of profit sharing are made apparent.

Discovery of desired products becomes a more intimate search, where one can search for products by their specification. Imagine being able to seach for items by their ingredients. One could purchase a laptop that had only uses open hardware, or conflict free electronic components. Most wouldn't think to check for these components, but those that care will scrutinize a Bill of Materials (BOM) to great degree. The BOM is the ingredients list of a recipe, and thus consumer groups can creat white lists of products that follow their concerns. These lists can be made available to others that don't have the resources to scrutinize a product to such depths.


SSB emacs client

Github Repo The Secure Scuttlebutt community needs an emacs client. So I started one, figured out how to interact with the Scuttlebot server using elisp, sending and recieving messages. I got bogged down, mostly with how to create a effective database using buffers for caching user profiles, and how I should present the interface. This needs to be revisited.

Powerpallet Firmware

KS Powerpallet Github Repo The Powerpallet is a 10kW and 20kW generator that runs off of waste woody biomass (woodchips, walnut shells, corn cobs, etc.) that fit on a 4'x4' pallet so that it can be shipped to the fuel source.

Powertainer Firmware

KS Powertainer Github Repo Similar to the Powerpallet, except inside of a 20' shipping container and outputting 150kW. As a larger version it also had the capability of drying biomass in its hopper, with airlocks so that the hopper could be open to the air, also a heated auger tube that allowed for further moisture removal before supplying the fuel to the reactor chamber. The generator for our firs powertainer was a Cumins Turbodiesel, allowing for the generator to run off of diesel when woody biomass is not present, or not ready for consumption. Controlling the fuel usage is done over Canbus, J1939 was a fun experience.